[Asterisk-Users] Errors Compiling chan_capi 0.3.5
Armin Schindler
armin at melware.de
Sat Jun 4 09:45:34 MST 2005
On Sat, 4 Jun 2005, Ralf Schlatterbeck wrote:
> 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.
Can you please provide a log with 'capi debug' on and greater verbose level
(e.g. 9) ?
> 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
Thanks, I will have a look at it.
> > 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?
A signal is not a good idea. The monitor thread (which runs continously) can
maintain any timers we need.
> 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.
Looks good so far, but I think we can *ask* Asterisk after each digit
(without having sending complete yet) if more digits would make sense
by calling ast_matchmore_extension().
> > 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):
I'm not familiar with traces by AVM cards. It would be enough to have a
trace of all CAPI messages but DATA_B3.
Armin
More information about the asterisk-users
mailing list