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

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

 
Hi,

>If precondition is treated as a separate case, then are there other use cases where UAS would need to send answer in provisional response to re-Invite. IMO, in majority of cases 200 OK would 
>carry answer to offer in re-Invite/UPDATE.

I agree. I am not aware of other use-cases.

And, even if there are other use-case, I still think that in the majority of those the SDP offer of the re-INVITE request itself will carry the "main" media changes. I don't think you would normally add streams etc using the intermediate UPDATE/PRACKs.

Regards,

Christer




>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Paul Kyzivat (pkyzivat)
>Sent: Wednesday, June 04, 2008 6:40 PM
>To: Christer Holmberg
>Cc: sipping List; Elwell, John; Gonzalo Camarillo; Mary Barnes
>Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>
>Regarding SDP:
>
>I think the likely candidates are:
>
>1) as specified in 3261, and contrary to 3264, if a reinvite fails, the 
>SDP/media-session state rolls back to what it was before the reinvite. 
>This is so even if there answers were transmitted reliably via PRACK 
>and/or UPDATE.
>
>2) Once an answer has been transmitted reliably, it is committed, and 
>is not rolled back if the reinvite subsequently fails.
>
>Of these, (2) is probably easier to understand and implement. 
>And its probably semantically reasonable, except for one case:
>
>That case relates to preconditions. Using preconditions, you can get 
>into a state where an offer/answer has completed, but preconditions 
>have not been satisfied, so the media stream is not usable. It is then 
>expected that a subsequent o/a exchange will improve upon this, and 
>eventually result in usable media streams. If each o/a is committed 
>independently, then a previously working can be replaced with an 
>unusable state until a further o/a fixes it, and if a further o/a 
>doesn't fix it then it remains permanently broken.
>
>(An example of this might be starting from a working low bandwidth 
>audio session. A reinvite is then sent with an attempt to upgrade to a 
>wideband codec with preconditions used to condition the change on 
>obtaining sufficient bandwidth. In this case you would like to continue 
>to use the low bandwidth codec until you know if you have obtained the 
>resources for the wideband.)
>
>Note that this problem exists even without reinvite. It can occur if an 
>update to a working session is initiated using UPDATE with 
>preconditions.
>
>IMO this is an intrinsic problem with preconditions. Because they 
>aren't widely used, it may be prudent to split off fixing that as a 
>separate task. If that is done, then I think (2) above is probably a 
>good way to solve the rest of the problem.
>
>To solve the precondition problem I think we need a concept like 
>o/a-transaction. A single o/a pair is an o/a-transaction if it contains 
>no unsatisfied preconditions. But an o/a that has unsatisfied 
>preconditions results in an incomplete o/a-transaction. Additional o/a 
>pairs continue to be part of it until a final o/a pair where the 
>preconditions are satisfied. That ends the o/a-transaction. A failure 
>in the midst of an o/a-transaction (signaled in the enclosing protocol 
>like
>sip) would revert to the session state in effect before the beginning 
>of the o/a-transaction.
>
>I would expect this direction for preconditions to be controversial. 
>(Among the one or two people who actually care about
>preconditions.) Which is a good reason to split it off from the rest.
>
>	Thanks,
>	Paul
>
>Christer Holmberg wrote:
>> Hi,
>>  
>> I agree with Paul that we probably aren't talking about
>changes to 3264 here.
>>  
>> Also, I am fine if we want to decouple "committings" of
>media data/SDP updates with other types of data updates (contact etc).
>>  
>> But, that means that we need to specify specific
>"committing" rules for any type of data which can be affected. 
>Or, we can of course have a "default committing rule" (e.g. 
>full rollback), and then specify different rules for specific type of 
>data when/if needed.
>>  
>> But, for the SDP data, would anyone object to a full rollback?
>>  
>> Regards,
>>  
>> Christer
>> 
>> ________________________________
>> 
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Wed 04/06/2008 17:32
>> To: Gonzalo Camarillo
>> Cc: Christer Holmberg; Elwell, John; sipping List; Mary Barnes
>> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>> 
>> 
>> 
>> Gonzalo,
>> 
>> I generally agree with your characterization below. But as I see it 
>> there likely are no changes needed to 3264. It is intentionally 
>> focused on the SDP, and not the conveyance of the SDP in some 
>> containing protocol. The following is about the extent of it in 3264:
>> 
>>     Protocol operation begins when one agent sends an
>initial offer to
>>     another agent.  An offer is initial if it is outside of
>any context
>>     that may have already been established through the higher layer
>>     protocol.  It is assumed that the higher layer protocol provides
>>     maintenance of some kind of context which allows the various SDP
>>     exchanges to be associated together.
>> 
>>     The agent receiving the offer MAY generate an answer, or it MAY
>>     reject the offer.  The means for rejecting an offer are
>dependent on
>>     the higher layer protocol.  The offer/answer exchange is
>atomic; if
>>     the answer is rejected, the session reverts to the state
>prior to the
>>     offer (which may be absence of a session).
>> 
>> SIP messed this up somewhat with the offerless-invite, and more when 
>> it introduced PRACK and UPDATE. The offerless-invite creates a case 
>> when it is impossible to reject an offer. But we aren't discussing 
>> that case here. Without PRACK and UPDATE, and with an offer in the 
>> INVITE, it the success or failure of the INVITE that determines the 
>> acceptance or rejection of the offer. (With an offerless invite, the 
>> ACK always accepts the offer, for better or worse.)
>> 
>> The use of PRACK and UPDATE while an INVITE transaction is
>is progress
>> creates an ambiguous situation due to the following from
>section 14.1
>> of
>> 3261:
>> 
>>     If a UA receives a non-2xx final response to a
>re-INVITE, the session
>>     parameters MUST remain unchanged, as if no re-INVITE had
>been issued.
>> 
>> This implies that changes made via PRACK and UPDATE during
>the INVITE
>> transaction must be rolled back. Since the problem created
>by 3262 and
>> 3311, in conjunction with 3261, I think the fixes will have to apply 
>> to those, not to 3264.
>> 
>> Also, the issue about changing Contact addresses clearly has nothing 
>> to do with 3264. And I am becoming increasingly convinced that the 
>> rules for "committing" a change of Contact address ought to be 
>> decoupled from the rules for "committing" a change to media sessions.
>> 
>> Before we get into the specifics, does the above make sense?
>> 
>>         Thanks,
>>         Paul
>> 
>> 
>> 
>> Gonzalo Camarillo wrote:
>>> Hi,
>>>
>>> we should be providing 3GPP with an answer to their liaison soon:
>>>
>>> https://datatracker.ietf.org/liaison/444/
>>>
>>> The thing is that when working on the offer/answer usage
>draft below,
>>> we kept from making normative changes to offer/answer:
>>>
>>> 
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswe
>>> r-08.txt
>>>
>>>
>>> However, it seems that there are a few cases that would require 
>>> normative updates to RFC 3264. In this thread, two cases have been
>>> identified: roll back and address changes during ongoing 
>>> transactions. I would like to see a list of such pending updates in 
>>> order to decide whether we need to revise RFC 3264 at this point or 
>>> document the current issues (like we are doing with RFC
>3261) for a future update.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>>
>>>
>>> Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> I do NOT think John's case is connected to the rollback issue.
>>>>
>>>> The rollback issue is: what happens to data that has been updated 
>>>> between the re-INVITE request and failure response? It of course 
>>>> included the target, but is not related to where responses
>are sent.
>>>>
>>>> Responses are, afaik, always sent to where the request
>came from, so
>>>> if one updates the local target he has to make sure that
>he listens
>>>> to the "old" port if there are ongoing transactions.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> Lähettäjä: Paul Kyzivat [mailto:[e-mail]]
>>>> Lähetetty: pe 16.5.2008 14:38
>>>> Vastaanottaja: Elwell, John
>>>> Kopio: Christer Holmberg; sipping List
>>>> Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures
>>>>
>>>>
>>>>
>>>> John,
>>>>
>>>> This is a good point.
>>>>
>>>> It does expose a potentially long window when address changes are 
>>>> problematic. I guess if a quick address change is
>necessary then the
>>>> INVITE, or reINVITE, can be CANCELed.
>>>>
>>>> IMO this is starting to identify an area that could stand to have 
>>>> more specification. I guess this sounds like a best
>practices draft,
>>>> but its still a little fuzzy to me. And I am far from
>clear whether
>>>> this is tightly connected to the o/a rollback issue.
>>>>
>>>>         Thanks,
>>>>         Paul
>>>>
>>>> Elwell, John wrote:
>>>>> Paul,
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail]
>>>>>> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>>>>>> Sent: 15 May 2008 14:48
>>>>>> To: Christer Holmberg
>>>>>> Cc: sipping List
>>>>>> Subject: Re: [Sipping] Liaison Statement on offer/answer 
>>>>>> procedures
>>>>>>
>>>>>> Christer,
>>>>>>
>>>>>> Saying "you shouldn't do it" to changing contact address
>or media
>>>>>> address ignores facts of life that may require doing it. This 
>>>>>> overlaps strongly with the session mobility discussion that is 
>>>>>> currently going on.
>>>>>>
>>>>>> Specifically, if a UA is losing possession of its address, or 
>>>>>> connectivity via that address, then it will have to do 
>>>>>> *something*. If we are going to say that you shouldn't
>change the
>>>>>> contact address in a dialog, and shouldn't change the media 
>>>>>> address in a media session, then we need to specify some 
>>>>>> alternative.
>>>>>>
>>>>>> Clearly there are at least two distinct cases here:
>>>>>>
>>>>>> - there is a desire to switch to a new address, but the
>old address
>>>>>>    can continue to be supported until and unless use of
>the new one
>>>>>>    can be established
>>>>> [JRE] So if the contact address changes and we successfully 
>>>>> conclude the UPDATE transaction, and then the old contact address 
>>>>> disappears, it is likely that the Via list on the
>re-INVITE request
>>>>> will have become invalidated too, so the final response
>will not reach the UAC. Correct?
>>>>>
>>>>> John
>>>>> _______________________________________________
>>>>> 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
>
_______________________________________________
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