[Home]

Summary:ASTERISK-22852: Error decoding H245 message - ooh323c
Reporter:Gabriele Odone (gabrieleodone)Labels:
Date Opened:2013-11-13 05:28:23.000-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Addons/chan_ooh323
Versions:11.4.0 11.6.0 12.0.0-beta1 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:RH 5.5Attachments:( 0) 20131120_capture.pcap
( 1) failure.pcap
( 2) failure2.pcap
( 3) h323.log
( 4) h323.log
( 5) PolycomRMX.pcap
( 6) success.pcap
Description:Environment:
- Asterisk 11.4
- H323 trunk between Asterisk and "Polycom CMA" (H323 Gatekeeper) using
ooh323c module.
- An H323 MCU  ("Polycom RMX") is registered to "Polycom CMA" gatekeeper.

When H323 calls are placed by Polycom RMX, the following lines are written
in /var/log/asterisk/h323_log:

=========================
16:42:04:417  Asn1Error: -2 at ooh323c/src/decode.c:67
16:42:04:418  Error decoding H245 message (incoming, ooh323c_2)
=========================

The same code generating this error is also in the latest 11.6 and 12.0
beta.

Symptom: From the "Polycom RMX" side, the call is heard ringing. From the
SIP side, the call is received and answered. See attached tcpdump example: failure.pcap

If, instead of placing the call from the "Polycom RMX", I place the call
from another H323 endpoint (registered to the same H323 Gatekeeper,
"Polycom CMA"), the call goes through without such error (example: success.pcap).

I suppose it is a H245 parsing error.

In the attached tcpdumps:

10.44.1.60 = SIP client
10.100.202.88 = Asterisk server
10.71.0.55 = H323 Gatekeeper (Polycom CMA)
10.71.0.51 = H323 "client" (Polycom RMX) registered to H323 gatekeeper
10.44.1.156 = H323 client (Polycom CMA Desktop) registered to H323 gatekeeper
Comments:By: Gabriele Odone (gabrieleodone) 2013-11-13 05:29:35.527-0600

see attached referenced traces.
By: Alexander Anikin (may213) 2013-11-13 15:48:08.929-0600

Gabriele,
I see some strange packet from RMX that can cause asn1 decode error.

Frame 29: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
...
Internet Protocol Version 4, Src: 10.71.0.51 (10.71.0.51), Dst: 10.100.202.88 (10.100.202.88)
...
TPKT
   Continuation data


Asterisk can't understand this packet.
I think there must be terminal capability set from RMX instead of this packet.

All another packets in call handshake are correct. Asterisk send TCS to RMX, RMX send TCS ACK,
then RMX send this strange packet, then Asterisk send MSD request and RMX send MSD ACK.
But because there isn't completed TCS exchange logical channels can't be opened and
voice path can't be established.

I'll investigate what is this packet, but you can try to change config parameters on RMX.
Most H.323 devices use faststart and h245tunneling for more fast and easy call establishement,
on your RMX these parameters are off. Please try to switch on these parms and make test calls.
Also change to on Asterisk if they are off there also.



By: Alexander Anikin (may213) 2013-11-13 15:49:10.602-0600

Garbiele,
please try make calls with faststar and h245tunneling activated on both
sides of call.
By: Gabriele Odone (gabrieleodone) 2013-11-14 03:03:38.755-0600

Hi Alexander,

I will try faststart and h245tunnelling, however I note that the TPKT packet behavior is not consistent, for example I attach a trace showing the full traffic between H323 client "Polycom RMX" and Asterisk, there is no such packet.

KR
Gabriele
By: Alexander Anikin (may213) 2013-11-15 04:47:53.320-0600

Gabriele,

it's difficult to analyze last attached cap because there is no h.323 packet only h.245. Could you reattach him with full call signalling data?
And how are results with faststart/h.245tun?

By: Gabriele Odone (gabrieleodone) 2013-11-15 05:12:03.027-0600

Hi Alexander,

H323 faststart is unfortunately not a configurable item on Polycom RMX side.

Please find attached a new full trace:

10.44.1.156 = SIP client
10.100.202.88 = Asterisk server
10.71.0.55 = Polycom CMA
10.71.0.51 = Polycom RMX


Kind Regards

Gabriele Odone
By: Alexander Anikin (may213) 2013-11-15 11:17:26.504-0600

Gabriele,

Fast start isn't main option here, h245tunnelling is more valueable. But in the last cap they are off both.

However, i guess i known where point of trouble. In the last cap is no one undecoded packet but i don't see
TCS acknowlege from asterisk and TCS ack found from Polycom. I will search bug in codes.

By: Alexander Anikin (may213) 2013-11-16 11:54:37.604-0600

Gabriele,

Could you make test call with tracelevel=6 in ooh323.conf section [genera] and attach /var/log/asterisk/h323_log here?
Don't see any bug in codes for sending TermCapSet ACK, it's could be TCS from RMX can't be decoded. Need to see more verbose log which will generated with tracelevel=6
By: Gabriele Odone (gabrieleodone) 2013-11-19 03:10:33.297-0600

Hi Alexander,

Please find attached the h323 log with tracelevel=6.

Thanks
Kind Regards,
Gabriele
By: Alexander Anikin (may213) 2013-11-19 15:48:58.157-0600

Hi Gabriele,

could you please attach h323 log and capture file exactly from same call?
I compare attached log and cap from 15 Nov and i think they are different in the point of problem (tcs packet from Polycom). Asterisk must decode right tcs request like from cap from 15 Nov, I guess it can't be decoded when Polycom try to fragment big h.245 packet.

By: Gabriele Odone (gabrieleodone) 2013-11-20 02:26:27.147-0600

Hi Alexander,

Please find attached a log and tcpdump of the same failed call.

10.44.1.156 = SIP client
10.100.202.88 = Asterisk server
10.71.0.55 = Polycom CMA
10.71.0.51 = Polycom RMX


Thanks

Kind Regards

Gabriele Odone
By: Alexander Anikin (may213) 2013-11-20 06:36:35.906-0600

Gabriele, thank you for attached files. TCS from Polycom same as from 15 Nov. I can't explain now why asterisk can't decode right this TCS, will research this.