Hello everyone, We have recently turned up a new T1 from McLeod (Midwestern CLEC). It is configured like so: /etc/zaptel.conf: loadzone=us defaultzone=us span=1,0,0,esf,b8zs ;(also tried 1,1,0,esf,b8zs) bchan=13-23 nethdlc=1-12 dchan=24 /etc/zapata.conf: switchtype=national context=pri-in signalling=pri_cpe group=1 channel => 13-23 I can get hdlc0 (and pvc0) up just fine after the appropriate sethdlc and ifconfig commands. Works perfectly. No alarms, everything looks good. PRI, however, refuses to work... pbx*CLI> pri show span 1 Primary D-channel: 24 Status: Provisioned, Down, Active Switchtype: National ISDN Type: CPE Window Length: 0/7 Sentrej: 0 SolicitFbit: 0 Retrans: 0 Busy: 0 Overlap Dial: 0 T200 Timer: 1000 T203 Timer: 10000 T305 Timer: 30000 T308 Timer: 4000 T313 Timer: 4000 N200 Counter: 3 Evidently, this is a Lucent 5ess switch but I am supposed to use national. I have tried both, and every combination of pri_cpe, pri_net, switchtype, etc. to no avail. The McLeod switch tech says that everything looks fine on their end, and they too verify that HDLC on the T is up and there are no alarms. We are both totally confused. I am pretty sure that it is something on their end, because I have configured many a T1/PRI without problems. If anything, the fact that this is an "integrated product" may have something to do with it, but I am bamboozled by the fact that HDLC data works and PRI does not. I also tried it without the nethdlc lines, no dice. "pri intense debug span 1" shows SABME's going out with nothing else happening. Currently this T is connected to a Te110p, but we also tried a te405p with the same results. Same thing with a Sangoma A101. We even connected them back to back, changed one to pri_net, and were able to bring up the PRI in between two Asterisk servers. Looks like it's McLeod? Does anyone have any ideas? Any magic words to give to the people at McLeod to get this running? Any success/failure stories with McLeod in general? Running CVS HEAD, tried three versions from three separate times, including the most recent from yesterday. Thanks! -- Kristian Kielhofner
**Snip** pbx*CLI> pri show span 1 Primary D-channel: 24 Status: Provisioned, Down, Active Switchtype: National ISDN Type: CPE Window Length: 0/7 Sentrej: 0 SolicitFbit: 0 Retrans: 0 Busy: 0 Overlap Dial: 0 T200 Timer: 1000 T203 Timer: 10000 T305 Timer: 30000 T308 Timer: 4000 T313 Timer: 4000 N200 Counter: 3 Take a second look at your status. It says that the D-Channel is down... No D-Channel, No PRI Signalling. Tell McCleod to bring up the D-Channel so their switch can talk to yours... -Chris
>Does anyone have any ideas? Any magic words to give to the people at >McLeod to get this running?You might ask the carrier to take a careful look at the mapping for the d-channel in their DACS equipment and perhaps even ask them to try re-mapping it for you. If that does not get things moving, then I would ask them to send somebody onsite with a PRI test set and see if they can complete any test calls with it. In any event, you should set your configuration to clock from the T1 circuit to avoid timing slips - although I don't expect it is the root cause of this particular problem.
We have a McLeod T1 and they told us specifically that it was a PRI, ended up being em_wink. Make sure they really have it setup right. -- ~Andy Brezinsky On Friday 08 July 2005 5:45 pm, Kristian Kielhofner wrote:> Hello everyone, > > We have recently turned up a new T1 from McLeod (Midwestern CLEC). It > is configured like so: > > /etc/zaptel.conf: > > loadzone=us > defaultzone=us > span=1,0,0,esf,b8zs ;(also tried 1,1,0,esf,b8zs) > bchan=13-23 > nethdlc=1-12 > dchan=24 > > > /etc/zapata.conf: > > switchtype=national > context=pri-in > signalling=pri_cpe > group=1 > channel => 13-23 > > I can get hdlc0 (and pvc0) up just fine after the appropriate sethdlc > and ifconfig commands. Works perfectly. No alarms, everything looks > good. PRI, however, refuses to work... > > pbx*CLI> pri show span 1 > Primary D-channel: 24 > Status: Provisioned, Down, Active > Switchtype: National ISDN > Type: CPE > Window Length: 0/7 > Sentrej: 0 > SolicitFbit: 0 > Retrans: 0 > Busy: 0 > Overlap Dial: 0 > T200 Timer: 1000 > T203 Timer: 10000 > T305 Timer: 30000 > T308 Timer: 4000 > T313 Timer: 4000 > N200 Counter: 3 > > Evidently, this is a Lucent 5ess switch but I am supposed to use > national. I have tried both, and every combination of pri_cpe, pri_net, > switchtype, etc. to no avail. The McLeod switch tech says that > everything looks fine on their end, and they too verify that HDLC on the > T is up and there are no alarms. We are both totally confused. > > I am pretty sure that it is something on their end, because I have > configured many a T1/PRI without problems. If anything, the fact that > this is an "integrated product" may have something to do with it, but I > am bamboozled by the fact that HDLC data works and PRI does not. I also > tried it without the nethdlc lines, no dice. > > "pri intense debug span 1" shows SABME's going out with nothing else > happening. Currently this T is connected to a Te110p, but we also tried > a te405p with the same results. Same thing with a Sangoma A101. We > even connected them back to back, changed one to pri_net, and were able > to bring up the PRI in between two Asterisk servers. Looks like it's > McLeod? > > Does anyone have any ideas? Any magic words to give to the people at > McLeod to get this running? Any success/failure stories with McLeod in > general? > > Running CVS HEAD, tried three versions from three separate times, > including the most recent from yesterday. > > Thanks! > > -- > Kristian Kielhofner > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20050709/51a04bd8/attachment.pgp