Re: ISDN4BSD (HPS version) is going into ports
Hans Petter Selasky <[email protected]> Sat, 24 Nov 2012 12:22:52 +0100
| Newsgroups | gmane.os.freebsd.devel.isdn |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isdn To unsubscribe, send any mail to "[email protected]"