Subject: Re: [Sipping] SDP Rollbackindraft-sawada-sipping-sip-offeranswer-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Feb 2007 08:39:01 -0500

Christer Holmberg (JO/LMF) wrote:
> Hi,
> 
> One approach would of course be to not allow reliable provisional
> responses for re-INVITEs in the first place.
> 
> But, then we MAY have a problem with preconditions - but not
> necessarily.
> 
> The SDP answerer could simply choose not to send 200 OK until he has
> reserved the needed resources. Ie he does not send any provisional
> responses.
> 
> The SDP offerer would then send a second re-INVITE/UPDATE when he has
> reserved the needed resources (unfortunatly he can't use the ACK to
> indicate it).

This would present some serious problems in the case of offerless 
reinvites. In that case, delaying the offer to the 200 means that the 
UAC has no way to reject the offer.

Nevertheless, restricting the offer/answer patterns that are allowed in 
reinvite (more restrictive than what is permitted in the initial invite) 
could be effective.

The question is whether it is a more attractive alternative than either 
of the others mentioned. To me it comes down to trading off simplicity, 
flexibility, and backward compatibility. I don't see simplicity or 
flexibility as being markedly different among these either. So it may be 
that this should be judged on the basis of backwards compatibility. But 
that may be hard to get good info on. Ideally we should take some sort 
of survey, but in the end I suppose that is roughly equivalent to voting.

	Paul

> Regards,
> 
> Christer
> 
>  
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email-masked]] 
>> Sent: 17. marraskuuta 2006 23:03
>> To: Sanjay Sinha (sanjsinh)
>> Cc: [email-masked]; [email-masked]; Siddhartha Bhakta
>> Subject: Re: [Sipping] SDP 
>> Rollbackindraft-sawada-sipping-sip-offeranswer-01.txt
>>
>> (To those who haven't been paying attention, this is about 
>> what to do about SDP when a reINVITE fails. RFC 3261, section 
>> 14.1, says that if a non-2xx final response is received the 
>> session parameters must remain unchanged, as if no reINVITE 
>> had been issued. Herein that is being described as "rollback" 
>> of the SDP.)
>>
>> There are several interesting questions relative to this topic:
>>
>> - are the existing RFCs clear about what should be done?
>>    (Do all informed and reasonable people agree what this is?)
>>
>> - what do currently deployed implementations do?
>>
>> - what is the *most reasonable* thing to do?
>>
>> There has been quite a bit of discussion in the past on this, 
>> though we could probably some more because I think only a few 
>> people participated.
>>
>> IMO the existing RFCs are *not* clear, because we are getting 
>> multiple interpretations that can be justified to some 
>> extent. The rollback rule only appears in 3261, and doesn't 
>> really address the additional issues raised by 3262, 3311, and 3312.
>>
>> There are also good arguments for either of two approaches 
>> being the most reasonable thing to do.
>>
>> The two competing interpretations are:
>>
>> 1) once an answer has been transmitted reliably it is committed and
>>     will not be rolled back, even if a reinvite fails.
>>
>> 2) an entire sequence of offers and answers (there could be many)
>>     that is initiated by a reinvite, is rolled back if the reinvite
>>     fails.
>>
>> Of these, (1) is somewhat easier to implement. It also 
>> eliminates some race conditions that seem unresolvable, 
>> though obscure, that can arise with (2). The downside is that 
>> when multiple offers and answers are used to resolve 
>> preconditions, and then the reinvite fails, you end up in an 
>> interim state with unresolved preconditions. The proper 
>> behavior in that state is not clear.
>>
>> With (2) the precondition problem goes away. A few ambiguous 
>> race conditions have been identified, but they are obscure 
>> cases that can probably be resolved by just just writing some 
>> best practices to avoid them. Its not entirely clear to me if 
>> this approach requires retention of any more state than (1), 
>> but if so it is only slightly more.
>>
>> It would be helpful if people that have opinions on this 
>> subject identify which approach they advocate and why. I'm 
>> not expecting to see a new approach different from either of 
>> the above, but if somebody has one, please spell out how it 
>> differs from these, and why it is better.
>>
>> 	Thanks,
>> 	Paul
>>
>> Sanjay Sinha (sanjsinh) wrote:
>>> SDP rollback applies only if previously there has been an 
>> offer-answer 
>>> exchange and an early dialog or a confirmed dialog has been 
>> established.
>>> In that case, if SDP in re-Invite/UPDATE is rejected, then session 
>>> continues with previously negotiated characteristics. This is 
>>> mentioned in RFC 3261. And this draft does mention that if offer in 
>>> Prack or in a sip response is rejected, then answerer has 
>> to send an 
>>> updated offer. So I am not sure how is the new proposal 
>> different than 
>>> what has been already stated.
>>>  
>>> Sanjay
>>>
>>>     
>> --------------------------------------------------------------
>> ----------
>>>     *From:* Siddhartha Bhakta
>>>     [mailto:[email-masked]]
>>>     *Sent:* Tuesday, November 14, 2006 12:37 PM
>>>     *To:* [email-masked]; Paul Kyzivat (pkyzivat)
>>>     *Cc:* [email-masked]
>>>     *Subject:* [Sipping] SDP Rollback
>>>     indraft-sawada-sipping-sip-offeranswer-01.txt
>>>
>>>     Hi,
>>>
>>>      
>>>
>>>     I am not sure (as I am a very new user to SIPPING
>>>
>>>     group) whether SDP rollback has ever been discussed
>>>
>>>     regarding this draft or not. I personally feel that
>>>
>>>     'SDP rollback' is very relevant topics regarding this
>>>
>>>     draft.
>>>
>>>      
>>>
>>>     The sec 1.2 indicates the response(488) to reject any
>>>
>>>     SDP offer. But the missing part is that if any SIP
>>>
>>>     request carrying SDP offer is rejected by 3xx-6xx then
>>>
>>>     SDP offer should be rolled-back. The rollback means,
>>>
>>>     applying last session description.
>>>
>>>      
>>>
>>>     Rather than specifying different SIP messages
>>>
>>>     separately, it would be better to have some thumb rule
>>>
>>>     that shall be quite easy to follow as far as SDP
>>>
>>>     rollback is concerned. I am proposing following thumb
>>>
>>>     rule. Please indicate whether that makes sense or not.
>>>
>>>      
>>>
>>>     The SDP rollback shall be associated with transaction
>>>
>>>     rollback/rejection.
>>>
>>>      
>>>
>>>     [1] If the transaction request (carrying SDP offer) is
>>>
>>>     rejected then SDP offer shall be rolled-back. The
>>>
>>>     exception is the ACK request. The ACK (of 2xx) can not
>>>
>>>     be rejected. (The ACK of 3xx-6xx is not the
>>>
>>>     transaction initiating request).
>>>
>>>      
>>>
>>>     [2] If any transaction request carries SDP answer
>>>
>>>     (e.g., ACK or PRACK) then that transaction can not
>>>
>>>     rejected as there shall be the confusion over whether
>>>
>>>     SDP shall be rolled-back or not. I suppose, SDP answer
>>>
>>>     can not be rolled-back. There is no confusion for ACK,
>>>
>>>     as it can not rejected but for PRACK the restriction
>>>
>>>     should be there that it can not be rejected if it
>>>
>>>     carries SDP answer.
>>>
>>>      
>>>
>>>     This draft says that PRACK(irrespective of whether it
>>>
>>>     is carrying SDP offer/answer) can not be rejected. I
>>>
>>>     can not understand the rationale about this statement.
>>>
>>>     Though, I can appreciate why PRACK MUST not be
>>>
>>>     rejected if it carries SDP answer.
>>>
>>>      
>>>
>>>     [3] If any SIP response contains SDP offer then that
>>>
>>>     SDP can not be rolled-back. If any SIP entity wants to
>>>
>>>     rollback the SDP offer carried by SIP response, it
>>>
>>>     should initiate a SIP transaction carrying old SDP to
>>>
>>>     accomplish it.
>>>
>>>      
>>>
>>>     There is a special case for re-INVITE. If multiple SDP
>>>
>>>     offer/answer happens(using PRACK/UPDATE) within
>>>
>>>     re-INVITE transaction and re-INVITE is rejected by
>>>
>>>     4xx-6xx then whether all the SDP offer/answer happens
>>>
>>>     within re-INVITE transaction shall be rolled-back or
>>>
>>>     not. My suggestion would be that once SDP offer/answer
>>>
>>>     is completed, that can not rolled-back by means of
>>>
>>>     transaction rejection. That means, all the completed
>>>
>>>     SDP offer/answer shall not be rolled-back due to
>>>
>>>     4xx-6xx of re-INVITE. This decision shall save the
>>>
>>>     work of SIP UA, SIP SBC, B2BUA etc. that follows SDP
>>>
>>>     offer/answer state.
>>>
>>>      
>>>
>>>     Please comment.
>>>
>>>      
>>>
>>>      
>>>
>>>     Thanks and Regards,
>>>
>>>     Siddhartha
>>>
>>>      
>>>
>>>
>>>
>>>     
>> --------------------------------------------------------------
>> ----------
>>>     ---------------
>>>     This e-mail may contain confidential and/or privileged 
>> information.
>>>     If you are not the intended recipient (or have received 
>> this e-mail
>>>     in error) please notify the sender immediately and delete this
>>>     e-mail. Any unauthorized copying, disclosure or 
>> distribution of the
>>>     contents in this e-mail is strictly forbidden.
>>>     ---------------
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP 
>> Use [email-masked] for questions on current 
>> sip Use [email-masked] for new developments of core SIP
>>
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP