RE: Re: JSEP: ICE candidate generation and association with sessions

Hi,

One more thing, regarding the assocation of candidates with m- lines.

If you are using the same port for all media, e.g. using the BUNDLE mechanism, you don't really need to do the association, because you are going to use the same candidates for all m- lines.

Regards,

Christer



________________________________________
From: Christer Holmberg [christer.holmberg@ericsson.com]
Sent: Tuesday, January 10, 2012 1:38 PM
To: public-webrtc@w3.org
Subject: 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

Received on Tuesday, 10 January 2012 19:47:38 UTC