[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Current status of response to 3gpp Liaison Statementon offer/answer procedures
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: sipping-bounces at ietf.org
> [mailto:sipping-bounces at ietf.org] 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: +44 7801723668
> >> ian.elz at ericsson.com
> >> -----Original Message-----
> >> From: sipping-bounces at ietf.org
> [mailto:sipping-bounces at ietf.org] 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:pkyzivat at cisco.com]
> >>>>>>>>> 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: sipping-bounces at ietf.org
> >>>>>>>>>>> [mailto:sipping-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions
> on current
> >>>>>>>>>> sip Use sip at ietf.org 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
> >>>>>>>>> sip-implementors at cs.columbia.edu for questions on
> current sip
> >>>>>>>>> Use sip at ietf.org 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
> >>>>>> sip-implementors at cs.columbia.edu for questions on
> current sip Use
> >>>>>> sip at ietf.org 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
> >>> sip-implementors at cs.columbia.edu for questions on current sip Use
> >>> sip at ietf.org 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
> >> sip-implementors at cs.columbia.edu for questions on current sip Use
> >> sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current
> sip Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP