Re: [Sipping] Liaison Statement on offer/answer procedures

["Christer Holmberg" <[e-mail]>]

Hi,
 
>>>>>> - If an UPDATE (inside or outside of a reINVITE) fails, any o/a in
>>>>>> the UPDATE has no effect on the media session state.
>>>>>> [Ian Elz ] OK, but how will we determine if an UPDATE is inside or
>>>>>> outside a re-INVITE?
>>>>> [Christer] I assume that any stateful entity must know whether it has
>>>>> a pending re-INVITE transaction for a specific call or not.
>>>> That's not actually enough. A UAS (or dialog stateful proxy) cannot know
>>>> whether an UPDATE received shortly after a 2xx is sent upstream was sent
>>>> before or after the 2xx was received by the UAC. We could add an
>>>> explicit indication to that effect, I suppose...
>>> Yes. Taking this approach to the current problem requires that we find a
>>> solution to knowing whether the update was sent inside the reinvite or not.
>>
>>If the UAS sends a 2xx response to the re-INVITE I guess it really doesn't matter when the UPDATE was sent.
>
>>But, if the UAS sends a non-2xx response to the re-INVITE I guess it would need to know when the UPDATE was sent: was it sent still assuming that the re-INVITE will succeed, OR was it sent bacause the re-INVITE did NOT succeed?
>
>>If we would go for the non-rollback alternative we wouldn't have this problem since the re-INVITE failure response doesn't affect UPDATE/PRACK offer/answers, and then it doesn't matter when the UPDATE was sent.
>
>Exactly! That is an advantage of the non-rollback solution.
>But the rollback solution has the advantage of providing a solution to
>the precondition rollback problem.
>
>We need to pick our poison.
 
Let's discuss the non-rollback alternative for a while.

For the pre-conditions case, when the re-INVITE fails, it most likely means that the UAS finally chose not to accept whatever was proposed in the re-INVITE request (maybe a new stream). Now,  before the re-INVITE failure response, intermediate o/a transactions may have succeeded, resources may have been reserved etc, e.g. because the UAS user wasn't "asked" about the new stream until a certain point.

So, since the re-INVITE failure response now wouldn't affect the suceeded intermediate o/a transactions, I guess the UAC (or UAS) would have to initiate a "manual fallback", by sending a new re-INVITE/UPDATE offer, with the SDP that was used before the previous failed re-INVITE request was sent - or maybe try some different offer (maybe it simply isn't possible to fall back to exactly the same SDP state as before the failed re-INVITE).

So, the non-rollback alternative would work also for pre-conditions, assuming the UAC does the "manual fallback", and we wouldn't have the race-condition problem that Anders brought up. 

Also, wouldn't automatically "force" the SDP state back to it's previous state, in case it for whatever reason isn't possible for the UAC/UAS. We would give the users more choise on how to deal with the situation.

Comments?

Regards,

Christer

 

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