Exchange Unified Messaging Fundamentals

UM components 
 
The essential functions for Unified Messaging are the: 
 
·         Microsoft Exchange Unified Messaging Call Router service 
·         Microsoft Exchange Unified Messaging service 
·         Microsoft Exchange Unified Messaging Worker Process 

The Client Access server runs the Unified Messaging Call Router service. It's responsible for accepting the initiating Session Initiation Protocol (SIP) traffic from the Lync server when a voicemail message is left destined for the Unified Messaging service. 
The Mailbox server runs the Unified Messaging service and the Unified Messaging Worker Process. The Mailbox server is responsible for accepting media traffic—that is, Real-Time Protocol (RTP) and Secure Real-Time Transport Protocol (SRTP) traffic—from a VoIP gateway, Session Border Controller (SBC), or PBX. 
Because the Exchange 2013 Client Access server isn't capable of receiving media traffic from a VoIP gateway, SBC, PBX, or even a Lync server (a Mediation server can be collocated on the Front End server), the Client Access server redirects all media traffic to the end user's Mailbox server. The Mailbox server will then receive traffic directly from the VoIP gateway, SBC, PBX, or Lync server. 
 
 
Lync 2013 and Exchange 2013 Call Flow 
The Lync 2013 and Exchange 2013 call flow is unique in that calls to the Unified Messaging service now travel through the Exchange Client Access server. There are four steps: 
1.    The call is routed inbound through the PSTN to the Lync Mediation server, then to the Lync Front End server. 
2.    The inbound call travels to the Lync Front End server (the Mediation server is collocated on the Front End server) and makes its way through the Lync Front End call routing process, which is referred to as the inbound routing logic, and rings the Lync client. 
3.    If the Lync end user doesn't answer the call after a certain number of rings, the voicemail routing logic on the Lync Front End server will determine whether the Lync user has a Unified Messaging mailbox. If so, Lync will route the call to the Client Access server. Note that the process of Lync routing an unanswered call to voicemail is equivalent to a Ring-No-Answer or Cover path in some telephony PBXs. 
4.    When the Client Access server receives the SIP invite from the Lync Front End server, the Unified Messaging Call Router service redirects the incoming call to the Exchange Mailbox server. The traffic that's sent to the user's Mailbox server is media (RTP and SRTP) traffic. 
 
 
Dial Plan Properties 
---------------------- 
 
Secured - SIP signaling and media both will be encrypted  
SIP Secured - Only SIP signaling will be encrypted not RTP media 
 
 
dialing rules 
dialing authorization 
 
 
 
1 - UM 1 
 
Step by Step setting up the Exchange and Lync integration 
 1. On exchange server create a dial plan (give it a name, type, an extension length, etc.) When a DP is created a default mailbox policy also gets created which gets associated with the DP 
2. Associate the UM server with the DP 3. Provide the SA number to the DP. (Everytime you create a dell plan mailbox policy will get associated to it) 4. Run the script on lync server - this script goes to exchange finds the available dial plans, creates a contact object in the AD so the lync can find the number of the dial plan when it needs 5. Run the script on exchange server- this script goes to lync and find the FE pools and creates the ip gateway with for the pools it found. It gives permission to Lync to read AD objects read exchange objects. It also creates the HG with th IPGW and associates the HG which day ip gateway. 
 
 
Flow 
================ 
 
 
It is the responsibility of the phone system to find out who didn't answer the call and send THIS information to the voicemail system along with WHO and WHY information. 
 
Remember even though extensions are not being used in the environment but we still need to provide extensions to the users we will talk on this later 
 
There are three types of dial plan: SIP URI - sip:gautam@contoso.com TEL URI - 9066052736 E.164 - +919066052736 
 

If the dial plan type is set to SIP URI then, when a user does not answer the call exchange expects the SIP URI of the user who didn't answer the call and so for the TEL URI, a telephone number and for E.164 a 12 digit number starting with + sign 
 
Dial plan has a Subscriber Access associated with it, and a SIP URI. Subscriber access has a phone number. So that if someone wants to reach dial plan he can dial the subscriber access number. 
 
Now when we enable a user for UM the user needs to be associated with a dial plan. It also asks to provide an extension number. If you are using any extension number in your environment then you can provide the same if not then still you will have to provide an extension ( though we are using SIP URI but still will have to provide an extension, we will discuss this later) 
 
Now when a user is enabled for UM he gets a EUM proxy address (the EUM address has the dial plan name) when a user is enabled for UM, and the value for property "voicemail" becomes "TRUE" 

So when a user doesn't answer the call, lync check the AD properties of the user and find out the user is enabled for VM and from the EUM address it also find the dial plan associated with the user 
 
Lync also checks the AD and finds the SIP URI and the SA number on the dial plan and sends the call to UM 
 
 
with the following details in the description field  
Refer to UM 
Reason = No Answer  
Divergent header = SIP URI of the user who didn't answered the call  
 
Now UM knows why the call has come to him, now exchange will first confirm if the call has come to him from a valid IPGW after that it will confirm if this user is enabled for VM, then it will access the mailbox of the user and play the greeting if user has kept any. And after taking the voicemail it will submit it to the transport server for the delivery 
 
Remember while setting up the UM we first run the script on Lync server, it will go to exchange side and look for the available dial plans and come back to lync and say i have found these many dial plans and it will create contact object in the active directory for those dial plans, that is called the Subscriber Access and the contact object will have, secure and it will also have a number which game is to the dell plan  object will have the same number which was given to the DP 

Other reason for which SA is called by an user, is to check e-mail i.e. when FE sends the call there is (REASON = NO ANSWER)  but when you will call UM to check your VM by calling the SA number assigned to your dial plan,  then you don't send any reason so when UM is called without any reason UM believes that he is been called by someone to check his VM 
 
Now if you call Exchange from internal lync client (in this case you are already authenticated) that call will have FROM Header which has the user's SIP URI  or extension number, UM does a lookup to fetch the user and if the user is calling the correct dial plan then UM gives you access to your vm 
 
Now suppose if you are trying to check your vm from a cell phone or from PSTN ( i.e. Dialing the SA number from the cell phone) then you need to ensure the SA number is in E.64 format and in this scenario the caller is not authenticated. The call will land to the IP-PBX, then to mediation to Front End to UM. 
 
Now the FROM header will have the number of the caller i.e. +919066052736 now UM need to find the user who is trying to check his voicemail UM can look in AD and see if that calling number is assigned to any user and can do  reverse look up and find the user and play the greetings of has voice mailbox but what is the cell phone number is not present in  the AD or you are calling from public booth in such situation UM needs to authenticate the user so it will ask to enter his extension (this is the reason extension is mandate even if we do not use extension and because of which while enabling a user for UM we have to provide the extension) after the user enters the extension the UM 

will look into the AD to check if any user is enable for VM has that extension, on the dial plan on which i receive the call  55:04 
 
Now once UM finds the user it will ask the user to authenticate himself by entering PIN then you will get access to your vm 
 
.------------------------------ 
 
There is a voicemail search folder in outlook what is not visible ..------------------------------- 
 
When we enable user for voicemail it does not ask for which dial plan but it asks for which mailbox policy you want the user to be associated with, and every mailbox policy is associated with a dial plan. 
 
Mailbox policy defines the pin length,  expiration, sequence of pin, etc. 
 
------------------------- 
 
Hunt Groups =  when UM receives a call (call can be made from one number to another number) on a number that is SA which is associated to a dial plan.. 
 
The call is coming from front end pool or any telephone system which is called IPGW in UM. 
 
When the UM receives the call it always receives the call from a IPGW i.e. Front end pool on a certain SA number, so the very first thing UM  does is, Checks, do i have  an IPGW from where the call has come ? Then it checks do i actually have a dial plan with this SA number ? 
 
An IPGW has something called hunt group.  Hunt group has all the data plans that UM has. 
 
So when are UM gets a call, it takes that number and it hunts in the hunt group to check if there is a Dial Plan which has this subscriber access number. HG=DP+IPGW 

CALL FLOW ===================================== 
 
LYNC/IPGW --------------INVITE   on port 5060 or 5061 i.e. tcp or tls  ----------------->EXCHANGE 
 
LYNC/IPGW <------------302 moved temporally, come on 5066 or 5065-------EXCHANGE 
 
Exchange responds back to Lync/IPGW that I understand your request, but I am not to take any voice mail please come to my UM Worker Process which is listening on port 5066 or 5065. Now Lync/IPGW sends a second INVITE on either 5066 or 5065 (The port on which the INVITE should come from Lync/IPGW depends upon the port given by exchange) 
 
NOTE - It is by design that  UM Worker Process keeps switching the port every week 5066 to 5068 and 5065 to 5067 
 
5065 = TCP   If UM worker process is listening on 5065 after 7 days it will switch to 5067 5066 = TLS    If UM worker process is listening on 5066 after 7 days it will switch to 5068 
 
 
Note - Some customers a smart, since their telephony system do not understand (302 moved temporally) so they configure their phone system to directly send the INVITE to 5065 instead of sending to 5060 or 5061 (i.e. The port number send by exchange server in 302 ) and things work fine, but after a week when the Exchange UM Worker process flips its port from 5065 to 5067 VM does not work. 
 
So, it is important that the phone system should understand (302 moved temporarily) and then send the second INVITE to the port asked by Exchange ! 
 
To troubleshoot 
 
Take wireshark on exchange server filter the trace for "sip" and look for 302 this can also be seen and lync trace for (sip stack, s4, inbound/ outbound routing, XUM routing) ============================================ 
 
The recorded voice mail is stored at V14\ unified messaging\temp\.txt & .wav 
 
At this location there should not be any files lying around because once the voicemail is delivered the files are deleted and this happens immediately. If you see the files here which means the hub server is not able to pick the files and send to mailbox so check the connector and hub transport server 
 
UM and hub transport server should be in the same AD site ________________________________________________ 


No comments:

Post a Comment