Subject: [Sipping] question on failed re-inv O/A in draft-ietf-sipping-sip-offeranswer-06

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Tue, 26 Feb 2008 17:51:26 +0800

Hi,
 
In draft-ietf-sipping-sip-offeranswer-06, 
sec6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction
 
it says "The proper handling of this issue is undefined by existing
standards."
 
But looks like RFC3261 has given a definite answer for this issue.
sec 14.1
"If a UA receives a non-2xx final response to a re-INVITE, the session
   parameters MUST remain unchanged, as if no re-INVITE had been
issued."
 
Do we plan to reconsider this issue in this draft or some other thoughs
will be figured out to update it against 3261?
 
Thanks

Regards,
Rockson Li
Cisco R&D Center, Shanghai, PRC

_______________________________________________
Sipping mailing list  http://www.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: Tue, 26 Feb 2008 12:05:40 -0500

Rockson Li (zhengyli) wrote:
>    parameters MUST remain unchanged, as if no re-INVITE had been issued."

This makes sense as long as there are no reliable provisional responses, 
which aren't included in 3261.

Once it has been possible, via reliable provisional responses, and 
potentially UPDATEs as well, to finalize the initial offer/answer and 
possibly do yet another complete o/a as well, the interpretation of the 
text in 3261 becomes much less obvious.

I have in fact taken the position that it should still apply, thus 
rolling back all the offers and answers that might have followed invite. 
But many have made the case (and I can see their point) that when an o/a 
has been *completed* it ought not be rolled back. And keeping enough 
state to rollback after a sequence of O/As would be difficult.

The bottom line is that it is considered an open issue that is not 
addressed normatively, and should be.

> will be figured out to update it against 3261?

The intent is to leave this for a subsequent normative document to fix.

	Paul