Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

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

>
>  On Feb 3, 2014, at 6:00 PM, Justin Uberti <[e-mail]>
>  wrote:
>
>  On Mon, Feb 3, 2014 at 2:32 PM, Jonathan Lennox <[e-mail]>wrote:
>
>>  On Feb 3, 2014, at 2:27 PM, Justin Uberti <[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.