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

Harald, 

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no] 
> Sent: 24 August 2011 14:48
> To: Elwell, John
> Cc: Stefan Håkansson LK; 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 14:41, Elwell, John wrote:
> > 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?
> The canonical case for me is the situation where we have two incoming 
> video streams, from the same source, displayed in two windows - the 
> "hockey game" case from the use cases docs is an example of this.
> 
> We need to display the "game" stream in a big window and the "agent" 
> stream in a small window. This requires knowing which one is 
> which, in a 
> deterministic manner. The sender knows which is which. The recipient 
> needs to be told.
[JRE] The SDP a=content attribute (RFC 4796) is designed for this. The currently registered values are insufficient, but new values can be registered (specification required). Whatever mechanism we use, some sort of registration of "game" and "agent" would be needed presumably.

> > 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?
> Actually, we need to communicate the identifier twice:
> - Once in the application's communication stream, to convey 
> the semantics
> - Once alongside the media stream, to identify the media stream
> It's the latter that is within the scope of this discussion.
[JRE] Normally a=content is conveyed in an SDP media description, which in turn is bound to an RTP stream by means of the IP addresses and ports contained in SDP (or indirectly through ICE negotiation based on candidates and parameters in SDP). So there is no need to convey the equivalent of a=content in RTP/RTCP. However, if we multiplex several streams onto a single session, I agree we would need something in SDP to map a given media description to a given stream within the single RTP session, and that could be based on CNAME.

> 
> RTCP doesn't have a delay if a SR is the first thing sent on 
> a session, 
> as recommended in draft-perkins-avt-rapid-rtp-sync-03 section 2.1.1 - 
> this is permitted by RFC 3550 too, it notes.
[JRE] OK, so CNAME can be used to map an RTP stream to a given media description in SDP. CNAME alone does not indicate the purpose of an RTP stream - it would still need something else to map it to "game" or "agent", and that is where a=content comes in.

John


> > 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.
> The drawback I see of RFC 5576 section 6.1 is that it requires a 
> renegotiation every time you add another MediaStream to the 
> PeerConnection, in order to add the new CNAME attribute to the 
> information table.
> The win is that it's (presumably) transported over a reliable 
> channel, 
> so has less chance of getting lost - which of course also means that 
> it's likely to arrive later.
> >   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?
> I believe that we can declare this to be true (that a single 
> MediaStream 
> is identifiable by a single CNAME, and that several 
> MediaStreams can go 
> over the same RTP session using different CNAMEs) without 
> harmful side 
> effects.
> 
> After all, MediaStream is a creation of the spec we're debating; by 
> definition, it is what the spec says it is.
> 
>

Received on Wednesday, 24 August 2011 15:47:40 UTC