PDF(440.9 KB) View with Adobe Reader on a variety of devices
ePub(502.5 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(631.9 KB) View on Kindle device or Kindle app on multiple devices
Updated:March 10, 2015
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the dial plan considerations on Cisco Unified Communications Manager (CUCM) when Collaboration Meeting Rooms (CMR) are used in a CUCM-centric deployment. It discusses the different options, the implications, and the configuration.
The solution in this example uses TelePresence Management Suite (TMS), TMSPE, TelePresence Conductor, TelePresence Server (TS), and CUCM. The other illustrated components (Expressway-C and Expressway-E) are optional and provide connectivity to endpoints on the Internet and/or Business-To-Business Calls.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Since this document uses a CUCM-centric deployment, the Expressway series is used and the Conductor is integrated with CUCM. A typical deployment is illustrated here:
In this example, the Session Initiation Protocol (SIP) domain in the deployment is company.com and users can be reached via Uniform Resource Identifier (URI) dialing, for example email@example.com.
The CMR are hosted by the TelePresence Servers. In order for users to dial into them, calls must be routed towards the SIP Trunk to the Conductor. There are two options for the format of the URI for the CMR.
Option 1: CMR Format - firstname.lastname@example.org
The first option uses a subdomain of company.com as the domain portion in the URIs of the CMR: meet.company.com.
This makes the dial plan configuration on CUCM straighforward; you can configure a new SIP Route Pattern with Domain Routing for this subdomain as illustrated here:
Note that in this example, no Route Partition is configured on the SIP Route Pattern and is hence reachable to all devices. Class Of Control using Call Search Spaces (CSS) and Partitions can be used in order to restrict certain users/devices to dial these patterns.
Option 2: CMR Format - email@example.com
The second option uses the main domain as the domain portion in the SIP URIs of the CMR: company.com.
SIP Route Patterns do not support regular expressions, so you could configure the SIP Route Pattern as illustrated here:
With this configuration, every URI that matches the domain portion company.com that is not in the CUCM database (locally-registered endpoints) is routed to the Conductor. It is important to note that calls to URIs not registered on CUCM are sent to the Conductor (even for URIs the Conductor is not aware about). In order to overcome this, you can use the InterCluster Lookup Service (ILS) import, which is described later.
The previous solution works when the deployment does not have any endpoints registered to the Video Communication Server (VCS) that shares the same domain or Lync integration that shares the same domain. In case there are endpoints or a Lync integration that share the same domain, some calls with the domain portion company.com must be sent to Expresssway-C/VCS-C, while calls towards the CMR (which also have the domain portion company.com) must be routed to the Conductor. An example deployment where the same domain is shared between endpoints registered to CUCM and a third-party Call Control system is shown here:
In this situation, you must use the ILS import feature in order to import Conductor SIP URIs as Global Catalog into the CUCM ILS table. As the source for this import, you can export the room data in TMS. This option is available under System > Provisioning > Users.
It is important to note, however, that if the CMR has not been created by the user, the room is not listed in this export. This means that you must perform this procedure every time a new room is created or export data from Active Directory (AD) in order to build the list for all users.
On CUCM, you must complete these steps:
Make sure the Cisco ILS and the Cisco Bulk Provisioning Service are activated and run.
Change the Role of the cluster to Hub Cluster under Advanced Features > ILS Configuration.
Give the Cluster ID a proper name under System > Enterprise Parameters.
Create a Global Dial Plan Catalog under Call Routing > Global Dial Plan Replication > Imported Global Dial Plan Catalogs. The Route String is used in conjunction with SIP Route Patterns in order to route calls to the Conductor: you associate the URIs for the CMR with this Global Dial Plan Catalog, CUCM then uses the Route String configured in order to decide how to route the call (instead of the original URI). This way, you can route calls with the same domain portion to a different SIP Trunk:
Configure a SIP Route Pattern that matches the Route String in the configured Global Dial Plan Catalog so that the imported URIs associated with the Global Dial Plan Catalog are routed to the Conductor SIP Trunk:
Upload the text file that contains the SIP URIs of the CMR as Imported Directory URIs and Patterns under Bulk Administration > Upload/Download Files: