Summary:ASTERISK-07774: hangup cause 38 for source releases calls
Reporter:Di-Shi Sun (homesick)Labels:
Date Opened:2006-09-19 15:49:07Date Closed:2011-06-07 14:07:54
Versions:Frequency of
Environment:Attachments:( 0) 1.log
( 1) 2.log
( 2) config.log
( 3) test2.doc
( 4) test2.txt
Description:In ooh323 (source asterisk)->(proxy asterisk)->(destination asterisk) test, if the source asterisk releases the call first, the hangup cause on the proxy asterisk is 38. If the destination asterisk releases the call first, the hangup cause on the proxy asterisk is 16.


asterisk-addons svn 295

I attached the test log including test bed configuration, ooh323.conf, extensions.conf, cli log, and h323_log in one doc file.
Comments:By: Anthony LaMantia (alamantia) 2006-09-27 17:51:13

is it possible that you can include these as a flat text file that i can read. ATM i don't have program that can view files in this format, and i assume quite a few others working on this project don't either.

By: jmls (jmls) 2006-11-01 06:37:22.000-0600

alamantia, any news on this ?

By: jmls (jmls) 2007-01-07 03:07:56.000-0600

can we close this ?

By: Serge Vecher (serge-v) 2007-01-08 12:48:53.000-0600

objsys: I think this is waiting for your input ...

By: Objective Systems (objsys) 2007-01-19 12:51:19.000-0600

16 means normal call clearing.

If 38 value is generated by call ending endpoint, than it is a correct value.

If 38 value doesn't sounds right, than please provide the h323_log with asterisk-ooh323c channel driver build as debug.

cd asterisk-addons-1.2/asterisk-ooh323c
make clean
make debug
make install

Than run the case & provide the h323_log

Avin Patel
Objective Systems Inc

By: Di-Shi Sun (homesick) 2007-01-19 13:49:34.000-0600

38: This cause indicates that the network is not functioning correctly and that the conditions are likely to last a relatively long period of time. A call that is attempted soon afterwards will most likely not connect successfully. - An Introduction to ISDN

I do not think it is correct for normal completed calls.

I am on vacation. I will provide debug log as soon as I am back to the office.

By: Objective Systems (objsys) 2007-01-19 14:12:46.000-0600

I think you are mentioning two case:
case 1: Call cleared by source, cause 38
case 2: Called cleared by destination, case 18

I don't see any problem in case 2.
For case 1, if call is dropped for network failure, than there is no problem in case 1 also.

Let me know this is not the case.

> A call that is attempted soon afterwards will most likely not
> connect successfully.
There is not hard bind rule here, it just thought that if network has problem, than for next *immediate* call, there is more possibility of network still has problem than the congestion is gone.

We have to see how the call is ended(should be from debug log). If call is ended normally, than number 38 is problem.

Avin Patel

By: Serge Vecher (serge-v) 2007-03-13 13:56:01

homesick: any updates here?

By: Di-Shi Sun (homesick) 2007-03-14 00:08:13

Sorry, I cannot work for this issue now. I hope I can back in two weeks.

By: Di-Shi Sun (homesick) 2007-05-25 13:01:20


I re-run the test for asterisk svn 65312 and addons svn 384. I attached the configure in config.log (including ooh323.conf and extensions.conf), source hung up log, 1.log (including source gateway log, asterisk cli, h323_log and destination gateway log), and destination hung up log, 2.log for this test.


Di-Shi Sun.

By: Russell Bryant (russell) 2008-01-16 12:05:02.000-0600

This module has been unsupported for a long time.  Now, it is officially marked as unsupported.  So, only bug reports with patches will be accepted at this time.