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

[Paul Kyzivat <[e-mail]>]

response at end.

Christer Holmberg wrote:
> 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.

Before answering that, I think there is a related issue of when the o/a 
changes actually take effect. Is it *immediately* (when the offer is 
sent and when the answer is sent), or is it only when all the 
preconditions have been resolved?

Consider a case where what is proposed is a codec change - to a higher 
bandwidth codec. Until the increased bandwidth is obtained, you can't 
really use the new codec. But the situation is reversed for downgrading 
- you need to switch to the lower bandwidth codec *before* giving up 
bandwidth. This could be solved by initially offering both the old and 
new codecs, along with proposing the bandwidth change. The switch in 
which codec is used would happen appropriately. But that depends on some 
careful conventions for codec usage, and we know there are 
implemenations out that that can't actually support simultaneous use of 
multiple codecs.

Even that doesn't fully resolve the problem. Suppose you had previously 
negotiated a bandwidth of B1 and have been happily using it. Then you 
decide to switch to bandwidth B2 ( which is > B1) and send an offer with 
preconditions for this, indicating that it isn't yet satisfied. If you 
get an answer that leaves this unresolved, what do you have? Can you 
assume you still have the old bandwidth, or not?

Life gets simpler if we assume that none of the o/a changes in the 
context of a reINVITE (and PRACKs and UPDATEs within the reINVITE scope) 
take effect until the successful completion of the reINVITE. (As 
contrasted to having them take effect immediately and then be rolled 
back on a failure.)

	Thanks,
	Paul

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