Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Monitor?

Status
Not open for further replies.

Mongo5150

Vendor
Apr 22, 2003
232
0
0
US
What is the monitor feature for? Is it only for Lucent?

Thank you and happy holidays.
 
Correct, it's only for Lucent. There's some people working on figuring out now I believe, but we can't talk about it on here. Avaya engineers have been complaining about us talking about the monitor because it is only for them.

KILLBOX
 
Most of "Monitor" commands are not real useful for other than the engineers and could get you into real trouble if you used them.

There are a couple of the commands however that would be very useful for them to move into maintenance mode. One of them is SMDR logging.

That's all I'm going to say since we don't want to get the engineers upset.

 
you can do SMDR through the SMDR port. The major that everyone wants to know about is the T1/PRI monitoring. How about that tool for battling with Telco.

KILLBOX
 
The T1/PRI logging feature is great. I will 100% agree. Using an ISDN signaling reference guide I found I was able to exactly pinpoint whether dropped calls were near end or far end disconnects as well as associated ISDN error codes. Lots more details than just SMDR.

I still don't understand what all of the hub-bub is about. Other PBX/ACD vendors I've worked with in the past have freely let me know drill down to the system tracing and operating language levels if need be in order to troubleshoot matters. Any group from AT&T to Nortel to Toshiba to Rockwell. Supposedly there's a danger of reverse engineering by using MONITOR per Avaya Legal. If that's what they say then I leave things at that.
 
So, who took all of the posts that were up here the other day?

MFurrer@charter.net
 
I think the word 'MONITOR' is verboten. Anyone guilty of posting will be ...ahhhh! #%#%#%#%
ATH
+++
NO CARRIER
.............
 
SMDR monitor was nice when you need to remote monitor the SMDR.

I agree that holding back on some features is overkill but it's their game and their rules. When I got the password to the monitor function I had to promise that I would NEVER give it out. That a promise I keep even now.

I remember my "AUDIX" system was based on AT&T system V UNIX. There were times when some of the printer functions need fixing. I could have easily gone in to UNIX and made the changes but they would "NEVER" give you the root password.

I've never liked having my vendor having a back door password. I'd rather change all my passwords and then give them one when they need to get in.

BTW, a yahoo group is always a nice place to talk about "free speech issues":)

 
It's not so much as free speech as it is of giving the customer all the tools to utilize their and I quote"THEIR" system. We purchase systems from the manufacturer based on features, and isnt one of those "monitor" Would the features under "monitor" better troubleshoot the system? Help with battling telco? DUH! Its frustratingr that even the manufacturers greed filters down to a third party like this foeum, WHICH, should be under free speech. IF Avaya is upset that some of their features and passwords are put out on a medium like this....THEN GET SMARTER AND MAKE IT HARDER...
Sorry for my rant...

MFurrer@charter.net
 
True this on all counts. The funny part is that this system function just provides low-level tracing and other read-only returns. AFAIK there is no write-back functionality. So it's not like you can perform system programming at the OS level. But like others have said since it's their system they can stake out the boundaries of what should and what shouldn't be done.

Although I've known about this function for years now I have only had to resort to it maybe 2-3 times at most. Sometimes it's the thrill of the chase that makes topics like this seem more intriguing than they really are...
 
Agreed.. Here's what I don't get..

If the function is competely undocumented, and it's so incredibly complicated to use.. Why not adopt the "security by obscurity" approach. Even if you happen to snag the password, you aren't going to know what in the hell to do with it. :)

- Joel
 
Reminds me of when I first started trying to learn the AT&T/Lucent/Avaya Merlin equipment line. There was a vendor field engineer I was asking about the 355AF serial adapter that I could use in order to access SPM. Asking pinout questions as well if I could pick one up through sales channels so I could work on things in a similar fashion to him.

I was left thinking that this tiny adapter was part of the Dead Sea Scrolls or the Apocrypha. Same with even trying to learn how to program a Magix INA board. No documentation that I could get my hands on, no intermediary software (other than the WinSPM passthrough mode), and no hard answers from vendor support. Digging around the Internet I was able to obtain some older Lucent PortMaster ComOS docs, the PortMaster Vision GUI utility, and a Merlin programming manual for it. But it was like being a private detective.

Security through obscurity is definitely appropo in the case of this little corner of technology. A far cry from Open Source Software :)
 
So,with the monitor function, can you troubleshoot T1 info from the LEC?

MFurrer@charter.net
 
You can extract ISDN cause codes, which can help point you in the right direction. A reference document I employed was Such cause codes can definitely be ammo in dealing with equipment vendors, telco, the customer, etc.

In my situation I had Site A (Merlin Legend) and Site B (Merlin Magix w/INA) connected via tandem networking. Site A was the PSTN and voice mail hub, as Site B relied on A for these services. For some reason Site B was experiencing a considerable amount of dropped calls from the PSTN. Site A reported no issues of this type. So it was up to me to address matters.

My first option was contacting telco and having them verify the point to point circuit's performance. Using SNMP data and Merlin CSU stats I knew that the circuit was relatively clean (in terms of Failed/Unavailable Seconds). As expected telco tested out the circuit fine.

Using SMDR at both sites I was able to demonstrate whether these dropped calls were recorded as near- or far-end disconnects. And using MONITOR I was also able to extract ISDN cause codes associated with these dropped calls. Since these calls had normal cause codes (i.e. - no error codes) I was able to determine that the INA was seeing these calls as completed and disconnecting them normally. When in fact the calls were still active. An INA issue that was addressed with a firmware upgrade. Although Avaya wouldn't confirm any known issues of this nature and stated that a 2-3% dropped calls rate is a vendor accepted value!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top