Re: JSEP: ICE candidate generation and association with sessions

On 01/04/2012 04:10 AM, Justin Uberti wrote:
>
>
> On Mon, Jan 2, 2012 at 6:55 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     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
>
> 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.
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?