Unified Messaging is the word coined by Microsoft in the Year 2007 when Microsoft released Exchange Server 2007 with the "Unified Messaging" feature.
The Unified Messaging role let’s users receive voice mail, e-mail, and faxes in their mailboxes, and lets them access their mailboxes from cell phones and other wireless devices. Voice commands can be given to control and listen to e-mail over the phone
Unified Messaging gained lots of popularity with the release of Lync Server 2010. This was a major move in the VoIP segment. Audio Video conferencing and interoperability with many third party PABX, Voice Gateway, Conferencing systems.
This blog post covers various different components that constitute the Unified Messaging. Such as
Step 1 – Call Initiation A user initiates a call using their Lync client. The first question to answer here is whether we’re dealing with a SIP URI (BenDonaldson@gecko-studio.co.uk for example), or a number string (a phone number or extension). SIP URI calls will be handled immediately and processed based on that URI. You can see in the diagram that they are passed directly to inbound routing, and that there is no need for Lync to apply number normalization, reverse lookups, or PSTN usage checks against the call – nice and simple. If we’re dealing with a number string however, then we move onto step two.
Step 2 – Emergency Number Query So we’re not dealing with a URI, and instead have a phone number. Our next check is to see if this number qualifies as an emergency number. If it does, then it will be routed immediately based on the location policy and associated PSTN usage record and routes; we’re getting it out of Lync as fast as we can once we’ve identified it as an emergency call. If it’s not an emergency number, then then we move to step three.
Step 3 - Unique Number Query Here we will check to see if the number is globally unique, presenting itself in E.164 format and starting with a + sign (+441392123456 for example). If the string is globally unique, then the number can be passed directly to the reverse number lookup process and we can jump ahead to step five. If the presented number is not globally unique, then we need to invoke the next step in an effort to make it so. An extension number of 1234 for example is not unique in the world zone, and cannot possibly be routed on the PSTN.
Step 4 – Dial Plan Application & Call Park Orbit Check Next Lync will apply the normalization rules contained within the dial plan associated with the initiating user, and the number normalized based on those rules to produce an E.164 formatted number. At this same point a check is performed to see if the number is part of a call park orbit range – this is important as orbit ranges should never be presented in E.164 and are a valid reason for a number being passed in such a way. We need at least one normalization rule to match our number in order for it to be translated, or for that number to be part of a call park orbit, failing that we have reached the first point at which our call could be dropped and considered unrouteable (resulting in a 404 error).
Step 5 – Reverse Number Lookup (RNL) Providing the call hasn’t been dropped based on step four, the number is now passed to the reverse number lookup process. Note that it may also have been directly passed here from step 3 if the number was already in a globally unique format (E.164). Reverse number lookup can be viewed as a simple query; Is this number assigned to anything in Lync? If it is, then Lync will be able to translate the number to a SIP URI and route the call directly to inbound routing based on said URI where the process will then end. This might occur if you dial a colleagues DDI (or DID for our cross Atlantic cousins) number rather than Lync calling them, with Lync preventing you from incurring a cost by re-routing the call internally rather than it being passed to the PSTN only to come back in. If reverse number lookup determines that the number does not reside within Lync, then we move to the next step.
Step 6 – Vacant Number & Call Park Orbit Ranges With no match from the previous reverse number lookup process, the number is now checked against vacant number and call park orbit ranges. If the number is part of either range, then it is passed directly to the announcement or call park application and can be considered successfully routed. Failing that we move on.
Step 7 – Voice Policy, PSTN Usage and Routes The final step in the routing process is to apply the initiating users voice policy and associated PSTN usage records. This will ultimately decide if they have the right to dial the number, and determine the route that will be selected based on the records’ route association. If there is no matching record / route for the number, then the call is dropped and considered unroutable (resulting in a 403 error). Alternately, the number is matched and routed out of Lync at which point we can consider the routing process complete.
The Unified Messaging role let’s users receive voice mail, e-mail, and faxes in their mailboxes, and lets them access their mailboxes from cell phones and other wireless devices. Voice commands can be given to control and listen to e-mail over the phone
Unified Messaging gained lots of popularity with the release of Lync Server 2010. This was a major move in the VoIP segment. Audio Video conferencing and interoperability with many third party PABX, Voice Gateway, Conferencing systems.
This blog post covers various different components that constitute the Unified Messaging. Such as
Microsoft
Exchange Server 2007/2010/2013/2016/2019
Microsoft
Lync Server 2010, 2013, skype for Business Server 2015/2019
O365
Hybrid configuration & Azure IaaS
Microsoft follows RFC 3261 for Lync Audio and Video, below is the explanation of voice routing
Microsoft follows RFC 3261 for Lync Audio and Video, below is the explanation of voice routing
If the no. is vacant the announcement will be played if not then it checks in the call park orbit range if the call is placed. (for all placed calls you get an orbit number) it retrives the call if the match is found.
Understanding the concepts, mechanics, and processes that underpin the Lync feature set is critical for anyone who wants to step beyond day to day administration of their environment. So recently I’ve been looking a little deeper into Enterprise Voice and examining what’s really going on behind the scenes with our Lync calls. One of the most vital concepts to understand in this area is that of Lync Voice Routing; how does Lync decide or know what to do with any given call, and what queries is it asking of itself to ensure that these decisions are the correct ones - lets answer that in this short post.
I should mention at this point that understanding the routing process assumes that you have a knowledge of basic enterprise voice concepts such as dial plans, normalisation rules, call park orbits, voice policies and PSTN usage records etc.
The voice routing process itself can be summarized into seven key decision points:
• Call Initiation • Emergency Number Query • Unique Number Query • Dial Plan & Call Park Orbit Check • Reverse Number Lookup (RNL) • Vacant Number & Call Park Ranges • Application of Voice Policy, PSTN Usages and Routing
If you take a look at any existing material that’s available on Lync voice routing (from the likes of Bryan Nyce, Geoff Clark, Brian Ricks and Rui Maximo to name but a few) you’ll notice a common trend across the content, that being the reference and weight placed on the below diagram when discussing the routing process.
This diagram (which I’ve spruced up a little) makes it infinitely easier to understand the entire process. The aforementioned seven key decision points directly correlate to diagram itself, so lets go ahead and walk through the call routing process from the start.
Step 1 – Call Initiation A user initiates a call using their Lync client. The first question to answer here is whether we’re dealing with a SIP URI (BenDonaldson@gecko-studio.co.uk for example), or a number string (a phone number or extension). SIP URI calls will be handled immediately and processed based on that URI. You can see in the diagram that they are passed directly to inbound routing, and that there is no need for Lync to apply number normalization, reverse lookups, or PSTN usage checks against the call – nice and simple. If we’re dealing with a number string however, then we move onto step two.
Step 2 – Emergency Number Query So we’re not dealing with a URI, and instead have a phone number. Our next check is to see if this number qualifies as an emergency number. If it does, then it will be routed immediately based on the location policy and associated PSTN usage record and routes; we’re getting it out of Lync as fast as we can once we’ve identified it as an emergency call. If it’s not an emergency number, then then we move to step three.
Step 3 - Unique Number Query Here we will check to see if the number is globally unique, presenting itself in E.164 format and starting with a + sign (+441392123456 for example). If the string is globally unique, then the number can be passed directly to the reverse number lookup process and we can jump ahead to step five. If the presented number is not globally unique, then we need to invoke the next step in an effort to make it so. An extension number of 1234 for example is not unique in the world zone, and cannot possibly be routed on the PSTN.
Step 4 – Dial Plan Application & Call Park Orbit Check Next Lync will apply the normalization rules contained within the dial plan associated with the initiating user, and the number normalized based on those rules to produce an E.164 formatted number. At this same point a check is performed to see if the number is part of a call park orbit range – this is important as orbit ranges should never be presented in E.164 and are a valid reason for a number being passed in such a way. We need at least one normalization rule to match our number in order for it to be translated, or for that number to be part of a call park orbit, failing that we have reached the first point at which our call could be dropped and considered unrouteable (resulting in a 404 error).
Step 5 – Reverse Number Lookup (RNL) Providing the call hasn’t been dropped based on step four, the number is now passed to the reverse number lookup process. Note that it may also have been directly passed here from step 3 if the number was already in a globally unique format (E.164). Reverse number lookup can be viewed as a simple query; Is this number assigned to anything in Lync? If it is, then Lync will be able to translate the number to a SIP URI and route the call directly to inbound routing based on said URI where the process will then end. This might occur if you dial a colleagues DDI (or DID for our cross Atlantic cousins) number rather than Lync calling them, with Lync preventing you from incurring a cost by re-routing the call internally rather than it being passed to the PSTN only to come back in. If reverse number lookup determines that the number does not reside within Lync, then we move to the next step.
Step 6 – Vacant Number & Call Park Orbit Ranges With no match from the previous reverse number lookup process, the number is now checked against vacant number and call park orbit ranges. If the number is part of either range, then it is passed directly to the announcement or call park application and can be considered successfully routed. Failing that we move on.
Step 7 – Voice Policy, PSTN Usage and Routes The final step in the routing process is to apply the initiating users voice policy and associated PSTN usage records. This will ultimately decide if they have the right to dial the number, and determine the route that will be selected based on the records’ route association. If there is no matching record / route for the number, then the call is dropped and considered unroutable (resulting in a 403 error). Alternately, the number is matched and routed out of Lync at which point we can consider the routing process complete.
============================================================================
No comments:
Post a Comment