Summary:	ASTERISK-07774: hangup cause 38 for source releases calls
Reporter:	Di-Shi Sun (homesick)	Labels:
Date Opened:	2006-09-19 15:49:07	Date Closed:	2011-06-07 14:07:54
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Addons/chan_ooh323
Versions:		Frequency of Occurrence
Related Issues:
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. ****** ADDITIONAL INFORMATION ****** 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. 38 means AST_CAUSE_NETWORK_OUT_OF_ORDER 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 Regards, 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. Regards, 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 Hi, 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. Regards, 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.