WinSPM Monitor Commands list

[AhhClem]

thread689-568937

This is regarding a Merlin Magix with 44xx phones, Merlin Messaging and 15 channels of PRI on a 100DCD board. Release 2.1.

Now that Avaya has killed the Merlin Magix/Legend product line and all tech support can we finally now get access to the Monitor commands built into WinSPM? Is it still a closely guarded secret?

I have a customer having PRI problems with incoming calls only and the Monitor trace commands might help me convince the phone company that the problem is theirs and not my switch. We've already replaced the 100DCD board with no change in the problem. The phone company seems convinced that they are not at fault. It seems that when the incoming calls get to channel 3 or above the caller hears the "your call cannot be completed as dialed. Please, try your call again later." recording. I need a tool that can end this arguement. As far as I can tell, the switch never sees the call come in. All outbound calls seem to work fine.

There have been no suspicious errors in the transient error log and there haven't been any permanent errors at all.

Thanks for your attention.

AC

 

[merlinman]

NOPE, Still not giving that away.

Perhaps if I write a book.

I think you've done enough to prove your point with them anyway.

http://home.comcast.net/~merlinman

 

[dagwoodsystems]

Monitor isn't intuitive at all. Even with a Computer Science degree and two decades of installing AT&T/Lucent/Avaya products, it's taken me a couple of years to understand how to make use of perhaps a dozen or so commands (and the ones relating to ISDN circuits are close to being the most cryptic). But if you're curious, you can always enter Monitor and type ? at the Monitor prompt for a list of available commands.

Better to troubleshoot the way you have been. Let's see if myself or somebody else here can help you get past this sticky spot. A few questions/remarks:

If telco only provides 15 of the proper 23 b-channels, it's clear to me that an IAD of some kind is involved. Prior to these devices, a "fractional PRI" didn't really exist. To make that work on a Legend/Magix, you'll obviously need to limit the number of trunks and possibly the number of b-Channels assigned to the PRI. If your DS1 board were in slot #5, the b-channels assignment entries would be 0523, 0522, 0521...down to 0509.

But let's say you've done that and you're still having problems. The way I've fixed this in the past is to assign all 23 b-channels to the PRI, but limit the number of trunks (to 15 in this case). Legend/Magix does not support a one-to-one correspondence between b-channels and trunks, so an inbound call on your 3rd trunk could very well use the 7th b-channel to complete the call. If the carrier's gear does the same thing, then we have to be prepared for a call on any of the standard 23 b-channels over one of the 15 trunks.

Such a mismatch may be the reason callers hear the carrier-generated "Please try your call again later" message. Another possiblity is that the carrier is sending a standard call setup message for some, but not all calls. A funky or ill-formed d-channel message would be rejected by the Legend/Magix, thus failing the call.

Oh, and how is it that you know that the problem occurs on "channel 3" or above? Is that something the telco is reporting to you? I wonder if they mean the third trunk.

Tim Alberstein

http://www.dagwoodsystems.com

 

[jinxs]

I was in your boat about 10 years ago. I knew about this mysterious monitor and I could not access it until I actually got the password from someone on this site.

Then once I got in there, I saw some commands that were very helpful and some that I knew nothing about. I was interested in PRI as well. Unfortunately the raw data dumped out for a PRI trace doesnt really help you much if you dont understand ISDN Layer 3. Here is a document that I found that truly helped me understand what it was that I was looking at. You will need to know how to break down each octet to a binary level, then the manual will show you the meaning of each 1 and 0.

http://www.corp.att.com/cpetesting/pdf/tr41459_99.pdf

You can also translate the data by converting it to more of of a text dump, make sure if you want to use this you name your log file as XXXXXXX.log. If you dont add the .log extension then it never worked for me.

To be honest, I use monitor more for finding out what the LEC is sending me than troubleshooting PRI issues. You are truly on the right path to isolating the trouble. Good luck.

 

[AhhClem]

Thanks all for the responses. It's great to hear from those who've been there.

I just got off the phone with the customer and the word from the line provider is that there was a bad channel 2. The provider is going to kill the bad channel until the problem is resolved.

My lines were set up for the first 15 channels for voice and the remaining 8 channels for video conferencing. The smart jack feeds a nteACE from Adtran which is what splits the channels out. The lines are assigned in the following manner; Channel 1 = 809, Channel 2 = 810 etc.

It's my understanding that if you build the channels backwards you get the correct relationship of channels to trunks. In the past, tech support has also informed me that when it's configured this way, outbound calls will hunt backwards thru the lines, starting at 15 and inbounds will come in starting with channel 1. However, I'm sure many factors, including the providers programming can alter how that works.

I've informed the customer that perhaps the Adtran device may be at fault. We'll have to poke around in it's programming to see if we can duplicate it when it's replaced.

Thanks again for the replies.

AC