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

[Christer Holmberg <[e-mail]>]

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:[e-mail]] 
Sent: 17. lokakuuta 2012 23:25
To: Cullen Jennings (fluffy); Christer Holmberg
Cc: [e-mail]
Subject: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta meeting)

From: [e-mail] [mailto:[e-mail]] 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