Re: [rtcweb] New JSEP draft posted

On Thu, Feb 9, 2012 at 10:26 AM, Jim Barnett <Jim.Barnett@genesyslab.com>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?
>

Yes for 5/6, but "not recommended" for 6/7. Otherwise, the UA will be out
of sync with what was signaled to the remote side.


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

Since streams need to be coupled to actual media sources, this wouldn't
work. (Or if it did, the remote side would just get a stream that never had
any media).


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

You would need to call setLocalDescription again with the modified
description in order to ensure the UA is in sync with what the other side
will send.

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