-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jan Willamowius
Sent: den 5 november 2012 12:00
To: wireshark-dev@xxxxxxxxxxxxx
Subject: Re: [Wireshark-dev] New Dissector only applied to first packet
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
It ought to be possible to set up the RTP or RTPmux data by using the information in
TraversalParameters ::= SEQUENCE
{
multiplexedMediaChannel TransportAddress OPTIONAL,
multiplexedMediaControlChannel TransportAddress OPTIONAL,
multiplexID INTEGER(0..4294967295) OPTIONAL,
keepAliveChannel TransportAddress OPTIONAL,
keepAlivePayloadType INTEGER (0..127) OPTIONAL,
keepAliveInterval TimeToLive OPTIONAL,
...
}
At least adding dissection of the parameter shouldn't be to difficult given an example trace.
/Anders
--
Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
