Subject: RE: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Jul 2006 22:14:00 +0300

Hi,

I don't understand this "proposed media states" thing. 

An offer (or answer) is not a parameter value you can store, and apply when the time is right. An offer (or answer) needs to br processed when received - and that processing will affect resources, DSPs etc. Streams may be added or removed.

I don't think the offer/answer transaction outcome should be dependent on the SIP messages used for it. If an offer/answer transaction succeeds the new media state becomes active. I have never heard about a "proposed media state"...

Regards,

Christer

________________ Reply Header ________________
Subject:	RE: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01
Author:	"Michael Hammer (mhammer)" <[email-masked]>
Date:		25th July 2006 10:31:11 am

Paul,

I am saying that although the PRACKs and UPDATES may advance the
*proposed* media states, they don't get committed until the INVITE that
started it is complete.  Otherwise, if you applied the same principles
as a re-INVITE on an original INVITE, you would be saying that the call
failed, but the media state is active instead of idle.

Mike

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat) 
> Sent: Tuesday, July 25, 2006 9:07 AM
> To: Michael Hammer (mhammer)
> Cc: Christer Holmberg (JO/LMF); [email-masked]; 
> [email-masked]
> Subject: Re: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01
> 
> 
> 
> Michael Hammer (mhammer) wrote:
> > WOW!  What a discussion.  Sorry I didn't jump in sooner.
> > 
> > May I suggest a simple test to verify correctness:  An INVITE and a 
> > re-INVITE should be isomorphic.  By that I mean that the 
> result should 
> > be the same.
> > 
> > Some of the suggested "committed" states would leave an original 
> > INVITE transaction which got a >3xx response in a state 
> where the call 
> > failed, but the media succeeded.  Doesn't make sense to me.
> 
> Can you say more. I am not following your logic.
> 
> > My logic in all this is that while the initial INVITE succeeded
> > (200/ACK) and created stable call and media state, all the 
> subsequent 
> > re-INVITE/PRACK/UPDATE stuff was just haggling about the 
> next proposed 
> > state and in effect is just early media.  It doesn't become 
> committed 
> > call/media state until the re-INVITE gets 200/ACK.
> 
> I think you are agreeing with my position, but am not sure.
> 
> > The next suggestion:  If you want to commit call/media states in 
> > smaller steps, make sure you keep doing the 200(INVITE)/ACK 
> to commit 
> > before jumping to the next stable state.  In other words, 
> if all this 
> > ugliness hurts, don't do it. :)
> > 
> > My $.02 from the peanut gallery,
> > Mike
> > 
> > 
> >> -----Original Message-----
> >> From: Christer Holmberg (JO/LMF)
> >> [mailto:[email-masked]]
> >> Sent: Sunday, July 23, 2006 3:25 AM
> >> To: Paul Kyzivat (pkyzivat); [email-masked]
> >> Cc: [email-masked]
> >> Subject: VS: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01
> >>
> >> Hi,
> >>
> >>> There may be some value in looking at preconditions as
> >> introducing some
> >>> added requirements. But I think that can be left to 
> another day. (An 
> >>> example of when this might come into play is when using
> >> UPDATE (without
> >>> reinvite) to add a stream using preconditions, which will require 
> >>> multiple UPDATES.)
> >> As I wrote in another mail, an alternative to allowing 18x 
> responses 
> >> for a re-INVITE would be to use multiple UPDATEs instead. Then it 
> >> would be much easier to "keep control", because if an  
> UPDATE fails 
> >> there is no possibility that there may have been other 
> offer/answer 
> >> transactions between the UPDATE request and failure response.
> >>  
> >> Regards,
> >>  
> >> Christer
> >>  
> >>
> >> _______________________________________________
> >> Sipping mailing list  
> https://www1.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://www1.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: Tue, 25 Jul 2006 16:25:08 -0400

> I don't understand this "proposed media states" thing. 

Would you be happier if we called it "provisional media states"?

> An offer (or answer) is not a parameter value you can store, and apply when the time is right. An offer (or answer) needs to br processed when received - and that processing will affect resources,…

Reinvite already requires this. Between the reinvite and the final 
response to it, the offerer and answerer are expected to be able to 
receive at both the old and the new. Sending can in principle go to 
either the old or the new.

I know this is troublesome and difficult, and maybe impossible, but that 
is what is specified. It could be another candidate for clarification.

As long as you are prepared to handle one provisional thing, how much 
harder is it to allow that provisional thing to change and then still 
eventually either make it permanent or drop it.

> I don't think the offer/answer transaction outcome should be dependent on the SIP messages used for it. If an offer/answer transaction succeeds the new media state becomes active. I have never hear…

It isn't written anywhere. It is part of trying to clarify all of this 
and make it self consistent. Doing as you propose has significant problems.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 26 Jul 2006 07:50:38 +0200

Hi,
 
>Would you be happier if we called it "provisional media states"?

No, because I still don't think there is anything "provisional" about it.

>>An offer (or answer) is not a parameter value you can store, and apply when the time is right. An offer (or answer) needs >>to br processed when received - and that processing will affect resources, DSPs etc. Streams may be added or removed.
>receive at both the old and the new.

I am not sure I agree on that. My understanding is that one shall be able to receive on the old until the new OFFER has been accepted. And, that new offer may get accepted in a 18x before you get the final SIP response.

>is what is specified. It could be another candidate for clarification.

I have a feeling the text in RFC3261 is something which was written before we had offer/answer, before we had UPDATE (i.e. the possibility to have multiple SDP exchanges between the re-INVITE request/final response), and maybe even before we had PRACK.

>As long as you are prepared to handle one provisional thing, how much harder is it to allow that provisional thing to >change and then still eventually either make it permanent or drop it.

This provisional thing may change many times before the final response comes, so when we do this rollback we could end up dropping multiple offer/answer exchanges, not only the previous one.

>>I don't think the offer/answer transaction outcome should be dependent on the SIP messages used for it. If an >>offer/answer transaction succeeds the new media state becomes active. I have never heard about a "proposed media >>state"...
>It isn't written anywhere. It is part of trying to clarify all of this and make it self consistent. Doing as you propose has >significant problems.

I think what you propose also has problems, and makes things unconsistent as far as offer/answer is concerned.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jul 2006 08:56:00 -0400

> I am not sure I agree on that. My understanding is that one shall be able to receive on the old until the new OFFER has been accepted. And, that new offer may get accepted in a 18x before you get t…

Even if we grant that for a moment, you are supposed to be prepared to 
receive on the *new* offer *before* the answer is accepted. For instance 
in a vanilla 3261 scenario, where the reinvite contains an offer, and an 
unreliable 180 contains a preview of the answer that is intended to be 
send formally in a 2xx. Transmission may begin toward your new offer, 
and yet the reinvite may fail, forcing you to revert to the SDP in 
effect prior to the reinvite.

> I have a feeling the text in RFC3261 is something which was written before we had offer/answer, before we had UPDATE (i.e. the possibility to have multiple SDP exchanges between the re-INVITE reque…

We will have to check with the authors. 3261 was completed with 
awareness of 3264 that was written in parallel, and with 3262. It is 
however obviously true that all of the subtleties were not understood. 
(Since we are just figuring them out now.)

> This provisional thing may change many times before the final response comes, so when we do this rollback we could end up dropping multiple offer/answer exchanges, not only the previous one.

Why should that be a problem?

> I think what you propose also has problems, and makes things unconsistent as far as offer/answer is concerned.

While all of these things have one kind of problem or another, I don't 
see an issue with O/A. 3264 doesn't include any mapping to the signaling 
that conveys it, nor AFAIK does it have any prohibition against 
something outside its scope defining rollbacks across a sequence of 
offer/answers.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 26 Jul 2006 19:20:44 +0200

Hi,
 
>>>An offer (or answer) is not a parameter value you can store, and apply when the time is right. An offer (or answer) >>>needs to br processed when received - and that processing will affect resources, DSPs etc. Streams may be added or >>>removed.
>>I am not sure I agree on that. My understanding is that one shall be able to receive on the old until the new OFFER has >>been accepted. And, that new offer may get accepted in a 18x before you get the final SIP response.
>
>receive on the *new* offer *before* the answer is accepted.
 
I don't think that is true. You can have only ONE active offer/answer transaction (Note: I did not say SIP transaction) at one time.
 
>For instance in a vanilla 3261 scenario, where the reinvite contains an offer, and an
>unreliable 180 contains a preview of the answer that is intended to be send formally in a 2xx. 
 
Yes, but that is just a preview, not an "official" answer. The offer/answer transaction is still ongoing at that point.
 
>Transmission may begin toward your new offer, and yet the reinvite may fail, forcing you to revert to the SDP in
 
I totally agree on that, because in that case the offer/answer transaction  did also fail (you never got an answer) Yes, you did get a "preview" of the answer, but you never got the "official" answer (which must be transported reliably) and the offer/answer transaction did fail. And, in that step you revert to the previous SDP. Nothing strange there.

> >I have a feeling the text in RFC3261 is something which was written before we had offer/answer, before we had >>UPDATE (i.e. the possibility to have multiple SDP exchanges between the re-INVITE request/final response), and maybe >>even before we had PRACK.
>>

Yes.

I can't of course speak for the authors of 3261, but I have a feeling the text is something which was simply moved from 2543 (I haven't checked whether it's there, though) without any thoughts given to it.

>>>As long as you are prepared to handle one provisional thing, how much harder is it to allow that provisional thing to >>>hange and then still eventually either make it permanent or drop it.
>>This provisional thing may change many times before the final response comes, so when we do this rollback we could >>end up dropping multiple offer/answer exchanges, not only the previous one.

1. The offer/answer transaction did terminate sucessfully. I should have no reason to remember old SDP information anymore.

2. Additional offer/answer transactions, taking place between the re-INVITE request and final response, are carried out using SIP UPDATE and/or PRACK transactions. Why should the result of those offer/answer transactions be rolled back just because the re-INVITE fails? 

>>>> I don't think the offer/answer transaction outcome should be dependent on the SIP messages used for it. If an >>>offer/answer transaction succeeds the new media state becomes active. I have never heard about a "proposed media >>>state"...
>>> It isn't written anywhere. It is part of trying to clarify all of this and make it self consistent. Doing as you propose has >>>significant problems.
>>>

I agree that this is not a 3264 issue. Because, as you say, 3264 does not map offer/answer transactions to SIP messages. That is done in 3261. 

The problem is the text in 3261, which I again does not take into consideration the fact that you can receive an answer in a reliable 18x, AND that there may be additional offer/answer transactions between that and the final response to the re-INVITE.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jul 2006 17:05:05 -0400

> I totally agree on that, because in that case the offer/answer transaction  did also fail (you never got an answer) Yes, you did get a "preview" of the answer, but you never got the "official" answ…

If you agree with the above, do you agree that you must be prepared to 
receive media on both/either the old or the (preview of the) new before 
receiving the final response to the reinvite?

At the least, this is needed because its impossible to synchronize the 
cutover from use of the old to use of the new to the signaling at both 
ends. Even if the UAS switches where it sends at the time it sends the 
final response, that may well arrive at the UAC before the response does.

Its also possible that the UAS might send something to the new address 
before it sends the final response. (E.g. it could send STUN packets for 
ICE, or it might even send real early media - weird as that might seem.)

There could also be different delays on the old and the new path, so 
even if there is a clear cutover at the sending side, packets could be 
arriving at both ports in arbitrary order for awhile.

Obviously some huristics are required here to decide what to play when. 
But I think you can still get into the situation where you have been 
receiving, and playing stuff addressed to the new port and then have the 
reinvite fail. In that case you must be prepared to revert to the old port.

So I don't think it is ever as simple as you only have one that you have 
to deal with at any one time. Once you are prepared to have two.

> I can't of course speak for the authors of 3261, but I have a feeling the text is something which was simply moved from 2543 (I haven't checked whether it's there, though) without any thoughts give…

I searched for some of the key text. It doesn't appear this was lifted 
from 2543. But I also talked to Jonathan, and he agrees that none of 
these issues were considered.

> 1. The offer/answer transaction did terminate sucessfully. I should have no reason to remember old SDP information anymore.

I'm not suggesting that you would necessarily be doing this today. I'm 
asking how hard it would be. Its different, but once the notion of old 
and new being around for awhile, making it a bit longer doesn't seem 
that big a deal.

I do realize that no matter what we decide, some people will have to 
make some changes to comply. If there were one choice that affected 
substantially fewer implementations then perhaps we should choose that 
one in the interest of maximizing backward compatibility. But I expect 
*everyone* will be affected somewhat, no matter what we decide. And it 
will be hard to measure which way affects the least implementations. So 
I am inclined to decide this based on which makes the most sense rather 
than which hurts the least.

> 2. Additional offer/answer transactions, taking place between the re-INVITE request and final response, are carried out using SIP UPDATE and/or PRACK transactions. Why should the result of those of…

Because 3261 at least implies that they should? And because it makes at 
least as much sense?

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 27 Jul 2006 16:03:01 +0200

Hi,

>>>>I am not sure I agree on that. My understanding is that one shall be able to receive on the old until the new OFFER >>>>has been accepted. And, that new offer may get accepted in a 18x before you get the final SIP response.
>>>Even if we grant that for a moment, you are supposed to be prepared to receive on the *new* offer *before* the >>>answer is accepted.
>> 
>>I don't think that is true. You can have only ONE active offer/answer transaction (Note: I did not say SIP transaction) at >>one time.
>> 
>>I totally agree on that, because in that case the offer/answer transaction  did also fail (you never got an answer) Yes, >>you did get a "preview" of the answer, but you never got the "official" answer (which must be transported reliably) and >>the offer/answer transaction did fail. And, in that step you revert to the previous SDP. Nothing strange there.
>
>If you agree with the above, do you agree that you must be prepared to receive media on both/either the old or the 
>(preview of the) new before receiving the final response to the reinvite?

The preview is just a preview, and I don't think it puts any kind of requirements on any of the entities.

Once the real answer has been delivered, e.g. in a reliable 18x, and the offer/answer exchange has finsihed, the entities need to be able to use the ONLY - even if the re-INVITE transaction itself is still ongoing.

I know you don't agree, but to me the rule would be very simple: if a new SDP offer/answer exchange (no matter which SIP messages are used) fails, revert back to the old SDP. Period. No words about failing re-INVITEs, etc...

>At the least, this is needed because its impossible to synchronize the cutover from use of the old to use of the new to the >signaling at both ends. Even if the UAS switches where it sends at the time it sends the

In the early media discussion it has been proposed that the UAS should not send early media before it has sent the answer, so I guess we could apply the same rule here. But, yes, the UAS may send STUN packages, which the UAC should be able to process.

However, let's take a closer look at this cutover thing, and what happens between the time a new offer is sent (no matter what SIP message is used) and an answer is received (no matter what SIP message is used). 

There are basically 2 possible types of UAC behavior, I think.

a) The UAC sends a new offer, and is able to receive BOTH on the new and old until the new answer is received (from which time it only listens to the new)

b) The UAC sends a new offer, and listens ONLY to the new - even before the answer is received (if the offer fails, it switches back to the old)

Now, most people would say that a) is the correct behavior. It is probably what the spec says, and it prevents any media cut during the offer/answer exchange.

However, I would claim that there are lots of entities out there which work according to b) . Not necessarily because the vendors don't understand the specs, but because it simply isn't possible to allocate "double" media resources (even for the duration of the offer/answer exchange). It may not be a big issue for a SIP phone handling a single session, but for entities handling a large number of sessions every resource count. So, in theory you have a cutover problem with these nodes.

BUT, when is cutover really a problem???

If the UAC adds a new stream, but keep the properties for the existing streams unchanged, cutover is no problem. It does not matter if the UAC listens using the new or old while the offer/answer transaction is ongoing, since the old and new properties for the existing stream are identical. And, there will be no cutover for the new stream, since it doesn't exist from before.

If the UAC changes properties for an existing stream, there is of course a change of cutover. BUT, how often does it occur in real life? How often does a UAC initiate a new codec negotiation for an existing stream in the middle of a call, and/or how often does it change the IP address/port for an existing call? Yes, there ARE cases (some people do transfer type of things using re-INVITE/UPDATE), but in those cases I don't think it matters if there is a cutover (since the media is moved to other entities etc). 

>reinvite fail. In that case you must be prepared to revert to the old port.

I am not saying that there aren't cases where reverting could be useful, but I think we shall be consistent: so, once it offer/answer exchange is done, it's done. 

The UAC can always, if the re-INVITE fails, send a new offer in order to "revert" as many offer/answer exchanges it wants.

>So I don't think it is ever as simple as you only have one that you have to deal with at any one time. Once you are >prepared to have two.

I still think you can only have one offer/answer exchange at one time. Yes, you may have to listen to both the new and old during that exchange, but that's not the same as having multiple offer/answer exchanges (we even have error codes in case of offer/answer race conditions).

>>>>> As long as you are prepared to handle one provisional thing, how much harder is it to allow that provisional thing to >>>>hange and then still eventually either make it permanent or drop it.
>>>> This provisional thing may change many times before the final response comes, so when we do this rollback we could >>>end up dropping multiple offer/answer exchanges, not only the previous one.
>>1. The offer/answer transaction did terminate sucessfully. I should have no reason to remember old SDP information >>anymore.
>

I agree. The problem is that I think my proposal makes most sense, while you have another opinion :)

>>2. Additional offer/answer transactions, taking place between the re-INVITE request and final response, are carried out >>using SIP UPDATE and/or PRACK transactions. Why should the result of those offer/answer transactions be rolled >>back just because the re-INVITE fails?
>
>Because 3261 at least implies that they should? And because it makes at least as much sense?

Again, to me it makes more sense to say that once and offer/answer exchange is done, it's done. It, and possible other finished offer/answer exchanges, will not be reverted/affected by the possible failure of a SIP request.

Regards,

Christer