[rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

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.