Wireshark · Wireshark-users: Re: [Wireshark-users] force decode of H.264 in RTP for payload type 35

[Thomas Edwards <tedwards@xxxxxxxxx>]

Here is a quick work-around for anyone who would like to register a
non-dynamic RTP payload type to H.264:

wireshark-1.6.5/epan/dissectors/packet-h264.c

2068c2068
<   if (rtp_pt >= 96 && rtp_pt <= 127)
---
> /*  if (rtp_pt >= 96 && rtp_pt <= 127) */

-Thomas

On Thu, Mar 8, 2012 at 3:37 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> 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).
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe