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

From: "Brett Tate" <[email-masked]>
Date: Thu, 7 Aug 2008 13:37:14 -0400

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

If an UPDATE is successfully processed while a re-INVITE is occuring, I
agree that the updates caused by the UPDATE and UPDATE 2xx should not be
rolled back upon re-INVITE failure.

> Would it also be acceptable to stay with whatever remote 
> Target was successfully set last?

What is meant by "successfully set last"?  Is the proposal for 1)
updating per received target update request or 2) it having triggered a
2xx?

Since it might be relevant to the discussion, what is the current
interpretation of rfc3261 concerning a re-INVITE 18x with an updated
Contact?  Is the current proposal to alter the current interpretation of
rfc3261?

Thanks,
Brett
_______________________________________________
Sipping mailing list  https://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: "Christer Holmberg" <[email-masked]>
Date: Thu, 7 Aug 2008 22:28:41 +0200

Hi,

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

>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'll get back to the target issue later.

Regards,

Christer

Thanks,
Brett

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 7 Aug 2008 17:36:55 -0400

Thanks for the response.  Reply inline.

> > 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 
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 Aug 2008 08:27:19 +0200

Hi, 

>>>>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.
>
>Which race condition concerning session is the actual problem?

The one we discussed was related to offer/answer, where a UAS does not
know whether an UPDATE was sent by the UAC before of after it received
the re-INVITE final response.

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.

So, you are basically suggesting an alternative which is something
between the two other alternatives?

What if something done in the UPDATEs etc is dependent on something
which was negotiatied e.g. using re-INVITE/183. If you then are supposed
to roll back whatever was negotiated in the re-INVITE/183 things could
get messy.

don't mind rfc3261 changes being made concerning the topic.  RFC 3261
section 14.1 appears clear concerning the issue; 

Well, when the 3261 (or, does it come from 2543?) text was written I am
sure we weren't aware of this issue (was UPDATE even around at that
time?).

>however I'm not sure how many implementations actually follow it after
successfully processing PRACK and UPDATE.

Well, the reason it is important to solve these open issues is that
implementators know what they will have to do :)

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

I think we have realized a while ago that we can't really rely on any
RFC giving us a clear answer on this issue :)

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 8 Aug 2008 12:53:11 -0400

> So, you are basically suggesting an alternative which is 
> something between the two other alternatives?

I'm actually not trying to suggest it; I'd rather deprecate allowing
100rel for re-INVITE. 

I'm mainly just trying to indicate what rfc3261 14.1 currently says: "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."

I don't disagree that improvements might be desired concerning re-INVITE
failure.  However I don't find rfc3261 ambiguous concerning the issue.

> What if something done in the UPDATEs etc is dependent on 
> something which was negotiatied e.g. using re-INVITE/183. If 
> you then are supposed to roll back whatever was negotiated in 
> the re-INVITE/183 things could get messy.

I don't disagree that rollbacks in general are messy (especially
concerning SIP headers like Contact).

The offer/answer of UPDATE is performed separately from re-INVITE/183
offer/answer.  What session specific data is of concern?

> >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; 
> 
> Well, when the 3261 (or, does it come from 2543?) text 
> was written I am sure we weren't aware of this issue 
> (was UPDATE even around at that time?).

The SIP draft for UPDATE's predecessor (COMET) was around prior to
rfc3261.  I have no idea if it was considered when the rfc3261 text was
added or during the 2543bis process.
_______________________________________________
Sipping mailing list  https://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: "Christer Holmberg" <[email-masked]>
Date: Sat, 9 Aug 2008 12:57:01 +0200

Hi,

>I'm actually not trying to suggest it; I'd rather deprecate allowing

Assume you have a mid-call case where you are adding a new stream, using pre-conditions, and instead of re-INVITE you use only UPDATEs.
Now, the pre-condition offer/answers may go well, but it is difficult for the UAS to finally indicate  whether he actually accepts the new stream or not. The pre-condition offer/answers may take place before the UAS user is even promted whether he wants the stream in the first place.

>failure.  However I don't find rfc3261 ambiguous concerning the issue.

The text is very clear. But, again, I think it was written before this issue came up.

Please also note that the scope of this whole discussions have been only SDP and offer/answer.

>offer/answer.  What session specific data is of concern?

Please keep in mind that the discussion has not only been about the separation between re-INVITE and UPDATE, it has also been between SIP transactions and offer/answer transactions. Even if a re-INVITE SIP transaction fails, a re-INVITE/183 offer/answer transaction may still have succeeded.

>added or during the 2543bis process.

Even if the draft was around, there were never any discussions about re-INVITEs with pre-conditions (or, any other use-case where a re-INVITE would "contain" UPDATEs).

Regards,

Christer