I have a T1 PRI from the telco and have been trying to get it to work with the wildcard T400P. I know framing and coding is esf and b8zs. what else should I be putting into the zaptel.conf and zapata.conf. Dave Anderson
> I have a T1 PRI from the telco and have been trying to get it to work > with the wildcard T400P. > > I know framing and coding is esf and b8zs. what else should I be > putting into the zaptel.conf and zapata.conf. > > Dave AndersonI've got basically the same question. After building everything, I edited zaptel.conf to include: span=1,0,0,esf,b8zs bchan=1-23 dchan=24 loadzone = us defaultzone=us Then, after: modprobe wct4xxp in dmesg, you'll see something like: Found TE410P at base address fe3ffc00, remapped to f8977c00 TE410P version c01a003a FALC version: 00000005, Board ID: 00 Reg 0: 0x2edfd800 Reg 1: 0x2edfd000 Reg 2: 0x07fc07fc Reg 3: 0x00000000 Reg 4: 0x00000000 Reg 5: 0x00000000 Reg 6: 0xc01a003a Reg 7: 0x00001000 Reg 8: 0x00000000 Reg 9: 0x00ff0000 Reg 10: 0x00000000 TE410P: Launching card: 0 TE410P: Setting up global serial parameters TE410P: Timing from source 0 Found a Wildcard: Wildcard TE410P-Xilinx Registered tone zone 0 (United States / North America) TE410P: Span 1 configured for ESF/B8ZS (I also noticed that you can use /sbin/ztcfg to reread /etc/zaptel.conf after it's been changed.) So far, I figured I was on the right path. So then I edited zapata.conf to include: switchtype=4ess signalling=pri_cpe group = 1 channel => 1-23 However, I can no longer start asterisk. It doesn't seem to like the signalling, spitting out the following on startup: .. [chan_zap.so] => (Zapata Telephony) == Parsing '/etc/asterisk/zapata.conf': Found WARNING[1024]: File chan_zap.c, Line 6890 (load_module): Ignoring switchtype ERROR[1024]: File chan_zap.c, Line 6834 (load_module): Unknown signalling method 'pri_cpe' ERROR[1024]: File chan_zap.c, Line 6603 (load_module): Signalling must be specified before any channels are. WARNING[1024]: File loader.c, Line 301 (ast_load_resource): chan_zap.so: load_module failed, returning -1 WARNING[1024]: File loader.c, Line 396 (load_modules): Loading module chan_zap.so failed! Any information on how to get futher would be greatly appreciated. None of the examples I've been able to find seem to be geared towards ISDN DS1s. Thanks, tony
Steven Critchfield said:>> .. >> [chan_zap.so] => (Zapata Telephony) >> == Parsing '/etc/asterisk/zapata.conf': Found >> WARNING[1024]: File chan_zap.c, Line 6890 (load_module): Ignoring >> switchtype ERROR[1024]: File chan_zap.c, Line 6834 (load_module): >> Unknown signalling method 'pri_cpe' >> ERROR[1024]: File chan_zap.c, Line 6603 (load_module): Signalling >> must be specified before any channels are. >> WARNING[1024]: File loader.c, Line 301 (ast_load_resource): >> chan_zap.so: load_module failed, returning -1 >> WARNING[1024]: File loader.c, Line 396 (load_modules): Loading module >> chan_zap.so failed! > > The error messages above are because you need to specify your b > channel and your D channel. Also just for chance sake, did you make > sure to download and compile libpri?Doh - I downloaded it and compiled it, but it doesn't seem that I did the "make install" for libpri prior to making astersk, and the ./channels/Makefile only looks for the library in /usr/lib/. Thanks for the pointer. I'll post a follow up once we get * and our Definity talking happy to each other. - tony
Well, it turns out that I needed to get intimate with the libpri source
anyway. After starting * with libpri linked in, * would annouce that the
B channels were up, but the Definity saw them as out of service
("OOS/FE-PINS" initially and then after two minutes,
"out-of-service-FE").
I started comparing the messages exchanged when the DS1 comes up to those
on a Dialogic GC box, and ended up patching libpri. The response to
SERVICE(0x0f) should be SERVICE ACKNOWLEDGE (0x07), as is indicated in the
comments. However, the code that's currently in CVS seems to be modifying
a byte in the Call Reference, not the Message Type byte. (Perhaps this
has something to do with my build environment?!? The typedef for q931_h
looks pretty tame, and I'm building on Debian stable, gcc 2.95.4.)
Anyway, here's the patch:
tmancill@tor:/usr/src$ diff -u ./libpri/q931.c ./libpri_prev/q931.c
--- ./libpri/q931.c Tue Sep 16 14:29:21 2003
+++ ./libpri_prev/q931.c Tue Sep 9 16:49:10 2003
@@ -1840,7 +1840,7 @@
/* This is the weird maintenance stuff. We majorly
KLUDGE this by changing byte 4 from a 0xf (SERVICE)
to a 0x7 (SERVICE ACKNOWLEDGE) */
- h->raw[4] -= 0x8;
+ h->raw[3] -= 0x8;
q931_xmit(pri, h, len, 1);
return 0;
}
After recompiling libpri, I'm up and running. Being new to the list and
the project, I'd appreciate some feedback on whether or not this sort of
thing is appropriate for submission back into CVS. For one, I'm not sure
if the maintenance kludge is Definity-specific. (/me probably needs to
take a look at asterisk-dev list.)
Cheers,
tony