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.

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 ExchUCUtil.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.

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.

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 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.

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.

 

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 ]

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:

#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

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.