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.
> 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.

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.
> 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 13:48:32 UTC