RE: [rtcweb] New JSEP draft posted

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] 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.