Re: [rtcweb] Plan A, respun

[Colin Perkins <[e-mail]>]

On 10 May 2013, at 21:03, Cullen Jennings wrote:
> On May 10, 2013, at 12:59 PM, Colin Perkins <[e-mail]> wrote:
>> On 10 May 2013, at 17:39, Cullen Jennings wrote:
>>> On May 8, 2013, at 4:33 AM, Colin Perkins <[e-mail]> wrote:
>>>> I agree: the PT was never intended to be used as a demultiplexing point for different flows in RT
>>> 
>>> I'm not sure I really agree on this point. Lots of implications use the PT along with the port received on to decide which codec to pass to the RTP packet on to. I think, in practice, the PT has been a very key demux pony for a  long time in RTP. 
>> 
>> 
>> To identify the codec, sure, that's what the PT is designed to do. That's logically separate to identifying the source, which is the role of the SSRC.
> 
> But I am not trying to identify the source, if I wanted to do that I agree CSRC would be one of things to use. I am trying to figure out which codec to pass the incoming packet to. I don't mind using SSRC when they are around but when they are not, PT seems perfectly reasonable to use if uniquely identifiers which codec to pass the packet to. I realize that you prefer the shim approach but when there is not a shim, I'm not seeing the problem with using PT. Adam's draft also allows use of SSRC for folks that want to overlap the PT from different m lines. 

I wasn't thinking about the shim at all; this is independent of that.

> Consider a normal SIP call with only single speaker of G.711 audio with early media where two sources are both sending to the same port and PT on that phone. That's normal. It does not need to figure out the sources to render the audio. Sure the codec probably might want to note that a SSRC changed and retrain the jitter buffer but the phone does not care about who the sources are in this case to play them.

Except that it does care about the source, as you say, to retrain the jitter buffer. Or, if you're using something other than G.711 to reset the codec state when you change source. Or to link to the appropriate FEC or retransmission stream, comfort noise packets, RTCP reports, codec control messages, etc. None of which works properly if you ignore the SSRCs. WebRTC isn't building a dumb SIP phone that only does G.711. The kind of features people are talking about for WebRTC need to use the SSRC as the first demultiplexing point to work properly, then use the payload type to select the codec. 

> In more complicated conferring cases the phone could use SSRC/CSRC info to map to roster information received over some other protocol than SDP to display a name for the active speaker or something. But thats a case where who the sources are matters - this is just about getting the media to the right codec on the right m line. 



-- 
Colin Perkins
http://csperkins.org/