Discard unexpected RTP packets?
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/
There is, in my opinion, no conceivable justification for ignoring the RTP PT and blindly accepting packets. That's probably why we didn't state the obvious. (Plus, Internet specs tend to be reluctant to proscribe receiver behavior too tightly - after all, the receiver suffers the consequences.) This behavior should be stamped out as soon as possible, as it will make backwards-compatible developments like DTMF carriage, comfort noise indication and forward error correction that much more difficult.
I'm cc'ing Steve Casner; I have added the following to the next draft of the spec (when it goes for Draft Standard):
\begin{changebar} A receiver MUST ignore packets with payload types that it does not understand. \end{changebar} Paul Long wrote:
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/
-- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 (@Bell Labs: 908 949 8344) Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
On Mon, 29 Sep 1997, Henning Schulzrinne wrote:
There is, in my opinion, no conceivable justification for ignoring the RTP PT and blindly accepting packets. That's probably why we didn't state the obvious.
I agree.
I expect the practice of ignoring the PT came about because the capabilities negotiation allowed the use of only a single PT at a time. I hope that restriction will be removed. -- Steve
participants (3)
-
Henning Schulzrinne
-
Paul Long
-
Stephen Casner