ISDN4BSD - Dropped Calls

[Hans Petter]

   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