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

[Robert Sparks <[e-mail]>]

Well, the problem I'm pointing to is with ACK-200. It's not as dire to  
have differing T1s at the ends of a string of hops as it is to have  
different T1s at each end of one hop, but its still leads to cases  
where the endpoints can have a different idea of whether or not the  
transaction was successful.

This comes from this text in 3261 (at the bottom of page 85):
    Once the response has been constructed, it is passed to the INVITE
    server transaction.  Note, however, that the INVITE server
    transaction will be destroyed as soon as it receives this final
    response and passes it to the transport.  Therefore, it is necessary
    to periodically pass the response directly to the transport until  
the
    ACK arrives.  The 2xx response is passed to the transport with an
    interval that starts at T1 seconds and doubles for each
    retransmission until it reaches T2 seconds (T1 and T2 are defined in
    Section 17).  Response retransmissions cease when an ACK request for
    the response is received.  This is independent of whatever transport
    protocols are used to send the response.

btw - Invfix doesn't change the TU behavior here - it just makes sure  
there's  a transaction still in place to act as a conduit for those  
messages to go through.

So, at some point, a 3261 UAS TU is allowed to (and is going to) stop  
listening for 200 retransmissions and will likely do something other  
than send an ACK again if they show up. Its going to do that based on  
what _its_ value of T1 currently is.

infix makes this a little more explicit - based on the UAS's T1, the  
transaction that acts as a conduit is going to eventually go away and  
after that retransmitted 200s aren't going to _get_ to the TU in order  
to get ACKed (that's on purpose and is a good thing).

Now the UAC on the other end of some chain of proxies has its _own_  
idea of what T1 is, and if that's different, we get into a  
disagreement about when the time to recover based on retransmission is  
over.

Concretely, if the answering endpoint (the one sending the 200) has a  
T1 larger than the requesting endpoint and circumstances lead to  
retransmission of the 200 and ACK-200, it's going to 1) retransmit  
more slowly than requesting endpoint (and likely the operators of the  
network it is on) will expect, and 2) send retransmissions long after  
the requesting endpoint will be willing to re-ACK.

Similarly, you get into some cases where there is the opportunity for  
a mismatch in the idea of final state of a CANCELed INVITE when the  
endpoints at either end of a string have different T1s.



On Aug 5, 2008, at 12:36 PM, Paul Kyzivat wrote:

> I was talking about the two ends of a single hop.
> AFAIK there is no requirement for e2e consistency of timers.
>
> 	Paul
>
> DRAGE, Keith (Keith) wrote:
>> 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