Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

On Mon, Feb 3, 2014 at 12:19 PM, Adam Roach <[e-mail]> wrote:

>  On 2/3/14 13:27, Justin Uberti wrote:
>
> Therefore, I think we need some similar way for a receiver to do the same
> for a remote track.
>
>
> Yes.
>
>
>  And fortunately, I think we have a surface that can be used for this,
> namely the "recv-appId" attribute that has been discussed in the context of
> unified-plan and explained in
> http://tools.ietf.org/id/draft-even-mmusic-application-token-02.txt and
> unified-plan. If an endpoint doesn't want to receive a particular track on
> a m= line, it sets the m= line to a=sendonly and also removes any
> a=recv-appId.
>
>
> No.
>
> The problem is that you're defining semantics to a behavior that is
> indistinguishable from the behavior exhibited by something that does not
> support app-id: if the thing on the other end isn't using app-id, then an
> attempt to put a stream on hold will be misinterpreted as an attempt to
> reject or remove it.
>

See my response to Martin. Putting a stream on hold will never result in
that being misinterpreted as a reject; on the contrary, without appid,
there is no way to 'fully' reject half of a stream, and, as a problem
confined to pre-unified-plan devices, I think that is probably OK.

>
> I agree that we want an SDP operation that differentiates between "don't
> send me this now" and "don't send me this ever" [1]  -- but it needs to be
> explicit. Something more like "a=i-am-rejecting-this-stream", but with a
> less cumbersome name.
>
> It's not clear to me that adding a new attribute would solve any problem
that appid doesn't solve; you still need to deal with the "other end not
using it" issue.


> ____
> [1] Along with a Javascript control that allows us to do the same thing,
> but that's a W3C issue.
>

Agree. But while we're on the subject, I am thinking that MST.stop() ==
"not ever", and RtpReceiver.active = false causes "not now".