Subject: [Sipping] Current status of response to 3gpp Liaison Statement on offer/answer procedures

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Jul 2008 09:35:14 -0400

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-offeranswer-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:[email-masked]]
>>>>>> 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: [email-masked]
>>>>>>>> [mailto:[email-masked]] 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 [email-masked] for questions on current sip
>>>>>>> Use [email-masked] 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 [email-masked] for questions on current sip
>>>>>> Use [email-masked] 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 [email-masked] for questions on current sip
>>> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Wed, 2 Jul 2008 09:51:17 +0800

Paul,

>From my personal experience, I have never seen reliable response with o/a to re-invite,
What I find in real world is there might be only 100Trying between re-INVITE and final response.

I think if UA really need multiple o/a, it just need multiple re-invite/200 or UPDATE/200 pairs, 
It's unnecessary to have reliable response with o/a to re-invite in implementation, 
many vendors would prefer simple mechanism which is clear stated in spec.

Therefore, is there possibility that we exclude  reliable response with o/a to re-invite in SIP o/a framework?

Regards,
-Rockson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
Sent: Tuesday, July 01, 2008 9:35 PM
To: sipping
Cc: Mary Barnes; Gonzalo Camarillo
Subject: [Sipping] Current status of response to 3gpp Liaison Statement on offer/answer procedures

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:

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.

MULTI-OA-TRANSACTION:

SINGLE-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.

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:
>> 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.
> 
> there have been PRACKs and/or UPDATEs along the way, then maybe it 
> won't need to be changed at all.
> 
> 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.
> 
>>> 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,
>>>>
>>>> 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:
>>>>
>>>> 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:
>>>>
>>>> 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.
>>>>
>>>>> The thing is that when working on the offer/answer usage draft 
>>>>> below, we kept from making normative changes to offer/answer:
>>>>>
>>>>> 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,
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> problematic. I guess if a quick address change is necessary then 
>>>>>> the INVITE, or reINVITE, can be CANCELed.
>>>>>>
>>>>>> 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,
>>>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> *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.
>>>>>>>>
>>>>>>> [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 
>>>>>>> [email-masked] for questions on current sip 
>>>>>> Sipping mailing list  
>>>>>> https://www.ietf.org/mailman/listinfo/sipping
>>>>>> This list is for NEW development of the application of SIP Use 
>>>>>> [email-masked] for questions on current sip Use 
>>>>>> [email-masked] for new developments of core SIP
>>>>>>
>>>>>
>>>>>
>>>
>>> This list is for NEW development of the application of SIP Use 
>>> [email-masked] for questions on current sip Use 
>>> [email-masked] for new developments of core SIP
>>
>>
> 
This list is for NEW development of the application of SIP Use [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 2 Jul 2008 14:29:36 +0200

Hi,

>What I find in real world is there might be only 100Trying between re-INVITE and final response.

That may have been the case until now, but at least in 3GPP there are cases where re-INVITEs with pre-conditions WILL be needed.
 
I guess the most simple (non-3GPP specific) example is when new media types (e.g. video) is added to an existing session, and additional resources need to be reserved.
 
In addition, 3GPP is working on "session continuity" (I don't intend to describe the details here) type of features, where re-INVITEs with resource reservation may be needed.

>I think if UA really need multiple o/a, it just need multiple re-invite/200 or UPDATE/200 pairs,

Maybe it would work in theory. The problem is that it would not be possible, if needed, for the UAS to actually indicate whether he has finally accepted whatever was requested by the re-INVITE. It is not sure that the UAS user is prompted as soon as he receives the re-INVITE, so multiple o/a transactions may take place before the UAS user actually decides to accept/reject.
 
>Therefore, is there possibility that we exclude  reliable response with o/a to re-invite in SIP o/a framework?

Assuming we would do that, we could still end up in a similar situation as for the SINGLE-OA-TRANSACTION alternative, if one UPDATE suddenly fails, and a "clean up" would be needed.
 
Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
Sent: Tuesday, July 01, 2008 9:35 PM
To: sipping
Cc: Mary Barnes; Gonzalo Camarillo
Subject: [Sipping] Current status of response to 3gpp Liaison Statement on offer/answer procedures

To summarize the issue:

MULTI-OA-TRANSACTION:

SINGLE-OA-TRANSACTION:

General discussion:

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Jul 2008 10:57:21 -0400

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:
>>> what happens to a failed attempt
>>>>> focused
>>>>> nothing to
>>>>>>>> conclude

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Fri, 4 Jul 2008 22:31:16 +0800

Paul,

Comments inline.

Thanks
Regards,
-Rockson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
Sent: Thursday, July 03, 2008 10:57 PM
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:

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):

- 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.
[Rockson] if UAS sends UPDATE after final response, but first final response is lost, 
So UPDATE will arrives to UAC before retransmission of final response. Roll back this UPDATE??

- 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.
[Rockson] Same issue here, if UPDATE is sent before final response, but it's lost in the middle, retransmission of 
UPDATE arrives to UAC after final response, not rollback??

UAS (for the INVITE):

[Rockson] Cseq could be used to identify if UPDATE is sent before or after INIVITE, looks no request-lost-in-the-middle issue here.

[Rockson] I do not understand this case, why UPDATE should be assumed being sent before the final response was received?
The UPDATE could be sent before or after ACK is sent , but all after final response is received, ACK might be lost in the middle.
You cannot tell if UPDATE is sent before or after ACK , Cseq does not work here.

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:
> 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.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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.
>> 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.
>>
>> 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.
>>
>>>> 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 
>>>>> when it introduced PRACK and UPDATE. The offerless-invite creates 
>>>>> a case when it is impossible to reject an offer. But we aren't 
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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,
>>>>>>>>
>>>>>>>>
>>>>>>>>> the contact address in a dialog, and shouldn't change the 
>>>>>>>>> media address in a media session, then we need to specify some 
>>>>>>>>> alternative.
>>>>>>>>>
>>>>>>>> re-INVITE request will have become invalidated too, so the 
>>>>>>>> final response will not reach the UAC.
>>>>>>>> Correct?
>>>>>>>>
>>>>>>>> John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Jul 2008 14:25:11 -0400

> So UPDATE will arrives to UAC before retransmission of final response. Roll back this UPDATE??

My proposal was that the UAS may not send an update until it has 
received the ACK from the invite. The ACK won't be sent until the final 
response is received. So this case doesn't happen.

> UPDATE arrives to UAC after final response, not rollback??

Same answer.

> [Rockson] Cseq could be used to identify if UPDATE is sent before or after INIVITE, looks no request-lost-in-the-middle issue here.

Hmm. I didn't discuss the case of an UDATE being sent, and then a 
reINVITE. You are right that CSeq can be used to verify the order of 
those, but it may not be needed.

Consider the cases:

- UPDATE w/offer, followed by reINVITE w/offer.

   This is clearly invalid, since the earlier offer hasn't been answered.

- UPDATE w/offer, followed by offerless reINVITE:

   Seems like a stupid thing to do. But if the messages arrive in order
   it should work without any difficulty.

   If the messages arrive out of order, then the UPDATE will get
   a 500 response because of the CSeq. Nothing special required for
   that to happen.

Its at the other end of the reINVITE that there is a problem, and that 

> [Rockson] I do not understand this case, why UPDATE should be assumed being sent before the final response was received?

The assumption is in accord with the proposal I made initially.

> You cannot tell if UPDATE is sent before or after ACK , Cseq does not work here.

The restriction on when UPDATE can be used to precisely to deal with this.

If the UAC doesn't adhere to this new restriction, then the problem 
could occur. The "assumption" in that case may be wrong. If so, things 
will be messed up. That is just the recognition of there being a bug in 
the spec.

	Thanks,
	Paul

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 25 Jul 2008 11:20:51 +0200

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.

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.

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.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

UAC (for the INVITE):

UAS (for the INVITE):

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 25 Jul 2008 15:08:58 +0200

Hi,

Regarding rule 1, I agree with Ian.

As Paul says, it is true that one could send a re-INVITE instead of UPDATE. But, "inside" that re-INVITE there may be a need for UPDATEs.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Elz
Sent: 25. heinäkuuta 2008 12:21
To: Paul Kyzivat; sipping
Cc: Mary Barnes; Gonzalo Camarillo
Subject: Re: [Sipping] Current status of response to 3gpp Liaison Statementon offer/answer procedures

Paul,

1. Regarding rule 2. 

T1 value                   0.5        1          2         4

2. Regarding rule 1

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

UAC (for the INVITE):

UAS (for the INVITE):

	Thanks,
	Paul

This list is for NEW development of the application of SIP Use [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP _______________________________________________

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Jul 2008 10:58:40 -0400

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

> 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.

> 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.

> 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

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 27 Jul 2008 19:54:33 +0200

Hi, 

>>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 think the use case Ian has in mind is that the UAC DOES send a new re-INVITE, but then it needs to send UPDATEs "inside" that re-INVITE, e.g. again due to pre-conditions, within the timer period.

However, when thinking about it, I am not sure it will be a problem.

Because, the offerer is not allowed to send the new re-INVITE until it has received the final response for the prevous (failed) re-INVITE.

So, the rule should say that it is not allowed to send an UPDATE until the timer has expired - unless a new re-INVITE is sent first.

>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.

If the invite/reinvite contains an offer, I don't think a reliable response can contain an offer. The UAS first has to send an answer, in a reliable response, and after that it cannot send a new offer in a reliable response.

>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.

If 100rel is not supported I don't think we have a problem, because there can not be any offer/answers between the re-INVITE request and response.

Regards,

Christer

> 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:
> 
> question of whether it should be part of the prior INVITE or not. To 
> be sure, lets cover the cases:
> 
> UAC (for the INVITE):
> 
>> 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:
>>
>> 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 
>> 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.
>>
>> Another possible disadvantage is that this requires the UAC and UAS 
>> to maintain enough state to accomplish the rollback.
>>
>> 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"
>>> Early in the thread I proposed separating the concerns. The 
>>> remainder of the thread had indeed focused on the o/a issues.
>>>
>>> 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* 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.
>>>>>> 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:
>>>>>>
>>>>>> by 3262 and 3311, in conjunction with 3261, I think the fixes 
>>>>>> will have to apply to those, not to 3264.
>>>>>>
>>>>>>>>>> media address ignores facts of life that may require doing 
>>>>>>>>>> it. This overlaps strongly with the session mobility 
>>>>>>>>>> discussion that is currently going on.
>>>>>>>>>>
>>>>>>>>>> media address in a media session, then we need to specify 
>>>>>>>>>> some alternative.
>>>>>>>>>>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Jul 2008 15:50:38 +0100

One comment inline:

On Jul 25, 2008, at 3:58 PM, Paul Kyzivat wrote:

> 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,
>> 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.
>
> 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.
>> 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.
> 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.

>> 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.
>
> 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)
>> issue which the MULTI-OA-TRANSACTION has. I have a potential  
>> solution, which involves the following new restrictions:
>> question of whether it should be part of the prior INVITE or not.  
>> To be sure, lets cover the cases:
>> UAC (for the INVITE):
>> 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:
>>>
>>> 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:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Another possible disadvantage is that this requires the UAC and  
>>> UAS to maintain enough state to accomplish the rollback.
>>>
>>> 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.
>>>
>>> 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:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>>> following it closely - sorry)  as  focusing _only_ on the impact  
>>>>> on the session(s) being negotiated.
>>>>> 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?
>>>> 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?
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>>>> introduced PRACK and UPDATE. The offerless-invite creates a  
>>>>>>> case when it
>>>>>>> progress
>>>>>>> creates an ambiguous situation due to the following from  
>>>>>>> section 14.1 of
>>>>>>> 3261:
>>>>>>>
>>>>>>> INVITE
>>>>>>>>> updated
>>>>>>>>> from, so
>>>>>>>>> have more
>>>>>>>>> specification. I guess this sounds like a best practices  
>>>>>>>>> draft, but its
>>>>>>>>>> UPDATE transaction, and then the old contact address  
>>>>>>>>>> disappears, it is
>>>>>>>>>> invalidated too, so the final response will not reach the  
>>>>>>>>>> UAC. Correct?
>>>>>>>>>>
>>>>>>>>>> John