RE: [rtcweb] New JSEP draft posted

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?  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?  

 

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