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

["DRAGE, Keith \(Keith\)" <[e-mail]>]

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