W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

RE: [rtcweb] New JSEP draft posted

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Thu, 9 Feb 2012 07:26:54 -0800
Message-ID: <E17CAD772E76C742B645BD4DC602CD8105C53D1B@NAHALD.us.int.genesyslab.com>
To: "Justin Uberti" <juberti@google.com>, <rtcweb@ietf.org>, <public-webrtc@w3.org>

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.

Received on Thursday, 9 February 2012 15:28:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC