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

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

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:[e-mail]] 
> 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: [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