Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

+mmusic (meant to include the first time around)


On Mon, Feb 3, 2014 at 12:25 PM, Justin Uberti <[e-mail]> wrote:

>
>
>
> 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".
>
>