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

RE: [rtcweb] JSEP-02: Associating ICE candidates with m- lines

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Fri, 17 Feb 2012 07:56:29 +0100
To: Justin Uberti <juberti@google.com>
CC: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D8C59FE@ESESSCMS0356.eemea.ericsson.se>

>> In jsep-01, an "m- line reference" has been added to the a=candidate attribute, in order 
>> for the browser to indicate for which m- line the attribute belongs to.
>> Q1: As, within a session, as new SDP offers may be sent (and, as least in theory I 
>> assume, new local candidates may be provided), I wonder whether it, in addition to 
>> the m- line reference, also would be useful to include an SDP version reference 
>> (found the SDP o- line)?
> Need to think through the exact scenario where this would come into play, but it seems 
> useful. If you have a flow in mind, I'd be interested in seeing it.

I guess it depends on when the browser would stop collecting candidates for an offer.

Take the following example:

1. The JS app creates an offer (o-1).
2. The JS app gets some candidates using the ice callback function.
3. The JS app sends the offer over-the-wire as an 3264 offer.
4. The JS app receives an 3264 answer, and gives it (and the associated candidates) to the browser.
5. The JS app creates a NEW offer (0-2).
6. The JS app gets some candidates using the ice callback function.

Now, the question is: once the JS app has created the new offer (o-2), can it still receive 
candidates for the old offer (o-1)? IF so, there MAY be a need to make the distinction (depending 
on how the new and old offer vary from each other).

OR, does the browser stop collecting candidates for a given offer, once at least one associated 
answer has been provided?

>> Q2: If BUNDLE is used, multiple m- lines may share the same candidates, so it should be possible 
>> to indicate that an a=candidate attribute belongs to multiple m- lines - AND/OR to indicate that 
>> it belongs to a given bundle group.
> In this case I was going to have the IceCallback fire twice with the same candidate, once for 
> each m= line. I think this is the simplest approach, but let me know if you see an issue with it. 

In my opinion a single IceCallback would be simpler. Otherwise the app developer has to consider the case where it would not - for whatever strange reason - receive candidates for every m- line associated with the BUNDLE, AND/OR it would receive different candidates. That should of course not happen in normal situations, but a single callback would mean the app developer doesn't even have to think about it.


Received on Friday, 17 February 2012 06:56:54 UTC

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