> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Michael Di Martino > Sent: Sunday, June 12, 2005 7:21 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [Asterisk-Users] PRI trouble > > > On Sun, 2005-06-12 at 20:09 -0400, Andrew Kohlsmith wrote: > > On Sunday 12 June 2005 06:10, Michael Di Martino wrote: > > > Out of the blue i started receiving the following error on my PRI line > > > which connects my asterisk server to a Norstar 0x32 key system. {clip} > > > > Sounds like someone changed the pri signaling. > > > I thinking it is a timing issue, but i an not sure how to test. > What type of PRI signaling and timing do u use to connect to > your MICS. and yes my 0x32 is a MICS. >
It's very unlikely someone has accidentially tampered with the Norstar side as it requires taking the DTI card administratively out of service, manipulating its config and then restoring it to service... this would be an intentional act. To confirm your configuration go into System Configuration on your Norstar MICS (Feature **CONFIG). Drill into Hardware->Cards on KSU->Cd1-KSU:PRI (assuming the DTI card is in slot 1) Note the value of the 'Protocol', 'Framing', 'Line coding' and 'ClockSrc' fields. The protocol should match the 'switchtype=' entry in /etc/asterisk/zapata.conf. dms100 is a popular choice. If the ClockSrc is 'Primary', the Framing 'ESF' and the Line coding B8ZS then the relevant 'span=' entry will probably read similar to 'span=1,0,0,esf,b8zs' in /etc/zaptel.conf If the ClockSrc is 'TimeMstr', the Framing 'ESF' and the Line coding B8ZS then the relevant 'span=' entry will probably read similar to 'span=1,1,0,esf,b8zs' in /etc/zaptel.conf Adjust to taste for SF, AMI etc. If this issue just suddenly started happening and the configurations match on both sides (and you've confirmed you're not having interrupt issues or other zaptel hardware/OS related badness) then you likely have developed a cabling fault or a problem with either interface card. Asterisk doesn't provide CSU statistics and the stats in the Norstar CSU aren't directly visable to end users, so you're down to 'swap it and see' debugging. You can check the alarm log in the Norstar (Maintenance->Sys test log (or Sys adm log)) to confirm the DTI card isn't throwing any internal alarms (ie. excessive frame corruption etc.). Use http://www.optiontelecom.com/tech_support/AlarmEventCodeManual.pdf as a guide to translating the codes. Start by replacing cables, next cards, etc. etc. There is a 'patlooptest.c' in the zaptel sources and you can loop up the DTI card in the Norstar using the button on the front, however I don't know if patlooptest is at all useful at the moment as it's rather poorly documented. Hope that helps. Kris Boutilier Information Services Coordinator Sunshine Coast Regional District _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
