Enterprise Voice Features
Site Resiliency
With the addition of a ‘Site’ component in Communications Server user services can now be balanced and protected against device and site failures by associating users with more than one location. Data Center and main office locations with full CS server deployments are defined as a Central Site while small and medium remote offices where a Survivable Branch Appliance (SBA) is installed is deemed a Branch Site. Each Enterprise Voice enabled user is then associated with a primary site and secondary, backup site automatically by virtue or simply registering with the primary site under normal conditions.
One of the new server components found in the Front-End server role is the Registrar. I will cover that component and the core changes involved in a later article, but for now it’s important to understand the Registrar service handles Communicator end-point login and connections to CS. This component lives on both a Front-End server role (both Standard Edition and Enterprise Edition) and on an SBA. When CS end-points perform automatic SRV lookup they can now leverage multiple response, ordered by priority, which now gives clients the ability to look for services on another host in the event the primary host is unreachable. This feature offers the ability to provide highly-available services to users leveraging a secondary pool in the same site or disaster recovery protection by using yet another pool in a different site.
For clients located in a branch office with the SBA configured as their primary registrar those users can be serviced by another pool in a central site in the event that the SBA fails. In the case of a WAN outage or loss of connection to the primary pool in the central site the branch office users are still signed-in to their Communicator client, but only Enterprise Voice features are available along with peer-to-peer communications between users in that ‘orphaned’ office location.
It is important to understand that the SBA is simply a registrar and not a full pool, only limited services are provided by the SBA, mainly with the intention of handling user registration and voice dialing features via the PSTN in that branch location.
Call Admission Control
Call Admission Control (CAC) is basically a fancy name for bandwidth management of voice call routing, which determines whether or not an audio or video session can (and should) be established based on taking real-time measurements of the network conditions. It is applied to media flow traversing LAN/WAN network segments but does not extend out to communications across the Internet or PSTN. The egress point of Communications Server (the Edge Server or the media gateway) is where the boundaries lie for CAC functionality.
CAC policies can be defined by administrators to set maximum values for total bandwidth for audio and video (independently) as well as the maximum possible bandwidth allocated to a single audio or video call (again, separate settings). In the scenario of a highly congested WAN link between two remote sites video calls may be disabled by CAC in order to prevent any poor communications experiences and provide users with the option to select alternative methods before ever having a ‘bad call’. And in the same scenario audio calls would automatically be routed via the PSTN if both locations have their own PBX or some other form of PSTN connectivity. Audio quality changes may be noticed at that point as RTA would be changed to G.711 for PSTN call routing, but the switchover is otherwise transparent to the users.
Mediation Server Bypass
This feature (also referred to simply as media bypass) offers bandwidth savings and can help improve call quality by reducing latency, removing transcoding, and minimizing the potential for additional packet routing problems to impact the communications.
Multiple Gateway Support
Unlike previous in versions of OCS where a mediation server could only be configured to communicate with a single gateway the Mediation Server role can now configured to handle multiple routes so many media gateways can be configured to route calls to the same Mediation Server. This can greatly reduce the amount of on-site hardware required in some distributed deployment scenarios.
Caller ID Manipulation
The Caller ID information can be customized on outbound calls placed by all users or any number of specific users or groups.
E911
Support for enhanced emergency services dialing is now provided by a combination of location services solutions which can be defined both by administrators and Communicator users themselves to provide proper location information in the event that a 911 call is placed from Communications Server.
Private Telephone Lines
A user (typically an executive) can now be configured with a second private telephone number which would not be listed anywhere in the directory for other users to browse and identify it. A special ring is associated with incoming calls directed to the private line number, and none of the advanced features (call forwarding, team ring, RGS, etc) are available. Private calls also do not adhere to Do Not Disturb presence rules and will always ring through to the user if they are signed-in. Outbound calls from teh user will still appear from their primary number, the private number will only be used to route inbound calls and thus further protect the number from becoming known to undesired users.
Common Area Phones
Because the Polycom CX700 (Tanjay) device has always required a user to sign-in it has never been a good solution for open areas and shared workspaces to provide telephony services. With CS ‘14’ come a host of new telephony end-points from various partners including Polycom and Aastra. Some photos of the latest Polycom devices can be seen on fellow MVP Mike Stacy’s blog.
These devices can register directly to Communications Server using a dedicated AD object and provide for, at minimum, voice services at all times. Additionally CS Enterprise Voice enabled users can log into some devices using a PIN, brining their number and presence over to the device until they either sign-out or a time-out period is reached in which the phone reverts back to the standard number.
Call Management
The Response Group Service contains a host of new features. Anonymous Calling allows agents to accept and place calls without showing their identity. Attendant Routing Method offers a configuration setting in which all RGS agents will receive an incoming call simultaneously, regardless of their current presence. The RGS management controls have been brought into the same tools as the rest of the CS components, the CS Shell (PowerShell) and CS Control Panel (CSCP). Richer IVR configurations and prompts provide more options to customize Response Group attendants.
The Announcement service has been updated to handle unassigned number routing rules so that if inbound calls to valid, but unassigned DIDs are routed to Communications Server the routing and response to those calls can be handled as desired instead of just dropping the calls or forwarding them all to a single primary number.
A Call Park feature has been added to allow users to put a voice call on hold and then pick it up on another endpoint without having to forward the call.
Outbound Route Translation
And saving the best for last (IMO) is a topic near and dear to my heart, normalization. As it is still best practice to design numbering plans and normalization rules to fully conform to RFC3966 standard (E.164 with the ‘+’ prefix) there will still exist the scenarios where the connected telephony system cannot handle some digits (as in the ‘+’) or the device cannot (or the administrators will not) allow changes to the numbering plans or rules.
In previous versions only the ‘+’ could be stripped off by the Mediation server just prior to leaving OCS, but that was it. With CS ‘14’ multiple rules can be added to further manipulate URIs just prior to routing to the gateway. This mean digits can be added, stripped, or replaced using RegEx patterns. This is very advantageous when dealing with Direct SIP deployments where no media gateway is available to provide additional number manipulation.
This single feature addition alone should be the last nail in the coffin of any Communications Server deployments in which RFC3966 complaint numbers are not utilized.
