[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Liaison Statement on offer/answer procedures
Dear all,
This looks like a useful discussion, thanks!
A simple binary answer could be conveyed reliably between the companies,
but as we are not converging towards anything as simple as that, I would
appreciate if the result and the way forward could be captured in a
short document or letter that could be used as a reply to the CT1 LS,
please.
Knowing our liaison statement procedures differ between IETF and 3GPP I
do not know which way the reply should be sent back to us, but the main
thing is to somehow document the decisions that I hope we can get as the
outcome of this discussion.
If that can be done, then we can transport the reply via the nominated
contact persons (Gonzalo and myself), via contribution by companies (or
even people like Christer) who are active in both IETF and 3GPP, or as a
formal LS back to CT1.
But if a solution can be found, it is more useful to document it to
minimise the time CT1 needs to de-cipher it.
I have already put this item on the 3GPP - IETF conference call agenda
for today, so those who have already got the invitation are welcome give
their views there.
BR,
Hannu Hietalahti
3GPP CT chairman
Mobile phone: +358 40 5021724
>-----Original Message-----
>From: sipping-bounces at ietf.org
>[mailto:sipping-bounces at ietf.org] On Behalf Of ext Christer Holmberg
>Sent: 09 June, 2008 20:42
>To: Paul Kyzivat
>Cc: sipping List; Elwell, John; Mary Barnes; Gonzalo Camarillo
>Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>
>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
>sip-implementors at cs.columbia.edu for questions on current sip
>Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP