This article shows the call flow between Exchange and Skype for Business when someone is leaving a voice mail or trying to access OVA or auto-attendant.
Voice Mail Call Flow
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 CAS. Skype will always use Secure SIP (5061), but since Exchange UM can receive SIP invites from third party PBX systems, those systems may send unsecure 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 UM worker process 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.
UM call answering flow
Alice calls Bob, and the call reach Skype, and 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, 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 reach from AD the UM dial plan object, and since each dial plan is attached to UM servers, then the Skype server has now lists 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 exists in his mailbox, so the first mailbox server 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 record 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 and will get the greeting and will return through RTP 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 Delete repeated word
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.
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 wit 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 as those are candidate to be defined as UM IP gateways.
What this tool do? 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 fins, so that you can use it when you configure your dial plans.
Outlook Voice Access Call Routing
OVA is a greeting that Exchange plays and gives users ability to reach their email and do many actions. OVA configuration is just deciding 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:
- Authenticated user: OVA answers the call, and asks the user to authenticate by providing extension and PIN. the extension is just the four digit number like (1222) and not (801 1222). 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.
- Unauthenticated user: If the user did not authenticate, 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 say LOC801 that 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 in GSO dialing that DID to end up in the Exchange OVA greeting, so that they can put their PIN and have access to their email.
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.
So, you configured your PBX to direct calls to +9626551333 to the Skype servers, but the problem is that how can you instruct Skype to route that call to Exchange UM?
Problem 1: well, Skype servers need to see 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.
Problem 2: moreover, the UM dial plan is configured as SIP URI dial plan, so the Skype server should route calls to Exchange UM via SIP URI and not via a number (+9626551333)
To solve the first problem, Microsoft decided that we should create a user in that is configured with +962551333 as phone number, bust 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.
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. Remember that Exchange UM only accepts SIP URI for the destination extension.
To make the life easier to IT Admins, Microsoft provided two ways to create such contact:
- First way: using PowerShell command in Skype [New-CsExUmContact]
New-CsExUmContact -SipAddress sip:firstname.lastname@example.org -RegistrarPool Skypepool.jo.contoso.com -OU “OU=ExUmContacts,DC=contoso,DC=com” -DisplayNumber +9626551333
Actually running this command is note 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.
- Second way: 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
So now, suppose we used the PowerShell command above, imagine someone from outside is calling +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 founds 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, and 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, and then will try to read the UM dial plan information from AD, from there it will lookup 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 maps 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:
- Maps an extension to SIP URI that can be routed to the Exchange SIP URI Dial Plans.
- 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>].