Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Jonathan Lennox <[e-mail]>]

On Feb 3, 2014, at 7:05 PM, Justin Uberti <[e-mail]<mailto:[e-mail]>>
 wrote:

On Mon, Feb 3, 2014 at 3:11 PM, Jonathan Lennox <[e-mail]<mailto:[e-mail]>> wrote:

On Feb 3, 2014, at 6:00 PM, Justin Uberti <[e-mail]<mailto:[e-mail]>>
 wrote:

On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox <[e-mail]<mailto:[e-mail]>> wrote:
On Feb 3, 2014, at 2:27 PM, Justin Uberti <[e-mail]<mailto:[e-mail]>> wrote:

Also, this essentially makes recv-appId the converse of MSID; for simplicity, I think we should consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have rather different scopes, which are visible once sources are sent using more than one packet stream.

For example, an m-line which has both a primary encoded stream (of media) and a redundancy stream (of rtx packets) would have two appid values, but only one msid.  On the receive side, if you wanted to receive both a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problems, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

That would be fine by me - it would allow a single invention (msid + recv-msid) to focus on solving the three identified problems with MSTs in unified-plan:
- correlation of a MediaStreamTrack to m= line in signaling (msid)
- correlation of packets from a MST to m= line ahead of signaling (recv-msid)
- rejection of an individual MST (recv-msid)

Based on your description, appid seems to go one or two levels down from a MST to an individual RTP flow, but we can let that develop on its own, separate from the timetable of webrtc 1.0 and unified plan.

Points 1 and 3 make sense to me, and are I think what msid is for; but I don't think point 2 will work.

I don't think a single, m-line-wide, identifier will work for the correlation-ahead-of-signaling problem, once you have multiple RTP flows in the m-line.  That's why we've designed appid the way we have.

I think appid is the right solution to point 2.  More specifically, the problem appid is solving is better expressed as the correlation of packets from an RTP flow to an m-line; the correlation from the m-line to a MST is a separate step, and is msid's job.

Agree that msid should map m-line to MST, but it would seem recv-msid could map RTP flow to m=line as well as indicate whether the receiver is in fact interested in receiving the MST associated with said m= line. Note that recv-msid doesn't specify an actual MSID; its purpose is to indicate that the receiver wants to receive data from the remote side's MST, and provide a mechanism for the sender to mark the data accordingly. (Which ends up seeming a lot like appid.)

Generally, I am hesitant to depend on 3 things if we think we could get by with only 2.

I understand that, but I'm also hesitant to have one mechanism do two (it seems to me) fairly unrelated things, especially where the scenarios in which the problems it's solving are applicable vary fairly widely.

As far as I can tell, the only use case anyone's identified for MSID is WebRTC, whereas the disambiguation problem occurs (and thus appid and recv-appid are applicable) for anything using Bundle with Unified-like semantics.