Date: Sat, 06 Jan 2007 17:23:58 +0100 From: Oliver von Bueren <maillist@ovb.ch> To: freebsd-isdn@freebsd.org Subject: ISDN4BSD - Dropped Calls Message-ID: <459FCD1E.9080303@ovb.ch>
next in thread | raw e-mail | index | archive | help
Hi Hans Petter As said in the last post about the update procedure, here are my traces concerning the disconnect after some 13 seconds. Calling from the ISDN side to Asterisk works fine, voice is played but then of a sudden, it stops/disconnects. I tried to get into the source of i4b but without much luck, I'm not used to driver code on FreeBSD. Following my findings after going through the traces including a link to the traces itself. Any ideas? Oliver ==== Additional information to the trace Software Versions FreeBSD 6.1-RELEASE-p11 (after a complete build/install world/kernel) (cvsup dated 20070104 around 18:00 GMT, RELENG_6_1) From Ports (cvsup dated 20070104 around 18:00 GMT) Asterisk 1.2.13, Copyright (C) 1999 - 2006 Digium, Inc. and others. ISDN4BSD (incl. chan_capi) via svn, 20070104 around 19:00 GMT) ==== The full trace files are on http://www.ovb.ch/i4b/isdn-trace-20070105.tar.gz ==== It's a base installation of Asterisk and i4b/chan_capi Connected to a PABX. All numbers starting with 84* terminate on the S0 the FreeBSD is connected to. Fresh startup of asterisk and isdntrace: asterisk -cdfgvvvvvvT // ISDN Debuging is enabled in capi.conf isdndecode -u 0 -i -x -r Extension 811 calls 840. Up to and including frame 117 the greeting voice from the default installation can be heard without problem. Then the sound stops. Frame 118-119 come in at the time the voice stops. Frame 120-121 shortly afterwards Frame 122- Hangup on the still connected (?) phone Stop isdntrace and asterisk I've done some analysing of this trace. BTW: I'm doing software development of a Dialogic PRI card (E1 in QSig mode), so I'm somewhat used to this kind of traces. NT is the PABX and TE is Asterisk/chan_capi/i4b. So lets see what happens. - F93 is a SETUP message for Call 0x35 => OK - F94/F95 is a TEI req and resp => OK - F97/F98 is quite strange, here TE makes two STATUS_ENQUIRY for call 0x7F. This is not a call ID we've had so far and looks like a MAX-Value to me. - F101 these ENQs are answered by NT with a RELEASE/invalid call ref id. Which to me looks quite correct. - F103 is the SETUP_ACK by TE => OK - F104 a PROCEEDINg by TE => OK - F105 TE tries to clean-up the Call 0x7F and sends a REL_COMPLETE, also with cause invalid call ref. id - F106: Release to the second STAT_ENQ by NT (see F101) - F109: see F105 - F111: We connect the call 0x35 => OK - F113: NT sends CON_ACK => OK - F116: TE makes a STAT_ENQ for Call 0x35 - F118: TE sends a REL_COMPLETE for Call 0x35 => ?? - F122: NT answers with DISCoNNECT My questions in this scenario are: Why are the STATUS_ENQs sent two times for Call 0x7f, which obvoiusly are not valid ones? My guess: The two available ISDN channels are initialised with call 0x7F and now cause some confusion. Why does TE send a REL_COM with F118? Has this still to do with the 0x7F-Call and some mixup with the channels. It doesn't look like a clean hangup by TE. === As you can see from the options of Asterisk, I've done a trace there as well. In the Asterisk-Trace the TEI assignment and STAT_ENQs for the 0x7F-Calls is not visible, it looks like that is not initiated by chan_capi. For the CAPI stuff in the trace, it looks quite good up to the point where a CAPI_DISCONNECT_B3_IND pops up. But I can't tell where that one is comming from. From the point on where the phone drops the call as well, it takes still some seconds till the PBX cleans up the call completely. If you do that several times, you can end up having both channels "blocked" without actually having a work connection. A call will fail with a busy then.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?459FCD1E.9080303>