|Summary:||ASTERISK-18748: channel ooh323 hangs up calls after about 1 minute|
|Reporter:||Fabrizio Lazzaretti (fabsoft)||Labels:|
|Date Opened:||2011-10-24 05:17:19||Date Closed:||2011-11-09 12:44:15.000-0600|
|Versions:||1.8.3 220.127.116.11||Frequency of|
|Environment:||Attachments:||( 0) asterisk_ooh323.log|
( 1) ASTERISK-18748-2.patch
( 2) ASTERISK-18748-3.patch
( 3) ASTERISK-18748-4.patch
( 4) ASTERISK-18748-5.patch
( 5) ASTERISK-18748-double-tcs-seq0.patch
( 6) ASTERISK-18748-status-msg.patch
( 7) dump_asterisk_tcp_filtered_patch4.pcap
( 8) dump_asterisk_tcp_filtered.pcap
( 9) dump_yate_tcp_filtered.pcap
|Description:||Hi all, im trying to interconnect a ericsson md110 h323 card to channel ooh323 in asterisk 1.8.|
the configuration is very simple, it's the standard ooh323.conf file without gatekeeper and only one device:
ip=192.168.2.115 ; UPDATE with appropriate ip address
port=1820 ; UPDATE with appropriate port
when i call to ooh323 channel, it works normally but after a while, in a indeterministic-behaviour, the call stops.
i've also enabled ooh323 debug but it reports a normal ending call. it happens sometime after 40 sec. and sometimes after 1 minute.
do you have some advise or test that i can do ?
|Comments:||By: Alexander Anikin (may213) 2011-11-01 08:37:20.172-0500|
Please enable more verbose log with tracelevel=6 and attach part of the log related to problematic call here.
I suggest there is some H.245 exchange trouble, but i need to see detail log.
By: Fabrizio Lazzaretti (fabsoft) 2011-11-02 05:18:15.804-0500
Thanks for your reply, i have attached the logfile.
In this call, the channel hangs up after 39 seconds.
I have no idea about the h323's card configuration in the other end because there's another system engineer, but he told me that he tryed different confs without any success to solve the problem, also he reports that the ericcson md-110 logfile show a normal call ending caused by asterisk.
Thanks in advance
By: Fabrizio Lazzaretti (fabsoft) 2011-11-02 05:19:18.361-0500
call started by asterisk and ended up in 39 seconds.
By: Alexander Anikin (may213) 2011-11-02 07:35:18.513-0500
Fabrizio, please attach part of /var/log/h323_log file generated with tracelevel=6 in general section in /etc/asterisk/ooh323.conf
Trouble looks like to MSD (master/slave detemination) procedure have timeout here (msd timer is set to 30 seconds).
By: Fabrizio Lazzaretti (fabsoft) 2011-11-02 13:11:41.193-0500
log with tracelevel=6
the call i started by console dial command.
By: Alexander Anikin (may213) 2011-11-03 02:56:13.270-0500
Looks like to main trouble is here:
18:58:59:612 H.225 Status Inquiry message Received (outgoing, ooh323c_o_1)
18:59:23:724 Warn:RemoteEndpoint closed connection (outgoing, ooh323c_o_1)
I suggest MD110 wait some reply from asterisk side to status inquiry message
and close connectin without that reply. I will do some research about it.
And i see some additional issue that need explaining:
asterisk send two Terminal Cap Set requests instead of just one.
By: Alexander Anikin (may213) 2011-11-03 03:02:22.574-0500
please check faststart settings in MD110 section of your ooh323.conf.
I see on the log that faststart is disabled.
Also you can try to activate h245tunneling on md110 if it support this feature.
also you can setup roundtrip=0,0 in general on individual peer section in the ooh323.conf
to disable these feature instead of setup this to very big values (in your config these are 99999,99999).
By: Alexander Anikin (may213) 2011-11-03 10:45:45.276-0500
Patch for status inquiry message processing uploaded. Pls try it.
By: Alexander Anikin (may213) 2011-11-03 10:59:23.345-0500
double-tcs-seq0.patch must solve double term cap set sending, pls apply it also
By: Fabrizio Lazzaretti (fabsoft) 2011-11-03 11:46:22.048-0500
Thanks for your time spent investigating in this issue.
I've applied both patches and i've corrected ooh323.conf with new values of roundtrip=0,0 and faststart=yes.
Unfortunately i guess the received inquiry message is not recognized and the call ends in the same way.
I'll try to explain to the engineer to reconfigure the md110 in order to activate the faststart feature with the hope that something changes.
By: Alexander Anikin (may213) 2011-11-03 18:45:55.307-0500
faststart feature is activated already on yours MD as i seen on the log.
You can ask your colleague to enable h245tunelling on PBX.
Inquiry msg is recognized and processed by lower layer of codes but status message banned
by upper layer (q.931 packet processing).
You can see this on log:
16:23:53:885 H.225 Status Inquiry message Received (outgoing, ooh323c_o_1)
16:23:53:885 Building StatusMsg (outgoing, ooh323c_o_1)
16:23:53:885 Built Status (outgoing, ooh323c_o_1)
16:23:53:885 Error:Unknow Q931 message type. (outgoing, ooh323c_o_1)
16:23:53:885 Error:Failed to encode H225 message. (outgoing, ooh323c_o_1)
16:23:53:885 Error:Failed to enqueue Status message to outbound queue.(outgoing, ooh323c_o_1)
I'll fix this tomorrow.
Double TCS solved by the patch, there is one TCS on last log.
By: Alexander Anikin (may213) 2011-11-04 06:15:24.938-0500
New patch uploaded. It contain status message support with correct identification message on q.931 layer.
It contain double tcs patch and must be applied to clean branch.
By: Alexander Anikin (may213) 2011-11-04 06:16:30.199-0500
pls test new patch.
By: Fabrizio Lazzaretti (fabsoft) 2011-11-04 10:58:31.211-0500
the problem related to status message encoding seems to be solved, but nothing change with the hangup, ericsson side closes the connection and i dont understand why...
thanks a lot for your support
By: Alexander Anikin (may213) 2011-11-04 13:32:16.475-0500
It's could be that we make status reply message incorrectly. I'll try to understand about it, but unfortunately i don't have any PBX/Switches that send Status inquiry message.
By: Alexander Anikin (may213) 2011-11-04 19:12:54.465-0500
New (3rd) patch here. It add cause and call state Information Elements according H.225.0 spec (these IEs are mandatory for Status message)
By: Alexander Anikin (may213) 2011-11-04 19:15:04.593-0500
Pls try 3rd patch. It add mandatory IEs (as in H.225.0 spec).
This patch is for clean branch.
By: Fabrizio Lazzaretti (fabsoft) 2011-11-07 04:29:50.093-0600
hi've tested the third patch but the hangup problem remains.
Can i help you if i tell you i'm currently using h323 with yate sip-to-h323 bridge ?
Maybe enabling some sort of tracing/debug i can extrapolate something useful..
By: Alexander Anikin (may213) 2011-11-07 04:52:05.037-0600
Sure, you can help if you attach here log from yate same
as /var/log/asterisk/ooh323_log from asterisk.
Unfortunately, i need some time to understand how to configure/use yate for getting this log,
i had not use yate previously.
By: Fabrizio Lazzaretti (fabsoft) 2011-11-07 05:48:07.598-0600
i think this can help more that yate's tracelog. i'm attaching 2 tcp captures, one from yate call and other one from asterisk call.
the first call i made from yate is correctly closed by callee peer after about 2 minutes, just to see how yate reply to status inquiry msg.
With the help of wireshark is easy to decode h225 messages.
for now, thanks for your support
By: Fabrizio Lazzaretti (fabsoft) 2011-11-07 06:15:50.197-0600
im trying to compare the reply message to statusinquiry msg between both files.
i figure out a difference in reply msg (status) in the q931 header:
asterisk fits the cause code to 0x08.02.80.80 ("valid cause code not yet received" as wireshark shows) while
yate fits the cause code to 0x08.02.80.9e ("STATUS ENQUIRY 30" as wireshark decodes).
hope it can be helpful
By: Alexander Anikin (may213) 2011-11-07 07:57:32.080-0600
Thank a lot, it's that i need to explain. I'll analyze attached caps.
By: Alexander Anikin (may213) 2011-11-07 15:44:43.185-0600
4th patch uploaded. Just change cause code from 0 to 30 (response to status enquiry) in the status response.
By: Alexander Anikin (may213) 2011-11-07 15:45:43.884-0600
I changed cause code to correct. Please check call from asterisk with new patch.
By: Fabrizio Lazzaretti (fabsoft) 2011-11-08 12:29:33.898-0600
sadly we had no luck! call ends in the same way.
the only difference in the status message (reply to statusinquiry)is the additional "Display" field in q931 header set to "asterisk". I dont mind this can be he problem or it shouldn't.
can you address me how to remove that header field ?
thank you anyway
By: Alexander Anikin (may213) 2011-11-08 13:46:34.396-0600
Patch uploaded. DisplayIE removed here for q.931 Status message
By: Alexander Anikin (may213) 2011-11-08 13:48:18.230-0600
pls test 5th patch. DisplayIE removed from Status message
By: Fabrizio Lazzaretti (fabsoft) 2011-11-09 05:26:56.444-0600
now it succeeded ;)
the fight against md110 was won.
I dont know if md110 match over q931 lenght (which in the case of Status msg is equal to 48 bytes) to validate a packet, or simply discards it whenever match a "Display" tag.
Anyway it works ! thank you a lot
By: Alexander Anikin (may213) 2011-11-09 07:13:44.522-0600
Thank a lot for testing, i think md assume status reply incorrect with display info element.
So i will close issue due to resolved.
By: Dorin Florea (dorinf) 2013-01-30 02:15:31.910-0600
Hello, I tried also to connect Ericsson MD110 PABX to Asterisk 18.104.22.168 using H.323 trunks as described in this issue but in the moment I try to apply the ASTERISK-18748-5.patch (that seems to be the patch that fixes the issue) I got this message from Asterisk:
patching file ootypes.h
patching file ooh323.c
patching file ooh245.c
patching file oochannels.c
patching file ooq931.c
patching file ooq931.h
patch unexpectedly ends in middle of line
Hunk #3 succeeded at 719 with fuzz 1.
If I run Asterisk after this, I get "segmentation fault".
Could you please help me with the correct patch or to indicate the right procedure?
The solution of this issue is included in the later releases of the Asterisk (1.8.20, 10, 11)?
By: Alexander Anikin (may213) 2013-01-31 13:08:47.543-0600
Dorin, this patch is included to asterisk from 22.214.171.124 and 10.2.0 and later versions.
Please check these or newest versions.
If you will have troubles again please create new issue to fix it.