Definitely not what I'm seeing here; the channels that were out were scattered across the whole range of 24. Turns out my first guess was right; the telco was set to NI-2 instead of DMS-100 custom. But for some reason it looked to them like it was on DMS-100 at first glance; they had to dig around to find it. (Probably because these are on a remote switch.) Anyway, I could still use some docs on DMS-100 and NI-2 service messages (and 5ESS) if anyone's got 'em. :) Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet access for Frankfort, Lexington, Louisville and surrounding counties www.fark.com: If it's not news, it's Fark. (Or something like that.) On Thu, 29 Mar 2001, Mark Thornton wrote:
We had a similar situation here. Remember that PRI's are really T1's with differentl stripes. T1's are typically delivered via HDSL in two 768kbps segments. You can lose half a T1 and still keep going. In our case the half that failed on the PRI did not include the B channel so the switch and our end thought everything was OK. When we brought it up to the telco they found the problem rather quickly, a bad splice in the pair to our facility.
Mark Thornton San Marcos Internet, Inc. 512-393-5300
----- Original Message ----- From: "Mike Andrews" <mandrews@bit0.com> To: <usr-tc@lists.xmission.com> Sent: Thursday, March 29, 2001 12:56 AM Subject: (usr-tc) PRI service message docs
Hey folks... Anyone have any good low-level docs on PRI service messages? Anyone know q.931 and q.921 really well?
I'm trying to track down a really bizarre PRI problem I'm having with the telco in one city. The HiPer DSP software (2.1.9) doesn't appear to give you much in the way of D-channel debugging at all... except for the "trc debug 25 2" command that gives a hex dump of the packets on the console.
So, I'm writing a program to take that hex dump and turn it into something readable. (Hey, it's a good excuse to finally learn about q.931, too.) It mostly works, except for service messages -- it doesn't really grok them correctly. In particular they come in with weird protocol discriminator numbers like 0x03 and 0x43 instead of the usual 0x08. Unfortunately, Google is not helping me as much as it usually does here.
The specific PRI problem is calls aren't hitting my PRI's; it takes about 10 calls and starts to fast-busy or dead-air... *sometimes* calls will roll over to the next PRI, sometimes not. Every so often the switch sends a series of service messages with protocol discriminator 0x43, with a list of B-channels -- probably the switch thinks my lines are busied out and it wants me to restore them. The DSP does not acknowledge these packets. I've been able to fix this condition before by rebooting the DSP's, but that doesn't exactly tell me why it's happening in the first place.... One theory is that maybe the telco is set to NI-2 instead of DMS-100 Custom... of course they say it's set to DMS anyway...
Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet access for Frankfort, Lexington, Louisville and surrounding counties www.fark.com: If it's not news, it's Fark. (Or something like that.)
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.