- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Fri, 10 Feb 2012 12:07:58 +0100
- To: Justin Uberti <juberti@google.com>
- CC: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 02/08/2012 09:57 PM, Justin Uberti wrote: > 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. Good to see a concrete JS example. Some comments below. I believe the example has a deadlock on the caller side: * hasCandidates (initially false) is set true by the ice callback * the ice callback can never trigger before startIce() is called * maybeSignal(), which calls startIce(), will return early if hasCandidates is false Another thing, how are the candidates from the ice callback included in the offer? The candidate argument from the ice callback is never used. /Adam
Received on Friday, 10 February 2012 11:13:22 UTC