Re: New Dissector only applied to first packet

[Guy Harris <guy () alum mit edu>]

On Nov 2, 2012, at 2:25 PM, Jan Willamowius <jan () willamowius de> wrote:

> Guy Harris wrote:
> > > My dissector only handles UDP packets, but strangely the stop-packets
> > > are all TCP packets and I have verified that my dissector never even
> > > gets called for them.
> >
> > A dissector for one protocol can set up future (in the sense of "later in the capture") packets to or from certain 
> > endpoints to be dissected as a particular protocol.  This is used, for example, for protocols such as SIP, which 
> > initiate a session and specify "use port XXX" for that session, so that future UDP traffic to or from port XXX 
> > should be dissected as RTP for that session.
> >
> > What protocol(s) are in the TCP packets in question?
>
> Thats it!
>
> I'm doing a dissector to decode the H.460.19 RTP multiplexing used by
> H.323 and the packets I have to ignore contain openLogicalChannel
> messages that probably set up rules to decode future packets as RTP.

At least as I read H.460.19 section 7.3.2 "Multiplexed media mode – RTP/RTCP", it should set up rules to decode future 
packets as "multiplexed RTP":

        When operating in the multiplexed media mode, a multiplexing layer shall be added by H.460.19 entities between 
the UDP and RTP/RTCP packet headers as shown in Figures 7 and 8.

                +---------------------------+
                | IP header                 |
                +---------------------------+
                | UDP header                |
                +---------------------------+
                | 4-byte multiplexID        |
                +---------------------------+
                | RTP HEADER                |
                +---------------------------+
                | RTP PAYLOAD               |
                +---------------------------+

        Figure 7/H.460.19 – The multiplexed RTP packet                                          

                +---------------------------+
                | IP header                 |
                +---------------------------+
                | UDP header                |
                +---------------------------+
                | 4-byte multiplexID        |
                +---------------------------+
                | RTCP HEADER               |
                +---------------------------+
                | RTCP PAYLOAD              |
                +---------------------------+
                | ...                       |
                +---------------------------+

        Figure 8/H.460.19 – The multiplexed RTCP packet

So there'd need to be a dissector for "multiplexed RTP" (which would probably be part of the RTP dissector source 
file), and, when the multiplexed media mode is negotiated, use the "multiplexed RTP" dissector rather than the regular 
RTP dissector.

> Is there a way to override these rules for future packets ?
> Or is the only way to adapt the dissector for H.323 to auto detect when
> RTP multiplexing is used ?

It looks, from my quick reading of H.460.19, as if the H.323 dissector would, and could, and probably should detect RTP 
multiplexing at call setup time.

If you don't have the call setup traffic, RTP traffic would have to be recognized heuristically - the H.323 dissector 
(or SIP dissector, or...) wouldn't be setting up future packets to be dissected as RTP; a heuristic "multiplexed RTP" 
dissector could probably recognize "multiplexed RTP" by using the same mechanisms as the regular heuristic RTP 
dissector but fetching the fields it uses at an offset 4 bytes greater than the regular offset.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe