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

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Jun 2008 10:02:09 +0300

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jun 2008 11:32:17 -0400

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

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 4 Jun 2008 13:09:20 -0400

Agree with Paul here about decoupling things like remote target update from offer-answer updates in re-Invite. One of the rules that makes sense is if there is a provisional response to the re-Invite, the non-media updates will not be rolled back even if later the re-Invite transaction fails. If there is no provisional response then the transaction is atomic and all of it is rolled back in case of failure.

Thanks,
Sanjay

>[mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
>Sent: Wednesday, June 04, 2008 11:32 AM
>To: Gonzalo Camarillo
>Cc: sipping List; Elwell, John; Mary Barnes; Christer Holmberg
>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:
>
>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:
>> 
>> 
>> 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,
>>>  
>>> 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
>>>  
>>>  
>>>
>>> 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,
>>>>
>>>>
>>>>> 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
>>>> 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

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Jun 2008 23:04:18 +0200

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:[email-masked]]
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,

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jun 2008 18:39:43 -0400

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.

	Thanks,
	Paul

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 4 Jun 2008 22:50:00 -0400

If precondition is treated as a separate case, then are there other use cases where UAS would need to send answer in provisional response to re-Invite. IMO, in majority of cases 200 OK would carry answer to offer in re-Invite/UPDATE.

Sanjay

>Sent: Wednesday, June 04, 2008 6:40 PM
>To: Christer Holmberg
>Cc: sipping List; Elwell, John; Gonzalo Camarillo; Mary Barnes
>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.
>
>(Among the one or two people who actually care about 
>preconditions.) Which is a good reason to split it off from the rest.
>
>	Thanks,
>	Paul
>
>Christer Holmberg wrote:
>> Hi,
>>  
>> 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.
>>  
>> 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.)
>> 
>> creates an ambiguous situation due to the following from 
>section 14.1 
>> of
>> 3261:
>> 
>> 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.
>> 
>>> 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,
>>>>
>>>>>> *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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Jun 2008 07:12:25 +0200

Hi, 

>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.
>
>(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. We should not not dig into different SDP parameters, attributes etc, and define rules for each of them.

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.

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.

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.

Regards,

Christer

Christer Holmberg wrote:
>> The thing is that when working on the offer/answer usage draft below, 
>> document the current issues (like we are doing with RFC 3261) for a future update.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>>
>> Christer Holmberg wrote:
>>> Hi,
>>>
>>> more specification. I guess this sounds like a best practices draft, 
>>>>> *something*. If we are going to say that you shouldn't change the 
>>>> 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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Jun 2008 07:19:31 +0200

Hi,

>If precondition is treated as a separate case, then are there other use cases where UAS would need to send answer in provisional response to re-Invite. IMO, in majority of cases 200 OK would 
>carry answer to offer in re-Invite/UPDATE.

I agree. I am not aware of other use-cases.

And, even if there are other use-case, I still think that in the majority of those the SDP offer of the re-INVITE request itself will carry the "main" media changes. I don't think you would normally add streams etc using the intermediate UPDATE/PRACKs.

Regards,

Christer

>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.
>
>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 
>(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 
>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.
>
>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
>full rollback), and then specify different rules for specific type of 
>data when/if needed.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Jun 2008 11:00:39 -0400

Inline

Christer Holmberg wrote:
> 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?)

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

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.

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

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.

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

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

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Jun 2008 14:55:38 +0200

Hi,

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

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

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

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

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

>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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jun 2008 09:34:30 -0400

Crister,

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.

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

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

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

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

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

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.

	Thanks,
	Paul

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 6 Jun 2008 16:43:14 +0200

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:

 [Ian Elz ] sounds fine

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

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

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

[Ian Elz ] OK

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

[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

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Jun 2008 20:12:02 +0200

Hi,

Yes.

Yes.

Yes.

Yes.

Yes. 

>preconditions have been resolved. (Whether this is normative, or best
 
I guess this is more a precondition issue than an o/a issue, isn't it?

Yes.
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Jun 2008 20:34:52 +0200

Hi,
 
>[Ian Elz ] OK, but how will we determine if an UPDATE is inside or outside a re-INVITE? 
 
[Christer] I assume that any stateful entity must know whether it has a pending re-INVITE transaction for a specific call or not.

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

How-to-reject-a-PRACK is another open issue that we have been discussing for a long time, and different solutions have been proposed (see the offer-answer draft). 
Let's keep that out of that thread, and assume that the PRACK is rejected somehow :)

>[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.
>
>
>
>[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.]
>[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.
>
[Christer] As I wrote in my previous reply, I am not sure we should go so much into the precondition procedures themselves as part of this task. I think it's enough if we say what the SDP status is in case of a failure. You do raise interesting questions, though, and maybe we need to look into that as a separate task.

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Fri, 6 Jun 2008 15:22:01 -0400

Christer,

One comment inline ... 

>[mailto:[email-masked]] On Behalf Of Christer Holmberg
>Sent: Friday, June 06, 2008 2:35 PM
>To: Ian Elz; Paul Kyzivat (pkyzivat)
>Cc: Elwell, John; sipping List; Gonzalo Camarillo; Mary Barnes
>>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.
>>
>>I think we are coming to something that seems workable to me. Let me 
>>try to summarize:
>>
>[Christer] I assume that any stateful entity must know whether 
>it has a pending re-INVITE transaction for a specific call or not.

But is a UA allowed to send UPDATE while re-Invite transaction hasn't
completed? 

It is not clear whether it is legal or not because of conflicting text
in RFC 3261.
Here is text from sec. 14.1, which suggests this is legal:
	
   However, a UA MAY initiate a regular transaction while an INVITE
   transaction is in progress.

And according to the following text from sec. 28, this call flow is
illegal.

   o  RFC 2543 was silent on whether a UA could initiate a new
      transaction to a peer while another was in progress.  That is now
      specified here.  It is allowed for non-INVITE requests, disallowed
for INVITE.

Sanjay

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 06 Jun 2008 13:15:18 -0700

> [Christer] I assume that any stateful entity must know whether it has a pending re-INVITE transaction for a specific call or not.

That's not actually enough. A UAS (or dialog stateful proxy) cannot know 
whether an UPDATE received shortly after a 2xx is sent upstream was sent 
before or after the 2xx was received by the UAC. We could add an 
explicit indication to that effect, I suppose...

Anders

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Jun 2008 23:11:30 +0200

Hi,
 
>      specified here.  It is allowed for non-INVITE requests, disallowed

The preconditions mechanism uses UPDATEs while the INVITE is still pending, so I see no reason why it shouldn't be allowed also for re-INVITE (a re-INVITE is a mid-call INVITE, so.. :)

Of course, the UPDATE cannot carry a new SDP offer unless you still haven't received an answer for your previous offer.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jun 2008 17:57:05 -0400

> I guess this is more a precondition issue than an o/a issue, isn't it?

The two are highly intertwined.

I'd rather not leave loose ends that we know about if we could easily 
tie them up. But if this is contentious then it could be left for 
another BIS to 3312.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jun 2008 18:03:23 -0400

Sanjay,

If the reasoning you lay out actually prohibits use of UPDATE in a 
reINVITE, then it must also prevent use of PRACK in a reinvite. And it 
doesn't distinguish between reINVITE and initial INVITE, so that would 
be true there, breaking reliable provisional responses.

But section 28 is not normative, so we shouldn't take it too seriously.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jun 2008 18:05:25 -0400

Anders Kristensen wrote:
> 
> Christer Holmberg wrote:
>>> - If an UPDATE (inside or outside of a reINVITE) fails, any o/a in 
>>> the UPDATE has no effect on the media session state.
>> [Christer] I assume that any stateful entity must know whether it has 
>> a pending re-INVITE transaction for a specific call or not.
> 

Yes. Taking this approach to the current problem requires that we find a 
solution to knowing whether the update was sent inside the reinvite or not.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jun 2008 18:38:25 -0400

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

I think you misunderstand me. I should have been more careful of my 
wording. I should have said:

"An o/a carrying unresolved preconditions SHOULD be sent within the 
scope of a (reI)NVITE *transaction*. This includes the (re)INVITE, 
reliable provisional responses to the (re)INVITE, and PRACK and UPDATE 
transactions sent within the span of that (re)INVITE transaction.
The reINVITE should not complete successfully until all the
preconditions have been resolved."

This is what I meant, but I didn't say it well enough. I used (re)INVITE 
above because this applies to the initial invite too.

What this excludes is:
- getting started negotiating preconditions within a (re)INVITE,
   but then sending a 200 for the (re)INVITE before the preconditions
   have been resolved.

- sending an o/a with *unresolved* preconditions in an UPDATE that
   is not nested within a (re)INVITE. (This *may* mean you can't
   use UPDATE outside of INVITE with preconditions at all. Can
   the offer claim the preconditions are resolved, but the
   answer state that they are not?)

> [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 provision…

I think the above covers this case.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 7 Jun 2008 13:05:16 +0200

Hi,
 
>solution to knowing whether the update was sent inside the reinvite or not.

If the UAS sends a 2xx response to the re-INVITE I guess it really doesn't matter when the UPDATE was sent.

But, if the UAS sends a non-2xx response to the re-INVITE I guess it would need to know when the UPDATE was sent: was it sent still assuming that the re-INVITE will succeed, OR was it sent bacause the re-INVITE did NOT succeed?

If we would go for the non-rollback alternative we wouldn't have this problem since the re-INVITE failure response doesn't affect UPDATE/PRACK offer/answers, and then it doesn't matter when the UPDATE was sent.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 07 Jun 2008 13:42:45 -0400

> If we would go for the non-rollback alternative we wouldn't have this problem since the re-INVITE failure response doesn't affect UPDATE/PRACK offer/answers, and then it doesn't matter when the UPD…

Exactly! That is an advantage of the non-rollback solution.
But the rollback solution has the advantage of providing a solution to 
the precondition rollback problem.

We need to pick our poison.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 8 Jun 2008 01:58:44 +0200

Hi,
 
>We need to pick our poison.
 
Let's discuss the non-rollback alternative for a while.

For the pre-conditions case, when the re-INVITE fails, it most likely means that the UAS finally chose not to accept whatever was proposed in the re-INVITE request (maybe a new stream). Now,  before the re-INVITE failure response, intermediate o/a transactions may have succeeded, resources may have been reserved etc, e.g. because the UAS user wasn't "asked" about the new stream until a certain point.

So, since the re-INVITE failure response now wouldn't affect the suceeded intermediate o/a transactions, I guess the UAC (or UAS) would have to initiate a "manual fallback", by sending a new re-INVITE/UPDATE offer, with the SDP that was used before the previous failed re-INVITE request was sent - or maybe try some different offer (maybe it simply isn't possible to fall back to exactly the same SDP state as before the failed re-INVITE).

So, the non-rollback alternative would work also for pre-conditions, assuming the UAC does the "manual fallback", and we wouldn't have the race-condition problem that Anders brought up. 

Also, wouldn't automatically "force" the SDP state back to it's previous state, in case it for whatever reason isn't possible for the UAC/UAS. We would give the users more choise on how to deal with the situation.

Comments?

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 8 Jun 2008 08:23:19 -0400

What about backward compatibility with UA which do not follow this
manual rollback mechanism?

>Sent: Saturday, June 07, 2008 7:59 PM
>To: Paul Kyzivat (pkyzivat)
>Cc: Elwell, John; Mary Barnes; sipping List; Gonzalo Camarillo
>>>>>>> - If an UPDATE (inside or outside of a reINVITE) fails, any o/a 
>>>>>>> in the UPDATE has no effect on the media session state.
>>>>>> [Christer] I assume that any stateful entity must know 
>whether it 
>>>>>> has a pending re-INVITE transaction for a specific call or not.
>>>>> That's not actually enough. A UAS (or dialog stateful 
>proxy) cannot 
>>>>> know whether an UPDATE received shortly after a 2xx is sent 
>>>>> upstream was sent before or after the 2xx was received by 
>the UAC. 
>>>>> We could add an explicit indication to that effect, I suppose...
>>>> Yes. Taking this approach to the current problem requires that we 
>>>> find a solution to knowing whether the update was sent 
>inside the reinvite or not.
>>>
>>>If the UAS sends a 2xx response to the re-INVITE I guess it 
>really doesn't matter when the UPDATE was sent.
>>
>>>But, if the UAS sends a non-2xx response to the re-INVITE I 
>guess it would need to know when the UPDATE was sent: was it 
>sent still assuming that the re-INVITE will succeed, OR was it 
>sent bacause the re-INVITE did NOT succeed?
>>
>>>If we would go for the non-rollback alternative we wouldn't 
>have this problem since the re-INVITE failure response doesn't 
>affect UPDATE/PRACK offer/answers, and then it doesn't matter 
>when the UPDATE was sent.
>>
>For the pre-conditions case, when the re-INVITE fails, it most 
>likely means that the UAS finally chose not to accept whatever 
>was proposed in the re-INVITE request (maybe a new stream). 
>Now,  before the re-INVITE failure response, intermediate o/a 
>transactions may have succeeded, resources may have been 
>reserved etc, e.g. because the UAS user wasn't "asked" about 
>the new stream until a certain point.
>
>So, since the re-INVITE failure response now wouldn't affect 
>the suceeded intermediate o/a transactions, I guess the UAC 
>(or UAS) would have to initiate a "manual fallback", by 
>sending a new re-INVITE/UPDATE offer, with the SDP that was 
>used before the previous failed re-INVITE request was sent - 
>or maybe try some different offer (maybe it simply isn't 
>possible to fall back to exactly the same SDP state as before 
>the failed re-INVITE).
>
>So, the non-rollback alternative would work also for 
>pre-conditions, assuming the UAC does the "manual fallback", 
>and we wouldn't have the race-condition problem that Anders 
>brought up. 
>
>Also, wouldn't automatically "force" the SDP state back to 
>it's previous state, in case it for whatever reason isn't 
>possible for the UAC/UAS. We would give the users more choise 
>on how to deal with the situation.
>
>Comments?
>
>Regards,
>
>Christer
>
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 8 Jun 2008 20:29:50 +0200

>What about backward compatibility with UA which do not follow this manual rollback mechanism?
 
What about backward compability with UA which doesn't do full fallback, if we chose that altenative?
 
I don't think there are - yet - too many implementations out there doing re-INVITEs with intermeidate offer/answer in the first place, so I don't think backward compability is a big problem.
 
But, I can forsee implementations that WILL implement this (this is the reason 3GPP need a solution, for example), so therefor I think it is important that we make a decission now.
 
But, to answer your question:
 
In a pre-condition case there are most likely going to be resources reserved for no good, and I am sure either/both user is going to detect that things don't work as they should (a UAC that wanted to add a media stream is not going to get any media from the other end, which rejected the re-INVITE, etc).
 
Regards,
 
Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Jun 2008 13:18:31 +0300

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:
>> identified: roll back and address changes during ongoing transactions. 
>> I would like to see a list of such pending updates in order to decide

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Jun 2008 10:24:52 -0400

Gonzalo Camarillo wrote:
> RFC 3264...

It also may revise 3261.

The issue of preconditions *may* require us to revise 3264 as well - 
recognizing that individual O/A pairs may not be atomic in the case of 
preconditions - that is some cases there may be a sequence of changes 
that need to be rolled back. (While still leaving the mechanism for 
triggering this rollback to the using protocol.) Do others see a need 
for this?

(The split off of 3264 was done so that it could apply to o/a done in 
other protocols as well as sip. AFAIK there still aren't any of those, 
so it feels like we are playing a politically correct game. It would be 
easier to just address the problem wrt sip. But we should work to 
continue the distinction.)

> do people agree that the way to document the resolution of 
> this issue would be to write a new RFC

Yes

> that would clarify how 
> offer/answer works with re-INVITEs, PRACKs, and UPDATEs,

Yes

> and would include discussions on preconditions?

Yes.

Should this just be a standalone RFC, or should it be tied into the new 
revision process?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Jun 2008 10:51:12 -0400

response at end.

> Also, wouldn't automatically "force" the SDP state back to it's previous state, in case it for whatever reason isn't possible for the UAC/UAS. We would give the users more choise on how to deal wit…

Before answering that, I think there is a related issue of when the o/a 
changes actually take effect. Is it *immediately* (when the offer is 
sent and when the answer is sent), or is it only when all the 
preconditions have been resolved?

Consider a case where what is proposed is a codec change - to a higher 
bandwidth codec. Until the increased bandwidth is obtained, you can't 
really use the new codec. But the situation is reversed for downgrading 
- you need to switch to the lower bandwidth codec *before* giving up 
bandwidth. This could be solved by initially offering both the old and 
new codecs, along with proposing the bandwidth change. The switch in 
which codec is used would happen appropriately. But that depends on some 
careful conventions for codec usage, and we know there are 
implemenations out that that can't actually support simultaneous use of 
multiple codecs.

Even that doesn't fully resolve the problem. Suppose you had previously 
negotiated a bandwidth of B1 and have been happily using it. Then you 
decide to switch to bandwidth B2 ( which is > B1) and send an offer with 
preconditions for this, indicating that it isn't yet satisfied. If you 
get an answer that leaves this unresolved, what do you have? Can you 
assume you still have the old bandwidth, or not?

Life gets simpler if we assume that none of the o/a changes in the 
context of a reINVITE (and PRACKs and UPDATEs within the reINVITE scope) 
take effect until the successful completion of the reINVITE. (As 
contrasted to having them take effect immediately and then be rolled 
back on a failure.)

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 9 Jun 2008 19:41:49 +0200

Hi,

>>For the pre-conditions case, when the re-INVITE fails, it most likely means that the UAS finally chose not to accept whatever was proposed in the re-INVITE request (maybe a new 
>>stream). Now,  before the re-INVITE failure response, intermediate o/a transactions may have succeeded, resources may have been reserved etc, e.g. because the UAS user wasn't 
>>"asked" about the new stream until a certain point.
>>
>>So, since the re-INVITE failure response now wouldn't affect the suceeded intermediate o/a transactions, I guess the UAC (or UAS) would have to initiate a "manual fallback", by 
>>sending a new re-INVITE/UPDATE offer, with the SDP that was used before the previous failed re-INVITE request was sent - or maybe try some different offer (maybe it simply isn't 
>>possible to fall back to exactly the same SDP state as before the failed re-INVITE).
>>
>>Also, it wouldn't automatically "force" the SDP state back to it's previous state, in case it for whatever reason isn't possible for the UAC/UAS. We would give the users more choise >>on how to deal with the situation.
>

Well, it depends on the use-case. If the UAC is offerin a new stream, it most likely will have to reserve resources (IP address/port, codecs etc) for it before the pre-conditions are met. Of course, it will not start to use them before the pre-conditions have been met.

More on this below, when discussing your codec downgrade use-case.

>really use the new codec.

Correct.

>But the situation is reversed for downgrading - you need to switch to the lower bandwidth codec *before* giving up
>bandwidth.

Well, if you KNOW you are going to downgrade the bandwidth I guess you don't need preconditions in the first place. You just send a re-INVITE/UPDATE without pre-conditions, and I doubt the network will "complain".

But, if you don't know, I guess it very much depends on what access network technology, QoS mechanisms etc you are using. I think a downgrade will happen very fast, so I don't think the high-bandwidth codec would be used for a very long time.

Also, the issue you are describing exists even when a 200 OK response is sent to the re-INVITE, so... :)

>This could be solved by initially offering both the old and new codecs, along with proposing the bandwidth change. The switch in
>which codec is used would happen appropriately. But that depends on some careful conventions for codec usage, and we know there are
>implemenations out that that can't actually support simultaneous use of multiple codecs.

Yes. So, again, I think this is an implementation issue, and people need to be careful when downgrading.

>assume you still have the old bandwidth, or not?

Again, implementation issue. It's impossible to, for different kind of access network technologies, QoS techniques etc, specify exactly what happens at a certain time.

Also, in the case you describe something has most likely gone wrong somewhere, so the bandwidth status could be whatever...

>contrasted to having them take effect immediately and then be rolled

I don't think we can assume that.

Take the initial INVITE for example. The negotiated codecs etc take affect once the preconditions have been met - which can happen long before the final re-INVITE final response comes (in many cases the UAS doesn't get alterted until the preconditions are met).

Regards,

Christer

---

From: <[email-masked]>
Date: Tue, 10 Jun 2008 15:22:56 +0300

Dear all,

This looks like a useful discussion, thanks!

A simple binary answer could be conveyed reliably between the companies,
but as we are not converging towards anything as simple as that, I would
appreciate if the result and the way forward could be captured in a
short document or letter that could be used as a reply to the CT1 LS,
please.

Knowing our liaison statement procedures differ between IETF and 3GPP I
do not know which way the reply should be sent back to us, but the main
thing is to somehow document the decisions that I hope we can get as the
outcome of this discussion. 

If that can be done, then we can transport the reply via the nominated
contact persons (Gonzalo and myself), via contribution by companies (or
even people like Christer) who are active in both IETF and 3GPP, or as a
formal LS back to CT1.

But if a solution can be found, it is more useful to document it to
minimise the time CT1 needs to de-cipher it.

I have already put this item on the 3GPP - IETF conference call agenda
for today, so those who have already got the invitation are welcome give
their views there.

BR,
Hannu Hietalahti
3GPP CT chairman
Mobile phone: +358 40 5021724

>[mailto:[email-masked]] On Behalf Of ext Christer Holmberg
>Sent: 09 June, 2008 20:42
>To: Paul Kyzivat
>Cc: sipping List; Elwell, John; Mary Barnes; Gonzalo Camarillo
>>>For the pre-conditions case, when the re-INVITE fails, it 
>most likely 
>>>means that the UAS finally chose not to accept whatever was proposed 
>>>in the re-INVITE request (maybe a new stream). Now,  before 
>the re-INVITE failure response, intermediate o/a transactions 
>may have succeeded, resources may have been reserved etc, e.g. 
>because the UAS user wasn't "asked" about the new stream until 
>a certain point.
>>>
>>>So, since the re-INVITE failure response now wouldn't affect the 
>>>suceeded intermediate o/a transactions, I guess the UAC (or 
>UAS) would 
>>>have to initiate a "manual fallback", by sending a new 
>re-INVITE/UPDATE offer, with the SDP that was used before the 
>previous failed re-INVITE request was sent - or maybe try some 
>different offer (maybe it simply isn't possible to fall back 
>to exactly the same SDP state as before the failed re-INVITE).
>>>
>>>So, the non-rollback alternative would work also for pre-conditions, 
>>>assuming the UAC does the "manual fallback", and we wouldn't 
>have the race-condition problem that Anders brought up.
>>>
>>>Also, it wouldn't automatically "force" the SDP state back 
>to it's previous state, in case it for whatever reason isn't 
>Well, it depends on the use-case. If the UAC is offerin a new 
>stream, it most likely will have to reserve resources (IP 
>address/port, codecs etc) for it before the pre-conditions are 
>met. Of course, it will not start to use them before the 
>pre-conditions have been met.
>
>>But the situation is reversed for downgrading - you need to switch to 
>>the lower bandwidth codec *before* giving up bandwidth.
>
>Well, if you KNOW you are going to downgrade the bandwidth I 
>guess you don't need preconditions in the first place. You 
>just send a re-INVITE/UPDATE without pre-conditions, and I 
>doubt the network will "complain".
>
>But, if you don't know, I guess it very much depends on what 
>access network technology, QoS mechanisms etc you are using. I 
>think a downgrade will happen very fast, so I don't think the 
>high-bandwidth codec would be used for a very long time.
>
>Also, the issue you are describing exists even when a 200 OK 
>response is sent to the re-INVITE, so... :)
>
>>This could be solved by initially offering both the old and 
>new codecs, 
>>along with proposing the bandwidth change. The switch in 
>which codec is 
>>used would happen appropriately. But that depends on some 
>Yes. So, again, I think this is an implementation issue, and 
>people need to be careful when downgrading.
>
>
>>decide to switch to bandwidth B2 ( which is > B1) and send an offer 
>>with preconditions for this, indicating that it isn't yet 
>satisfied. If 
>>you get an answer that leaves this unresolved, what do you have? Can 
>>you assume you still have the old bandwidth, or not?
>
>Again, implementation issue. It's impossible to, for different 
>kind of access network technologies, QoS techniques etc, 
>specify exactly what happens at a certain time.
>
>Also, in the case you describe something has most likely gone 
>wrong somewhere, so the bandwidth status could be whatever...
>
>
>>context of a reINVITE (and PRACKs and UPDATEs within the reINVITE 
>>scope) take effect until the successful completion of the 
>reINVITE. (As 
>Take the initial INVITE for example. The negotiated codecs etc 
>take affect once the preconditions have been met - which can 
>happen long before the final re-INVITE final response comes 
>(in many cases the UAS doesn't get alterted until the 
>preconditions are met).
>
>Regards,
>
>Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jun 2008 08:58:41 -0400

cHietalahti,

I will defer to others on formal liason procedures. But it is becoming 
clear that there will need to be a standards track document to deal with 
this - initially a draft and eventually an RFC. The draft will probably 
be the first formal output that is useful to you. At the moment we are 
still hashing out what that draft ought to say.

	Thanks,
	Paul

[email-masked] wrote:
> cHietalahti

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Jun 2008 15:25:57 +0200

Hi,
 
I think (and hope) that we can make a decission regarding the re-INVITE fallback issue "on the list", because I think we have a rather good understanding of both alternatives now. 
 
We can then inform 3GPP about that decission, and than start to discuss how/what we are going to document things in IETF.
 
Regards,
 
Christer

Lähettäjä: Paul Kyzivat [mailto:[email-masked]]
Lähetetty: ti 10.6.2008 14:58
Vastaanottaja: [email-masked]
Kopio: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]; Gonzalo Camarillo
Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures

cHietalahti,

        Thanks,
        Paul