Re: New JSEP draft posted

On Fri, Feb 10, 2012 at 6:07 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> On 02/08/2012 09:57 PM, Justin Uberti wrote:
>
>> Now available at http://www.ietf.org/id/draft-**uberti-rtcweb-jsep-01.txt<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
>

You're right. startIce() should be called in start(), if |isCaller| is
true.

>
> Another thing, how are the candidates from the ice callback included in
> the offer? The candidate argument from the ice callback is never used.


As mentioned in the draft, candidates are included in the offer
automatically (if they have already been gathered). In the example, we just
wait for the IceCallback to inform us that gathering is complete, and use
that to know when to dispatch the offer.

>
>
> /Adam
>

Received on Friday, 10 February 2012 14:03:57 UTC