Re: [Sipping] Liaison Statement on offer/answer procedures

["Ian Elz" <[e-mail]>]

Paul, Christer,

As one of the one or two people who actually care about Preconditions (Paul's email of 4 June 2008). I have been watching the conversation with interest.

My comments are included below:

Paul Kyzivat wrote on 06 June 2008 14:35:

I think we are coming to something that seems workable to me. Let me try 
to summarize:

- If a reINVITE fails, the media session state reverts to whatever it 
had been just before the reINVITE was sent, just as if the reINVITE had 
not been sent.

 [Ian Elz ] sounds fine

- If an UPDATE (inside or outside of a reINVITE) fails, any o/a in the 
UPDATE has no effect on the media session state.

 [Ian Elz ] OK, but how will we determine if an UPDATE is inside or outside a re-INVITE?

- If a PRACK (always inside a reINVITE) fails, any o/a in it has no 
effect on the media session state.

 [Ian Elz ] How does a PRACK fail? It may be possible that the whole session has gone and a 481 response is sent but that is a different scenario. The only way to reject an offer in a PRACK is to set the port numbers in the media streams to '0'. Is this a failure or not and what impact does it have on the overall session? [You may end up with no media streams.]

- If an UPDATE or PRACK inside a reINVITE succeeds, any o/a in it 
updates the new media session state being established by the reINVITE, 
but may be reverted if the reINVITE fails.

 [Ian Elz ] OK but we need something to advise if an UPDATE is inside a re-INVITE. We need to ensure that the issue highlighted in Figure 7 and associated text of draft-ietf-sipping-sip-offeranswer-08 can be handled.

- If an UPDATE outside of a reINVITE succeeds, any o/a in it updates the 
media session state without possibility of being rolled back. (It 
however may be subsequently changed with another o/a.)

[Ian Elz ] OK

- An o/a carrying unresolved preconditions SHOULD be sent in a reINVITE, 
and the reINVITE should not complete successfully until all the 
preconditions have been resolved. (Whether this is normative, or best 
practice is TBD.)

 [Ian Elz ] Mmmm! This raises an interesting issue. If there are multiple media streams each of which use precondition attributes then the first SDP answer will request confirmation of resource reservation for each media stream. At present there I nothing to prevent the originating UA from sending an UPDATE with confirmation of resource reservation for one media stream while the other media stream remains unresolved. What is being suggested will prevent that from occurring. The originating UA will need to wait until all media streams are reserved before sending an UPDATE. I am not in disagreement with this approach but it needs to be stated. 
[This does not however prevent two separate SDP offers to confirm resource reservation for different media streams with some media streams being confirmed by an SDP Offer in the PRACK and the rest using an additional SDP offer in an UPDATE.]

IMO there are still issues about when changes that might be rolled back 
take effect. But lets first see if we can get agreement on the above 
before worrying about that.

[Ian Elz ] There are also some other interesting sequences which will need to be resolved. One of interest is a re-INVITE with no SDP offer where the offer is returned in the 1xx reliable provisional response. This situation may result in precondition confirmation attributes being sent in both directions which may challenge the proposal that unresolved preconditions SHOULD be sent in a re-INVITE. This scenario extends the precondition negotiation and may require using UPDATE for unresolved preconditions.

	Thanks,
	Paul

Christer Holmberg wrote:
> Hi,
> 
>>>> Regarding SDP:
>>>>
>>>> I think the likely candidates are:
>>>>
>>>> 1) as specified in 3261, and contrary to 3264, if a reinvite fails, the SDP/media-session state rolls back to what it was before the reinvite. This is so even if there answers were transmitted
>>>> reliably via PRACK and/or UPDATE.
>>>>
>>>> 2) Once an answer has been transmitted reliably, it is committed, and is not rolled back if the reinvite subsequently fails.
>>>>
>>>> Of these, (2) is probably easier to understand and implement. And its probably semantically reasonable, except for one case:
>>>>
>>>> That case relates to preconditions. Using preconditions, you can get into a state where an offer/answer has completed, but preconditions have not been satisfied, so the media stream is not
>>>> usable. It is then expected that a subsequent o/a exchange will improve upon this, and eventually result in usable media streams. If each o/a is committed independently, then a previously
>>>> working can be replaced with an unusable state until a further o/a fixes it, and if a further o/a doesn't fix it then it remains permanently broken.
>>>>
>>>> (An example of this might be starting from a working low bandwidth audio session. A reinvite is then sent with an attempt to upgrade to a wideband codec with preconditions used to condition the
>>>> change on obtaining sufficient bandwidth. In this case you would like to continue to use the low bandwidth codec until you know if you have obtained the resources for the wideband.)
>>>>
>>>> Note that this problem exists even without reinvite. It can occur if an update to a working session is initiated using UPDATE with preconditions.
>>>>
>>>> IMO this is an intrinsic problem with preconditions. Because they aren't widely used, it may be prudent to split off fixing that as a separate task. If that is done, then I think (2) above is
>>>> probably a good way to solve the rest of the problem.
>>>>
>>>> To solve the precondition problem I think we need a concept like o/a-transaction. A single o/a pair is an o/a-transaction if it contains no unsatisfied preconditions. But an o/a that has
>>>> unsatisfied preconditions results in an incomplete o/a-transaction. Additional o/a pairs continue to be part of it until a final o/a pair where the preconditions are satisfied. That ends the
>>>> o/a-transaction. A failure in the midst of an o/a-transaction (signaled in the enclosing protocol like
>>>> sip) would revert to the session state in effect before the beginning of the o/a-transaction.
>>>>
>>>> I would expect this direction for preconditions to be controversial.
>>>> (Among the one or two people who actually care about preconditions.) Which is a good reason to split it off from the rest.
>>> I do NOT think we should fix pre-conditions as a separate task - it will only make things even more complicated.
>> OK - lets discuss the pros and cons.
>>
>>> We should not not dig into different SDP parameters, attributes etc, and define rules for each of them.
>> I would rather not. But the preconditions introduced the need for this
>> "extended transaction". I don't know of any other cases like that. (If
>> there are others, will people please bring them up?)
> 
> I am not aware of other use-cases either. But, they may of course come in future, so therefor I think there should be clear rules, and people will then have to design their use-cases according to those. For example, if one needs multiple o/a transactions, but wants to avoid a possible full fallback, he should use multiple "stand alone" UPDATEs instead of re-INVITE with intermediate PRACK/UPDATEs.
> 
>>> Now, speaking with a 3GPP hat on, I actually think that pre-conditions IS the use-case most people have had in mind. We are talking about cases when new media types/streams are added mid-call, and additional radio resources etc need to be reserved for that.
>> Well, if that is the case 3GPP is asking for a solution to, then I guess there is urgency in solving the precondition case, whether it is a special case or not.
> 
> Yes. 
> 
> But, still, I think that it would be good for 3GPP, and everyone else for that matter, to have a generic rule - before people start implementing all kinds of other use-cases and it will be more difficult.
> 
> 
>>> For non-pre-condition use-case I think you normally ould send a re-INVITE and get a 200 OK reply - without anything in between.
>> I don't know if you meant *c*ould or *w*ould above. :-)
> 
> Would :)
> 
> And, again, if you have a use-case where you do not want a full fallback in case of a re-INVITE failure, use stand alone UPDATEs.
> 
> 
>> In any case, I guess it depends on what you mean by "normally". For the
>> addition of another media stream (say adding video to an audio call) it
>> may be necessary to get permission from the callee before allowing the
>> reINVITE to succeed or fail. But there may be a desire to negotiate the
>> media stream in the meantime, even without preconditions, so reliable
>> provisionals might be used.
> 
> Sure. But, if we say a full fallback would happen also in that case people would have to take that into consideration when implementing such use-cases.
> 
> 
>>> So, IF 1) is the best solution for pre-conditions I would strongly suggest that we go for that, and anyone implementing whatever re-INVITE use-cases should keep that in mind.
>> For (1) to solve the problem for preconditions it would then be
>> necessary to ban the use of UPDATE outside of a reINVITE for offers that
>> have unresolved preconditions. I guess we could do that.
> 
> I am not sure we need to ban anything. If someone - for whatever reason - want to implement pre-conditions (or whatever use-case) which require multiple o/a transactions, but do NOT want to risk a full fallback, he should use multiple stand-alone UPDATEs instead. Then, if one UPDATE fails, previous UPDATEs are not rolled back.
> 
> 
>> *IF* people like (1) as the answer, then there are additional details to
>> work out. In particular, when does the new stream get put into operation?
>>
>> - does it become enabled for use, concurrently with the old one,
>>   as soon as it is known to each party? (and then be rolled back
>>   if there is a subsequent failure)
>>
>> - or does it simply get negotiated, but not be used until success of
>>   the reINVITE, at which point it replaces the old stream.
>>
>> - does it matter if the change is just new attributes to the existing
>>   stream vs an entirely new stream (different address)?
>>
>> Its going to be difficult for a lot of implementations to support
>> concurrent use of the old and the new on the same address/port.
> 
> I agree, but e.g. in the case of adding a new stream you probably don't touch the address/port for the existing streams. You will have to support the address/port for both the new stream and the old stream.
> 
> Your case is valid if I want to change the address/port for an existing stream. Now, there are probably use-cases for that, but maybe you don't need multiple o/a transactions for that (unless you use pre-conditions). And, if you DO need multiple o/a transactions, you just need to make sure you can handle it somehow .
> 
> Personally I would say that the whole thing is an impelementation issue. There are so many things, including hardware limitations, to take into consideration, and it is really difficult to say exactly what/when happens on the media plane between the re-INVITE request and final response (that is true even for the initial INVITE and final response - because the "you-must-be-able-to-listen-as-soon-as-you-have-sent-the-INVITE" rule doesn't always work in reality.
> 
> So, there are things people will have to think about when implementing their use-case, but unless we have clear rules on what happens when the re-INVITE fails it is very difficult to implement - at least if we care about interoperability etc :)
> 
> Regards,
> 
> Christer
> 
>  
> 
>  
> 
>  
> 
>>
>>
>>
>>
>>
>> Christer Holmberg wrote:
>>> Hi,
>>>
>>> I agree with Paul that we probably aren't talking about changes to 3264 here.
>>>
>>> Also, I am fine if we want to decouple "committings" of media data/SDP updates with other types of data updates (contact etc).
>>>
>>> But, that means that we need to specify specific "committing" rules for any type of data which can be affected. Or, we can of course have a "default committing rule" (e.g. full rollback), and then specify different rules for specific type of data when/if needed.
>>>
>>> But, for the SDP data, would anyone object to a full rollback?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> ________________________________
>>>
>>> From: Paul Kyzivat [mailto:[e-mail]]
>>> Sent: Wed 04/06/2008 17:32
>>> To: Gonzalo Camarillo
>>> Cc: Christer Holmberg; Elwell, John; sipping List; Mary Barnes
>>> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>>>
>>>
>>>
>>> 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-offeranswe
>>>> r-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