Discard unexpected RTP packets?
plong at SMITHMICRO.COM
Sun Sep 28 23:36:41 EDT 1997
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?
Smith Micro Software, Inc.__________http://www.smithmicro.com/
More information about the sg16-avd