Re: [rtcweb] Plan A, respun

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Adam Roach
Sent: 20 May, 2013 3:19 PM
To: Colin Perkins
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan A, respun

On 5/20/13 19:17, Colin Perkins wrote:
> On 20 May 2013, at 10:45, Adam Roach wrote:
>> On 5/18/13 00:10, Martin Thomson wrote:
>>
>>> Let's be very, very precise about this.
>>>
>>> Demultiplexing is *always* performed based on SSRC.  It's just that 
>>> correlation with signaling components (the m-line in this case) 
>>> might use of PT in the absence of prior knowledge of SSRC.
>>>
>>> We didn't get this quite right in Plan A.
>> Yeah, that's a valid point. It's not really being proposed as a demux
point as much as a correlation token. Thanks for clearing that up -- we
should definitely clear that up in the next version of the document.
>
> Rather than try to overload the PT, I would suggest we define an explicit
correlation token that can be sent. Put something in RTCP SDES and/or RTP
header extensions, and in the SDP, to signal what RTP flow corresponds to
what m-line.
>

>That kind of defeats some of the purpose here, which includes working with
existing deployed implementations.

I do not understand why it breaks. When existing implementation receive
three m-lines it is not specified what behavior they will take if they
support different number of RTP streams and there is no specification about
how they will render the three m-lines (no mapping)

/a
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb