[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
The way I read Robert's text was that all the timers in all the SIP entities along the call path have to have consistent values end to end. It was this end-to-end constraint that I was querying.
I agree that for each hop we need the timer values on each end of the same hop to be consistent, which is what you seem to be saying, although I don't remember anything saying this in the specification either. It is this latter condition that you seem to be addressing.
Regards
Keith
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Monday, August 04, 2008 12:58 PM
> To: DRAGE, Keith (Keith)
> Cc: Robert Sparks; sipping; Mary Barnes; Gonzalo Camarillo
> Subject: Re: [Sipping] Current status of response to 3gpp
> Liaison Statementon offer/answer procedures
>
> 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: 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