[Home]

Summary:ASTERISK-18748: channel ooh323 hangs up calls after about 1 minute
Reporter:Fabrizio Lazzaretti (fabsoft)Labels:
Date Opened:2011-10-24 05:17:19Date Closed:2011-11-09 12:44:15.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Addons/chan_ooh323
Versions:1.8.3 1.8.7.0 Frequency of
Occurrence		Constant
Related
Issues:
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
(10) h323_log
(11) h323_log_post_patches
(12) h323_log_post_patches_2
(13) h323_log_post_patches_3
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:

[md110]
type=friend
context=default
ip=192.168.2.115   ; UPDATE with appropriate ip address
port=1820    ; UPDATE with appropriate port
disallow=all
allow=ulaw,alaw
faststart=yes
h245tunneling=no

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 ?
thank you

Comments:By: Alexander Anikin (may213) 2011-11-01 08:37:20.172-0500

Hello,

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

Fabrizio,

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.
Thanks

By: Alexander Anikin (may213) 2011-11-03 18:45:55.307-0500

Fabrizio,

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

Fabrizio,
pls test new patch.
By: Fabrizio Lazzaretti (fabsoft) 2011-11-04 10:58:31.211-0500

Alexander,

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

Fabrizio,

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

Alexander,

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..
thank you
By: Alexander Anikin (may213) 2011-11-07 04:52:05.037-0600

Fabrizio,

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

Alexander,

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
thanks
By: Alexander Anikin (may213) 2011-11-07 07:57:32.080-0600

Fabrizio,

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

Fabrizio,

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

Fabrizio,

pls test 5th patch. DisplayIE removed from Status message
By: Fabrizio Lazzaretti (fabsoft) 2011-11-09 05:26:56.444-0600

Alexander !!
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

Fabrizio,

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 1.8.7.0 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)?

Thank you!
By: Alexander Anikin (may213) 2013-01-31 13:08:47.543-0600

Dorin, this patch is included to asterisk from 1.8.9.0 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.