Subject: RE: [Sipping] SDP Rollback indraft-sawada-sipping-sip-offeranswer-01.txt

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Tue, 14 Nov 2006 13:21:17 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Nov 2006 16:03:02 -0500

(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:
>     ------------------------------------------------------------------------
>     *From:* Siddhartha Bhakta
>     *Sent:* Tuesday, November 14, 2006 12:37 PM
>     *To:* [email-masked]; Paul Kyzivat (pkyzivat)
>     *Cc:* [email-masked]
>     *Subject:* [Sipping] SDP Rollback
>     ------------------------------------------------------------------------
>     ---------------
>     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