Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Christer Holmberg <[e-mail]>]

Hi,

Would this be solved by using uni-directional m- lines?

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.