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

Hi,
 	 
>> 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.

Regards,

Christer

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