Has anybody thought e.g. about constraints for coneversations? I.e. conversation would not
be boundless but with validity from/to some frame.
I guess it might solve this problem and problem with T.38 too.
Martin Regner wrote:
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.
