Merlin Magix Monitor for PRI 1

[TelecomAvatar]

I was wondering if anyone knew how to use the PRI monitoring feature through the monitor program in WinSPM. I try to do a ? to list the commands but I do not see it listed. Anyone know this command?

 

[dagwoodsystems]

Usage: trace "on"|"off"|"isdn"|"isdnf" <sid>|<fid>|"vmsmc"...(blah blah)
trace "prion"|"prioff"|"prigon"|"prigoff" <fid>|<B-ch group>...(blah blah)
trace "dchon" | "dchoff" <slot>...(blah blah)

The command "trace on prion <fid>" displays the layer 3 messaging for the specified trunk.

The "prigon <B-ch group>" switch initiates a trace on the entire B-Channel group.

The "pribig" switch displays 32 bytes of the message, while "prismall" shows the (first?) 16 bytes.

The "dchon <slot>" switch enables maintenence and global CRV (Call Reference Value) messages for the specified slot. It may offer other miscellaneous QSig messages as well...I just don't remember.


"sid" is an extension's software id. You can find out what it is by issuing a "locate <ext>" command (which spews out the sid/slot/port of the extension).

"fid" is the facility id...aka the trunk id (801-880).

So for example, "trace on <sid>" will echo (to your screen) the keypresses of a telephone in real time. Use only when necessary, and don't be evil.

"trace on <fid>" will similarly display relevant trunk info.

Also "history <fid>" or "history <sid>" shows all events of the trunk or extension specified. Some of this is cryptic, but you'll make out.



Final note: Be VERY VERY careful with this stuff. Do one test at a time, and make sure you turn OFF any traces. So for every "prion" command, there should be a corresponding "prioff" command to later follow. Same with "prigon" and "prigoff" and "wax on -- wax off". OK funny guy.

Use the "status" command to remind you what objects are being traced.

 

[TelecomAvatar]

Thanks dagwoodsystems! I will try this out, with great caution of course. Also, I will not use this for evil. Kind of funny, I use that line all the time! The one reason I would really use this is because of a provider saying a PRI problem "is not their problem". Do you know if this will generate an error code stating that the D-channel is down from the provider?

 

[dagwoodsystems]

Oh I think you'll get a message right away if the D-Channel falls down. But you can also see D-Channel messages in the error log more easily, so you don't have to be a Monitor shell cowboy. I know...it IS fun stuff. And now that you have a handfull of Avaya secrets, will you play along?

I'd like to know the details of what's going on over there. I could be something really simple! I don't want to discourage your fun, but the old phrase "When you hear hooves, think of horses...not zebras" applies. PRIs are pretty easy. In addition to myself (forum newbie), and there are A LOT of people here who can help.

I'll get right to the point: Does your PRI have intermittent problems, or is it not up at all?

 

[TelecomAvatar]

I have no current problems on any of the PRI's I have on Legend's or Magix systems. Also, the main thing I always check is the error logs. Unfortunately, some of the providers I deal with need to be shown proof sometimes. Error logs do not cut it with them. It's always the same thing, it's in your equipment! If anyone has a good way to prove it is the provider, D-channel issues only, the T-1 carrier is easy with a CSU, please tell me.

 

[dagwoodsystems]

It's unfortunate that there are so many idiots out there pretending to be phone guys. It has made the telcos cynical and less willing to look at themselves, even when a seasoned tech is at the helm.

The Magix only understands AT&T Custom protocol (that's ISDN talk). That limitation is a real irritant for me, but it is managable. Almost no one is using this protocol anymore, which means that provisioners often screw it up (provided that the customer ordered it correctly in the first place).

There's a great thread here that I'd like you to look at real quick. Check out

http://www.tek-tips.com/viewthread.cfm?qid=929943&page=5

There is talk about using NTNAPRI protocol with a Nortel DMS switch. This combination works OK, but can create a long list of error messages which include random drops of the D-Channel.

What I'm getting at is that there may need to be a slight tweak made that was never made from the beginning. We can investigate this by you doing a little homework. Call the carrier and ask about the switch type and protocol. Then publish your Magix's PRI programming here for me to check out. Lastly, is your CSU internal to the card (not all have it) or an external one? In either case, I'd be interested in know what errors--if any--you are seeing.

We wanna make sure our side of the street is clean before doing a bodyslam on the carrier.