At the H.323 interop in Jerusalem, I learned that some implementations discard RTP packets whose payload type is incorrect, either implied by the dataType or specified in the dynamicRTPPayloadType field. However, some implementations completely ignore the payload type and accept all packets in the stream. We, Smith Micro, used to be strict about this, then we stopped checking when we found that some vendors were using the wrong payload type. Now I'm thinking that we should go back to being strict about it.
I exchanged email with Henning Schulzrinne, and he said that endpoints must discard packets with unexpected payload types in order to ensure backward-compatibility with future encodings. (I CC'ed him in case I have misrepresented his thoughts on this subject in some way.) Let's take a concrete example. An incoming channel is established for G.723.1 audio, and the endpoint starts receiving RTP packets with PT=4--the expected payload type for G.723.1. Everything's fine. Then the endpoint receives an RTP packet with an unexpected payload type, PT=80. It doesn't matter here, but let's say that this is an RTP DTMF packet. What happens next? Apparently, H.323 and H.225.0 are silent about whether the packet is discarded or passed (with unintended results) to the G.723.1 codec, so the behavior is undefined.
I agree with Henning that endpoints should be required to discard packets with unexpected payload types, but most of all, I believe that we need to come to a concensus about what to do in this situation and then document it. Any comments?
-- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/