Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

On Mon, Feb 3, 2014 at 12:06 PM, Martin Thomson <[e-mail]>wrote:

> On 3 February 2014 11:27, Justin Uberti <[e-mail]> wrote:
> > 2a) Normal answer: B adds its own track MSTB, generates answer:
> > m=audio Y
> > a=msid:MSTB
> > a=recv-appId:1
>
> Potential problems:
>
> recv-appId looks like something that applies to what B is receiving
>

It does, in fact. In B's answer, a=msid indicates what B is sending;
a=recv-appId indicates that B wants to receive the MST from A that is
associated with this m-line.


> reject looks a little like does not support recv-appid as well
>

True. But if, as you say, we merge appid and msid, then the only possible
ambiguity comes from the legacy no-msid, no-appid case, and even that is
not an issue since all the possible outcomes are separable: full duplex
(m=audio Y), one-way reject (m=audio Y, a=sendonly), full reject (m=audio
0). Of course, we can't know that the one-way reject is final, but the
number of add/remove stream operations done by legacy devices should be
limited.


> I think that the merging appid/msid is worth considering.  I think
> that gets around these minor issues.