W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2011

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 24 Aug 2011 11:41:03 +0200
Message-ID: <4E54C72F.7030004@alvestrand.no>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: Cullen Jennings <fluffy@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 08/24/11 11:35, Stefan Håkansson LK wrote:
> My initial reaction:
>
> I think it is useful if every MediaStream has a unique identifier that 
> is available from the instant the MediaStream is created, and follows 
> it over a PeerConnection.
>
> Then, if this identifier is called 'label', 'Id', 'CNAME' or something 
> else is of less importance.
"label" is a defined term in SDP.
CNAME is a defined term in RTCP.
SSID is a defined term in RTP.

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.
>
> An alternative would be that said identifier is generated only when 
> the stream is sent over a PeerConnection. I.e. when the app does 
> 'addStream' it receives the identifier (created by PeerConnection) in 
> return, and at the other end the 'onaddstream' event carries the same 
> identifier. This would make it possible to identify which MediaStream 
> is which, but it has the drawback that if a MediaStream is sent to 
> several recipients (using individual PeerConnections) they would have 
> different identifiers. So if one of the receivers would like e.g. that 
> the camera used to generate a specific MediaStream is zoomed in, the 
> sending app would have to keep some kind of repository to be able to 
> identify that MediaStream.
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.
>
> 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 09:41:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC