[Asterisk-Users] Problem with chan-capi: outgoing calls on two lines

[Armin Schindler]

On Mon, 27 Feb 2006, Karsten Wemheuer wrote:
> Hello,
> 
> On Mo, 27 Feb 2006, Armin Schindler wrote:
> > On Mon, 27 Feb 2006, Karsten Wemheuer wrote:
> > > 
> > > In detail:
> > > When all lines are connected, the first two calls are placed on line 1
> > > (which is on controller 1). The next two calls are placed on line 2 (on
> > > controller 2)
> > > If I'll cut line 2, all works as expected (I can place two calls on line
> > > 1).
> > > But if I'll cut line 1, leaving line 2 up and running, I can not place
> > > any call. The CLI tells something about "Protocol error layer 1 (broken
> > > line or B-channel removed by signalling protocol)" and "No one is
> > > available to answer at this time (1:0/0/0)"
> > > 
> > > If I do the same thing in the opposite direction (Calls are initiated
> > > from the other box with bristuff in NT-mode), all works fine.
> > > 
> > > What am I doing wrong (or is this a bug)?
> > 
> > This is not a bug, just normal behaviour.
> > chan_capi does not know about the status of the ISDN line, it assumes to be
> > usable when configured. So when you try to dial out chan_capi will choose
> > a channel/line according to internal list of free channels and selects it
> > in the CAPI request. When the driver reports an error via CAPI, 
> > chan_capi just signals this error to Asterisk. 
> > There is no logic in chan_capi to do something like:
> >  If the controller 1 isn't ready, use controller 2.
> Ok, I didn't know the details of the capi layer.
> > 
> > The same happens if the b-channels are already used by another
> > application/device.
> ... which would not happen on a line in point-to-point mode.

No, the line mode doesn't matter. If you have another application
running using CAPI, chan_capi also doesn't know about the usage.

> And I just checked, that all works ok, if the channels are in use of
> asterisk itself (incomming calls).
> 
> So all is ok, except that there seems to be no possibility to check the
> lower layer state e.g. a broken line. (In case of zap You can look at
> the files in /proc/zap).

It would be possible to evaluate the error code and then try again
with another channel, but that logic is just not implemented.

Armin