Subject: Re: [siprec] Transport of snapshot request

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Dec 2011 15:28:53 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Dec 2011 02:27:24 +0800

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

I have a slightly different spin on this:

Send the snapshot is a different transaction from the snapshot request.
That allows the SRC to be in control of the o/a machinery. It also 
decouples the preparation of the snapshot from all the transaction 
timers - which is good from a layering perspective.

If we do that, then the sending of a snapshot isn't very different than 
sending an update - it just contains elements that would otherwise be 
skipped as redundant. And so it should be able to go into any signaling 
that a comparable update could go in.

We can discuss what sort of message the snapshot request should go in. 
The likely alternatives are an offerless re-INVITE or an offerless 
UPDATE. The UPDATE would be more optimal because then there will be no 
o/a at all with it. *If* the SRS has somehow forgotten the SDP, then an 
offerless re-INVITE would bring an offer with whatever the SRC thinks 
should be current, without metadata.

So then we get to the question of whether snapshots or updates can 
travel in UPDATE or if they must use INVITE. IMO both should be allowed, 
for two reasons:
- there can be common cases where you want to update metadata
   but there is no need to change the SDP. UPDATE is the easy way
   to accomplish this. It might not be the common choice for
   snapshots, but its an independent decision.

- the SRC "application" sitting on top of the stack may not have
   complete control over the sip stack. The stack will be dealing
   with the o/a behavior, and the application will be dealing with
   the metadata. It may not be so easy to control the decision of
   whether to use INVITE or UPDATE.

IMO the idea of requiring that things be done in one way, when the basic 
mechanisms allow multiple ways, is a dubious economy and a slippery 
slope. Its a dubious economy because it may require extra code to 
prevent alternatives from being used. And its a slippery slope because 
there are lots of other optional ways of doing things that could 
conceivably be proposed as "simplifications". E.g. ordering headers in a 
particular way, not using abbreviations for header names.

(Note it may be that a re-INVITE carrying metadata may end up also 
requiring an UPDATE. This would occur if preconditions are used in order 
to set up QoS on the media lines. I bring this up as an example of why 
the stack should be allowed to do what it needs to do.)

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 1 Dec 2011 10:56:36 -0800

Hi Paul,

If we go with this approach, then in the case of the SRS sending an
offer-less INVITE requesting a snapshot, it would also be valid for the
SRC to respond with an offer + metadata snapshot, correct? 

Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
> Sent: Thursday, December 01, 2011 10:27 AM
> To: Hadriel Kaplan
> Cc: <[email-masked]>
> > 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?
> >> 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
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Dec 2011 03:44:59 +0800

> SRC to respond with an offer + metadata snapshot, correct?

We should discuss this.
IMO we could allow (but not require) this.
Or we could forbid it.

I don't have a strong opinion either way.

	Thanks,
	Paul

>> Cc:<[email-masked]>
> Behalf
> Behalf

---

From: "John Elwell" <[email-masked]>
Date: Fri, 2 Dec 2011 17:52:15 -0000

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