Re: JSEP: ICE candidate generation and association with sessions

Hi,

Some comments inline (CHH).

>>>     One thing that's not clear to me in the JSEP proposal:
>>>
>>>     In the case where we don't have a single RTP session, there has to
>>>     be candidates generated for all sessions.
>>>
>>>     The job of putting the a=candidate lines into the SDP description
>>>     is left to the JS (or a JS library), which means that we need to
>>>     associate candidates with the right m= line.
>>>
>>>     Suggestion: Add some parameters....
>>>
>>>     pc.connect() -> pc.startIce(number of sessions)
>>>     iceCallback(candidate) -> iceCallback(session index, candidate)
>>>
>>>     where "index" is a number between 0 and "number of sessions" - 1.
>>>
>>>     There are probably more ways to do this. This was the simplest I
>>>     could think of.
>>>
>>>
>> Agree this is needed, but it's not clear that the web app can easily
>> know how many sessions are needed, given that this is affected by
>> 1) # of m= lines
>> 2) rtcp-mux being on/off for each m=
>> 3) BUNDLE

<CHH> I think you need to know whether to use mux (RTCP and/or RTP), RTP multiplexing scheme (single vs multiple RTP sessions) etc already when you create the SDP.

Then, based on the SDP, I think the system can figure out how many candidates you need, so there will be no need to indicate it when creating the candidates.

I THINK that is what Harald is also saying at the end of the e-mail :)

But, of course, if you want to create the candidates BEFORE you create the SDP, you may need to some indicators. </CHH>


>> The IceCallback definitely needs a way to know what m= line it's for;
>> I'd prefer to use the m= value (e.g "audio" or "video") instead of an
>> index. I've added this to the open issues part of the doc.

<CHH> That assumes you would only have one m= line for a given media type ("audio", "video", etc), which may not be the case.

Another alternaitve would simply be an index based on the location of the m= line in the SDP, as the location will remain the same throughout the session. </CHH>

> I suspect that the easiest answer is to let the browser implementation
> return the # of sessions needed for a particular offer or answer - or
> perhaps a dictionary giving the keys for identifying the needed
> sessions? Perhaps another return parameter from GenerateOffer?

Regards,

Christer