Subject: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)

From: Matthew Kaufman <[email-masked]>
Date: Wed, 17 Oct 2012 20:25:03 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
Sent: Tuesday, October 9, 2012 7:17 AM

> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up > 3264. Arguments that SIP early media in a 180 is not compliant with 3264 are just wrong.

We've *already* "relaxed" 3264's requirements in JSEP (comments apply to draft-ietf-rtcweb-jsep-01)
	
Straight from 3264: "At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a "glare" condition."

The JSEP API enforces no such rules. If you want to change the API to bring it into compliance with *just this section* of 3264, it would need all sorts of changes...

- 5.1.1 createOffer ... "Calling this method does not change state; its use is not required". Ok, so how then is JSEP to enforce the two "MUST NOT generate a new offer" is the quote from 3264 above? I would think that createOffer must return an error whenever the "MUST NOT" cases apply. (Never mind that if the "use is not required" then somehow I'm to guess what SDP is legal for this browser to pass in to setLocalDescription as an offer?)

- 5.1.4 setLocalDescription... has no language indicating that it is prohibited to call "setLocalDescription" with an offer and then call it again with a different offer without having supplied an answer. There also appears to be no way to pass a "reject" in. (These two issues appear in the W3C API state description too, so appears to really be what we mean when we say that we're going to "use JSEP")

- 5.1.2 createAnswer... "Calling this method does not change state; its use is not required". So then how can setLocalDescription know when it is forbidden to accept an "offer" passed to it (as createOffer is not required) when setRemoteDescription has been passed an "offer" but "createAnswer" has not yet been called?

And so on.

This isn't the only section of 3264 that's gone out the window with JSEP, but saying "I have not seen any reason to relax 3264 yet" doesn't make any sense... that ship sailed when JSEP was proposed.

Matthew Kaufman

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2012 18:51:44 -0400

Matthew,

IIUC, JSEP is what can euphemistically called an "extended subset" of 
3264. (Or less euphemistically, an incompatible dialect.)

If so, how is one to interwork this with SIP components that are 3264 
conformant?

I have been assuming that this is to be accomplished by the server 
pushing javascript that is aware it is/may be interworking with sip, and 
which then constrains itself to the subset of JSEP that compatible with 
3264. And then it is of course limited to those behaviors on the sip 
side that fall within the subset of 3264 that JSEP supports.

Is that the right way to view it?

	Thanks,
	Paul

On 10/17/12 4:25 PM, Matthew Kaufman wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 11:55:34 +0000

Hi,

I agree with Matthew.

In my opinion, the default should be that JSEP O/A is aligned with RFC 3264.

Then, IF some relaxation is needed, we should look at it case by case. At the moment, one has to try to figure out him/herself what the relaxations are.

 And, as the authors don't seem to think there are any relaxations in the first place, I REALLY think we need to clarify this :)

And, it's not only about PRANSWER - even without that there are relaxations (as Matthew's e-mail describes).

Regards,

Christer

-----Original Message-----
From: Matthew Kaufman [mailto:[email-masked]] 
Sent: 17. lokakuuta 2012 23:25
To: Cullen Jennings (fluffy); Christer Holmberg
Cc: [email-masked]
Subject: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta meeting)

	

And so on.

Matthew Kaufman

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 18 Oct 2012 15:55:14 +0000

Also agree in general we need more clarity on SDP usage and it would be good if the default use of JSEP was to maintain compatibility with 3264 offer/answer but I assume it is really the application that has to ensure that.

I am assuming that jsep-02 will start to clarify some of this and align with the W3C spec which for example does require createOffer and createAnswer to be used.

Also wondering if jsep-02 will clarify the current thinking on how rehydration is going to work I am thinking that in this case it would be has to be down to the application to do what it can to stick to O/A rules but there will be limitation.

I look forward to reviewing jsep-02 in detail when it is available.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: 18 October 2012 12:56
> To: Matthew Kaufman; Cullen Jennings (fluffy)
> Cc: [email-masked]
> Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for
> Atlanta meeting)
> 
> Hi,
> 
> I agree with Matthew.
> 
> Then, IF some relaxation is needed, we should look at it case by case.
> At the moment, one has to try to figure out him/herself what the
> relaxations are.
> 
>  And, as the authors don't seem to think there are any relaxations in
> the first place, I REALLY think we need to clarify this :)
> 
> And, it's not only about PRANSWER - even without that there are
> relaxations (as Matthew's e-mail describes).
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> > I have not seen any reason to relax 3264 yet but if something comes
> up, agree we should carefully look at the cases. I think we can just do
> straight up > 3264. Arguments that SIP early media in a 180 is not
> compliant with 3264 are just wrong.
> 
> Straight from 3264: "At any time, either agent MAY generate a new offer
> that updates the session. However, it MUST NOT generate a new offer if
> it has received an offer which it has not yet answered or rejected.
> Furthermore, it MUST NOT generate a new offer if it has generated a
> prior offer for which it has not yet received an answer or a rejection.
> If an agent receives an offer after having sent one, but before
> receiving an answer to it, this is considered a "glare" condition."
> 
> The JSEP API enforces no such rules. If you want to change the API to
> bring it into compliance with *just this section* of 3264, it would
> need all sorts of changes...
> 
> - 5.1.1 createOffer ... "Calling this method does not change state; its
> use is not required". Ok, so how then is JSEP to enforce the two "MUST
> NOT generate a new offer" is the quote from 3264 above? I would think
> that createOffer must return an error whenever the "MUST NOT" cases
> apply. (Never mind that if the "use is not required" then somehow I'm
> to guess what SDP is legal for this browser to pass in to
> setLocalDescription as an offer?)
> 
> - 5.1.4 setLocalDescription... has no language indicating that it is
> prohibited to call "setLocalDescription" with an offer and then call it
> again with a different offer without having supplied an answer. There
> also appears to be no way to pass a "reject" in. (These two issues
> appear in the W3C API state description too, so appears to really be
> what we mean when we say that we're going to "use JSEP")
> 
> - 5.1.2 createAnswer... "Calling this method does not change state; its
> use is not required". So then how can setLocalDescription know when it
> is forbidden to accept an "offer" passed to it (as createOffer is not
> required) when setRemoteDescription has been passed an "offer" but
> "createAnswer" has not yet been called?
> 
> And so on.
> 
> This isn't the only section of 3264 that's gone out the window with
> JSEP, but saying "I have not seen any reason to relax 3264 yet" doesn't
> make any sense... that ship sailed when JSEP was proposed.
> 
> Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 18:19:32 +0200

2012/10/18 Paul Kyzivat <[email-masked]>:
> I have been assuming that this is to be accomplished by the server pushing
> javascript that is aware it is/may be interworking with sip, and which then
> constrains itself to the subset of JSEP that compatible with 3264. And then
> it is of course limited to those behaviors on the sip side that fall within
> the subset of 3264 that JSEP supports.
>

Hi Paul, what about is the JavaScript app directly speaks SIP? please
let's also consider this case. Current web apps based on HTML5 and
modern JavaScript are powerful like any other desktop application. No
need to consider them limited and rely all the logic in the web server
(like 5 years ago).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Oct 2012 09:36:00 -0700

> need to consider them limited and rely all the logic in the web server
Iñaki,

I think that is *exactly* what Paul said.  After all, the Javascript
has to come from somewhere.  That's usually a server.  The alternative
is that there is a server somewhere that does this work.

I find the distinction uninteresting.  Server or Javascript are both
"application" and where this code is executed matters very little.

--Martin

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 18:49:24 +0200

> is that there is a server somewhere that does this work.

Sorry then, I understood something more similar to a "B2BUA" , my fault :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 18 Oct 2012 14:17:03 -0400 (EDT)

> From: Matthew Kaufman <[email-masked]>
>
> The JSEP API enforces no such rules. If you want to change the API
> to bring it into compliance with *just this section* of 3264, it
> would need all sorts of changes...

I'm not familiar with the details of JSEP, but on general
architectural principles, my suspicion is that the key regarding
interworking with SIP is not whether a JSEP-using application can send
offers at times that the 3264 offer/answer model forbids it, but
rather whether JSEP/WebRTC can *reject* an offer.

Certainly in SIP, a new offer presented in a re-INVITE or UPDATE
request can be rejected by the other UA by returning a failure
response.  Any WebRTC protocol that can interwork smoothly with SIP
will require this capability.

Given that, if the JSEP model permits an application to send offers at
times when SIP does not, the WebRTC/SIP gateway/server can immediately
send rejection of such offers back to the client, without sending a
SIP request containing the offer.

This approach tolerates considerable difference between the rules
enforced by JSEP and the rules enforced by SIP, which may be
convenient.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 18:27:59 +0000

Hi, 

>I'm not familiar with the details of JSEP, but on general architectural principles, my suspicion is that the key regarding interworking with SIP is not whether a JSEP-using application can send offers at times that the 3264 
>offer/answer model forbids it, but rather whether JSEP/WebRTC can *reject* an offer.
>
>Certainly in SIP, a new offer presented in a re-INVITE or UPDATE request can be rejected by the other UA by returning a failure response.  Any WebRTC protocol that can interwork smoothly with SIP will require this capability.
>
>Given that, if the JSEP model permits an application to send offers at times when SIP does not, the WebRTC/SIP gateway/server can immediately send rejection of such offers back to the client, without sending a SIP request containing 
>the offer.

For sure it must be possible to reject things which are not allowed by the state machnine.

The issue, however, is that the JSUP SDP O/A state machine currently does allow things which are not alligned with 3264.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Oct 2012 20:35:38 +0200

> enforced by JSEP and the rules enforced by SIP, which may be
Note that the JSEP API never sends anything. It permits the application 
to generate an offer (using CreateOffer), and it permits the application 
to tell the browser that it should set the local configuration according 
to an offer (using setLocal).

The assumption is that the normal way of using the API when interworking 
with SIP is to generate the offer, set it locally with SetLocal(), and 
send it as a SIP OFFER.

The API also offers signals (negotiationneeded) to tell the application 
that it would be good to change the offer it's sending; if the 
application intends to obey SIP rules, it will schedule that 
renegotiation after the current negotiation round finishes.

But the API never forces the application to send an offer; sending or 
not sending an offer is strictly the application's responsibility.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 18 Oct 2012 20:58:23 +0200

2012/10/18 Harald Alvestrand <[email-masked]>:
> But the API never forces the application to send an offer; sending or not
> sending an offer is strictly the application's responsibility.

In other words, the API allows implementing SIP's SDP usage, or not.
That's up to the application.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 18 Oct 2012 17:10:52 -0400 (EDT)

> From: Harald Alvestrand <[email-masked]>
> 

Is the API able to report that the far end has rejected the offer?

Dale

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Oct 2012 14:21:15 -0700

> Is the API able to report that the far end has rejected the offer?

No. It's able to report that the local end couldn't negotiate but
learning about the far end depends on messaging...

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Oct 2012 14:28:36 -0700

> learning about the far end depends on messaging...

That doesn't quite answer the question.

I think that the question is, if I setLocalDescription(offer), but the
remote peer rejects this offer, what do I do to (as 3264 dictates)
revert the session to the state it was in prior to "making the offer".

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Oct 2012 14:55:31 -0700

> revert the session to the state it was in prior to "making the offer".

I assume you mean in an update scenario, since in the initial offer
scenario, you do pc.close();

In the update scenario it seems to me that with the current
API, the natural gesture is setRemoteDescription() with the previous
answer. But obviously the world would be better if this were written
down.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Oct 2012 15:10:58 -0700

> answer. But obviously the world would be better if this were written

Or maybe setLocalDescription + setRemoteDescription with the entirety
of the previous session state.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 18 Oct 2012 18:22:26 -0400

> answer. But obviously the world would be better if this were written
In case of the session update scenario where update was refused (ie
something similar to re-INVITE failure), would not giving the previous
answer cause ICE and DTLS negotiations to run again or do we assume that
browser O/A logic is smart enough to know that since the SDP version is the
same it should be ignored?

Also, description that we passed in setLocalDescription might be very
different from the description that was passed in the
previous setLocalDescription call (for instance we added or removed video).
Would sending the previous answer in setRemoteDescription still work?

I would feel better if we had some sort of cancel offer command, which can
be just setRemoteDescription with an empty string instead of SDP.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 19 Oct 2012 08:23:37 +0200

> Is the API able to report that the far end has rejected the offer?
The concept of "the far end" (application far end, not RTP far end) and 
"reject" are application-level concepts, not API-level concepts.
So in the context of the API, I can't parse the question.

The API can report that it was handed an SDP blob it couldn't use.
The API can also report that the ICE state ended up in "failed" because 
communication didn't work.

But figuring out that a 500 error code in the SDP session (or whatever 
other method the signalling protocol uses to say "no, I don't want to 
talk to you") means "offer rejectd" has to be done at the application.

The application then has to tell the API not to bother with this 
PeerConnection any more - probably by calling close() or by deleting its 
references to the PeerConnection, so that it's garbage collected.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 19 Oct 2012 08:36:57 +0200

> The API can report that it was handed an SDP blob it couldn't use.

One discussion I think we've not had yet is the granularity the API 
could report "can't use this SDP blob" on. Say that a new offer (in on 
ongoing sessions) was received indicating the addition of two audio and 
two video tracks (from Alice to Bob). What if Bob's browser could decode 
both audio tracks but has resources to handle only one of the video 
tracks, should it be able to tell so (perhaps with the result that two 
audio and one video track was added)? Or should the update of the 
session just fail?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 19 Oct 2012 10:19:27 +0200

2012/10/19 Harald Alvestrand <[email-masked]>:
> But figuring out that a 500 error code in the SDP session (or whatever other
> method the signalling protocol uses to say "no, I don't want to talk to
> you") means "offer rejectd" has to be done at the application.

Right. SDP must be signaled by the application making use of it. SDP
is not a "end-to-end" protocol, it must be carried somehow (via a
signaling protocol in which the remote endpoint can reject the SDP
offer with some signaling code that the local endpoint must understand
for closing/aborting its SDP offer).

SIP and XMPP are signaling protocols using SDP and fit very well into
the state machine defined in RFC 3264. In WebRTC we DON'T have a
(network) signaling protocol and, thus, it's the JavaScript
responsability to respect or not RFC 3264 rules, but those rules
cannot be mandated at the media stack level.

So honestly I don't fully understand what we are discussing in this
thread. Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Oct 2012 09:23:40 +0000

> So honestly I don't fully understand what we are discussing in this

What is being discussed is whether it is possible to build a RFC 3264 compliant application using the current API as it is a requirement to be able to do so.

It would be good if the API made this easy for the application as it will be a common use case and I think JSEP probably needs to explain how to do this. 

RFC3624 requires that the session reverts to the state prior to the offer if the offer/answer exchange fails. 

If an applications attempts to modify a session but the updated offer is rejected by the far end there should be no interruption to the existing session. Like Roman suggested I am also thinking it would be nice if the API provided some way of cancelling an offer and reverting to the original state but if this is putting too much state back in the browser we would need a clearly documented mechanism.

Andy

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 19 Oct 2012 11:23:55 +0200

Forking thread, since this is a new topic....

On 10/19/2012 08:36 AM, Stefan Hakansson LK wrote:
> ongoing sessions) was received indicating the addition of two audio 
> and two video tracks (from Alice to Bob). What if Bob's browser could 
> decode both audio tracks but has resources to handle only one of the 
> video tracks, should it be able to tell so (perhaps with the result 
> that two audio and one video track was added)? Or should the update of 
> the session just fail?

This seems to be something that should be happening to SIP endpoints too.

I can imagine either answering with capabilities reduced to reflect what 
could be handled, accepting the offer followed by generating a new offer 
of reduced capabilities, or rejecting the offer.

What is existing practice in this area? (I would not be surprised if it 
was "it depends"....)

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 19 Oct 2012 11:26:38 +0200

On 10/18/2012 09:08 PM, Matthew Kaufman wrote:
> I think this interpretation is correct... which of course leads to the same question I asked on one of the last W3C calls on the subject: *IF* we are going to be producing an API which does not in fact comply with RFC 3264, but in fact significantly relaxes the rules of SDP O/A (which this email thread has confirmed is the case, as I suspected it would), then why are we so hung up on producing an API which looks anything like it (as opposed to, say, the proposal I jointly made with others here at Microsoft)?
Because making an interface that makes following an existing practice 
easy (but does not enforce all the constraints of that practice) is 
better than making an interface that makes following that practice very 
complex?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 19 Oct 2012 11:28:26 +0200

> If an applications attempts to modify a session but the updated offer is rejected by the far end there should be no interruption to the existing session. Like Roman suggested I am also thinking it…

Ok, I understand. Then I agree that the API should provide some
mechanism for respecting that rule in RFC 3264.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Oct 2012 11:55:46 +0000

> audio and one video track was added)? Or should the update of the

The update to the session should not just fail. Normally in this case the answer would simple reject the one video stream and not the whole offer.  

Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2012 11:02:19 -0400

> What is existing practice in this area? (I would not be surprised if it

Andy just talked about this.

The existing practice in sip is that the answerer will accept that part 
of the offer that it understands and is willing to use, and refuses the 
rest - by setting the port number to zero in the m-lines it can't/won't 
support.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Oct 2012 09:26:18 -0700

On 19 October 2012 04:55, Hutton, Andrew
<[email-masked]> wrote:
>> [...] What if Bob's browser could
>> decode

A more interesting case is where Alice decides to (attempt to) switch
codecs.  That decision might even be based on some prior knowledge of
Bob's ability to understand codecs.  Maybe Bob originally offers A and
B, but when Alice decides to upgrade from A to B, that is not a mode
that Bob supports any more.  The session should continue with A.

An answer that rejected the stream would cause an interruption to the session.

> [...] I am also thinking it would be nice if the API provided some way of cancelling an offer and reverting to the original state but if this is putting too much state back in the browser we would need a clearly documented mechanism.

Nice or necessary?  There is already a great deal of state in the browser.

I am actually interested in a small modification to the API for this
case, for outstanding offers there are actually three pieces of SDP in
play: original local description (could be offer or answer), original
remote description (answer or offer) and the new outstanding offer
(which is only ever a local description, the action can be immediate
on the answering side).  We currently have a means to get two of
these: the remote description and (I assume) the local description
that was most recently set.  We do not have a way to get the original
local description.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 19 Oct 2012 12:51:52 -0400

One other common case for offer roll back are O/A collisions. Both sides
are trying to make changes to SDP at the same time, offers cross over on
the wire, so, at least one side needs to rollback the offer and process the
offer received. The only way I can see it implemented is to generate a hold
response SDP based on the generated offer, send it to the
setRemoteDescription, and then process the offer from the remote side. Mind
you, this does not map well to SIP collusion handling where both offers
needs to be reverted, and this will most likely generate an audio
disruption even in case of only one offer being rolled back by putting on
hold.
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Oct 2012 13:15:09 -0400 (EDT)

[re-sent with the correct From address]

> From: Stefan Hakansson LK <[email-masked]>
> 

Within the use case of a WebRTC server/SIP gateway, whenever the
WebRTC client requests an update of SDP, the SIP far end UA can reject
the update.  (In regard to current practice, most of the time a UA
will accept the part of the SDP that it can and make the rest
inactive, but some transcoding SIP B2BUAs will fix a codec early in
the dialog and refuse any SDP changes after that.  In addition, some
UAs do not support UPDATE at all.)

The SIP gateway needs to be able to report this failure to the WebRTC
client API in a usable way, and the reporting has to be asynchronous
to the SDP update request.  By the rules of SIP, the session state
reverts to the previous session state, but it would be a reasonable
architecture if the gateway was required to execute additional WebRTC
actions to achieve that effect.  (However, the WebRTC client must be
forbidden from rejecting those actions!)

In theory, the reestablishment of the previous SDP state could require
renegotiating ICE (and SRTP keys?), but in practice, that would
require excessive overhead, I think.

Ideally, this does not require the code in the JSEP application to
know specifically that the remote end is a SIP gateway, because we
don't want the WebRTC client applications to have to be specially
coded to support SIP gateways (or any other particular type of WebRTC
server).

Given that these things need to be supported, it is easy for the SIP
gateway to interwork with a WebRTC architecture that allows SDP
updates in states where the SIP signaling does not:  If the SIP
gateway receives a WebRTC SDP update in a state where an update is not
permitted in SIP, it can instead send an update rejection to the
WebRTC client.  This allows the WebRTC offer/answer structure to be
more flexible than the SIP offer/answer structure without hindering
interworking (other than that sometimes WebRTC SDP updates fail).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2012 20:06:31 -0400

> An answer that rejected the stream would cause an interruption to the session.

Well, actually it would interrupt the media stream (rtp session).
I agree there are cases where rejecting the offer would make more sense.
That is certainly an option in sip. Deciding whether it is better to 
reject the media stream, or reject the offer can be tricky.

A more important aspect of this scenario is how it is managed on the 
offering side. When Alice makes the attempt, does she assume success and 
immediately put the offered SDP into operation? (And then undo it if the 
offer fails.) Or does the old local/remote SDP remain in effect until 
the answer is received?

SIP says that you must be prepared to receive according to the new offer 
as soon as it is sent. And yet the stuff you are receiving will still be 
in accord to the old o/a until the new offer is received by the 
answerer. And the offerer should still be sending according to the old 
stuff until it receives the answer. Hence there is a time period when 
you need to support *both*. If you switch too soon you may receive old 
stuff you can't deal with. And if you switch too soon and the offer is 
rejected then you will have to switch back, and there will be more 
disruption.

This is pretty ugly, and unless you can actually support both old and 
new concurrently (which many cannot) then you are forced to choose among 
bad choices for how to implement.

But webrtc can't ignore this. It must acknowledge this and provide some 
mechanisms to deal with it.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 20 Oct 2012 11:54:28 +0200

On 10/19/2012 04:26 PM, Matthew Kaufman wrote:
> Iñaki Baz Castillo [[email-masked]]:
Inaki is not alone.
The text in the JSEP draft could definitely bear improving. But I have 
problems parsing the definition of "compliant" here:
> What I am hoping to discuss is whether the JSEP API (which repeatedly claims to be exposing an RFC3264 SDP O/A compliant API surface*) has or has not "relaxed" RFC3264. I think it is pretty clear that it has (in that it does not in fact enforce any of "MUST NOT" called out in RFC3264 at the API level),
in that I would expect a "compliant" API to be one that permits an RFC 
3264 protocol machine to be built on top of it, which doesn't make the 
sentence above logical
>   and so now that we don't have an API that complies with SDP O/A
.... a premise I don't believe.
>   *any* API that doesn't comply with SDP O/A should be equally acceptable.
.... but this conclusion is still completely bizarre to me.

RFC 3264 compliance (for whatever definition of compliance) is just one 
aspect of the considerations of what main direction of API to choose. 
Anyone who wasn't part of the WEBRTC discussions is free to consult the 
archives of the recent discussion for the other reasons put forward.

"Equally acceptable" is a very strange phrase to use in this discussion 
(which, anyway, is in the wrong forum).

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 26 Oct 2012 04:03:07 +0000

> If an applications attempts to modify a session but the updated offer is rejected by the far end there should be no interruption to the existing session. Like Roman suggested I am also thinking it…

We talked about this before and I think just about everyone agrees that we need rollback in JSEP.  And it's not just needed for gatewaying with SIP, any signaling protocol that wanted to allow simultaneous changes is likely need it.  It's not yet fully defined in the current draft because we need to get stable on what we do the initial "O/A" pair before we step into the modifications of it. In SIP terms this would be let make sure we understand initial INVITE before taking on UPDATE. 

I agree this is 1) needed and 2) needs to be well defined in JSEP 3) it's not well defined in current draft. The idea/hope is that the current API will support rollback with no change to the API, we just have to write down the semantics and check all the details work.