[Asterisk-Users] Errors Compiling chan_capi 0.3.5

Sat Jun 4 09:04:16 MST 2005

On Sat, Jun 04, 2005 at 01:59:53PM +0200, Armin Schindler wrote:
> > 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 checked out the head version but unfortunately it produces a
deadlock when dialling out to some number, see sourceforge bug-report
https://sourceforge.net/tracker/index.php?func=detail&aid=1214837&group_id=140312&atid=746578
The same deadlock also occurs with 0.4.0-PRE1 and does *not* occur with
0.3.5.

In any case: I have attached the patch for making the busy and
congestion asterisk applications work to sourceforge. Note that for me
(but this may be a problem related to austrian ptp?) busy does not work.
If I use Busy in asterisk, the remote end *still* gets a ringing
indication even if asterisk thinks it has successfully signalled busy
(and logs this fact in the call data records). This is fixed by the
sourceforge patch.
https://sourceforge.net/tracker/index.php?func=detail&aid=1214843&group_id=140312&atid=746578

> > > > 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).
I've attached the patch to this to sourceforge so you can reproduce what
I'm doing -- I consider this patch a bad cludge and it should be fixed
by proper handling of sending complete in chan_capi.

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

How can I set a timer in chan_capi? Is the ALRM signal in use by
something else or can I use it?

Note that asterisk can't have the timer: chan_capi allocates a new
channel in AST_STATE_DOWN and then waits for digits. In this state,
however, the call is not yes seen by asterisk, so you cannot do anything
about it in the dial-plan (or am I mistaken in this assumption??). My
current solution would be to:
- Check if sending complete is received, if yes immediately hand call to
  asterisk by setting state to AST_STATE_RING
- For each received info_ind again check if sending complete is set, if
  yes hand to asterisk as above
- After reception of connect_ind start a timer (say 7 seconds -- ISDN
  standard says 15sec but this is way too long and most implementations
  use a shorter time)
- If an info_ind is received we probably should restart the timer, but
  would have to look this up in the standard.
- If timer expires hand call to asterisk
Only after chan_capi has set the channel status to AST_STATE_RING the
call is seen by asterisk -- at least thats what I grok from testing.

> But the 'sending complete' status of connect_ind/info_ind must be evaluated
> of course.
See above, that's what I plan to implement...

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

What debug-level of the capi driver do you want? Which layers?
I have currently debugging set as follows (from my /etc/modprobe.d/capi):

alias char-major-68-0 avmfritz

install avmfritz /sbin/modprobe capi; \
/sbin/modprobe mISDN_core debug=1; \
/sbin/modprobe mISDN_l1 debug=1; \
/sbin/modprobe mISDN_l2 debug=1; \
/sbin/modprobe l3udss1 debug=1; \
/sbin/modprobe mISDN_capi debug=1; \
/sbin/modprobe mISDN_x25dte debug=0; \
/sbin/modprobe mISDN_dsp; \
/sbin/modprobe mISDN_dtmf; \
/sbin/modprobe --ignore-install avmfritz protocol=0x22 debug=1

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