Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

On Mon, Feb 3, 2014 at 12:08 PM, Christer Holmberg <
[e-mail]> wrote:

>  Hi,
>
> Would this be solved by using uni-directional m- lines?
>
> Yes, but at the cost of compatibility with legacy. There has been broad
support for bidirectional m= lines each time this has come up.

>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Justin Uberti <[e-mail]> wrote:
>
>
>  While working on the latest JSEP update, I came across the following
> problem:
>
>  When a answerer wants to reject a "media stream" in 3264, it sets the m=
> line port in the answer to zero. However, when an endpoint wants to reject
> a remote MediaStreamTrack without rejecting the m= line entirely, because
> it is using the m= line for its own MediaStreamTrack, we don't have a clear
> way to express that. While setting a=sendonly in the answer will tell the
> other side to stop sending data, this won't kill the remote track. As far
> as the remote side is concerned, its track is just 'paused'/'held', and is
> still associated with the m= line.
>
>  Note that there is no such problem if an endpoint decides to kill its
> own local MediaStreamTrack; in the offer it sends to indicate this, in
> addition to setting the m= line to a=recvonly, it can also remove the MSID
> of the track from the m= line, indicating the track is gone. In other
> words, the a=msid attribute serves as the binding of MST to m= line, and
> its absence indicates the track is gone.
>
>  Therefore, I think we need some similar way for a receiver to do the
> same for a remote track. 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.
>
>  Below is an example of an audio call between A and B, with
> MediaStreamTracks MSTA and MSTB. A initially generates an offer, and then I
> show 4 different answer scenarios for various cases.
>
>  1) A generates offer with MSTA
> m=audio X
> a=msid:MSTA
> a=recv-appId:1 # use 1 in the header extension when sending MSTA
>
>  2a) Normal answer: B adds its own track MSTB, generates answer:
>  m=audio Y
> a=msid:MSTB
> a=recv-appId:1
>
>  2b) Add+reject answer: B adds its own track MSTB, stops MSTA, generates
> answer:
>  m=audio Y
> a=msid:MSB
> a=sendonly
>  # no appid; A can realize that MSA has been rejected
>
>  2c) Reject-only answer: B stops MSTA without adding a stream, generates
> answer:
> m=audio 0
> # entire m-line has been rejected
>
>  2d) Do-nothing answer: B does nothing, generates answer:
> m=audio Y
> a=recv-appId:1
>  a=recvonly
>
>  If this seems reasonable, I plan to use this mechanism for handling m=
> line allocation in JSEP.
>
>  Also, this essentially makes recv-appId the converse of MSID; for
> simplicity, I think we should consider unifying these concepts into a
> single document.
>