Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

+Harald as this affects the MSID doc


On Mon, Feb 3, 2014 at 3: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.
>
>
>