Although voice mail has been around for ages, it is still a little quirky... perhaps a lot quirky. This makes it occasionally challenging to configure, especially when trying to fit one vendor's PBX to another vendor's VM system. This occasionally happens when IP Phone systems replace legacy PBXs, but -- to save money -- organizations decide to keep their old voice-mail system. The heart of the problem is the rather obscure protocol known as SMDI, which stands for Simplified Message Desk Interface, and the varying degrees to which different vendors adhere to it, or "embrace and extend" it as the case may be.
As an example of this, take the "reason code" transmitted via SMDI by the switch to the voice-mail system. SMDI has four of these, A, B, D and N, which equate to "Forward All Calls", "Forward Busy Calls", "Direct Calls" and "Forward No Answer Calls". Now, you may want to configure your voice-mail system to play different greetings, based on how the call arrived. For example, "Sorry I can't talk to you; I'm on another call" when your phone is busy and the call goes to voice mail or "I'm not here, try back later" when there is no answer. You might just want a simple "Hi, this is Tom's voice mail" when a receptionist sends the call directly to your voice mail. This sort of feature is supported by several popular voice-mail systems, such as Octel.
But suppose you hooked up your Cisco CallManager, and callers always get your "Forward All Calls" message, no matter how they get into your voice mail? The way to troubleshoot this sort of problem -- after exhausting the easy avenues, like searching on the Web -- is to use a terminal program, like Telix, Procomm or Windows' HyperTerm. With your terminal program of choice connect yourself to the good old-fashioned RS-232 cable over which the SMDI travels, and watch the SMDI messages displayed by the PBX in ASCII text. In this case, you'd find all the messages with a "reason code" of A for the simple reason that CallManager doesn't support this function.
The point is, although the messages are a little cryptic, it's very simple to "sniff" RS-232 and find out what's really going on.
Thomas Alexander Lancaster IV is a consultant and author with over 10 years experience in the networking industry, focused on Internet infrastructure.
