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

[Paul Kyzivat <[e-mail]>]

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