- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 24 Aug 2011 11:41:03 +0200
- 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