I need to begin with a full disclosure. I am not a big fan of listening to voicemails. Give me email, instant message, or SMS text over dialing a phone and playing a voice message any day of the week. Voice messages on my PC as WAV files are a little better, but I find them annoying, too. I once enjoyed a speech to text service on our Modular Messaging system, but my company stopped renewing the Mutare licenses and I am back to using my ears.
Don’t get me wrong. I have nothing against human speech. It’s more a factor of time and my serious lack of patience. I lead a very busy life and prefer messages that are instantly digestible. I want to look at a piece of text and immediately know what’s expected of me. Perhaps it’s me, but it often requires more than one listen to come to the same understanding.
Still, I absolutely understand the importance of voicemail and voicemail systems which is why I want to spend some time talking about how all this works with SIP.
Let me start by identifying the different functional aspects of voicemail.
- There needs to be a connection from your communications system to your voicemail server. This, of course, assumes that they aren’t one and the same.
- Calls need to move from an unanswered, ringing phone to the voicemail server. Depending on why the voicemail system was called, different prompts might be played. For example, calling a busy number might result in one prompt while a no-answer-rollover might result in something different.
- The voicemail server needs to know the identity of the caller and the originally called number. The called number equates to a voicemail mailbox.
- Callers need the ability to enter DTMF (touch-tone digits) to gain access to specific voicemail services. “When you are finished you may hang-up or press pound for more options.”
- Users of the voicemail system need to be made aware of activity on his or her mailbox. For example, a red light might be illuminated when there are unread messages.
- Users of the voicemail system need to enter DTMF digits to log in, play messages, delete messages, etc.
The connection between the communications system and the voicemail server will be SIP trunks. These trunks can come directly from the call processing server (e.g. Avaya Communication Manager) or they can tandem through an intermediary device such as an SBC or a Session Manager. The use of a Session Manager allows the voicemail server to be easily shared by any number of communications systems. For example, Session Manager allows a single voicemail server to be used by multiple Avaya, Cisco, and Nortel systems.
Callers are transferred to the voicemail server just as they are in the TDM world. Telephones are configured with a Call Forward No Answer (CFNA) setting that instructs them to automatically transfer calls to a pre-set number or SIP username after so many rings. That number/name will be served by the SIP trunk group connected to the voicemail server.
Called party and caller information can be conveyed in the SIP To and From headers, but those values can sometimes be unreliable. The original caller might not have enough information about the subscribers in a domain to properly set the To header and the From headers can be masked for privacy reasons.
To overcome problems with using the To and From headers, the SIP URI itself can be encoded to indicate the target mailbox and the reason for call redirection. Specifically, the “target” parameter will contain the mailbox identifier and the “cause” parameter will contain the redirection reason. For example, the SIP URI for a call sent to a voicemail server might look as follows:
sip:voicemail@mycompany.com;target=andrew@mycompany.com;cause=408
Telephone number formats are also permissible.
sip:voicemail@mycompany.com;target=+15555551002@mycompany.com;user=phone;cause=408
As specified in RFC 4458, cause codes include the following values.
404 Unknown/Not available
486 User busy
408 No Reply
302 Unconditional
487 Deflection during alerting
480 Deflection immediate response
503 Mobile subscriber not reachable
In addition to the SIP URI, the History-info header can also be used to provide information about the retargeting of a request. History-Info is capable of carrying trace information about the SIP request along with the SIP response codes that led to the retargeting.
History-Info can be very important if a downstream proxy modifies the SIP URI and essentially removes the target and cause parameters. These parameters can be rebuilt through an examination of the History-info components.
So, now that the call is at the voicemail system, how is the mailbox user made aware of the new voice message? This is done with a subscription to the mailbox. The user, or a proxy on behalf of the user, sends a SIP SUBSCRIBE for the event package, “Message-Summary.” This will cause NOTIFY messages to be sent for that subscription whenever there is a change in the mailbox status. For example, a NOTIFY will be sent when a new message arrives and another NOTIFY message will be sent when all messages have been read. This allows a SIP phone to do something as simple as turn on and off its red message waiting indicator.
To learn more about SIP subscriptions, please refer to my blog article, SIP Subscribe, Notify, and Publish.
This leads us to DTMF. The best way to send and receive DTMF digits during a SIP session is to use RFC 4733/2833. This RFC defines a separate media stream for DTMF tones. An alternate, but frowned upon method is to use SIP INFO requests to carry DTMF digits. Cisco’s SIP voicemail system used to require this, but they may have moved to the better method of out-of-band DTMF.
DTMF digits can also be sent in-band with the voice stream, but this requires DSPs to detect and process them.
For a deeper dive into the subject of DTMF digits, please see my blog article, DTMF and RFC 4733/2833.
Be Aware
SIP is a standard, but companies have taken liberties with the standard. What I described might not be exactly how all voicemail systems work. However, it’s pretty close and if you were able to grasp my explanation, you should be able to figure out any vendor specific differences.
Tao, Zen, and Tomorrow 
This is really cool and nice teaching, As you are right not only you but every person have a busy life now a days to meet his/her monthly targets especially those who are related with marketing field as I am doing job in Internet Voip phone company who sell Ip phones and we really dont miss our calls when we are in field.
Thank you for reading and taking the time to leave a comment!
How can I get the voicemail information? For example I want to implement a header like this: “You have 3/3 voicemail” so the user can know whether he/she has voicemail even before contacting the server.
Im sitting here 3 yrs later having a difficult time trying to figure out an pre-mature BYE message issue affecting VM usage and your artical helps out a lot.
I like how you mention that the people who are using the voicemail system need to be made aware of notifications and providing a solution to notify the users. My wife and I are thinking about starting a business and might need a system to organize voicemails to make workflow more efficient. It seems like a good investment to look at voicemail systems to help manage message.