Anders Broman wrote:
> 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.
>
[...]
> 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.
[...]
>
>
> 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.
I have captured a trace of a multiplexing call to test with. One capture
contains one endpoint multiplexing to the H.323 gatekeeper and the
other trace has the other endpoint in it too.
http://www.gnugk.org/download/rtp-mux.pcap
http://www.gnugk.org/download/rtp-mux-both.pcap
Here is my dissector for H.460.19 rtp-mux (which right now can only be
used for Decode As if the openLogicalChannel and openlogicalChannelAck
packets are marked Ignore).
http://www.gnugk.org/download/packet-h46019rtpmux.c
Anders, how could one specify a different dissector for the upcoming
channel in packet-h245.c ?
Regards,
Jan
--
Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/
