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

[Gonzalo Camarillo <[e-mail]>]

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