ISDN4BSD (HPS version) is going into ports

[Hans Petter Selasky]

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