On Mar 8, 2012, at 1:43 PM, Thomas Edwards wrote:
> I have a multicast RTP H.264 video stream that uses payload type 35.
> I know how to change Wireshark preferences to force dynamic RTP
> payload types (96-127) to be decoded as H.264, but I can't see how to
> force payload type 35 to be H.264.
>
> [The issue is that ATSC A/153 "ATSC Mobile DTV Standard" Part 7 says
> "In addition, for RTP packets that carry AVC video elementary stream,
> the payload_type field in the RTP header shall have value 35."]
I guess they hadn't bothered to read section 3 of RFC 3551:
http://tools.ietf.org/html/rfc3551#section-3
In addition to assigning names to encodings, this profile also
assigns static RTP payload type numbers to some of them. However,
the payload type number space is relatively small and cannot
accommodate assignments for all existing and future encodings.
During the early stages of RTP development, it was necessary to use
statically assigned payload types because no other mechanism had been
specified to bind encodings to payload types. It was anticipated
that non-RTP means beyond the scope of this memo (such as directory
services or invitation protocols) would be specified to establish a
dynamic mapping between a payload type and an encoding. Now,
mechanisms for defining dynamic payload type bindings have been
specified in the Session Description Protocol (SDP) and in other
protocols such as ITU-T Recommendation H.323/H.245. These mechanisms
associate the registered name of the encoding/payload format, along
with any additional required parameters, such as the RTP timestamp
clock rate and number of channels, with a payload type number. This
association is effective only for the duration of the RTP session in
which the dynamic payload type binding is made. This association
applies only to the RTP session for which it is made, thus the
numbers can be re-used for different encodings in different sessions
so the number space limitation is avoided.
This profile reserves payload type numbers in the range 96-127
exclusively for dynamic assignment. Applications SHOULD first use
values in this range for dynamic payload types. Those applications
which need to define more than 32 dynamic payload types MAY bind
codes below 96, in which case it is RECOMMENDED that unassigned
payload type numbers be used first. However, the statically assigned
payload types are default bindings and MAY be dynamically bound to
new encodings if needed. Redefining payload types below 96 may cause
incorrect operation if an attempt is made to join a session without
obtaining session description information that defines the dynamic
payload types.
There's currently no mechanism for forcing that dissection; you'd have to modify the H.264 dissector to register in the "rtp.pt" dissector table even if the payload type is not in the dynamic range.
We should probably provide a "decode as" mechanism for RTP that can override the assignment for any payload type values (which might let us get rid of the preference items for other protocols' dynamic payload type - they're dynamic, so "decode as" is probably more appropriate than a preference).