From owner-freebsd-isdn@FreeBSD.ORG Fri Nov 23 11:18:26 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DB3FAF3 for ; Fri, 23 Nov 2012 11:18:26 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9F18FC13 for ; Fri, 23 Nov 2012 11:18:25 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 67BC25D724; Fri, 23 Nov 2012 12:18:18 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id wTuaoFBcuIEz; Fri, 23 Nov 2012 12:18:17 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 789C45D722; Fri, 23 Nov 2012 12:18:17 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 58A7150876; Fri, 23 Nov 2012 12:18:17 +0100 (CET) Message-ID: <50AF5B79.5050802@incore.de> Date: Fri, 23 Nov 2012 12:18:17 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201211151812.32616.hselasky@c2i.net> In-Reply-To: <201211151812.32616.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 11:18:26 -0000 Hi Hans, > The chan_capi port has now been updated to version "chan_capi-2.0.3" which > should resolve the mentioned issues. If not, please let me know. 1. chan_capi: Good news: I can confirm that all deadlock problems with asterisk 1.8 are gone with your new port chan_capi-2.0.3 ! Everything works fine for a week now. 2. isdn4bsd-utils-2.0.4: Works fine, but to start isdnd reliable a minor patch mentioned earlier is necessary: -- src/usr.sbin/i4b/isdnd/support.c.orig 2011-10-10 20:34:44.000000000 +0200 +++ src/usr.sbin/i4b/isdnd/support.c 2012-07-10 15:53:26.00000 +0200 @@ -854,7 +854,7 @@ case 0: /* child */ break; default: /* parent */ - exit(0); + _exit(0); } Further I propose that you integrate a file named files/isdnd.in in the port like this: #!/bin/sh # PROVIDE: isdnd # REQUIRE: netif FILESYSTEMS cleanvar # KEYWORD: nojail . /etc/rc.subr name="isdnd" rcvar=`set_rcvar` pidfile="/var/run/${name}.pid" command="/usr/local/sbin/isdnd" load_rc_config $name isdnd_enable=${isdnd_enable:-"NO"} run_rc_command "$1" 3. isdn4bsd-kmod-2.0.4: One thing is left: the handling of DISCONNECT including error codes like "busy". We had some discussion about this in late 2010, I wrote > My understanding of the standard closing of a Q.931 connection is > --> DISCONNECT > <-- RELEASE > --> RELEASE_COMPLETE > it is like closing a tcp socket (-> FIN; <- FIN+ACK; -> ACK). I have > never seen an example that RELEASE and RELESE_COMPLETE is send in the > same direction. Your method of finishing a Q.931 connection is correct > but not standard: In the active case you send RELEASE_COMLETE, in the > passive case you answer the incoming DISCONNECT with RELEASE_COMPLETE. and your answer was that the statemachine in ISDN4BSD must be changed to accomplish my requirement. If you have a patch for this, I would like to test this. One last thing: As you know for my old PBX I need a patch called patch-no_status_enquiry_in_NT_MODE: --- src/sys/i4b/dss1/dss1_l2fsm.c.orig 2012-07-08 17:42:19.00000 +0200 +++ src/sys/i4b/dss1/dss1_l2fsm.c 2012-07-08 18:10:10.00000 +0200 @@ -1494,9 +1494,11 @@ * STATUS_ENQUIRY seems to not * be included by this rule. */ - *ptr++ = PD_Q931; - ptr = make_callreference(pipe_adapter, 0x7f, ptr); - *ptr++ = STATUS_ENQUIRY; + if(!(NT_MODE(sc))) { + *ptr++ = PD_Q931; + ptr = make_callreference(pipe_adapter, 0x7f, ptr); + *ptr++ = STATUS_ENQUIRY; + } m->m_len = ptr - ((__typeof(ptr))m->m_data); } --- src/sys/i4b/dss1/dss1_l3fsm.h.orig 2012-07-08 17:42:19.00000 +0200 +++ src/sys/i4b/dss1/dss1_l3fsm.h 2012-07-08 18:10:10.00000 +0200 @@ -298,6 +298,17 @@ newstate--; } } + else if (NT_MODE(sc) && + ((newstate == ST_L3_UC_TO) || + (newstate == ST_L3_UA_TO) || + (newstate == ST_L3_U3_TO) || + (newstate == ST_L3_U4_TO) || + (newstate == ST_L3_U6_TO) || + (newstate == ST_L3_U7_TO))) { + /* don't send status enquiry */ + send_status_enquiry = 0; + newstate--; + } cd->state = newstate; Should this become a config option in the port or would you prefer a sysctl for this ? Regards Andreas Longwitz From owner-freebsd-isdn@FreeBSD.ORG Sat Nov 24 11:26:24 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39C36EDA for ; Sat, 24 Nov 2012 11:26:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id AF3508FC13 for ; Sat, 24 Nov 2012 11:26:23 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 349229114; Sat, 24 Nov 2012 12:21:15 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Sat, 24 Nov 2012 12:22:52 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201211151812.32616.hselasky@c2i.net> <50AF5B79.5050802@incore.de> In-Reply-To: <50AF5B79.5050802@incore.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201211241222.52897.hselasky@c2i.net> Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 11:26:24 -0000 On Friday 23 November 2012 12:18:17 Andreas Longwitz wrote: > Hi Hans, > > > The chan_capi port has now been updated to version "chan_capi-2.0.3" > > which should resolve the mentioned issues. If not, please let me know. > Hi, I've made a new release of ISDN4BSD, now version 2.0.6. I4B SVN has been updated with new ports. > 1. chan_capi: > Good news: I can confirm that all deadlock problems with asterisk 1.8 > are gone with your new port chan_capi-2.0.3 ! Everything works fine for > a week now. Good! > > 2. isdn4bsd-utils-2.0.4: > Works fine, but to start isdnd reliable a minor patch mentioned earlier > is necessary: Fixed. Please test updated port. > Further I propose that you integrate a file named files/isdnd.in in the > port like this: Fixed with some modifications. Please test updated port. > 3. isdn4bsd-kmod-2.0.4: > One thing is left: the handling of DISCONNECT including error codes like > "busy". We had some discussion about this in late 2010, I wrote > > > My understanding of the standard closing of a Q.931 connection is > > > > --> DISCONNECT > > <-- RELEASE > > --> RELEASE_COMPLETE > > > > it is like closing a tcp socket (-> FIN; <- FIN+ACK; -> ACK). I have > > never seen an example that RELEASE and RELESE_COMPLETE is send in the > > same direction. Your method of finishing a Q.931 connection is correct > > but not standard: In the active case you send RELEASE_COMLETE, in the > > passive case you answer the incoming DISCONNECT with RELEASE_COMPLETE. > > and your answer was that the statemachine in ISDN4BSD must be changed to > accomplish my requirement. If you have a patch for this, I would like to > test this. I haven't had time to look into this one yet. I will see if I can find some time to do this. Else keep in reminding me or if you want you can suggest a patch. I think we already have a DISCONNECT state, where we can go instead of release complete. I'm just not sure how that will interact with STATUS enquiry, what state we get back. Does the Q.931 define a maximum time before we can expect a RELEASE_COMPLETE? When I wrote the code, I tried to simplify. What makes the case difficult is that we need to hold on to the call descriptor after the application has left it. > > One last thing: As you know for my old PBX I need a patch called > patch-no_status_enquiry_in_NT_MODE: Fixed with some modifications. Please test updated port. See: isdnconfig isdnconfig -u XXX status_enquiry_enable isdnconfig -u XXX status_enquiry_disable --HPS