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

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 07:52:53 UTC