Re: [Sipping] Current status of response to 3gpp Liaison Statementon offer/answer procedures

[Paul Kyzivat <[e-mail]>]

I will defer to Robert for a definitive statement on this. But AFAIK 
this is *not* *written* anywhere. I think it is a consequence of the 
specs - that as the state machines are defined they *will not work 
correctly* if the two ends don't have he same values.

	Paul

DRAGE, Keith (Keith) wrote:
> Robert wrote:
> 
>> It is a hard requirement that any pair of transaction state 
>> machines (the client and server machines for any given hop) 
>> have the same timer values. Without that, behavior becomes 
>> very incorrect. And for INVITE/ 200/ACK the TU timers (which  
>> are all based on T1) have to be the same or you get into 
>> broken territory. The result is that if you change a timer 
>> somewhere in the network, you either change it across the 
>> whole network or you put in a node that's essentially playing 
>> the role of a SIP-SIP gateway that deals with complexity of 
>> having timers different on each side. 
> 
> Is this actually written anywhere. I expected to find it in RFC 3261 if it was written but a scan did not reveal this.
> 
> I know IMS uses, for the mobile accesses, timer values that are T1 * 4 for UA to 1st proxy, and then the normal values in the network.
> 
> Robert, can you be more specific on the implications of such a mismatch.
> 
> Regards
> 
> Keith
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Robert Sparks
>> Sent: Monday, July 28, 2008 3:51 PM
>> To: Paul Kyzivat
>> Cc: sipping; Mary Barnes; Gonzalo Camarillo
>> Subject: Re: [Sipping] Current status of response to 3gpp 
>> Liaison Statementon offer/answer procedures
>>
>> One comment inline:
>>
>> On Jul 25, 2008, at 3:58 PM, Paul Kyzivat wrote:
>>
>>> Copying Robert. I think his input on this would be invaluable.
>>>
>>> This is exactly the sort of response I was hoping to get to my 
>>> proposal. It really needs to be carefully vetted.
>>>
>>> Comments inline.
>>>
>>> 	Paul
>>>
>>> Ian Elz wrote:
>>>> Paul,
>>>> I have two potential issues with the rules you have 
>> mentioned below.
>>>> Sorry for the delay in replying to your email but I have 
>> taken some 
>>>> vacation and one of the possible issues has just been noticed.
>>>> 1. Regarding rule 2. I am assuming that in this rule the UAC not 
>>>> sending an UPDATE also applies after any retransmission of the ACK 
>>>> due to receipt of a 200 OK retransmission. Perhaps this should be 
>>>> explicitly stated.
>>> What I had in mind was that UPDATE couldn't be used until all 
>>> retransmissions of the ACK has completed. So it would  be 
>> 32 seconds.
>>> Since it is quite possible that there will be need of a new 
>> O/A within 
>>> that period (e.g. because the UAC goes on hold quickly), 
>> the UAC will 
>>> have to be prepared to use alternative means (reINVITE).
>>> The net effect is probably that the UAC will *never* use UPDATE for 
>>> O/A outside of an invite transaction.
>>>
>>>> I will preface by stating that this is an unlikely scenario but it 
>>>> can and will occur. The UAC is not allowed to send an UPDATE until 
>>>> after sending an ACK until the timer has expired. In the UAS the 
>>>> timer for receipt of an ACK is based upon T1 with the 200 OK being 
>>>> resent at 2 * T1, 4 * T1, 8 * T1 etc until 64 * T1. With the 
>>>> recommended value of T1 (0.5 s) then the timer is 32 s.
>>>> The setting of T1 however is only recommended and the 
>> value of T1 on 
>>>> the UAS may be different than as set on the UAC. If the 
>> UAS has its 
>>>> T1 set 4 X or greater than the T1 of the UAC then there may be an 
>>>> issue.
>>>> I will explain by showing the 200 OK retransmission times from the 
>>>> UAS.
>>>> T1 value                   0.5        1          2         4
>>>> 1st Retransmission          1         2          4         8
>>>> 2nd retransmission          2         4          8        16
>>>> 3rd retransmission          4         8         16        32
>>>> 4th retransmission          8        16         32        64
>>>> 5th retransmission         16        32         64       
>> 128 If the  
>>>> UAC has T1 set to 0.5 seconds then there are 
>> retransmission intervals 
>>>> which are equal to or greater than the ACK timer when the UAS T1 
>>>> value is 2 seconds or greater. This could cause an issue.
>>>> This may be prevented by making recommendations about 
>> timer setting.
>>> I don't know much about the timers. It has always baffled 
>> me that we 
>>> allow them to be changed. Its my impression that all bets 
>> are off if 
>>> the two ends of a transaction don't have the same timer values.
>> It is a hard requirement that any pair of transaction state 
>> machines (the client and server machines for any given hop) 
>> have the same timer values. Without that, behavior becomes 
>> very incorrect. And for INVITE/ 200/ACK the TU timers (which  
>> are all based on T1) have to be the same or you get into 
>> broken territory. The result is that if you change a timer 
>> somewhere in the network, you either change it across the 
>> whole network or you put in a node that's essentially playing 
>> the role of a SIP-SIP gateway that deals with complexity of 
>> having timers different on each side.
>>
>>>
>>>> 2. Regarding rule 1
>>>> This prevents the UAS from sending an UPDATE as part of a 
>> re-INVITE 
>>>> transaction.
>>>> We have come across a case for an initial INVITE where it becomes 
>>>> necessary for the UAS to send an early dialog UPDATE which 
>> may also 
>>>> be applicable in a re-INVITE case. I am not sure if it is 
>> applicable 
>>>> for a re-INVITE but others may be able to advise.
>>>> When a SIP INVITE passes via an MGC to an ISDN connection the IP 
>>>> address and port to be used can be controlled by the ISDN 
>> PBX. When 
>>>> the ISDN bearer identity is provided by the ISDN terminal, in an 
>>>> Alerting signal, the MGC may change the ephemeral (& 
>> possibly H.248 
>>>> context). If we have an INVITE sequence involving 
>> preconditions the 
>>>> extended INVITE sequence occurs with an UPDATE from the UAC to 
>>>> confirm reservation of resources. As an immediate response is 
>>>> required to this UPDATE the UAS can only respond with the 
>> IP address 
>>>> and port of the H.248 ephemeral that it selected initially.
>>>> In the ALERTING response to the SETUP request the ISDN terminal 
>>>> specifies a bearer which may result in a different the IP address 
>>>> and/or port. This requires that the UAS sends a further 
>> UPDATE with a 
>>>> modified sdp offer to change the IP address and/or port prior to 
>>>> sending the 200 OK.
>>>> While this scenario can occur for an initial INVITE it may also be 
>>>> possible for a re-INVITE; e.g. when a new media type is 
>> added to an 
>>>> existing session.
>>>> I am uncertain as to whether this will occur in this 
>> situation and I 
>>>> would welcome input from the list to show that it cannot.
>>> My point was that while an invite/reinvite is in progress, 
>> any offer 
>>> the UAS might want to send in an UPDATE can instead be sent in a 
>>> reliable provisional response.
>>>
>>> This *does* present a problem if the UAC supports UPDATE 
>> but doesn't 
>>> support reliable provisional responses. Is that an important case?
>>> Does anybody do that?
>>>
>>> If we must deal with the case where a UAC doesn't support 
>> 100rel, but 
>>> does support UPDATE, then this proposal won't work. If so, I don't 
>>> currently have any alternative.
>>>
>>> 	Paul
>>>
>>>> Ian Elz
>>>> System Manager
>>>> DUCI LDC UK
>>>> (Lucid Duck)
>>>> Office: + 44 24 764 35256
>>>> gsm: [phone]
>>>> [e-mail]
>>>> -----Original Message-----
>>>> From: [e-mail] 
>> [mailto:[e-mail]] On 
>>>> Behalf Of Paul Kyzivat
>>>> Sent: 03 July 2008 15:57
>>>> To: sipping
>>>> Cc: Mary Barnes; Gonzalo Camarillo
>>>> Subject: Re: [Sipping] Current status of response to 3gpp Liaison 
>>>> Statement on offer/answer procedures I have been thinking 
>> about how 
>>>> we might solve the UPDATE ambiguity issue which the 
>>>> MULTI-OA-TRANSACTION has. I have a potential solution, 
>> which involves 
>>>> the following new restrictions:
>>>> 1) A UAS for a reINVITE MUST NOT send UPDATE requests
>>>>    within the scope of that INVITE. It must refrain from sending
>>>>    UPDATE until it has received an ACK for the INVITE.
>>>>    Note that this isn't much of a restriction, since the 
>> same things
>>>>    can be accomplished with reliable provisional responses before
>>>>    the INVITE completes, and reINVITE can be used after sending a
>>>>    final response. The only limitation I can see is if reliable
>>>>    provisionals are not being used and yet a change is desired
>>>>    before completion of the INVITE. But I doubt that is a realistic
>>>>    case.
>>>> 2) A UAC for an INVITE or reINVITE MUST NOT send an UPDATE request
>>>>    immediately *after* the completion of the INVITE. It 
>> must refrain
>>>>    until the timer has expired on the ACK. (I forget which 
>> timer that
>>>>    is.)
>>>>    This also isn't much of a restriction. Anything that can be done
>>>>    by the UPDATE can also be done with a reINVITE.
>>>> With these restrictions, the recipient of an UPDATE never has any 
>>>> question of whether it should be part of the prior INVITE or not.
>>>> To be sure, lets cover the cases:
>>>> UAC (for the INVITE):
>>>> - An UPDATE that was legally sent by the UAS will arrive after the
>>>>   final response for the INVITE is received and the ACK sent.
>>>>   It will be unaffected by failure of the prior reINVITE.
>>>> - There is no possibility that a legally sent UPDATE will arrive
>>>>   before the final response. If one arrives it must have been sent
>>>>   by a UAS not compliant to these new rules. If one does arrive,
>>>>   I propose that it be assumed to have been sent within the
>>>>   INVITE, and hence be rolled back if the INVITE eventually fails.
>>>> - There is no possibility that a legally sent UPDATE will arrive
>>>>   after the receipt of a failing final response, and before any
>>>>   ACK has been sent. If one arrives it must have been sent
>>>>   by a UAS not compliant to these new rules. If one does arrive,
>>>>   I propose that it be assumed to have been sent after the
>>>>   final response, and hence not be subject to rollback.
>>>> UAS (for the INVITE):
>>>> - An UPDATE that is received before the final response to the
>>>>   INVITE has been sent is assumed to belong within the INVITE.
>>>>   If the final response is a failure, then any o/a effects of
>>>>   the UPDATE will be rolled back.
>>>> - An UPDATE that is received after the final response to the
>>>>   INVITE has been sent, but before the ACK has been received,
>>>>   is assumed to have been sent before the final response was
>>>>   received. Hence it is subject to rollback if the final response
>>>>   was failure. Since it hasn't yet been processed, and is to be
>>>>   rolled back, the response to it should be an error - perhaps
>>>>   487.
>>>> I think the above will resolve the issue and be interoperable with 
>>>> current implementations except in cases of message reordering. I 
>>>> doubt we can do any better than that.
>>>> 	Thanks,
>>>> 	Paul
>>>> Paul Kyzivat wrote:
>>>>> Some time ago 3gpp requested liaison regarding offer/answer 
>>>>> procedures. The liaison document may be found at:
>>>>>
>>>>> https://datatracker.ietf.org/liaison/444/
>>>>>
>>>>> Information about the discussion can be found at:
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/sipping/current/msg15771.html
>>>>>
>>>>> Some of us (especially Christer and I) have been discussing this 
>>>>> privately. Mary has asked for a clarification of the 
>> current status 
>>>>> to the group. This is my attempt to do so:
>>>>>
>>>>> To summarize the issue:
>>>>>
>>>>> - Assume one issues a re-INVITE,
>>>>> - and that results in multiple offer/answer exchanges  (via PRACK 
>>>>> and UPDATE) prior to the completion of  the re-INVITE,
>>>>> - and then the re-INVITE *fails* (response >= 300)
>>>>>
>>>>> Then in what state is the session left, with regard to 
>> SDP and media 
>>>>> sessions?
>>>>>
>>>>> None of the RFCs clearly cover this case. The offer/answer draft 
>>>>> touched on it, but is not normative and so could not resolve it.
>>>>>
>>>>> We have concluded that there are two plausible ways of treating
>>>>> this:
>>>>>
>>>>> MULTI-OA-TRANSACTION:
>>>>>   The re-INVITE, and all the offers/answers that take place within
>>>>>   its scope, are treated as a transaction. All succeed or fail
>>>>>   together based on the outcome of the re-INVITE. So, if the
>>>>>   re-INVITE fails, then the media state reverts to what 
>> it had been
>>>>>   before the re-INVITE began.
>>>>>
>>>>> SINGLE-OA-TRANSACTION:
>>>>>   Each time an answer is transmitted *reliably*, that is 
>> considered
>>>>>   final, regardless of what happens subsequently. A failure of the
>>>>>   re-INVITE only rolls back an offer that offer that was not 
>>>>> reliably
>>>>>   answered prior to the failure response.
>>>>>
>>>>> The merits of MULTI-OA-TRANSACTION:
>>>>>
>>>>> The advantage of the MULTI-OA-TRANSACTION approach is 
>> that it aligns 
>>>>> with a real need. In some cases it is necessary to do 
>> multiple o/a 
>>>>> exchanges to transition from one stable state to another.
>>>>>
>>>>> A clear example of this is when preconditions are used. Multiple 
>>>>> exchanges are required to resolve the preconditions, and the 
>>>>> intermediate states may not be useful for exchanging media. The 
>>>>> ultimate failure is likely an indication that the preconditions 
>>>>> could not be resolved. Rolling back to the state prior to the re- 
>>>>> INVITE cleanly resolves this.
>>>>>
>>>>> A key to making this work is, when a re-INVITE failure 
>> occurs, the 
>>>>> UAC and UAS must agree on on which offers and answers 
>> were part of 
>>>>> the re-INVITE and hence must be rolled back. Those carried in the 
>>>>> re-INVITE itself, its responses, in PRACKs, and in the ACK, are 
>>>>> clearly within the scope of the re-INVITE. The UPDATEs 
>> that are sent 
>>>>> within the scope of the re-INVITE also must be included, 
>> but in that 
>>>>> case there is a problem. When an UPDATE is sent near the 
>> time when 
>>>>> the re-INVITE fails, the recipient of it cannot clearly 
>> determine if 
>>>>> it was sent before or after the re-INVITE failed.
>>>>> This case is discussed in section xxx of yyy.
>>>>>
>>>>> Adopting answer (1) requires that we find a resolution to this 
>>>>> ambiguity. The need to solve this problem is a disadvantage of 
>>>>> MULTI-OA-TRANSACTIONs.
>>>>>
>>>>> Another possible disadvantage is that this requires the 
>> UAC and UAS 
>>>>> to maintain enough state to accomplish the rollback.
>>>>>
>>>>> The merits of SINGLE-OA-TRANSACTION:
>>>>>
>>>>> These are, unsurprisingly, pretty much the inverse of MULTI-OA- 
>>>>> TRANSACTIONs.
>>>>>
>>>>> One advantage is that less state need be kept. Once an answer is 
>>>>> received reliably, or the confirmation of an answer sent 
>> reliably is 
>>>>> received, prior state may be discarded.
>>>>>
>>>>> Another advantage is that the ordering of an UPDATE 
>> relative to the 
>>>>> completion of the prior re-INVITE need not be of concern.
>>>>>
>>>>> The main disadvantage of this approach arises when multiple o/a 
>>>>> exchanges are required to achieve a stable state, such as with 
>>>>> preconditions. With this approach, each o/a exchange is 
>> locked in as 
>>>>> it occurs. If the re-INVITE subsequently fails, there may be 
>>>>> wreckage to clean up. Until it is cleaned up, the state 
>> of the media 
>>>>> session(s) may be problematic.
>>>>>
>>>>> General discussion:
>>>>>
>>>>> While I have used preconditions as an example of the need for 
>>>>> multiple o/a exchanges, they are not the only example. 
>> While I don't 
>>>>> recall seeing them in any of our use-case documents, I have 
>>>>> definitely seem them in the wild. For instance there are 
>> cases where 
>>>>> initial offers are made with a=inactive, and later revised to 
>>>>> a=sendrecv, not because the call is initially on hold, 
>> but because 
>>>>> the caller is waiting to see how things come out. This 
>> may be "poor 
>>>>> man's preconditions". These aren't always done within the 
>> re-INVITE, 
>>>>> but could be.
>>>>>
>>>>> Either approach will require some normative change, since the 
>>>>> existing text seems ambiguous as to which of these is the 
>> "correct" 
>>>>> interpretation. The MULTI-OA-TRANSACTION requires 
>> additional work to 
>>>>> define a mechanism for determining of an UPDATE near the 
>> end of an 
>>>>> INVITE transaction falls within it, or beyond it. So far 
>> there has 
>>>>> been no proposal for how to do this. It seems likely that it will 
>>>>> require that something new be placed into some messages. And this 
>>>>> may present backward compatibility issues.
>>>>>
>>>>> Many UAs will never experience a re-INVITE containing 
>> multiple O/A 
>>>>> exchanges. But even those are impacted by this issue. If a re- 
>>>>> INVITE has an offer, and it is answered in a reliable provisional 
>>>>> response, and then the re-INVITE fails, we still have the issue.
>>>>> If one side assumes the O/A is rolled back, and the other 
>> assumes it 
>>>>> remains in effect, then we have an interoperability 
>> error. So it is 
>>>>> important to come to some conclusion.
>>>>>
>>>>> NOTE: There is a related issue which we have agreed to 
>> rule out of 
>>>>> scope for the current discussion. This is whether a change of 
>>>>> Contact address during a re-INVITE is rolled back if the 
>> re-INVITE 
>>>>> fails. We concluded that the two issues should not be 
>> constrained to 
>>>>> have the same answer. This latter issue is left for another day.
>>>>>
>>>>>    Thanks,
>>>>>    Paul
>>>>>
>>>>> Paul Kyzivat wrote:
>>>>>> Robert Sparks wrote:
>>>>>>> (off-list reply)
>>>>>>>
>>>>>>> I'm mostly comfortable with that approach. Let me ask a 
>> question 
>>>>>>> or two to see if I can remove some of the dangling bits of 
>>>>>>> discomfort.
>>>>>>> The conversation so far has been described to me (I 
>> haven't been 
>>>>>>> following it closely - sorry)  as  focusing _only_ on 
>> the impact 
>>>>>>> on the session(s) being negotiated.
>>>>>>> It is _not_ attempting to answer some of the gnarly 
>> dialog-state 
>>>>>>> questions we've uncovered for these failed requests 
>> (specifically 
>>>>>>> what happens to a failed attempt to update a remote target (by 
>>>>>>> changing the Contact in new requests), correct?
>>>>>> Early in the thread I proposed separating the concerns. The 
>>>>>> remainder of the thread had indeed focused on the o/a issues.
>>>>>>
>>>>>> I do think that the other dialog state, notably the 
>> contact, issues 
>>>>>> need to be addressed. But I think we must not constrain them to 
>>>>>> have the same answer that works for o/a. We can start a separate 
>>>>>> thread to discuss that now, or we can wait for the current o/a 
>>>>>> discussion to settle first to avoid losing focus.
>>>>>>
>>>>>>> If I misunderstand and the second thing's in scope for this 
>>>>>>> effort, then my comfort is much lower.
>>>>>>>
>>>>>>> Paul - you responded separately that you think this 
>> touches 3261 
>>>>>>> as well - roughly what is the character of those touches?
>>>>>> Hopefully it touches only slightly. The current text regarding 
>>>>>> rolling back state to where it was prior to reinvite *may* need 
>>>>>> some tweaking depending on what solution we come to.
>>>>>>
>>>>>> *If* we agree on the solution that does indeed cause 
>> rollback even 
>>>>>> if there have been PRACKs and/or UPDATEs along the way, 
>> then maybe 
>>>>>> it won't need to be changed at all.
>>>>>>
>>>>>> I am personally still undecided on which is the better 
>> solution.  
>>>>>> They have complementary pros and cons. It really is a matter of 
>>>>>> picking your poison. The precondition stuff really does 
>> cause nasty 
>>>>>> problems. I just posted another response in the thread 
>> about that.
>>>>>> I earlier suggested splitting off the precondition 
>> issues as their 
>>>>>> own problem, and solving the rest. But apparently 3gpp 
>> wants this 
>>>>>> resolved precisely *because* they want to know how it impacts 
>>>>>> preconditions. So my suggestion wasn't helpful.
>>>>>>
>>>>>> It would be helpful to get some additional perspectives 
>> into this 
>>>>>> discussion. So far there have been very few participants.
>>>>>>
>>>>>>    Paul
>>>>>>
>>>>>>> RjS
>>>>>>>
>>>>>>> On Jun 9, 2008, at 5:18 AM, Gonzalo Camarillo wrote:
>>>>>>>
>>>>>>>> Hi Paul,
>>>>>>>>
>>>>>>>> yes, it may make more sense to update RFCs 3262 and 
>> 3311 than to 
>>>>>>>> update RFC 3264... do people agree that the way to 
>> document the 
>>>>>>>> resolution of this issue would be to write a new RFC 
>> that would 
>>>>>>>> clarify how offer/answer works with re-INVITEs, PRACKs, and 
>>>>>>>> UPDATEs, and would include discussions on preconditions?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Gonzalo
>>>>>>>>
>>>>>>>>
>>>>>>>> Paul Kyzivat wrote:
>>>>>>>>> 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-offe
>>>>>>>>>> ranswer-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
>>>>>
>>>> _______________________________________________
>>>> 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