[Anders Broman <anders.broman@xxxxxxxxxxxx>]

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jan Willamowius
Sent: den 6 november 2012 21:53
To: wireshark-dev@xxxxxxxxxxxxx
Subject: Re: [Wireshark-dev] New Dissector only applied to first packet

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

I'm not familiar with the H.460.19 procedures and don't have the time to dive to deeply into the spec
But using the OLC info it should be possible to "detect" that RTPmux is beeing used and
Overide setup of the RTP conversation and instead create an RTPmux conversation possibly a
Per Conversation data structure is needed to keep information per MUX id about the muxed RTP connections.
Somthing like 
"If multiplexID present use_rtpmultiplex = TRUE" and use the IP addr of multiplexedMediaChannel(?)(and ctrl)
As conversation data to set UDP sub dissector as RTPmux.


This should "direct" the RTPmux packets to your dissector which then would remove the mux id and
Call the RTP dissector. Your dissector would probably need set up the RTP paylod data in the RTP
Dissector to have the payload properly dissected. I'm not sure if this is interleaved with the
RTP conversation setup in that case modifications to the RTP dissector may be needed.


About the dissector:
I don't think this lines are needed:
	if ((tvb == NULL) || tvb_length(tvb) < 16) 
		return 0; /* only look at UDP packets */ 
	
	if (pinfo->ipproto != IP_PROTO_UDP) 
		return 0; 
	
	/* check RTP version */ 
	version = RTP_VERSION(tvb_get_guint8(tvb, 4)); 
	if (version != 2) 
		return 0; 

I'd do all the column stuff after:
	/* Clear out stuff in the info column */ 
	col_clear(pinfo->cinfo,COL_INFO); 


-	mux_id = tvb_get_guint8(tvb, 0)*16777216 + tvb_get_guint8(tvb, 1)*65536 + tvb_get_guint8(tvb, 2)*256 + tvb_get_guint8(tvb, 3); 
+     mux_id = tvb_get_ntohl(tvb, 0); 

Move proto_register_h46019rtpmux() after dissect_h46019rtpmux()

Regards
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