On Nov 2, 2012, at 2:25 PM, Jan Willamowius <jan@xxxxxxxxxxxxxx> 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.