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/2011 05:47 PM, Elwell, John wrote:
> 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.
a=content has the same issue as a=label: it attaches to an RTP session.

Query: What is the semantic difference between a=content and a=label? 
Closed (content) versus open (label) namespace? Anything else?

>>> 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.
Yup, I was being imprecise - using SDP as one example of "alongside the 
media stream", without being explicit about it.
>> 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.
I'm beginning to detest the fact that SDP "media streams" are mapped 1:1 
to RTP "sessions", and that RTP "sessions" are mapped 1:1 to 5-tuples......

Remember that the hockey game viewer is not general comms infrastructure 
- it's a specialized application.
The app can use HTTP POST/GET or Websockets via a Web server to send 
"hey, the game is on 1234@567" in whatever (proprietary) syntax it wants 
to. I wouldn't want to be in a state where we have to do an IANA 
registration for "hockey game".

Received on Wednesday, 24 August 2011 21:52:28 UTC