Discard unexpected RTP packets?

Henning Schulzrinne schulzrinne at CS.COLUMBIA.EDU
Mon Sep 29 07:58:03 EDT 1997


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



More information about the sg16-avd mailing list