This document discusses how Exchange Unified Messaging (UM) handles voice mail, Outlook Voice Access (OVA), and auto attendants. It explains the call flows and components involved, including how Skype servers route calls to the appropriate UM servers based on information in Active Directory. Key UM concepts like the diversion header and UM proxies are also covered at a high level.

1. Exchange UM voice mail, OVA, and auto attendant
blog.ahasayen.com /exchange-um-voice-mail-ova-and-auto-attendant/
In previous blog posts, we talked about Exchange Unified Messaging and what you can do with such great product.
We also talked about Exchange UM architecture and cover Exchange UM dial plan concepts in great details.
In this blog post, you will discover how everything work, from Exchange UM voice mail, Exchange OVA or Exchange
Outlook Voice Access, Exchange auto-attendant and more.
Exchange UM voice mail call flow
We will stat by talking about Exchange UM voice mail, and how it really works. To explain how Exchange UM voice
mail work, we will give an example and walk you through Exchange UM voice mail components and call routing. So,
Alice just called Bob on his Skype extension, and let us say that Skype decided to route the call to Exchange UM for
any reason, like Bob not answering.
Skype will then send SIP INVITE to the UMCallRouter.exe hosted on the Exchange Client Access Server or
Exchange CAS for short. Skype will always use Secure SIP (5061), but since Exchange UM can receive SIP
invites from third party PBX systems, those systems may not send secure SIP over TCP 5060. Exchange
does not care if it is SIP or secure SIP as its service will listen on both ports if the startup mode for Exchange
UM services is Dual Mode.
UMCallRouter.exe will then send SIP REDIRECT, saying “hey I got your call, but I am not the one you
should be talking to that machine over there“.
Skype will then initiate another SIP INVITE to the UMService.exe on the mailbox role.
The UMService.exe on the mailbox server will send SIP 302 Moved Temporarily.
Skype server will send SIP traffic to the UM worker process, and then the media traffic start to flow. This is
Exchange answering the phone and do some greeting and get the audio message.
The below figure shows how Exchange UM voice mail works and the different components of Exchange UM voice
mail.
1/9

2. Exchange UM call answering flow
Now that you know about Exchange UM voice mail components, it is time to talk about Exchange UM call answering
flow. So, Alice calls Bob, and the call reaches Skype. Skype will ring all Bob end points. If Bob did not answer the
call, then Skype will try to see if it can provide an option for voice mail or missed call notification.
First thing Skype will do is to see if the user is configured for hosted voice mail option by running Get-CSUser and
then inspect the hostedvoicemail property and see if it is true or false. We will not discuss hosted voice mail case
(that is voice mail in Office 365), so we will assume the value is false.
Since the user is not enabled for hosted voice mail [Hosted Voice mail = voice mail in Office 365, and the user
mailbox is hosted in Office 365], the next step is to see if he is enabled for on premise UM solution. If the user is
enabled for Exchange UM, then the next challenge is how the Skype server will know which UM server it should
contact? It will answer that by querying AD and looking for the dial plan for the user. Once identified, it will then go to
AD and tries to read from the AD configuration partition the UM dial plan properties. Skype server will need special
permissions to read those attributes and this should be assigned by the IT administrator by running a script in
Exchange called ExUCUtil.ps1.
Now assuming that the Skype server has permission to read from AD the UM dial plan object, and since each dial
plan is attached to UM servers, then the Skype server has now list of Exchange UM servers that are servicing that
dial plan, and hence it knows where to send the SIP Invite and hope for an answer. The UM component that the
Skype talks to, exists in the CAS server [Exchange 2013 and above].
CAS will generate a redirect, and the call will reach the mailbox server. The mailbox server sees SIP traffic, it
inspects the Diversion header info, and it sees Bob extension in the form of extension or SIP URI.
So the mailbox server needs to map that extension or SIP URI, to a mailbox or identity, and it do that using
Exchange UM Proxy Addresses (EUM Proxies). This is just one more address that exist in the email address
attribute in the user object in AD. EUM addresses start with EUM and then extension that can be SIP URI or actual
extension like 1222, then @ then name of dial plan @contoso.com.
2/9

3. So the mailbox server will query AD for that EUM address (which is indexed property, so that searching for it will be
very fast), and then will know who owns that EUM address, it is BOB.
The next step is that that mailbox server needs to know where Bob’s mailbox is hosted (that is, what is the mailbox
server hosted Bob’s mailbox). Why this is needed? Well, because the greeting that Bob had recorded for his voice
mail, exists in his mailbox, so the first mailbox server that Skype talks to, will query AD for EUM proxy and will figure
out the which mailbox server hosting his mailbox.
There are three types of greetings and they are stored on the user’s mailbox:
Fully recorded by Bob
Bob only records how his name is pronounced, and then Exchange UM will say (Hey, you have reach the
mailbox of The Thing You Recorded).
The Exchange UM text to speech engine will try to pronounce your name and play fully automated greeting.
The mailbox server will then connect using MAPI to Bob’s mailbox, get the greeting, and return RTP media traffice,
to Skype or PBX to the caller.
The caller then will need to make a decision, will it hang up or leave a message.
If Alice leaves a message, her message will go through Skype back to the Exchange server, that will record it using
the configured codec, optionally convert it to text (voice mail preview), and ends up delivering through the transport
mechanism to Bob’s mailbox. This is SMTP traffic going from the mailbox server through the transport pipeline to
Bob’s mailbox. Because It is SMTP, then all the transport rules can be applied here, and this is a powerful thing.
They go through the dumpster, the safety net, and it can be protected via IRM. You can also configure retention
policies on voice mail messages.
Now if Alice does not leave a message, a missed call notification will be generated by the mailbox server who was
playing the greeting, and it will go via the same transport pipeline.
3/9

4. Exchange UM Diversion header
Diversion header is an important concept when dealing with Exchange UM voice mail. Usually the PBX system
knows why a call is going to voice mail system, perhaps the party did not answer or busy. Exchange has no way to
know that, because it is PBX independent, and it does not use any specific PBX vendor API to know why this call
comes to it (why a voice mail request is made to Exchange).
So what exchange gets instead is a SIP header (Diversion header) that indicates where the call is really coming
from (extension) along with the extension that is supposed to go to.
Let us say that the pilot extension in the PBX is 7000, and Bob’s extension is 9000 and Alice’s number is
2565551212, so the diversion header will say that the call is FROM 2565551212, and it was originally to extension
9000, but it is coming from extension 7000, so Exchange will then try to map the 7000 extension to EUM proxy in
AD.
Two notes here:
Diversion header is not used when connecting to hosted voice mail in Office 365 as Microsoft has new
architecture of knowing the extension information when connecting to O365.
The pilot extension is not used in Exchange UM and is always left blank.In case of auto attendant, there is no
need for the mailbox to search for EUM, because it knows this is the target, and it will start playing the auto
attendant media.
What is ExchUCUtil.ps1?
It is a PowerShell script located in any installation of Exchange, you run it without any parameters and it will do
4/9

5. some magic. The person running this tool needs to have permissions on both the Skype environment and the
Exchange environment.
When you should run the tool? When you have new Skype servers deployed. Skype servers are what Exchange UM
considers as UM IP gateways.
What this tool does? Well, remember that Skype servers need to identify which dial plan the user in, and then what
UM servers servicing that dial plan, so that they know where to route the call next? To do that, Skype servers need
access to the UM dial plan objects located in the AD configuration partition. Well, running the script will give Skype
servers access to read UM dial plan information in AD.
What else, well the script will also create a UM IP Gateway for each Skype server it finds, so that you can use it
when you configure your dial plans.
Outlook Voice Access Call Routing
Now that you know how Exchange UM voice mail works, let us talk about Exchange Outlook Voice Access or OVA.
OVA is a greeting that Exchange plays, that gives users ability to reach their email and do many actions. OVA
configuration is simple, as you just decide on the OVA number that people will dial. This number is called OVA
Access Number or Subscriber Access number.
This number is configured in one place, which is inside the UM dial plan configuration. One OVA number cannot
serve two different dial plans, so you need different numbers for different dial plans.
When someone calls that subscriber access number or OVA number, the user will be one of two:
1. Authenticated user: OVA answers the call, and asks the user to authenticate by providing extension and PIN.
Since there is one OVA number per dial plan, there is no way for OVA to be confused between two users
having same extension number but located in different UM dial plans.
2. Unauthenticated user: If the user did not authenticate and his dialing the OVA number, he can only do
directory search.
So, what is the big deal here? Well, I will give you a confusing case, and walk you through the way Microsoft
decided to implement a resolution.
Imagine you have a UM dial plan that is called LOC801. This dial plan is serving Jordan office. Now you decided
you want to give people OVA access, so you allocate a DID number say +96265515333 and you want anyone
dialing that DID to end up in the Exchange OVA greeting, so that they can put their PIN and have access to their
email using OVA.
So, you opened the UM dial plan configuration, then you configured the Outlook Voice Access number there. This
means that when Exchange UM receive a call directed to that number, it knows it should play the OVA greeting for
that dial plan.
5/9

6. Let us imagine how the result will look like? You call a DID number from outside, and you receive a greeting from
Exchange UM asking you to enter your extension and PIN, and you can access your email via a phone call.
Usually, your company has a DID number [i.e +9626551333], and this will terminate on some PBX system or voice
gateway, you will then route the call from your PBX or voice gateway to the Skype servers. Skype servers now need
to route that call to an Exchange UM server. Not only that Skype should know which UM servers the call should be
routed to, Exchange UM server should have a way to know that this is an OVA number
Again, the real challenge is how can you instruct Skype to route that call to Exchange UM? Remember that
+9626551333 does not exist as a phone number on any user object in Active Directory as it is a dedicated DID for
OVA.
Let us start thinking about this problem from the Skype server perspective. To do that, let us see how Skype servers
route calls. Skype servers need to locate a user or contact in AD that has that number configured on it, or else it will
try to route it through mediation to the external PBX system and try to dial it out as an external call. In other words, if
Skype received a call to a number, it will search AD for a user or contact object that has that number attached to it. If
it did not find such a match, it will do other actions like routing the call to one of its configured gateways as
configured by the Skype admin.
Moreover, Exchange UM dial plans are SIP URI dial plans, so Skype servers should route calls to Exchange UM via
SIP URI and not via a number (+9626551333). In other words, Exchange UM expect that the caller is represented
by a SIP URI and not a phone number.
6/9

7. To solve the first problem, Microsoft decided that we should create a user that is configured with +962551333 as
phone number, but since user objects are heavy objects and needs passwords, then they decided that it makes
sense to create AD contact object with +9626551333 as its phone number.
So, when Skype server received a call to +9626551333, it will search AD for a match, and will find a contact with
that number attached to it.
To solve the second problem, we need to give that contact a SIP URI, so that Skype can send that SIP URI when it
sends a SIP invite to Exchange UM.
Finally, we need a way to link that contact with a dial plan information, so that when Skype servers find that contact,
it can know what Exchange UM dial plan it belongs to. Since each Exchange UM dial plan is linked to one or more
Exchange UM servers, Skype servers can now route the call to that Exchange UM server.
To make the life easier to IT Admins, Microsoft provided two ways to create such contact
Using PowerShell
The first way is by doing it all manually, using a PowerShell command in Skype [ New-CsExUmContact ]
7/9

8. PowerShell
1 New-CsExUmContact -SipAddress sip:exumsa1@contoso.com -RegistrarPool Skypepool.contoso.com -
OU "OU=ExUmContacts,DC=contoso,DC=com" -DisplayNumber +9626551333
Running this command is not enough in case of on-premise UM integration. As we need to make Skype know what
dial plan this contact belongs to so it can route the call to Exchange UM.
This can be done by doing another Set-ADObject and setting the OtherIpPhone property for the contact and inject
the UM dial plan information there.
To know exactly how to do such PowerShell commands manually, download this script. I will show here some
important lines from that script:
PowerShell
1
2
3
4
5
#Create UM contact object for Auto Attendant
$AANameFormated = $ExistingAutoAttendant.name.Replace(" ","")
$SIPAddress = "sip:" + $AANameFormated + "_AA@" + $SIPDomain
$OtherIpPhone = $SIPAddress + ";opaque=app:exum:" + $($ExistingAutoAttendant.UMDialPlan) + "." +
$Domain + ":" + $($ExistingAutoAttendant.name)
$UMContact = New-CsExUmContact -SipAddress $SIPAddress -RegistrarPool $RegistrarPool -OU $OU -
DisplayNumber $AutoAttendantPilotIdentifier -Description "Exchange UM Auto-Attendant" -AutoAttendant
$True
As you can see, the OtherPhone attribute has the UM Dial Plan information, so that Skype servers can find out
which Exchange UM dial plan that contact is attached to. Knowing the UM dial plans, Skype server can know which
UM servers serve that UM dial plan, and can route the call accordingly.
Using a tool on Skype called [OcsUmUtil.exe]
This utility will do it all. It will create contact object in AD, it will assign SIP address and access number
(+96265515333) and it will inject the UM dial plan information in the OtherIpPhone attribute.
Final Thoughts
8/9

9. Let us see how everything works now. Someone from outside calls +9626551333, this DID is configured to be
routed to Skype. Skype will try to locate a SIP enabled object (user or contact) that has such extension or phone
number by querying the (msRTCSIP-Line) attribute, and it finds a contact that we created using the PowerShell
script (sometime the PowerShell command will create the contact with ugly display name that looks like a GUID but
this does not matter, just make sure to put a good description on it).
Now, the Skype server will say “ok let ring that contact on its sip address endpoints”. Of course, no one will answer,
so guess what, the same logic we talked about will happen. Skype will say let me try to see if it can leave voice mail
or missed call notification, so it will look if that contact has hostedvoicemail policy on it, and if it does not, it will try
to see if that contact belongs to UM dial plan by inspecting the (OtherIpPhone) attribute. Once it extracts the UM
dial plan information from the OtherIpPhone attribute, Skype will query AD again, to read the UM dial plan
information from AD. From there, it will look up the UM servers serving that dial plan from the dial plan AD object
properties, and then it will send SIP INVITE to that UM server containing the phone number and the SIP URI for that
contact. UM server will then map that extension +9626551333 to the dial plan OVA access number, and it will know
to play the OVA greeting.
You can see that the contact object serves two things:
1. Maps an extension to SIP URI that can be routed to the Exchange SIP URI Dial Plans.
2. provide UM dial plan assignment to the subscriber number so that Skype can route the call.
Note: Auto-attendant works the same way, but the New-CsExUmContact PowerShell command has a switch called
[ -AutoAttendant <$true | $false> ].
I hope by know you know about Exchange UM voice mail components, Exchange UM voice mail call routing,
Outlook Voice Access or OVA, and auto-attendant. We talked about Exchange UM voice mail when the user’s
mailbox is hosted on-premises. I will be talking about Exchange UM voice mail when the user mailbox is hosted in
Office 365, while the Skype servers are hosted on-premises.
9/9