Andreas Sikkema:
>I just checked some H.323 captures I have in my archive and I found a
>couple of problems.
>
>1. InformationRequestResponses are not decoded properly (I have not
> yet seen one decoded properly) (H.225.0 RAS)
>2. There is a problem with H.225.0 CS messages (particularly with
> SETUP messages for some reason.
>3. I have seen problems with H.245
>
>The last two are probably related to TPKT handling. The first two
>problems are evident in the attached capture.
Hi,
I have also noticed problems with IRR messages. I haven't looked so much closer on that issue, but I sent a sample capture to
Ronnie yesterday.
I checked the Setup messages in your capture and I don't see any problem. Can you send a printout of the Setup message
and also indicate more in detail what is faulty. Are you using TCP desegmentation?
Are you using the latest version of the H.225/H.245 dissectors?
I am going to test the latest version of the H.245/H.225 dissectors together with a lot of captures during the weekend.
The tests I did Friday went very well then (but then I only tested a subset of captures). The only problems I found then was:
1) IRR messages:
================
perCallInfo
Sequence-Of Length: 6
Item 0
perCallInfo_item
CallReferenceValue: 256
[Malformed Packet: H225]
Same problem as appeared in your capture.
2) productID/versionID without null-termination resulting in rubish last in the productID/versionID:
==========================================================================
e.g.
h221NonStandard
t35CountryCode: 11
t35Extension: 11
manufacturerCode: 11
Octet String Length: 28
productID: InnoMedia InfoView Broadband\00101\001@
Octet String Length: 2
versionID: 01\001@
instead of:
h221NonStandard
t35CountryCode: 11
t35Extension: 11
manufacturerCode: 11
Octet String Length: 28
productID: InnoMedia InfoView Broadband
Octet String Length: 2
versionID: 01