Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Christer Holmberg <[e-mail]>]

Hi,

Just for my clarification: none of this would have any impact on transport level features related to RTCP, STUN, etc?

Regards,

Christer


From: rtcweb [mailto:[e-mail]] On Behalf Of Justin Uberti
Sent: 4. helmikuuta 2014 2:05
To: Jonathan Lennox
Cc: Cullen Jennings; Harald Alvestrand; [e-mail]; mmusic
Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP



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.