[Asterisk-Users] Errors Compiling chan_capi 0.3.5

[Armin Schindler]

On Sat, 4 Jun 2005, Ralf Schlatterbeck wrote:
> > > I'm had difficulties with applications Busy and Congestion in Asterisk
> > > with chan_capi -- which is not solved in chan_capi-0.4.0-PRE1. So I
> > > looked at the source and made an implementation of capi_indicate that
> > > can now signal congestion or busy to the remote end.
> > >
> > > I would be interested to merge the changes back into an 'official'
> > > version.
> > 
> > We can add this to the CVS, that's why I created it.
> OK, for now I'll submit it as a patch against your version of chan_capi
> from CVS. Do you have a tag in CVS I should check out, so you know later
> against which version I'm working?

There are no special tags, just use HEAD.
 
> > > I've also got difficulties with the Austrian implementation of
> > > Euro-ISDN PTP: Obviously the current 0.4.0-PRE1 (and 0.3.5 before it)
> > > assume that an incoming PTP call will be followed by an INFO_IND that
> > > conveys the DID information -- In Austria, at least when called from a
> > > fully-digital line (ISDN or mobile phone) the DID information is already
> > > there and no INFO_IND follows, resulting in a timed-out call (because
> > > the INFO_IND never comes).
> > > In line 2144 of chan_capi.c (0.4.0-PRE1) the new channel is handed to
> > > asterisk in AST_STATE_DOWN. When I change this to AST_STATE_RING it
> > > works for me -- but I lose DID information from analogue phones (which
> > > is still better than loosing all calls from digital phones and leaving
> > > asterisk in an inconsistent state).
> > > Are there solutions for this? I'd appreciate help in debugging (and
> > > patching) this...
> > 
> > Hmm, I think this is what kapejod told me already about. As far as I 
> > understood, he knows this problem and may have a fix. But if he has a
> > probable fix, it would be nice to publish it. (Via CVS it's simple).
> I'm now in contact with somebody quite knowledgeable about ISDN in
> general and austrian/german differences in particular.
> One of the things I discovered already is that chan_capi currently does
> not honor the "Sending complete" subelement in the "Additional Info" of
> a connect_ind or info_ind. This means it will wait for additional digits
> even in the case where there will be no more (block dialling from a
> mobile phone will send all the dialling -- including DID -- in the
> connect). I think you have a copy of the capi-spec, in part-I on p.77
> and p.107 you can check out the sending complete info. In addition there
> should be a timer for waiting for additional dialling information (if
> sending complete is zero). The timer is set to 15sec in the standard but
> most implementations use a shorter time. After the timer expires the
> call should be handed to asterisk even if the dialling info is not
> complete, otherwise the call will be timed out (thats what happens to me
> with the original implementation) I don't know if CAPI already
> implements this timer or if the application is responsible for doing
> this.

As far as I know the timer should be part of the application. I think the 
correct way is to handle each number/digit to Asterisk and Asterisk should
state an own 'sending complete' according to dialplan, or time out.

But the 'sending complete' status of connect_ind/info_ind must be evaluated
of course.
 
> > I did not have a closer look at this problem yet. Can you provide a log
> > of capi messages for such calls (ISDN and analog)?
> > What ISDN card do you use? If it's Eicon, then
> > divactrl ditrace will help you here.
> I don't think a log will improve the current understanding of the
> problem much. I think I know how the implementation should look like and
> I need it myself. So I check if I can code it up and send a patch. If It
> doesn't work I can always send a log :-)

I cannot reproduce every case, so a trace of the CAPI messages would show 
what is done in the real world.
 
> > > Hmm, maybe this should have gone to the devel list after all :-)
> > 
> > Which devel list? Asterisk? 
> > Hmm, maybe I should have a look at this list as well ;-)
> I'm also subscribe only since yesterday... and I'm only playing for 2
> weeks or so with asterisk but already am fascinated what is possible...

I know what you mean ;-)

Armin