Re: [Sipping] Reconciling O/A rollback with dialog state rollback

["Brett Tate" <brett at broadsoft.com>]

Thanks for the response.  Reply inline.

> > > Christer's proposal 2 for the offer/answer situation 
> > > is to stay with whatever offer/answer exchange 
> > > completed successfully last (perhaps in 
> > > the INVITE/183 below).
> >
> > I don't have a strong opinion on the topic; I'd 
> > actually prefer 100rel usage for re-INVITE be 
> > deprecated. :)
> >
> > I'm curious why preferring not to follow rfc3261 
> > section 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."?
> 
> That was the other alternative (full rollback). However, 
> there a race condition issues identified for that (see 
> previous discussions), which we couldn't find a good 
> solution for. 

I don't disagree that race conditions can cause various problems
(especially concerning Contact and other SIP headers).

Which race condition concerning session is the actual problem?

An UPDATE with SDP occurs separate from re-INVITE even though it might
occur while a re-INVITE is occurring.  Thus the UPDATE and UPDATE 2xx
should not rollback upon re-INVITE failure; however I don't see why the
re-INVITE/PRACK session modifications can't rollback per rfc3261 section
14.1.

As I mentioned, I don't have a strong opinion on the topic.  I also
don't mind rfc3261 changes being made concerning the topic.  RFC 3261
section 14.1 appears clear concerning the issue; however I'm not sure
how many implementations actually follow it after successfully
processing PRACK and UPDATE.


> > If an UPDATE is successfully processed while a re-INVITE 
> > is occurring, I agree that the updates caused by the 
> > UPDATE and UPDATE 2xx should not be rolled back upon 
> > re-INVITE failure.
> 
> Well, that IS the alternative we chose to go for - any 
> offer/answer that has succeeded remains valid :)

I'm trying to indicate that the rfc3261 section 14.1 text allows the
re-INVITE session adjustments to rollback while allowing the UPDATE
adjustments to remain.

An UPDATE occurring while re-INVITE is occurring has no direct
offer/answer correlation beyond handling offer collisions and correctly
formatted offers.  Thus no RFC has indicated to rollback the UPDATE
adjustments based upon re-INVITE failure.
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP