Summary: | ASTERISK-22852: Error decoding H245 message - ooh323c | ||
Reporter: | Gabriele Odone (gabrieleodone) | Labels: | |
Date Opened: | 2013-11-13 05:28:23.000-0600 | Date Closed: | |
Priority: | Major | Regression? | |
Status: | Open/New | Components: | 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.5 | Attachments: | ( 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. |