Subject: [siprec] SRS-initiated INVITE

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Aug 2011 13:03:55 +0200

(as individual)

During the IETF 81 session, Andy and I agreed to propose some text for the protocol document to cover the case of SRS-initiated INVITE in more detail. This is our proposal:

=======================
The following is a sample call flow that shows the SRS establishing a recording session towards the SRC.  The most likely application of this is for persistent recording, where the SRS does not need to have prior knowledge of particular CSs that need to be recorded but simply requires to record all CSs with certain characteristics (e.g., involving a particular user). Also it is more likely to arise when the SRC is located at a B2BUA, rather than at a UA, and therefore the SRS does not need to identify a particular UA as the target of the INVITE request.

   UA A           SRC                    UA B                    SRS
    |              | (1) RS INVITE without SDP                    |
    |              |<---------------------------------------------|
    |              |    (2) OK with SDP                           |
    |              |--------------------------------------------->|
    |              |    (3) ACK with SDP                          |
    |              |<---------------------------------------------|
    |(4)CS INVITE  |                       |                      |
    |------------->|                       |                      |
    |              |(5)CS INVITE           |                      |
    |              |---------------------->|                      |
    |              |               (6)OK   |                      |
    |              |<----------------------|                      |
    |        (7)OK |                       |                      |
    |<-------------|                       |                      |
    |              |(8)RS UPDATE with SDP and metadata            |
    |              |--------------------------------------------->|
    |              |     (9)OK with SDP                           |
    |              |<---------------------------------------------|
    |(10)CS RTP    |                       |                      |
    |=============>|======================>|                      |
    |<=============|<======================|                      |
    |              |(11)RS RTP             |                      |
    |              |=============================================>|
    |              |=============================================>|
    |(12)CS BYE    |                       |                      |
    |------------->|                       |                      |
    |              |(13)CS BYE             |                      |
    |              |---------------------->|                      |
    |              |    (14) CS OK         |                      |
    |              |<----------------------|                      |
    |       (15)OK |                       |                      |
    |<-------------|                       |                      |
    |              |(16)UPDATE with SDP and metadata              |                      |
    |              |--------------------------------------------->|
    |              |    (17)OK with SDP                           |
    |              |<---------------------------------------------|
    |              |                       |                      |

            Figure 2: Persistent Recording Call Flow, RS Established by SRS

The initial INVITE request for establishing the RS (1) has a Request-URI that identifies the SRC and instructs the SRC what to record (e.g., all CSs involving a particular user). The SDP offer from the SRC (2) might have no media or might establish inactive media in anticipation of future requirements.

The first UPDATE request (8) occurs on establishment of a recordable CS. It includes metadata describing the CS and, if necessary, includes a new SDP offer to establish or modify media streams needed for recording that CS.

The second UPDATE request (16) occurs on termination of a recordable CS. It includes metadata indicating termination of the CS and might include a new SDP offer changing media streams that are no longer wanted to disabled or inactive. Because this is persistent recording, the RS would typically remain in place awaiting other recordable CSs.
=================================

Other places in the document will also need some changes, but I would like first to see if we can get agreement on the general principle and on inclusion of this scenario in section 4.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Aug 2011 10:55:17 -0400

IIUC, the essential feature of this flow is that the R-URI from SRS to 
SRC in some way encodes the criteria for what calls the SRC should record.

I guess you are assuming that the manner of that encoding is 
unstandardized, and hence requires a side agreement between the SRC and 
SRS. Or else it requires that the SRS be configurable to establish an RS 
to an arbitrary URI, and that the administrator is aware of the specific 
URI encoding required by the SRC to achieve the intended effect.

While that is a bit of a stretch, I don't have any particular problem 
with including such an example. But this doesn't ensure that any SRC 
actually has this capability.

	Thanks,
	Paul

On 8/23/11 7:03 AM, Elwell, John wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Aug 2011 21:51:09 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 23 August 2011 15:55
> To: [email-masked]
> Subject: Re: [siprec] SRS-initiated INVITE
> 
[JRE] Quite so. But if the SRC has a URI that can be used and the SRS is configured with that URI, it should work.

John

> > During the IETF 81 session, Andy and I agreed to propose 
> some text for the protocol document to cover the case of 
> SRS-initiated INVITE in more detail. This is our proposal:
> >
> > =======================
> > The following is a sample call flow that shows the SRS 
> establishing a recording session towards the SRC.  The most 
> likely application of this is for persistent recording, where 
> the SRS does not need to have prior knowledge of particular 
> CSs that need to be recorded but simply requires to record 
> all CSs with certain characteristics (e.g., involving a 
> particular user). Also it is more likely to arise when the 
> SRC is located at a B2BUA, rather than at a UA, and therefore 
> the SRS does not need to identify a particular UA as the 
> target of the INVITE request.
> >
> >
> >     UA A           SRC                    UA B              
>       SRS
> > The initial INVITE request for establishing the RS (1) has 
> a Request-URI that identifies the SRC and instructs the SRC 
> what to record (e.g., all CSs involving a particular user). 
> The SDP offer from the SRC (2) might have no media or might 
> establish inactive media in anticipation of future requirements.
> >
> > The first UPDATE request (8) occurs on establishment of a 
> recordable CS. It includes metadata describing the CS and, if 
> necessary, includes a new SDP offer to establish or modify 
> media streams needed for recording that CS.
> >
> > The second UPDATE request (16) occurs on termination of a 
> recordable CS. It includes metadata indicating termination of 
> the CS and might include a new SDP offer changing media 
> streams that are no longer wanted to disabled or inactive. 
> Because this is persistent recording, the RS would typically 
> remain in place awaiting other recordable CSs.
> > Other places in the document will also need some changes, 
> but I would like first to see if we can get agreement on the 
> general principle and on inclusion of this scenario in section 4.
> >
> > John
> >
> >
> > John Elwell

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 23 Aug 2011 14:05:42 -0700

Hi John,

I was envisioning a use case in which the INVITE from the SRS to the SRC
contains a Request-URI for a call that is to be joined for the purpose
of recording (e.g. a conference call). The SRS may include SDP as well.
The SRC could initiate the CS INVITE in this case. 
I'd like to hear what others think about making your proposal more
generic to accommodate that as well.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Tuesday, August 23, 2011 12:51 PM
> To: Paul Kyzivat; [email-masked]
> [JRE] Quite so. But if the SRC has a URI that can be used and the SRS
is configured with that URI, it
> should work.
> > >      |
|<---------------------------------------------|
> > >      |              |    (2) OK with SDP
|
> > >      |
|--------------------------------------------->|
> > >      |              |    (3) ACK with SDP
|
> > >      |
|<---------------------------------------------|
> > >      |(4)CS INVITE  |                       |
|
> > >      |------------->|                       |
|
> > >      |              |(5)CS INVITE           |
|
> > >      |              |               (6)OK   |
|
> > >      |        (7)OK |                       |
|
> > >      |<-------------|                       |
|
> > >      |
|--------------------------------------------->|
> > >      |              |     (9)OK with SDP
|
> > >      |
|<---------------------------------------------|
> > >      |(10)CS RTP    |                       |
|
> > >      |              |(11)RS RTP             |
|
> > >      |
|=============================================>|
> > >      |
|=============================================>|
> > >      |(12)CS BYE    |                       |
|
> > >      |------------->|                       |
|
> > >      |              |(13)CS BYE             |
|
> > >      |              |    (14) CS OK         |
|
> > >      |       (15)OK |                       |
|
> > >      |<-------------|                       |
|
> > >      |
|--------------------------------------------->|
> > >      |              |    (17)OK with SDP
|
> > >      |
|<---------------------------------------------|
> > >      |              |                       |
|

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Aug 2011 09:48:39 +0200

Charles,, 

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 23 August 2011 22:06
> To: Elwell, John; Paul Kyzivat; [email-masked]
> Subject: RE: [siprec] SRS-initiated INVITE
> 
> Hi John,
> 
[JRE] So this would be a different use case, for recording only a specific call. Did you envisage using the Join or Target-Dialog header field to identify the CS dialog?

> The SRC could initiate the CS INVITE in this case. 
[JRE] Not sure I understand this. I had assumed, from what you said at the start, that the purpose would be to record a CS already in progress, so the initial CS INVITE would be history. I can't imagine why the SRS would want the SRC to establish a CS for the purpose of recording.

John (as individual)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 24 Aug 2011 13:29:19 -0700

Please see inline.

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, August 24, 2011 12:49 AM
> To: Charles Eckel (eckelcu); Paul Kyzivat; [email-masked]
> [JRE] So this would be a different use case, for recording only a
specific call. Did you envisage
> using the Join or Target-Dialog header field to identify the CS
dialog?
> > The SRC could initiate the CS INVITE in this case.

I do not think either of those is really appropriate for this.

> [JRE] Not sure I understand this. I had assumed, from what you said at
the start, that the purpose
> would be to record a CS already in progress, so the initial CS INVITE
would be history. I can't
> imagine why the SRS would want the SRC to establish a CS for the
purpose of recording.
> John (as individual)

Take the case of a conference call is that is not being recorded. At
some point in time, someone decides they want to start recording the
conference. This could be done by a SIP UA that is participating in the
conference, or by the focus of the conference, acting as or interacting
with the SRC. This is already covered by our use cases. But it could
also be accomplished using some mechanism outside the scope of the
SIPREC that asks the SRS to record the conference. While the trigger is
outside the scope of SIPREC, the way the SRS initiates the RS is what I
think could be considered in scope for SIPREC.

Cheers,
Charles

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Aug 2011 09:50:08 +0200

Charles,

But I still don't understand your earlier statement "The SRC could initiate the CS INVITE in this case."

I agree that an SRS could be asked, but some means outside SIPREC, to establish recording for a conference, and given some sort of reference for the conference, could initiate the INVITE to the SRC (collocated with the conference focus).

The question is how to get the INVITE from SRS to SRC to identify the conference to be recorded. Should that just be implicit in the Request-URI (the way Request-URIs are constructed would be outside the scope of SIPREC), or do we need something explicit? 

I think I agree that neither Join nor Target-Dialog header fields have quite the right semantics for this, so if we need an explicit means of identifying the existing conference we would have to invent a new mechanism.

John (as individual)

> Sent: 24 August 2011 21:29
> [mailto:[email-masked]] On
> > > Behalf Of Elwell, John

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 26 Aug 2011 14:16:10 -0700

> Sent: Thursday, August 25, 2011 12:50 AM
> But I still don't understand your earlier statement "The SRC could
initiate the CS INVITE in this
> case."
> 
> I agree that an SRS could be asked, but some means outside SIPREC, to
establish recording for a
> conference, and given some sort of reference for the conference, could
initiate the INVITE to the SRC
> (collocated with the conference focus).
> 
> The question is how to get the INVITE from SRS to SRC to identify the
conference to be recorded.
> Should that just be implicit in the Request-URI (the way Request-URIs
are constructed would be outside
> the scope of SIPREC), or do we need something explicit?

The Request URI could be used, but if others agree this is a worthwhile
use case, I think it would be more appropriate to define something
explicit. Taking this to the extreme, the explicit information could be
in the form of metadata from the SRS to the SRC, providing as much
information about the intended recording as the SRS knows.

Cheers,
Charles  
 
> I think I agree that neither Join nor Target-Dialog header fields have
quite the right semantics for
> this, so if we need an explicit means of identifying the existing
conference we would have to invent a
> new mechanism.
> > > > > > While that is a bit of a stretch, I don't have any
particular
> > > > problem
> > > > > > general principle and on inclusion of this scenario in
section
> > 4.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Aug 2011 09:55:29 -0400

> information about the intended recording as the SRS knows.

ISTM that this is a slippery slope - there are many possibilities for 
how one might want to specify what to record. I can foresee desires much 
like what came out in Martini for bulk registrations.

I would be happy to leave this out of scope for now.

	Thanks,
	Paul