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

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

Hi,
 
I think (and hope) that we can make a decission regarding the re-INVITE fallback issue "on the list", because I think we have a rather good understanding of both alternatives now. 
 
We can then inform 3GPP about that decission, and than start to discuss how/what we are going to document things in IETF.
 
Regards,
 
Christer
 
 

________________________________

Lähettäjä: Paul Kyzivat [mailto:[e-mail]]
Lähetetty: ti 10.6.2008 14:58
Vastaanottaja: [e-mail]
Kopio: Christer Holmberg; [e-mail]; [e-mail]; [e-mail]; Gonzalo Camarillo
Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures



cHietalahti,

I will defer to others on formal liason procedures. But it is becoming
clear that there will need to be a standards track document to deal with
this - initially a draft and eventually an RFC. The draft will probably
be the first formal output that is useful to you. At the moment we are
still hashing out what that draft ought to say.

        Thanks,
        Paul

[e-mail] wrote:
> 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,
> cHietalahti
> 3GPP CT chairman
> Mobile phone: [phone]
> 
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] 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
>> [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
>


_______________________________________________
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