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

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

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Christer Holmberg
> Sent: 18 October 2012 12:56
> To: Matthew Kaufman; Cullen Jennings (fluffy)
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for
> Atlanta meeting)
> 
> 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:matthew.kaufman@skype.net]
> Sent: 17. lokakuuta 2012 23:25
> To: Cullen Jennings (fluffy); Christer Holmberg
> Cc: rtcweb@ietf.org
> Subject: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta
> meeting)
> 
> 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