Subject: Re: [siprec] SRS-initiated INVITE

From: "Henry Lum" <[email-masked]>
Date: Tue, 6 Sep 2011 12:51:53 -0700

This also sounds like distributing the policy server from the SRS to the
SRC to choose which calls to record. To me this is more like a specific
solution than a generic one. 

If we can only agree on only supporting the basic mechanics for
SRS-initiated INVITEs, I am not sure how much interoperability we can
get for this mechanism among the SRC and SRS, then would there much
value in supporting this call flow at all?

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Saturday, August 27, 2011 9:55 AM
To: Charles Eckel (eckelcu)
Cc: [email-masked]
Subject: Re: [siprec] SRS-initiated INVITE

On 8/26/11 5:16 PM, Charles Eckel (eckelcu) wrote:
>> -----Original Message-----
>> From: Elwell, John [mailto:[email-masked]]
>> Sent: Thursday, August 25, 2011 12:50 AM
>> To: Charles Eckel (eckelcu); Paul Kyzivat; [email-masked]
>> Subject: RE: [siprec] SRS-initiated INVITE
>>
>> 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?
>
> 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.

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

> 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.
>>
>> John (as individual)
>>
>>
>>
>>> -----Original Message-----
>>> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
>>> Sent: 24 August 2011 21:29
>>> To: Elwell, John; Paul Kyzivat; [email-masked]
>>> Subject: RE: [siprec] SRS-initiated INVITE
>>>
>>> Please see inline.
>>>
>>>> -----Original Message-----
>>>> From: Elwell, John [mailto:[email-masked]]
>>>> Sent: Wednesday, August 24, 2011 12:49 AM
>>>> To: Charles Eckel (eckelcu); Paul Kyzivat; [email-masked]
>>>> Subject: RE: [siprec] SRS-initiated INVITE
>>>>
>>>> Charles,,
>>>>
>>>>> -----Original Message-----
>>>>> 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,
>>>>>
>>>>> 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.
>>>> [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
>>>
>>>
>>>>
>>>>> I'd like to hear what others think about making your proposal
> more
>>>>> generic to accommodate that as well.
>>>>>
>>>>> Cheers,
>>>>> Charles
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked]
>>> [mailto:[email-masked]] On
>>>>> Behalf Of Elwell, John
>>>>>> Sent: Tuesday, August 23, 2011 12:51 PM
>>>>>> To: Paul Kyzivat; [email-masked]
>>>>>> Subject: Re: [siprec] SRS-initiated INVITE
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----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
>>>>>>>
>>>>>>> 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.
>>>>>> [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
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 	Thanks,
>>>>>>> 	Paul
>>>>>>>
>>>>>>> On 8/23/11 7:03 AM, Elwell, John wrote:
>>>>>>>> (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.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> siprec mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>
>>>
>

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.