[Freeswitch-dev] INFO: Update on Mikey's OpenZAP experimenting
FYI, I have been working with MikeJ on a few OpenZAP issues. The good news is that I've figured out what setting in my openzap.conf.xml was triggering the seg fault on startup. It is probably an easy fix to zap_isdn.c or thereabouts. The issue is with how many spans of each type I have and what ID I give them. I have a four-port card so I initially had this: <analog_spans> <span id="1"> ... </span> <span id="2"> ... </span> <span id="3"> ... </span> </analog_spans> <pri_spans> <span id="4"> ... </span> </pri_spans> It turns out putting the first PRI span as id="4" made zap_isdn.c barf. I changed it to id="1" and the system came right up. I don't have physical access to the machine at this point so all I can do now is report to you where I stand, and what I'm doing. First off my physical config: FS Box Asterisk Box Span 1 <--+ Span 1 N/C | Span 2 <--+ Span 2 N/C Span 3 <--------> Span 3 Span 4 <--------> Span 4 (PRI, DMS, Asterisk = pri_net) I have spans 1,2 back-to-back w/ x-over T1 cable. Ideally one span would be FXS and the other FXO, however I couldn't get the spans to come up unless I specified the channels as all b-channels in /etc/openzap/openzap.conf. Span 3 on FS is connected to Span 3 on the Asterisk box. I don't recall exactly what I have * setup as, but I think it's FXS. (I lost my LAN connectivity to the box, so I won't know until Monday when I get in to the office.) Span 4 on FS is connected to Span 4 on the Asterisk box. I've got * set up to emulate the telco, so it is signaling as pri_net. On Friday I was getting ISDN Q931 errors, which is good and bad. Bad cuz it's not working but good cuz at least I know the D channels are talking. However, I can't get anything going this weekend. (I think I've got a network or hardware issue on my * box.) For reference, all the B channels seem to come up. The only issue I have is getting the D channel on the PRI span to come up. I'm getting this output: 2007-11-03 23:28:44 [DEBUG] zap_io.c:1777 load_config() span 4 [d-channel]=[96] 2007-11-03 23:28:44 [ERR] zap_zt.c:162 zt_open_range() failure configuring device /dev/zap/channel as OpenZAP device 4:24 fd:113 2007-11-03 23:28:44 [INFO] zap_io.c:1848 load_config() Configured 95 channel(s) I'm attaching the openzap.conf and openzap.conf.xml contents at the end of this email. If you have any suggestions on things you'd like to see me try then by all means let me know. Thanks, MC /etc/openzap/openzap.conf: [span zt] name => OpenZAP number => 1 trunk_type => t1 b-channel => 1-24 [span zt] name => OpenZAP number => 2 trunk_type => t1 b-channel => 25-48 [span zt] name => OpenZAP number => 3 trunk_type => t1 b-channel => 49-72 [span zt] name => OpenZAP number => 4 trunk_type => t1 b-channel => 73-95 d-channel => 96 openzap.conf.xml: <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="1"/> </settings> <analog_spans> <span id="1"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> <span id="2"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> <span id="3"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </analog_spans> <pri_spans> <span id="1"> <param name="mode" value="user"/> <param name="dialect" value="DMS"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </pri_spans> </configuration>
Let me preface this email by saying, "I am a *RETARD*"!!! I didn't read my own friggin' configs. After some researching I figured out that I had my spans 3 and 4 flip-flopped in the openzap configuration. The actual configuration of my systems is as follows: FS Box Asterisk Box Span 1 <--+ T1 Span 1 N/C | X-Over Span 2 <--+ Cable Span 2 N/C Span 3 <--T1 X-over--> Span 3 (PRI, DMS, Asterisk = pri_net) Span 4 <--T1 X-over--> Span 4 (??? - possible PRI) To make a long story short, my first email was stupid. I was trying to make my span 4 be a PRI when the zaptel was configured as plain-Jane T1 w/ fxsks signaling and then talking to who knows what on the * side (my LAN conn is still down so I honestly don't know what's up on that span, although when I configured span 4 to be clear channel I did receive goofy ring signals on channel 24 which suggests some sort of PRI on the * side, so I've got a temp PRI setup on span 4 right now...). I configured span 3 to be PRI and I got all sorts of cool and interesting D-channel messages. My modified configs are below, including my zaptel.conf, which I should have looked at first! (kicking myself in the head...) Also, I believe my conclusion about the span id settings in openzap.conf.xml is probably wrong as well. I set up only span 3 for testing and left it with <span id="3"> when it was the only one configured in XML and it came up like a champ. Thanks for your patience. I'll keep testing and report back with more information and better researched questions in a few days. -MC /etc/zaptel.conf: ## Test FreeSWITCH/OpenZAP config span=1,0,0,esf,b8zs # FS back-to-back "Network" fxoks=1-24 span=2,1,0,esf,b8zs # FS back-to-back "CPE" fxsks=25-48 span=3,1,0,esf,b8zs # Asterisk back-to-back PRI (I am CPE) bchan=49-71 dchan=72 span=4,1,0,esf,b8zs # Asterisk back-to-back PRI (I am CPE) bchan=73-95 dchan=96 # Global data loadzone = us defaultzone = us /etc/openzap/openzap.conf: [span zt] name => OpenZAP number => 1 trunk_type => t1 b-channel => 1-24 [span zt] name => OpenZAP number => 2 trunk_type => t1 b-channel => 25-48 [span zt] name => OpenZAP number => 3 trunk_type => t1 b-channel => 49-71 d-channel => 72 [span zt] name => OpenZAP number => 4 trunk_type => t1 b-channel => 73-95 d-channel => 96 openzap.conf.xml: <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="1"/> </settings> <analog_spans> <span id="1"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> <span id="2"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </analog_spans> <pri_spans> <span id="3"> <param name="mode" value="user"/> <param name="dialect" value="DMS"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> <span id="4"> <param name="mode" value="user"/> <param name="dialect" value="DMS"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </pri_spans> </configuration> _____ From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: Saturday, November 03, 2007 11:32 PM To: freeswitch-dev@lists.freeswitch.org Subject: [Freeswitch-dev] INFO: Update on Mikey's OpenZAP experimenting FYI, I have been working with MikeJ on a few OpenZAP issues. The good news is that I've figured out what setting in my openzap.conf.xml was triggering the seg fault on startup. It is probably an easy fix to zap_isdn.c or thereabouts. The issue is with how many spans of each type I have and what ID I give them. I have a four-port card so I initially had this: <analog_spans> <span id="1"> ... </span> <span id="2"> ... </span> <span id="3"> ... </span> </analog_spans> <pri_spans> <span id="4"> ... </span> </pri_spans> It turns out putting the first PRI span as id="4" made zap_isdn.c barf. I changed it to id="1" and the system came right up. I don't have physical access to the machine at this point so all I can do now is report to you where I stand, and what I'm doing. First off my physical config: FS Box Asterisk Box Span 1 <--+ Span 1 N/C | Span 2 <--+ Span 2 N/C Span 3 <--------> Span 3 Span 4 <--------> Span 4 (PRI, DMS, Asterisk = pri_net) I have spans 1,2 back-to-back w/ x-over T1 cable. Ideally one span would be FXS and the other FXO, however I couldn't get the spans to come up unless I specified the channels as all b-channels in /etc/openzap/openzap.conf. Span 3 on FS is connected to Span 3 on the Asterisk box. I don't recall exactly what I have * setup as, but I think it's FXS. (I lost my LAN connectivity to the box, so I won't know until Monday when I get in to the office.) Span 4 on FS is connected to Span 4 on the Asterisk box. I've got * set up to emulate the telco, so it is signaling as pri_net. On Friday I was getting ISDN Q931 errors, which is good and bad. Bad cuz it's not working but good cuz at least I know the D channels are talking. However, I can't get anything going this weekend. (I think I've got a network or hardware issue on my * box.) For reference, all the B channels seem to come up. The only issue I have is getting the D channel on the PRI span to come up. I'm getting this output: 2007-11-03 23:28:44 [DEBUG] zap_io.c:1777 load_config() span 4 [d-channel]=[96] 2007-11-03 23:28:44 [ERR] zap_zt.c:162 zt_open_range() failure configuring device /dev/zap/channel as OpenZAP device 4:24 fd:113 2007-11-03 23:28:44 [INFO] zap_io.c:1848 load_config() Configured 95 channel(s) I'm attaching the openzap.conf and openzap.conf.xml contents at the end of this email. If you have any suggestions on things you'd like to see me try then by all means let me know. Thanks, MC /etc/openzap/openzap.conf: [span zt] name => OpenZAP number => 1 trunk_type => t1 b-channel => 1-24 [span zt] name => OpenZAP number => 2 trunk_type => t1 b-channel => 25-48 [span zt] name => OpenZAP number => 3 trunk_type => t1 b-channel => 49-72 [span zt] name => OpenZAP number => 4 trunk_type => t1 b-channel => 73-95 d-channel => 96 openzap.conf.xml: <configuration name="openzap.conf" description="OpenZAP Configuration"> <settings> <param name="debug" value="1"/> </settings> <analog_spans> <span id="1"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> <span id="2"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> <span id="3"> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </analog_spans> <pri_spans> <span id="1"> <param name="mode" value="user"/> <param name="dialect" value="DMS"/> <param name="dialplan" value="XML"/> <param name="context" value="default"/> </span> </pri_spans> </configuration>
participants (1)
-
Michael Collins