Re: Mapping of media streams to RTP (Re: Query: What does "context" mean in the context (sic) of requirement A15? [ACTION-6])

> So the reason I changed the subject line is that this is not just naming
> the identifier, it is about where it is carried in protocol - which in
> turn affects the syntax and uniqueness requirements of the identifier.
Yes, I should have added that my input was only from the web app 
developer perspective. Others will have to provide feedback on the 
protocol implications - your reasoning sounds fine to a novice (=me).
....

> If we use the CNAME generation method of RFC 6222, it seems logical to
> generate a new CNAME every time a new MediaStream is created, so that we
> have it available when we need it. They're cheap to generate, and
> (probabilistically) globally unique.
Sounds fine to me. I assume that the SDP would carry the CNAME to the 
other end.
>>
>> Stefan
>>
>> On 2011-08-24 09:52, Harald Alvestrand wrote:
>>> On 08/24/11 00:17, Cullen Jennings wrote:
>>>> On Aug 21, 2011, at 6:01 AM, Harald Alvestrand wrote:
>>>>
>>>>> It leads into interesting directions, but I would prefer to think
>>>>> about this as "once I have the identifier, I can look up the stream
>>>>> object; once I have the stream object, I can get all sorts of
>>>>> interesting information from it".
>>>>>
>>>>> Then we'll see what requirements there are for "interesting
>>>>> information".
>>>>>
>>>> I'm on board with the intent but I think we probably need to start
>>>> getting a bit more specific. It seems like the useful thing things
>>>> are SSRC, CNAME, and the Label as defined in 4574. Both CNAME and
>>>> SSRC are hard to use so I want to make sure we at least have support
>>>> for Label and and SSRC. CNAME I don't find much use for but if
>>>> others do, no objection to it.
>>>>
>>> Thanks for the lead-in!
>>>
>>> I think this maps straight into the "how do we match these constructs
>>> into RTP" discussion that we need to have.
>>>
>>> To my mind, the multiplexing discussions have led us to a place where
>>> people want to be able to set up a connection with mutliple media
>>> streams inside one network-layer flow (one source and one destination
>>> port) - which means one RTP session in the current definitions of RTP.
>>>
>>> Given any need for interworking at all, we also need to be able to
>>> support multiple RTP sessions.
>>> So the allocation of media streams to RTP sessions has to be something
>>> that's more or less decided at the implementation / negotiation layer.
>>>
>>> The current draft API specifies a media hierarchy (names taken from
>>> memory - check draft for current version):
>>>
>>> PeerConnection (zero or more media streams)
>>>        MediaStream (zero or more media tracks)
>>>             MediaTrack (one audio or video media flow)
>>>
>>> A MediaTrack maps pretty neatly to what SDP thinks of as an SSRC - it is
>>> a stream of data intended to be decoded in sequence, resulting in a
>>> media signal of some sort, and can be (in the simple case) decoded
>>> independently from other tracks. (ignoring FEC and repair streams for
>>> the moment).
>>>
>>> Given that audio and video may go in separate tracks, but need to be
>>> synchronized if they're from the same source, we need to associate them
>>> somehow.
>>> The RTP identifier that is defined for synchronization is the CNAME -
>>> two or more streams that are intended to be synchronized should have the
>>> same CNAME.
>>> We have the RFC, already quoted in -rtp-usage, that says basically
>>> "generate CNAMEs on the fly as random-number@random-number" - these
>>> aren't long term, privacy-revealing identifiers; they are just IDs.
>>>
>>> So *at the RTP level*, it seems logical to map:
>>>
>>> PeerConnection               SDP "session" (one SDP description)
>>>        MediaStream                   CNAME
>>>             MediaTrack                       SSRC
>>>
>>> Neither CNAME nor SSRC are human friendly identifiers. But as long as
>>> they're defined to be unique within the context of a single
>>> PeerConnection, it's possible to associate them with human-friendly
>>> identifiers of the same scope. And present APIs I'm familiar with seem
>>> to make it possible to get at them.
>>>
>>> I'm sure there are details I've glossed over. But that's my current
>>> thinking at the moment - it leaves "label" out in the cold, because the
>>> "SDP media level" that maps to "one RTP session" didn't turn out to be
>>> very useful given our current thinking about multiplexing and RTP port
>>> usage.
>>>
>>> What do others think?
>>>
>>>                                    Harald
>>>
>>>
>>>
>>>
>>>
>>
>>
>

Received on Wednesday, 24 August 2011 10:00:51 UTC