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

[Paul Kyzivat <[e-mail]>]

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