Hi,
Here is the patch to fix the bug related to the decodification of a h225 packet as a h245 packet.
Please review the change and tell me your feedback. I let you commit the change once it has been reviewed and accepted.
Is there any regression tests out there to find out if these modifications create other problems ?
Regards,
Frederic Heem
-----Original Message-----
From: Martin Regner [mailto:martin.regner@xxxxxxxxx]
Sent: Mon 11/8/2004 6:32 PM
To: ethereal-dev@xxxxxxxxxxxx
Cc: Frederic Heem
Subject: Re: [Ethereal-dev] h225 decoded as h245
Frederic Heem wrote:
<In some situations, ethereal (0.10.0a and 0.10.7, linux and windows) fails to find the protocol h225, it says it's a
h245 whereras it's a h225.
<In the trace attached, there are four endpoints based on the telsey h323 stack, each of them have 2 phone numbers:
<When the setup decodification fails, all successive messages failed to be decoded (call proceeding, alerting, connect
and release complete).
<If "Decode As" is performed on a wrong packet, it doesn't allow to choose h225
I think that I understand what the reason for this is.
Some of the H.225 messages include a h245address element
Optional Field Bit: .1.. .... True (h245Address is present)
Object Length: 6
ProtocolIdentifier: 0.0.8.2250.0.4
h245Address
Extension Bit: 0... .... False
h245Address: ipAddress (0)
ipAddress
IP: 192.168.0.16 (192.168.0.16)
Port: 1024
(packet 53, 84, ...)
Ethereal will set up "conversations" to catch the H.245 messages sent on that specific ip-address/port-number
combination,
but that port number will be used for H.225 messages later on in the capture.
Those messages will then be decoded as H.245 messages even if they are H.225 messages since "conversations" have
higher priority.
I don't know right know how this problem could be solved in a good way.
Attachment:
packet-h225.c
Description: packet-h225.c
