Re: [rtcweb] New JSEP draft posted

I agree we should provide guidance here on what can be changed, and fail
any edits that are disallowed. We can do this while nailing down exactly
what parts of SDP all implementations must support.

On Thu, Feb 9, 2012 at 4:47 PM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

> So we will need to specify which aspects of an offer can be modified
> before setLocalDescription is called (or, equivalently, specify the
> conditions under which setLocalDescription must fail).    For compatibility
> reasons we wouldn’t want to allow the individual browser vendors decide
> which modifications to accept.  Could we define an API on offer that would
> allow only the legal changes to be made, or would that be impractical?  If
> changes to the offer went through the API, it might be possible to track if
> changes had been made since the last call to setLocalDescription, and at
> least issue a warning if the application tried to send an offer that was
> out of synch with the local description.  ****
>
> ** **
>
> I suppose it’s a matter of taste how much we try to keep app developers
> from shooting themselves in the foot,  but it seems to me that it’s
> dangerous to tell them that they can edit the offer object or the resulting
> SDP when there are so many ways for that to fail.****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* Harald Alvestrand [mailto:harald@alvestrand.no]
> *Sent:* Thursday, February 09, 2012 3:29 PM
> *To:* Jim Barnett
> *Cc:* Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org
> *Subject:* Re: [rtcweb] New JSEP draft posted****
>
> ** **
>
> On 02/09/2012 07:26 AM, Jim Barnett wrote: ****
>
> Justin,****
>
> What happens if the application JavaScript modifies the offer?  Take the
> offer generation in example 7.1:****
>
> OffererJS->OffererUA:   pc = new PeerConnection();****
>
> OffererJS->OffererUA:   pc.addStream(localStream, null);****
>
> OffererJS->OffererUA:   pc.startIce();****
>
> OffererUA->OffererJS:   iceCallback(candidate, false);****
>
> OffererJS->OffererUA:   offer = pc.createOffer(null);****
>
> OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER, offer.toSdp());*
> ***
>
> OffererJS->AnswererJS:  {"type":"OFFER", "sdp":"<offer>"}****
>
>  ****
>
> Could the JS modify the offer between steps 5 and 6 or between steps 6 and
> 7?  For example, between steps 5 and 6, could the JS add a stream for which
> pc.addStream had not been called previously?****
>
> The JS would not know what to enter for an added stream, I think. Most
> probably an attempt to do this should result in the SetLocalDescription
> being invalid, and thus rejected.
>
> Removing codecs, for instance, would be expected to cause no difficulties,
> and cause the right thing to happen (local UA being configured not to
> expect incoming data in that format). I think.
>
> ****
>
>   Would setLocalDescription make the necessary modifications in that
> case?    What about changes after setLocalDescription has been called?  Are
> they not allowed?  If they are allowed, how does the peer connection know
> what to expect from the other side?  ****
>
> Seems to me that pc.setLocalDescription would have to be called again,
> otherwise the local PC doesn't know about the change.
>
> ****
>
>  ****
>
> Jim****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org<rtcweb-bounces@ietf.org>]
> *On Behalf Of *Justin Uberti
> *Sent:* Wednesday, February 08, 2012 3:57 PM
> *To:* rtcweb@ietf.org; public-webrtc@w3.org
> *Subject:* [rtcweb] New JSEP draft posted****
>
>  ****
>
> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-01.txt***
> *
>
>  ****
>
> Includes changes based on implementation feedback, and I believe it
> addresses most of the concerns raised in last week's interim meetings:****
>
> - Initial documentation provided for each API call, and what state changes
> it causes****
>
> - More examples, including a complete basic sample application****
>
> - Simplified approach to trickle candidate handling****
>
> - Resolved concerns about how to separate SDP attributes into media /
> transport****
>
> - Provided encapsulation for SDP blobs and ICE candidate lines, in the
> event we want to change encodings or provide helper functions for JS****
>
> - Provided mechanism for limiting candidates to TURN-only****
>
> - Resolved several implementation issues****
>
>  ****
>
> I have not yet addressed the non-overlapping codec concern mentioned in
> the interim meeting. I think there are ways of handling this either in the
> application or the implementation, but I wanted to get this -01 out first
> for feedback.****
>
> ** **
>