Bug#386052: zaptel-source: Cannot initiate a call to BRI

[Cybaer]

uuuh, now I get some problems...

Jens Wilke wrote:
> Please try:
> # pri debug span 1
> and provide the output.
> 

you mean: startup asterisk (e. g. asterisk -vvvvvvc), startup pri debug
span 1 and dial? Then I got the same as before:

*CLI>     -- Executing SetCallerID("SIP/myid-081baf58", "msn") in new stack
    -- Executing Dial("SIP/myid-081baf58", "Zap/g1/phonenumber|60|rTW")
in new stack
Sep  6 20:48:23 NOTICE[4575]: app_dial.c:1076 dial_exec_full: Unable to
create channel of type 'Zap' (cause 34 - Circuit/channel congestion)
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Executing Hangup("SIP/myid-081baf58", "") in new stack
  == Spawn extension (somecontext, phonenumber, 3) exited non-zero on
'SIP/myid-081baf58'

No more information from the debug mode. I guess, I did something wrong?!

> Alternatively try to load the module with:
> modprobe vzaphfc force_l1_up=1
> 

hm, next problem: vzaphfc is loaded with one of the new magic
udev/discover/whatever mechanisms and I cannot find the point where it
is done. When I...

- stop asterisk
- rmmod vzaphfc
- modprobe vzaphfc force_l1_up=1
- (ztcfg -vv)
- startup asterisk -vvvvvvvc

... I get:

[chan_zap.so] => (Zapata Telephony w/PRI)
  == Parsing '/etc/asterisk/zapata.conf': Found
    -- Registered channel 1, PRI Signalling signalling
    -- Registered channel 2, PRI Signalling signalling
    -- Automatically generated pseudo channel
  == Starting D-Channel on span 1
  == Registered channel type 'Zap' (Zapata Telephony Driver w/PRI)
  == Manager registered action ZapTransfer
  == Manager registered action ZapHangup
  == Manager registered action ZapDialOffhook
  == Manager registered action ZapDNDon
  == Manager registered action ZapDNDoff
  == Manager registered action ZapShowChannels
  == Registered application 'zapEC'
  == Registered application 'zapCD'
  == Registered application 'zapInband'

> When starting asterisk you should see:
> == Primary D-Channel on span 1 up

no line like this

> and maybe:
> == Restart on requested on entire span 1
>
not either.

Most of the time (the above I managed only once) I get the following
effect after reloading the module and starting up asterisk in console mode:

 [chan_zap.so] => (Zapata Telephony w/PRI)
  == Parsing '/etc/asterisk/zapata.conf': Found
Sep  6 21:07:44 WARNING[5108]: chan_zap.c:1097 zt_open: Unable to
specify channel 1: No such device or address
Sep  6 21:07:44 ERROR[5108]: chan_zap.c:7359 mkintf: Unable to open
channel 1: No such device or address
here = 0, tmp->channel = 1, channel = 1
Sep  6 21:07:44 ERROR[5108]: chan_zap.c:12169 setup_zap: Unable to
register channel '1-2'
Sep  6 21:07:44 WARNING[5108]: loader.c:414 __load_resource:
chan_zap.so: load_module failed, returning -1
Sep  6 21:07:44 WARNING[5108]: loader.c:554 load_modules: Loading module
chan_zap.so failed!
mymachineprompt:~# Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!
Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!
Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!
Junk at the beginning 49443303
Warning, flexibel rate not heavily tested!

To initialize vzaphfc with the force_l1_up option on bootup I inserted

option vzaphfc force_l1_up=1

into /etc/modules.conf (hope that will do, any suggestions?) and
restarted the machine, but nothing changes.

> If this is not appearing d-channel layer 2 is not coming up.
> Try the following:
> # pri intense debug span 1
> Then unplug and plug the ISDN cable, so we see the initial handshaking.
>

*CLI> pri intense debug span 1
Enabled EXTENSIVE debugging on span 1
*CLI>

nothing happens when (un)plugging the cable, sorry.

Thomas