Re: [rtcweb] Plan A, respun

[Cullen Jennings <[e-mail]>]

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. 

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