[Asterisk-Users] Errors Compiling chan_capi 0.3.5

Ralf Schlatterbeck ralf at zoo.priv.at
Sat Jun 4 00:56:47 MST 2005


On Fri, Jun 03, 2005 at 11:14:31AM +0200, Armin Schindler wrote:
> > What is the difference of your project to chan_capi-0.4.0-PRE1 ?
> 
> The features are the same at this time, but
> - source code cleanup
> - race conditions fixup
> - compile with all Asterisk versions using own configure
>   (no option in Makefile needed)
> - some Makefile options removed (all settings available at runtime)
> 
> and this the base for me to implement new features/fixes.
Fine, lets join efforts then.

> > 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?

> I need to work on chan_capi and I would like to make my
> work public as soon as possible. Also feedback is what I would like to 
> get. This is now accomplished with my registration at sourceforge.
Fine with me.

> kapejod did a very good job, but right now I get the impression, that
> he does not have much time for chan_capi. So to be faster, I did this.
> I hope this will not create a forked version and we can merge all
> things.
Fine.

> > 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.
> 
> 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 :-)

> > 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...

Ralf
-- 
Ralf Schlatterbeck
email: ralf at zoo.priv.at FAX: +43/2243/26465/23




More information about the asterisk-users mailing list