Summary:	ASTERISK-10086: mISDN sporadically rejects incoming calls
Reporter:	workaholiker (workaholiker)	Labels:
Date Opened:	2007-08-15 02:58:36	Date Closed:	2008-05-06 16:10:23
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_misdn
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) debugtool.log-1 ( 1) debugtool.log-2 ( 2) dmesg.txt ( 3) misd_trace.txt ( 4) misdn_call_ok.txt ( 5) misdn_call_rejected#2.txt ( 6) misdn.config.txt
Description:	Incoming calls are rejected, caller hears "the number you've called is not available", to get rid of tis issue asterisk must be restarted, misdn reload doesn't help. Trace files of succesfull and broken call are atattached, differences begin under the ======= line.
Comments:	By: crich (crich) 2007-08-15 05:43:37 can you please follow the instructions on: http://www.misdn.org/index.php/Debugtool and enable the debugging of the NT Ports. It seems that the PBX which is connected to the NT Port is sending a reject, i want to make sure what happens with the debugtool. with the debugtool we can create a trace which we take shortly before and shortly after data is transceived from the BRI Card, which will show us what is really happening on the line. By: workaholiker (workaholiker) 2007-08-15 07:37:57 here is a trace of a failed one By: crich (crich) 2007-08-15 07:44:48 i will need the binary trace, which is created by ' -f ' By: workaholiker (workaholiker) 2007-08-15 07:59:31 sorry :) By: crich (crich) 2007-08-15 08:18:05 you can open the trace with wireshark easily and see that we receive a CONNECT, and directly afterwards we receive a DISCONNECT with cause:21 => Call Rejected So i think this is sent by your PBX.. By: workaholiker (workaholiker) 2007-08-15 09:03:54 yes, i think too, that i have something causing chan_misdn to reject a call: PP[ 2] $$$ find_holded: --> holded:0 channel:0 P[ 2] $$$ find_holded: --> holded:0 channel:0 P[ 2]  --> org:1 nt:1, inbandavail:0 state:11 P[ 2]  --> * SEND: Queue Busy pid:3 P[ 2]  --> queue_hangup P[ 2] I SEND:RELEASE oad: dad:XXXXXXX pid:3 why chan_misd thinks that all queues are busy? By: crich (crich) 2007-08-15 09:33:19 the PBX (not Asterisk and chan_misdn) is rejecting the Call with the DISCONNECT ! I IND: <-- means incoming event, as you see: P[ 2] I IND :DISCONNECT oad: dad:XXXXXX pid:11 state:CONNECTED P[ 2]  --> channel:1 mode:NT cause:21 ocause:16 rad: cad: P[ 2]  --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0 By: workaholiker (workaholiker) 2007-08-15 10:54:53 I have no other PBX as asterisk here... Connect is working perfectly. P[ 1] I IND :CONNECT_ACKNOWLEDGE  oad: dad:XXXXXX pid:37 state:CONNECTED P[ 1]  --> channel:1 mode:TE cause:16 ocause:16 rad: cad:XXXXXX P[ 1]  --> info_dad: onumplan:0 dnumplan:4 rnumplan:  cpnnumplan:0 P[ 1]  --> caps:Speech pi:0 keypad: sending_complete:1 P[ 1]  --> screen:3 --> pres:1 P[ 1]  --> addr:50010102 l3id:2002e b_stid:10010100 layer_id:50010180 P[ 1]  --> facility:Fac_None out_facility:Fac_None P[ 1]  --> bc_state:BCHAN_ACTIVATED P[ 1] BCHAN: bchan ACT Confirm pid:37 there is no audio, sometimes a caller hears rejection tones and connection drops, but the callee always has an active channel until hangup button is pressed on the phone. after a while comes P[ 2] % GOT L2 DeActivate Info. and incoming disconnect event occurs only after the caller/callee hangups. Please take a look at tracefile from te port. Events are in some kind of strange order as i think: call proceeding->alerting->connect->disconnect->connect_aknowledge By: crich (crich) 2007-08-15 13:12:29 what kind of device is connected to your NT port? is it maybe a Siemens Gigaset ? These devices seem to be a lot buggy.. By: workaholiker (workaholiker) 2007-08-15 13:52:38 yes it's a gigaset sx445 By: workaholiker (workaholiker) 2007-08-18 07:28:12 Hi crich, let's discuss what can we do to get rid of this. I've started with misdn 1.0.4 and i swear i hadn't this issue. Few months ago an update of asterisk and the whole stuff was made and something is broken now. i've tested this particular phone attached to a fritzbox as an ata adapter to my *. All features are working flawlessly. May be gigaset is very buggy, but fact is it functions as it must attached directly to pstn line or to other hardware. i'm ready to provide you all logs, traces everything you need, but please take a look at this. By: crich (crich) 2007-08-21 10:00:07 I'll check that out, i'll connect my gigaset equipment here too. Is there a certain way to reproduce the issue? By: workaholiker (workaholiker) 2007-08-21 13:00:53 after a reboot things are generally fine, if i want to reproduce this i do two calls to NT ports and try to hold/retrieve the first one. It always fails and after that i have 80% probabylity that all incoming calls are not accepted. i only hope it's not some interrupt or resource issue, but i can't see anything suspicious in syslog. By: crich (crich) 2007-09-12 04:25:55 I've made a new release of mISDNuser (1.1.6) and chan_misdn 0.3.1-rc35, these contain a bug fix for HOLD/RETRIEVE. Also there are some minor NT Mode tweaks, that might ressolve your problem. Could you please upgrade to these versions and try again. If you use Asterisk 1.4 or higher you'll need to use the latest svn release in order to have this bugfix. Please report back any issues. By: workaholiker (workaholiker) 2007-09-13 02:11:13 great news! svn version ist too much buggy for me, i've patched chan_misdn.c and isdn_lib.c from 1.4.11 and installed 1.1.6 version of mISDN, here my first impressions: - hold/retrieve is now working, conferencing not. - i can't dial a port group any more, ex. dial(misdn/2) fails, i need to provide an extension. - if a holded caller hangups channel is not closed, so after active call is over i have incoming "ghost" calls that can't be picked up and it's always reproduceable Don't know if the issue with incoming calls still persist, need more time to test. Thanks. By: Joshua C. Colp (jcolp) 2008-02-26 11:52:36.000-0600 workaholiker: Any further progress? By: Jason Parker (jparker) 2008-05-06 16:10:21 Since the issue that was causing this was fixed by upgrading to 1.1.6, I am going to close this report. If you have further issues, and they can be reproduced on the latest versions of Asterisk 1.4 and mISDNuser, please do open new reports for those.