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

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.

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.

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:36:27 UTC