I believe I have been pretty clear about this. I am not a fan of voice mail. I don’t like leaving them because I know that most will never be heard and I don’t like listening to them because text and email are quicker and more efficient. Needless to say, I was thrilled when I read that Coca Cola announced they are phasing out voice mail from their corporate headquarters: Coca Cola Disconnects Voice Mail at Headquarters.
Still, I realize that voice mail isn’t going to disappear from every company overnight and IT professionals will be installing new systems and maintaining existing systems for some time to come. That means that nerds like me need to stick around to explain how voice mail works.
For some background information, please refer to my article, Thank you for Calling – Voicemail and SIP.
I was recently teaching my SIP class to a company near Detroit, Michigan when I was asked to describe how Avaya works with a SIP-based voice mail system. Honestly, I didn’t know. I had some ideas, but as I have often seen in the SIP world, what I would like vendors to do isn’t always what they implement. So, I did what I always do in cases like this. I started up traceSM, placed a call to my extension, and let it roll over to Modular Messaging.
A few notes about what I am about to describe.
- I wanted the call to come in from outside the Avaya system so I used an 1140 telephone on a Nortel CS1000 that was SIP trunked to an Avaya Session Manager. The user of that phone is my coworker, Coleen Frink.
- With traceSM, I created a filter to capture packets to my extension (4563516) while filtering out registration and subscription messages. The filter itself looked as follows: -u “4563516” –nr –ns.
- I used traceSM to capture the trace, but eventually moved the data to Wireshark. You need traceSM to decrypt TLS (encrypted SIP signaling), but Wireshark is a better tool for packet analysis.
For a deep dive into traceSM, please refer to A Necessary Guide to the Avaya traceSM Utility.
The following are screen shots of the entire call flow as seen on traceSM. Since the flow is too big to fit onto the screen all at once, I was forced to create three captures.
Looking at SIP from the standpoint of Session Manger is never a straight-forward process. That is because there are so many different elements involved. You have the SIP endpoints. In this case, that would be the Nortel 1140 (left most entity in the screenshots) and Avaya 9641 (right most entity in the screenshots) telephones. You also have SIP entities such as Communication Manager and the CS1000. Session Manager is also divided into two parts – SM 100 and SM. So, unless you pay close attention to what is happening, it is easy to get lost in all the clutter. Thankfully, traceSM uses color to help you isolate packet flows between the different elements.
At a very high level, you should see the following.
- Coleen (from a Nortel 1140 IP telephone via a Network Routing Server (NRS)) calls Andrew
- Andrew’s telephone (an Avaya 9641 SIP telephone) rings
- Communication Manager reaches the call forward no answer (CFNA) threshold
- Coleen is informed that the call is being forwarded
- The call to Andrew’s telephone is cancelled
- An INVITE is sent to Modular Messaging
- Modular Messaging answers the incoming call
- After leaving a message, Coleen releases the call to Modular Messaging
Out of all the messages that go back and forth between the different SIP entities, I want to pull out a few to examine. First, let’s take a look at the original INVITE from Coleen.
This should look fairly typical with the exception of a few things. Nortel adds a History-info header containing Andrew’s extension. It also uses multi-part MIME in the message body. This non standard approach cannot be deciphered by Wireshark. Fortunately, Session Manager understands Nortel and will reformat the message (i.e. drop the non-SDP portion of the message body) so it can be understood by non-Nortel systems.
Next, let’s look at the 181 Call is Being Forwarded response.
This response is sent by Communication Manager to inform Coleen that her call is being redirected to a new destination. I wish it stated that the call was being forwarded to Modular Messaging, but that doesn’t appear to be the case.
Next, I want you to take a look at the INVITE that is sent to Modular Messaging.
There are three things of interest in this message. Both the To header and SIP URI have been changed from Andrew’s information to Modular Messaging as the recipient of the call. You can still find Andrew’s information, but it’s now in History-Info. This is how Modular Messaging knows the correct mailbox greeting to play and where to save any subsequent message.
This isn’t all that important, but notice how Avaya uses History-Info and Nortel uses History-info. Clearly, SIP headers are not case sensitive.
What I don’t show is the messaging waiting indicator (MWI) being lit, but that’s a blog article for another day.
Mischief Managed
I hope this wasn’t too hard to understand. Clearly, Communication Manager is doing a lot of the heavy lifting by redirecting the unanswered call to Modular Messaging and canceling the ringing call on Andrew’s telephone. Before I did the trace, I expected it to send a 302 Moved Temporarily response to Coleen, but that didn’t occur. Of course, that would have required Coleen to perform the redirection and Avaya doesn’t want to rely on someone else to implement an essential call processing feature.
Well, that’s it for 2014. I hope you enjoyed all my SIP and unified communications missives these past 12 months. Stick around for more fun and games in 2015.
Tao, Zen, and Tomorrow 
From this article it appears that the local pbx controls the number of rings before redirecting the call to voicemail. Do phone users get any say in how many times the phone rings before it’s redirected to voicemail?
That is typically controlled by the phone system and not the phone.