Subject: [rtcweb] JSEP-01: Associating ICE candidates with m- lines

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Feb 2012 11:56:08 +0100

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

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.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Feb 2012 22:42:28 -0800

> 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 wou…

Seems like good idea. 

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

+1 

>  
> Regards,
>  
> Christer
>  
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Justin Uberti <[email-masked]>
Date: Thu, 16 Feb 2012 21:23:40 -0500

On Wed, Feb 15, 2012 at 5:56 AM, Christer Holmberg <
[email-masked]> wrote:

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2012 07:56:29 +0100

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