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

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

Hi,

>>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, it 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?

Well, it depends on the use-case. If the UAC is offerin a new stream, it most likely will have to reserve resources (IP address/port, codecs etc) for it before the pre-conditions are met. Of course, it will not start to use them before the pre-conditions have been met.

More on this below, when discussing your codec downgrade use-case.


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

Correct.

>But the situation is reversed for downgrading - you need to switch to the lower bandwidth codec *before* giving up
>bandwidth.

Well, if you KNOW you are going to downgrade the bandwidth I guess you don't need preconditions in the first place. You just send a re-INVITE/UPDATE without pre-conditions, and I doubt the network will "complain".

But, if you don't know, I guess it very much depends on what access network technology, QoS mechanisms etc you are using. I think a downgrade will happen very fast, so I don't think the high-bandwidth codec would be used for a very long time.

Also, the issue you are describing exists even when a 200 OK response is sent to the re-INVITE, so... :)

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

Yes. So, again, I think this is an implementation issue, and people need to be careful when downgrading.


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

Again, implementation issue. It's impossible to, for different kind of access network technologies, QoS techniques etc, specify exactly what happens at a certain time.

Also, in the case you describe something has most likely gone wrong somewhere, so the bandwidth status could be whatever...


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

I don't think we can assume that.

Take the initial INVITE for example. The negotiated codecs etc take affect once the preconditions have been met - which can happen long before the final re-INVITE final response comes (in many cases the UAS doesn't get alterted until the preconditions are met).

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