Guy Harris wrote:
> > 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":
Ideally, yes.
> 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.
I have one as plugin right now that calls the RTP dissector, but either
way is fine by me.
> > 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.
No, it cannot. The use of H.460.19 (with or without RTP multiplexing) is
negotiated in Setup / Alerting / Connect if both sides support it. At
that point Wireshark could know that the RTP addresses sent by H.460.19
client side (the side that doesn't set the server flag), should be
disregarded, because that side is possibly behind a NAT.
The use of multiplexing is negotiated in openLogicalChannel and
openLogicalChannelAck. It can be bi-directional or only in one
direction. If one side wants to _receive_ multiplexed RTP, it will add
a multiplexedMediaChannel + control channel to the traversal parameters
plus the payload type it expects.
In the case of an H.460.19 client, those addresses must be disregarded
again, because it may be behind a NAT and the real IPs will be
determined by keepAlive packets.
> 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.
I don't really want to detect it heuristically. If one has the call
signaling, We can know whether it is multiplexed or not and if only
the RTP is available I would prefer to do Decode As.
Looking at the template that packet-h245.c is generated from, I don't
really see where it says that the upcoming channel will be RTP. Is that
implied and all upcoming channels are RTP right now ?
Changing that to multiplexed-RTP is my priority right now.
The other change we could make is disregarding addresses from H.460.19
clients, but that will require to carrying over the state from the
H.225 dissector and it currently seems to work OK without most of the
time.
Regards,
Jan
--
Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/
