Subject: Re: [siprec] Transport of snapshot request

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 19 Jan 2012 19:52:19 +0100

Hi All,

So let me try to summarize where we are on transporting the snapshot request and the resulting metadata snapshot and give my own view on this.

It seems that at least a couple of people (Paul & John) proposing that we need to keep the snapshot request and the resulting snapshot separated in different transactions and I also think that would be a good idea. 

We should however make sure we support the case when there is no metadata provided via an XML body in which case I can see that a reINVITE without SDP is effectively a snapshot request and must be supported but that is just basic SIP and maybe we just don't call this a snapshot request at all.

Assuming we agree on the different transaction model then I see no benefit to including the snapshot request in a reINVITE in fact it would be quite messy to do so given that the response would have to include an SDP offer and so would most likely the resulting snapshot itself. This would be a mess so let's mandate that the snapshot request is made in an UPDATE request.

The resulting snapshot which includes an SDP offer plus metadata could then be included in either a reINVITE or an UPDATE. I am not sure there is much benefit in mandating that this is always in an UPDATE because an SRS is almost certainly going to support sending a reINVITE with metadata anyway but we could.

So in summary my thinking is:

1. An explicit snapshot request MUST be in an UPDATE without SDP.

2. The snaphot MUST be in either an UPDATE or a reINVITE both of which MUST have SDP. I would be ok with mandating it be only in an UPDATE but I think it is not necessary.

3. The SRS MAY generate a reINVITE without SDP but this MUST not include a snapshot request.

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Elwell
Sent: 02 December 2011 17:52
To: Hadriel Kaplan; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Transport of snapshot request

I am happy with the notion of keeping options to a minimum. However, I 
prefer to decouple the snapshot request and the snapshot into different 
transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself can 
then be done the same way as any metadata update (except we might choose to 
mandate that a snapshot be accompanied by an SDP offer, even though a 
regular update might be with or without an SDP offer). So a simple approach 
might be:
- UPDATE request (without SDP offer) for snapshot request;
- UPDATE request (with/without SDP offer) for metadata update or snapshot.

John

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 01, 2011 3:28 PM
Subject: Re: [siprec] Transport of snapshot request

>
> The reason to "exclude" anything is to improve interoperability.  I've 
> seen countless issues with implementations not expecting another device to 
> do something causing problems when the other device does it, and 
> definitely for re-INVITEs and UPDATE scenarios.
>
> So unless there's some pressing need to support multiple possible 
> scenarios, I don't see any reason not to just pick one and only one way to 
> do something - it will improve interop to do so.
>
> If we think a snapshot request from the SRS will usually need SDP from the 
> SRC, and we don't think the SRS can provide an SDP offer in the snapshot 
> request - and I don't think the SRS can in fact always provide an SDP 
> offer in it because the whole reason it's asking for a snapshot is it 
> forgot stuff - then we should pick a way to do it without requiring the 
> SRS to send an SDP offer.
>
> Ergo, I vote we pick the snapshot request mechanism be an offerless 
> re-INVITE, period.  That will work in every scenario anyone has ever 
> mentioned, afaict, and thus there's no reason to do anything else.  No?
>
> -hadriel
>
>
> On Nov 30, 2011, at 9:46 PM, Paul Kyzivat wrote:
>
>> On 12/1/11 8:47 AM, Ravindran, Parthasarathi wrote:
>>> Hi all,
>>>
>>> I agree with UPDATE without SDP based snapshot request in case there is
>>> an agreement that SRS will never generate offer as there is no 
>>> possibility
>>> of offer-answer race condition based on snapshot request mechanism. So,
>>> I'm interested in hearing everybody opinion on "no offer from SRS" 
>>> stance
>>> For SIPREC.
>>
>> I don't see how it would ever make sense for the SRS to make an offer to 
>> the SRC, so I'm fine with declaring that invalid SRS behavior.
>>
>> As far as a snapshot without SDP, I agree it is unlikely that a snapshot 
>> would not require an SDP update. But I see no reason to exclude it in the 
>> unlikely event that a case comes up when it is valid.
>>
>> This would be a problem if a snapshot request was in an UPDATE without 
>> SDP and the snapshot was required to be in the reply. But as long as the 
>> SRC can wait and send the snapshot in a request it initiates, it can make 
>> any offer it needs to, or potentially it could do the snapshot in an 
>> UPDATE without SDP if no SDP was needed.
>>
>> Thanks,
>> Paul
>>
>>> Brad/John,
>>>
>>> Please read inline.
>>>
>>> Thanks
>>> Partha
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf
>>>> Of Brad Winslow
>>>> Sent: Wednesday, November 23, 2011 10:23 PM
>>>> To: [email-masked]
>>>> Subject: Re: [siprec] Transport of snapshot request
>>>>
>>>> Hi Folks,
>>>>
>>>> In the situation where the SRS needs a metadata update, it most likely
>>>> will need an SDP update, as there is no guarantee the metadata-only
>>>> update would be consistent with the current SDP label attributes of the
>>>> SRS, aren't we asking for trouble if we allow a metadata-only update?
>>> <partha>  Snapshot request UPDATE without SDP from SRS is used to 
>>> trigger
>>> Metadata request in SRC using RE-INVITE or UPDATE method
>>> </partha>
>>>
>>>> If we decide on a full update, metadata + SDP, should we settle on
>>>> UPDATE or INVITE to transmit the update from SRC to SRS?
>>> <partha>  We have common understanding here</partha>
>>>
>>>>
>>>> As an aside, there is an expectation that the SRC behaves as a SIP UA,
>>>> in this case it should be able to respond to an offer-less re-INVITE
>>>> from the SRS and provide metadata and SDP in the response.
>>>>
>>> <partha>  offerless Re-INVITE with 100 + 200 response is currently 
>>> considered
>>> as alternative Proposal to UPDATE without SDP snapshot request</partha>
>>>
>>>> Finally, if the SRS receives an INVITE for a new recording session,
>>>> should we have an error code response which indicates the SRS is not
>>>> interested in recording the session, not as a failure status, just as a
>>>> status to terminate the recording.
>>>
>>> <partha>  It will be negative response in case INVITE with 
>>> require:siprec is
>>> not accepted using 200 OK right? Do we need the new server negative 5xx
>>> response code for this policy decision?</partha>
>>>
>>> This presupposes the SRS may make
>>>> policy decisions for recording.
>>>>
>>>> Thanks in advance for your thoughts,
>>>> Brad
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf
>>>> Of Leon Portman
>>>> Sent: Thursday, November 17, 2011 4:47 AM
>>>> To: John Elwell
>>>> Cc: [email-masked]
>>>> Subject: Re: [siprec] Transport of snapshot request
>>>>
>>>> John, Nice to have you back on the list.
>>>>
>>>> Actually discussion during IETF meeting was started to converge to
>>>> similar as you describe below.
>>>>
>>>> Regards
>>>>
>>>> Leon
>>>>
>>>> On Nov 17, 2011, at 5:15 PM, John Elwell wrote:
>>>>
>>>>> There has been a long thread discussing the SIP messages for snapshot
>>>> requests.
>>>>>
>>>>> First, I see no reason to tie the snapshot request and the metadata
>>>> transmission to the same transaction (request/response). If they are
>>>> tied together, this imposes unnecessary time and architectural
>>>> constraints on the SRC.
>>>
>>> <partha>  The model proposed is request/provisional response/response
>>> Wherein RE-INVITE/100/200 trying shall be used wherein there is no
>>> Immediate response to SRS.</partha>
>>>
>>> I much prefer an approach similar to the
>>>> subscribe/notify approach of RFC 3265 - use different transactions.
>>>
>>> <partha>  The downside of this approach is 4 SIP messages per every
>>> Service. I'm seeing the middle ground of offerless RE-INVITE with
>>> Provisional response (100) and final response wherein 3 messages are
>>> Involved but there is no extra offer/answer race condition from SRS.
>>>
>>> Having said that, in case it is confirmed that SRS will never offer
>>> Then I'm fine with UPDATE based snapshot request</partha>
>>>
>>>  I am
>>>> rather unsympathetic to allowing, as an option, metadata transmission 
>>>> in
>>>> a response. Apart from the timing and architectural concerns, there is
>>>> no means of responding to a response if anything is wrong. Keep it
>>>> simple, and allow metadata transmission only in requests, as in NOTIFY.
>>>>>
>>>>> Second, I think it is an SRC decision whether it needs a further
>>>> offer-answer exchange. When sending the request containing the 
>>>> metadata,
>>>> the SRC must ensure that any references to media description labels are
>>>> consistent with the last SDP sent by the SRC - if not, the SRC can
>>>> initiate a further offer-answer exchange at the same time as the
>>>> metadata transmission.
>>>>>
>>>>> Perhaps it is my imagination, but I thought we had on the table at one
>>>> time the notion of:
>>>>> - SRS sends snapshot request in an UPDATE request.
>>>>> - SRC sends medata in an UPDATE request (with offer if it needs to
>>>> change SDP, otherwise without).
>>>>>
>>>>> I have lost track of how we came to diverge from this simple model.
>>>>>
>>>>> John
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>> _______________________________________________
>> 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

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 20 Jan 2012 19:16:00 -0800

I agree on keeping the snapshot request and the snapshot as separate
transactions which is the main point of this issue. The resulting 3
items below to me are basically the mechanism of mandating the snapshot
request and snapshot as separate transactions, which I also agree is a
reasonable and simple mechanism.
 
Thanks
Henry

> Behalf Of Hutton, Andrew
> Sent: January-19-12 1:52 PM
> To: [email-masked]
> So let me try to summarize where we are on transporting the snapshot
> request and the resulting metadata snapshot and give my own view on
> this.
> 
> It seems that at least a couple of people (Paul & John) proposing that
> we need to keep the snapshot request and the resulting snapshot
> separated in different transactions and I also think that would be a
> good idea.
> 
> We should however make sure we support the case when there is no
> metadata provided via an XML body in which case I can see that a
> reINVITE without SDP is effectively a snapshot request and must be
> supported but that is just basic SIP and maybe we just don't call this
> a snapshot request at all.
> 
> Assuming we agree on the different transaction model then I see no
> benefit to including the snapshot request in a reINVITE in fact it
> would be quite messy to do so given that the response would have to
> include an SDP offer and so would most likely the resulting snapshot
> itself. This would be a mess so let's mandate that the snapshot
request
> is made in an UPDATE request.
> 
> The resulting snapshot which includes an SDP offer plus metadata could
> then be included in either a reINVITE or an UPDATE. I am not sure
there
> is much benefit in mandating that this is always in an UPDATE because
> an SRS is almost certainly going to support sending a reINVITE with
> metadata anyway but we could.
> 
> 2. The snaphot MUST be in either an UPDATE or a reINVITE both of which
> MUST have SDP. I would be ok with mandating it be only in an UPDATE
but
> I think it is not necessary.
> 
> Behalf Of John Elwell
> >>> of offer-answer race condition based on snapshot request
mechanism.
> So,
> >> SDP and the snapshot was required to be in the reply. But as long
as
> the
> >> SRC can wait and send the snapshot in a request it initiates, it
can
> make
> >>>> As an aside, there is an expectation that the SRC behaves as a
SIP
> UA,
> >>>> interested in recording the session, not as a failure status,
just
> as a
> >>> not accepted using 200 OK right? Do we need the new server
negative
> 5xx

-------------------------------------------------------------------------------------------------------------------
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.

---

From: Leon Portman <[email-masked]>
Date: Mon, 23 Jan 2012 11:21:47 +0200

+1 

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: Saturday, January 21, 2012 5:16 AM
To: Hutton, Andrew; [email-masked]
Subject: Re: [siprec] Transport of snapshot request

I agree on keeping the snapshot request and the snapshot as separate transactions which is the main point of this issue. The resulting 3 items below to me are basically the mechanism of mandating the snapshot request and snapshot as separate transactions, which I also agree is a reasonable and simple mechanism.
 
Thanks
Henry

request
there
but
> transactions (rather like SUBSCRIBE and NOTIFY). The snapshot itself 
> can then be done the same way as any metadata update (except we might 
> choose to mandate that a snapshot be accompanied by an SDP offer, even 
> though a regular update might be with or without an SDP offer). So a 
> simple approach might be:
> >>> possibility of offer-answer race condition based on snapshot 
> >>> request
mechanism.
as
can
> >>>> Behalf Of Brad Winslow
> >>> trigger Metadata request in SRC using RE-INVITE or UPDATE method 
> >>> </partha>
> >>>
SIP
> >>> considered as alternative Proposal to UPDATE without SDP snapshot
> request</partha>
> >>>
just
> >>> require:siprec is not accepted using 200 OK right? Do we need the 
> >>> new server
negative
> >>>> Thanks in advance for your thoughts, Brad
> >>>>
> >>>> Behalf Of Leon Portman
> >>>> metadata, the SRC must ensure that any references to media 
> >>>> description
> labels are

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 23 Jan 2012 09:34:19 +0000

Hi Andy,

I agree with your proposal as it is reduces the race condition introduced by UPDATE snapshot request. I guess that the following statement will clarify more on the snapshot requirement.

"SRS MAY generate a RE-INVITE with or without SDP but this MUST NOT include a snapshot request." 

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Leon Portman
>Sent: Monday, January 23, 2012 2:52 PM
>To: Henry Lum; Hutton, Andrew; [email-masked]
>------------------------------------------------------------------------
>-------------------------------------------
>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.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 23 Jan 2012 12:56:02 +0100

Hi Partha,

Great I also agree that your text is also makes the requirements very clear.

Regards
Andy

-----Original Message-----
From: Ravindran, Parthasarathi [mailto:[email-masked]]
Sent: 23 January 2012 09:34
To: Leon Portman; Henry Lum; Hutton, Andrew; [email-masked]
Subject: RE: [siprec] Transport of snapshot request

Hi Andy,

Thanks
Partha

>Of Henry Lum

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 23 Jan 2012 11:24:55 -0800

Works for me.

Charles

> Sent: Monday, January 23, 2012 3:56 AM
> To: Ravindran, Parthasarathi; Leon Portman; Henry Lum; [email-masked]
> I agree with your proposal as it is reduces the race condition
> introduced by UPDATE snapshot request. I guess that the following
> statement will clarify more on the snapshot requirement.
> 
> >> I am happy with the notion of keeping options to a minimum.
However,
> I
> >> > scenarios, I don't see any reason not to just pick one and only
> one
> >> way to
> >> > offer in it because the whole reason it's asking for a snapshot
is
> >it
> >> > forgot stuff - then we should pick a way to do it without
> requiring
> >> the
> >> > mentioned, afaict, and thus there's no reason to do anything
else.
> >> No?
> >> >> would not require an SDP update. But I see no reason to exclude
> it
> >> in the
> >> >> any offer it needs to, or potentially it could do the snapshot
in
> >an
> >> >>>> In the situation where the SRS needs a metadata update, it
most
> >> likely
> >> >>>> will need an SDP update, as there is no guarantee the
metadata-
> >> only
> >> >>>> update would be consistent with the current SDP label
> attributes
> >> of the
> >> >>>> If we decide on a full update, metadata + SDP, should we
settle
> >on
> >> >>>> should we have an error code response which indicates the SRS
> is
> >> not
> >> >>>> Actually discussion during IETF meeting was started to
converge
> >to
> >> >>>> transmission to the same transaction (request/response). If
> they
> >> are
> >> >>> Provisional response (100) and final response wherein 3
messages
> >> are
> >> >>>> no means of responding to a response if anything is wrong.
Keep
> >it
> >> >>>> simple, and allow metadata transmission only in requests, as
in
> >> NOTIFY.
> >> >>>>> Perhaps it is my imagination, but I thought we had on the
> table
> >> at one
> >> >>>> time the notion of:
> >> >>>>> - SRC sends medata in an UPDATE request (with offer if it
> needs
> >> to