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

We need to consider how this will be used. I am not sure I understand the requirements, but I think the requirement is that a single identifier be shared between a JS running on one browser and a JS running on another browser. Is this correct, and if so, exactly why is it needed? What breaks if we don't have it?

Assuming this to be correct, there is a need for the side that assigns the identifier to convey that identifier to the other side. Basically there are 4 ways this could be done: SDP, RTCP, RTP and STUN. I don't think RTP and STUN have any means to do this, and RTCP suffers a delay, so I would imagine we want to do it in SDP. Correct so far?

The label attribute (RFC 4574) is one way of doing this, and is designed to allow applications to refer to an SDP media description. CNAME is another, and can be conveyed using RFC 5576 and allows reference to a particular source when several sources are contributing to an RTP session. So it is question which is appropriate: label, CNAME or neither. I believe we are tying to solve the problem for multiple media streams multiplexed on the same RTP session, but is a single stream identifiable by means of a CNAME, or can a single stream have several sources and hence several CNAME values, making CNAME unsuitable for the present purpose?

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: john.elwell@siemens-enterprise.com
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.


> -----Original Message-----
> From: public-webrtc-request@w3.org 
> [mailto:public-webrtc-request@w3.org] On Behalf Of Harald Alvestrand
> Sent: 24 August 2011 10:41
> To: Stefan Håkansson LK
> Cc: Cullen Jennings; Christer Holmberg; public-webrtc@w3.org
> Subject: Re: 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 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 12:42:32 UTC