asterisk users - Dec 2005 - Eicon DIVA Server V-BRI questions

Hi *,

Coming from a very simple and nicely working pure IP setup I'm now  
trying to  converge the IP setup with my "real" (German) ISDN phone  
line. I bought a Eicon DIVA Server V-BRI-2 and it is currently  
connected like this:

PSTN -> DSL Splitter -> NTBA -> DIVA

The NTBA has two S0-connections, the second one is still hooked up to  
a T-Com T-Eumex 520 PC which allows me to connect analog devices,  
that's how my phone and fax works currently.

I went to the Eicon website and downloaded the latest version of  
their driver package "divas4linux_EICON", version 8.0beta1. Using  
their configuration tools, the card is currently configured this way:

D-Channel protocol - 1TR6 - Germany
Interface mode - TE
DID - no
D-channel layer 2 activation policy - only by other side
Trunk operation mode - Point to Multipoint

Upon system start I am getting the green Layer 1 light on the card's  
back and the following system log messages, which to me looks like  
the drivers are loading correctly:

--------------------------------------------------------
Eicon DIVA - DIDD table (http://www.melware.net)
divadidd: Rel:3.0  Rev:1.13  Build:105-92(local)
Eicon DIVA Server driver (http://www.melware.net)
divas: Rel:2.0  Rev:1.46  Build: 105-92(local)
divas: support for: BRI/PCI PRI/PCI adapters
divas: Diva Server BRI-2M 2.0 PCI bus: 00000006 fn: 00000000 insertion.
ACPI: PCI interrupt 0000:06:00.0[A] -> GSI 11 (level, low) -> IRQ 11
divas: Diva Server V-BRI-2 IRQ:11 SerNo:35681
divas: started with major 252
Eicon DIVA - User IDI (http://www.melware.net)
diva_idi: Rel:2.0  Rev:1.25  Build: local
diva_idi: started with major 251
diva_mtpx: no version for "struct_module" found: kernel tainted.
diva_mtpx: module license 'Eicon Networks' taints kernel.
divacapi: Unknown symbol detach_capi_ctr
divacapi: Unknown symbol capi_ctr_ready
divacapi: Unknown symbol capi_ctr_handle_message
divacapi: Unknown symbol attach_capi_ctr
CAPI Subsystem Rev 1.1.2.4
Eicon DIVA - CAPI Interface driver (http://www.melware.net)
divacapi: Rel:2.0  Rev:1.24  Build: 105-83(local)
kcapi: Controller 1: MTPX101 attached
kcapi: card 1 "MTPX101" ready.
kcapi: notify up contr 1
capi20: Rev 1.1.2.3: started up with major 68 (no middleware)
---------------------------------------------------------------

The problem I am having is that according to the isdn4linux page when  
calling in the card should recognize the call and note this in /var/ 
log/messages (like "Call from X, ignored"). It does not do this at  
all. Also, if I disconnect the T-Com T-Eumex unit so that the server  
is the only ISDN unit connected to the NTBA and call in I get a  
message played back by the phone company that the number is not  
reachable. At that point the green Layer 1 light on the card turns off.

To me this sounds like s severe misconfiguration on my part. Is there  
anyone on the list who is using a DIVA Server V-BRI card in Germany  
who could help?

After digging through all kinds of websites I am also confused about  
the relationship between the CAPI drivers included with the Eicon  
software and BRIStuff. When using chan_capi, do I need BRIStuff and  
zaptel at all?

Thanks for any insights, and a wonderful holiday period!!

jens

On 26 Dec 2005, at 13:54, Jens Vagelpohl wrote:
> The problem I am having is that according to the isdn4linux page  
> when calling in the card should recognize the call and note this  
> in /var/log/messages (like "Call from X, ignored"). It does not
do
> this at all. Also, if I disconnect the T-Com T-Eumex unit so that  
> the server is the only ISDN unit connected to the NTBA and call in  
> I get a message played back by the phone company that the number is  
> not reachable. At that point the green Layer 1 light on the card  
> turns off.
The mistake was in the D channel protocol - switching from 1TR6 to  
EuroISDN allowed me to test the card successfully using the Eicon  
tools. Asterisk now also shows the call coming in.

My second question remains: Do I need BRIStuff? I guess I don't  
seeing how  defining a simple extensions context with just Answer()  
and Echo() works through chan_capi when I tell Asterisk not to load  
any of the chan_modem* and chan_zap, and the zaptel module is  
unloaded... :)

jens