Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Adam Roach <[e-mail]>]

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.

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.

/a


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