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:
>
> 1.   OffererJS->OffererUA:   pc = new PeerConnection();
>
> 2.OffererJS->OffererUA:   pc.addStream(localStream, null);
>
> 3.OffererJS->OffererUA:   pc.startIce();
>
> 4.OffererUA->OffererJS:   iceCallback(candidate, false);
>
> 5.OffererJS->OffererUA:   offer = pc.createOffer(null);
>
> 6.OffererJS->OffererUA:   pc.setLocalDescription(SDP_OFFER, 
> offer.toSdp());
>
> 7.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.
>