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

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:
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>