Date: Sat, 06 Jan 2007 18:09:02 +0100 From: "Hans Petter" <mc467741@c2i.net> To: Oliver von Bueren <maillist@ovb.ch>, freebsd-isdn@freebsd.org Subject: Re: ISDN4BSD - Dropped Calls Message-ID: <web-51294860@mailbe05.swip.net> In-Reply-To: <459FCD1E.9080303@ovb.ch> References: <459FCD1E.9080303@ovb.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Oliver, On Sat, 06 Jan 2007 17:23:58 +0100 Oliver von Bueren wrote: > 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. These are dummy messages, which are part of the procedure to bring up the layer 2 "TCP" connection. The idea was to send a zero length I-frame, but many PBX's simply lack a check for zero length I-frames and will continue to process the frame as if data was present leading to crashes i n most cases. To avoid this, I send four extra bytes, which makes up the STATUS_ENQUIRY message. > This is not a call ID we've had so far and looks like a >MAX-Value to me. The call ID 0x7F is never used for outgoing calls from the I4B. > - F101 these ENQs are answered by NT with a >RELEASE/invalid call ref id. It indicates that the PBX creates a new call at the moment it receives a new Call-reference messages. Really it should do nothing when the call reference is invalid, or maybe send a RELEASE_COMPLETE. But not RELEASE. > 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 If you don't send a message back in reply to the RELEASE message, the NT-side will most likely send a RESTART message or just hang up all c alls, from my experience. > - 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 => ?? I4B will hangup the call if the NT-side does not respond to STATUS_ENQUIRY, after 8 to 16 seconds. This is just a safety mechanism. The DSS1 specification says that implementing STATUS_ENQUIRY response is mandatory. > > - 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. It is just how I4B starts up the D-channel. It sends two I-frames and waits until it gets a reply before it sends more frames. This avoids races with SABME/UA. > 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. Because else the NT-side will most likely do a reset on all active calls. The reason I4B hangs up is because the NT-side does not reply to the last STATUS_ENQUIRY message for call reference 0x35 in your log. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?web-51294860>