Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines

[Adam Roach <[e-mail]>]

On 7/24/13 17:58, Emil Ivov wrote:
> So you are confirming that the number of media sources, that the 
> bridge expected to get from the callee, was hard-coded or 
> pre-provisioned. Right?

It's part of the application. Sure. "Hard-coded" is a reasonable way to 
think about it.

> To simplify let's get back to Iñaki's scenario of 8 "m=" lines in the 
> offer, but lets also assume that different callees can answer with 
> anything between 1 and 8 sources.
>
> In this case, do you set all your "m=" lines to "a=sendrecv"?

If the bridge wanted to deal with receiving that many media streams, sure.

> If so, we are back to Iñaki's original question: how does a 
> single-source callee know which if these "m=" lines to pick for its 
> own stream?
>
> I suppose one possible answer would be: it just takes any "m=" line 
> that matches its needs and sends stuff there. It also sets everything 
> else to "a=recvonly" in the answer. Is this what you'd suggest?
>
> Or maybe the callee sends an answer where it sets everything to 
> "a=recvonly" and then re-offers with a ninth "a=sendonly" "m=" line?
>
> Or does the callee use app-specific signalling to tell the bridge that 
> it has N sources so that the bridge would offer with N "a=sendrecv" 
> "m=" lines and 8-N "a=sendonly" "m=" lines?
>
> Or are all three of the above legal?

Yes, the first one is what I would recommend.

The second one is certainly valid, but why would you do that? It delays 
the callee-to-caller media unnecessarily.

The third one is fine, too, assuming you want to bind yourself to that 
kind of signaling (it may complicate interdomain federation, if that 
ever becomes important to you).

But this is all pretty easy to derive from RFC 3264 section 6.1, really.

/a