From owner-freebsd-isdn Mon May 24 2: 2:33 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (Postfix) with ESMTP id 93F2914BFE for ; Mon, 24 May 1999 02:02:27 -0700 (PDT) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id LAA31383; Mon, 24 May 1999 11:02:27 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m10lqcU-002ZjcC; Mon, 24 May 99 11:02 MET DST Received: from bert.kts.org([194.55.156.2]) (4424 bytes) by ernie.kts.org via sendmail with P:smtp/R:smart_host/T:uux (sender: ) id for ; Mon, 24 May 1999 10:27:11 +0200 (CEST) (Smail-3.2.0.103 1998-Oct-9 #5 built 1999-Apr-19) Received: from localhost (3974 bytes) by bert.kts.org via sendmail with P:stdio/R:smart_host/T:smtp (sender: ) (ident using unix) id for ; Mon, 24 May 1999 10:28:30 +0200 (CEST) (Smail-3.2.0.103 1998-Oct-9 #4 built 1998-Dec-26) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: Bug in i4b? Status Enquiry In-Reply-To: <199905232348.BAA06659@pollux.use.ch> from Caspar Schlegel at "May 24, 1999 1:48:32 am" To: schlegel@pollux.use.ch (Caspar Schlegel) Date: Mon, 24 May 1999 10:28:30 +0200 (CEST) Cc: freebsd-isdn@freebsd.org (ISDN for BSD) Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (i'm forwarding to the list, perhaps someone else has an idea ...) Caspar Schlegel wrote: > I seem to have found a bug in i4b... I'm getting kicked off the line > after about 3 mins after dialling & being connected. > > I'm using a AVM A1/Fritz Card with i4b 0.81, Freebsd 3.1 Release. I'm using > syncPPP. (isp0). I'm located in Switzerland. > > This is the D-Channel Dump from dialling until the Status Enquiry... > Note Frame 51, where I'm getting kicked off with cause 41. Linux > worked ok with these Sense keys. [...] > -- NT->TE - unit:0 - frame:000048 - time:19.05 07:58:31.186530 - length:8 ------ > Dump:000 02 91 08 04 .... > Q921: SAP=0 (Call Control), C, TEI=72, I-Frame: N(S) 4 N(R) 2 P 0 > Dump:004 08 01 b0 75 ...u > Q931: pd=Q.931/I.451, cr=0x30 (from destination), message=STATUS ENQIRY: > > -- TE->NT - unit:0 - frame:000049 - time:19.05 07:58:31.186530 - length:15 ----- > Dump:000 00 91 04 0a .... > Q921: SAP=0 (Call Control), C, TEI=72, I-Frame: N(S) 2 N(R) 5 P 0 > Dump:004 08 01 30 7d 08 02 80 1e 14 01 0a ..0}....... > Q931: pd=Q.931/I.451, cr=0x30 (from origination), message=STATUS: > [cause: 30: Response to STATUS ENQUIRY (Q.850) > (location=user, std=CCITT)] > [call state: Std=CCITT, State=Active] > > -- NT->TE - unit:0 - frame:000050 - time:19.05 07:58:31.196536 - length:4 ------ > Dump:000 00 91 01 06 .... > Q921: SAP=0 (Call Control), R, TEI=72, S-Frame: RR N(R) 3 PF 0 > > -- NT->TE - unit:0 - frame:000051 - time:19.05 07:58:35.736599 - length:22 ----- > Dump:000 02 91 0a 06 .... > Q921: SAP=0 (Call Control), C, TEI=72, I-Frame: N(S) 5 N(R) 3 P 0 > Dump:004 08 01 b0 4d 08 02 82 a9 28 08 46 52 2e 20 30 2e ...M....(.FR. 0. > Dump:020 30 30 00 > Q931: pd=Q.931/I.451, cr=0x30 (from destination), message=RELEASE: > [cause: 41: Temporary failure (Q.850) > (location=public network serving local user, std=CCITT)] > [display: FR. 0.00] The trace shows a completely valid behaviour according to Q.931, i've just read the specs again (or there is something going wrong what i simply don't see and have overlooked). The real question is, what makes the NT send you a STATUS ENQUIRY message ??? All is fine, nothing strange. The status reply is valid and shows everything is fine on our side too, so there is no obvious reason to send the RELEASE. There might be a drop of layer 1 (add the -i flag to isdntrace's options to see that). Cause 41 is a catch-all: ".. indicates that the network [!!! -hm] is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user [!!! -hm] may wish to try another call immediately". But it shows something is not working properly in the network, not on your side. Now it wold be interesting _how_ Linux handles this exact situation (i can't think how it could handle this differently - but again, i may be overlooking something). hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe We all live in a yellow subroutine, yellow subroutine, yellow subroutine ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message