Network Multipoint Design for Static Meetings

Contents

Setting Up Network Multipoint for Static Meetings

You do not need to perform any network multipoint-specific configuration of the CTMS devices. However, we assume that you have set up these elements, which are required for network multipoint meetings:

Understanding the Role of Partitions, Calling Search Spaces, and Route Patterns in Network Multipoint Meetings

The basic Cisco TelePresence topology shown in Figure 1-1 includes endpoints in Kansas City, San Jose and New York City that frequently participate in meetings. Originally, only CTMS 1 was deployed in the San Jose area. To reduce the number of expensive links established during meetings and the workload for CTMS 1, CTMS 2 was deployed in the New York area and CTMS 3 was deployed in the Kansas City area.

To support network multipoint meetings in this topology, the following items must be set up in Unified CM:

•Partitions—We use partitions to divide the Cisco TelePresence topology into logical subsets based on location. Each partition contains route patterns and routes, which determine how to route calls from endpoints.

•Calling search spaces (CSSs)—A CSS is an ordered list of partitions that Unified CM systematically analyzes to determine how to route a call.

•Route patterns—A route pattern is a string of digits and optional wildcards that enable Unified CM to route calls from endpoints to a specified CTMS.

•SIP trunks—A SIP trunk is used for communication between Unified CM and a CTMS.

The purpose of the Unified CM setup is to route calls from endpoints to the closest CTMS in the topology. In the sample topology shown in Figure 1-1, CTMS 1 is the closest CTMS for endpoints D, E, and F, CTMS 2 is the closest CTMS for endpoints, G, H, and I and CTMS 3 is the closest CTMS for endpoints A, B and C.

Note that the endpoints shown in Figure 1-1 are not included in SJNetMultiPartition, NYNetMultiPartition and KCNetMultiPartition. We recommend that endpoints are included in a general partition that is not network multipoint-specific or are not included in a partition. This recommended setup preserves the ability of each endpoint to directly dial all other endpoints in the topology regardless of geographical location.

Setting Up Unified CM Items for Static Network Multipoint Meetings

To support static network multipoint meetings, partitions, CSSs, route patterns, and SIP trunks must be set up in Unified CM.

We make these assumptions about the Unified CM administrator, who is responsible for this setup:

•They understand and have previously set up partitions, CSSs, route patterns, and SIP trunks.

•They have worked with the CTMS administrator and understand the setup required for network multipoint meetings.

Table 1-3 shows the completed network multipoint setup for the three areas.

Note Before performing the tasks in Table 1-2, we assume that the CTMS administrator has already set up a route pattern on each CTMS that supports static meetings that can transition to network multipoint meetings, and if they have not already, will set up static meeting(s) as needed on each CTMS.

Table 1-2 Unified CM Setup Required For Network Multipoint Meetings

Task No.

Task

Notes

1

Create partition(s) for your Cisco TelePresence topology.

One partition per CTMS.

We recommend setting up a partition for each geographical area that will participate in network multipoint meetings.

In the Trunk Configuration page, the following fields must be configured for network multipoint support:

•In the Inbound Calls section, the Calling Search Space field must include a CSS that routes a non-local call to one of the other CTMS devices that supports network multipoint meetings in the topology.

•In the SIP Information section, the Destination Address field must include the IP address of the CTMS.

A trunk can have multiple route patterns assigned to it. For example, if you are setting up CTMS 1, and the topology also includes CTMS 2 and CTMS 3, to which you want to route non-local calls, the CSS specified for CTMS 1 must be able to reach the route patterns of CTMS 2 and CTMS 3.

For each route pattern, these fields must be configured for network multipoint support:

•Route Pattern—Specify a range of access numbers for static meetings on the CTMS. For example, 100[09][09].

•Route Partition—Specify a partition created in Task 1.

•Gateway/Route List—Specify a SIP trunk for a CTMS to which non-local calls can be routed.

•Route Option—Select "Route this pattern".

For example, if you are working on CTMS 1 on which the route pattern 100[09][09] was previously configured and you have set up three partitions, create three 100[09][09] route patterns, each of which specifies one of the partitions.

Caution If you are setting up network multipoint for both static and scheduled meetings, do not include the CTMS Directory (Route Pattern Start) Number for each CTMS. This number is reserved for scheduled network multipoint meetings.

5

For each endpoint that should be able to join a network multipoint meeting, set the partition and/or CSS to which you want to endpoint to be a part.

•In Unified CM, filter the phones by directory number and systematically perform this setup on the desired endpoints.

•You must perform this setup on both the phone and codec.

•You can specify the partition and/or CSS at the device or line level.

Using Route Patterns with Wildcards for Non-Network Multipoint and Network Multipoint Meetings

When setting up a route pattern, you can specify numbers along with one or more wildcards, for example, 100[09][09], which establishes a range of patterns from 10000 through 10099. If any of the patterns in this range are used as a static call-in number, the resulting meeting can become a network multipoint meeting.

If you want to set up a route pattern with wildcards and use the range of patterns for both non-network multipoint and network multipoint meetings, we recommend using these guidelines to avoid issues:

•Set up the route pattern with wildcard characters, for example 100[09][09], in Unified CM.

•Set up the Route Pattern Start and Route Pattern End parameters, for example, 10000 and 10099, respectively, in the Configure > System Settings page/Route Pattern tab in the CTMS Administrative UI.

•Split the range established by the route pattern, and use part of the range exclusively for non-network multipoint meetings and the other part exclusively for network multipoint meetings. For example, you could use 10000 through 10049 for non-network multipoint meetings, and 10050 through 10099 for network multipoint meetings.

•When creating static meetings in the Manage > Static Meetings page in the CTMS Administrative UI, for the Subject parameter, you can specify "Non-network multipoint meeting" or "Network multipoint meeting" as appropriate. For example, if creating a static meeting with the access number of 10051, you could specify "Network multipoint meeting."

Example of How Static Network Multipoint Works

Given the sample Unified CM setup in Table 1-2 and the sample Cisco TelePresence topology in Figure 1-1, here is a functional overview example of how network multipoint works in this topology:

For a Static Meeting Created on CTMS 1 with the Access Number 10001

Endpoint Connecting to the RP:

1. Endpoint D dials 10001

2. Unified CM receives the call and because endpoint D is associated with SJMultiCSS, Unified CM looks up the corresponding partition and route pattern and routes the call to CTMS 1

3. CTMS 1 accepts the call.

Note If endpoints E and F, part of the same CSS, subsequently dial 10001, they join endpoint D in the meeting. CTMS 1 is the RP because 10001 is the static meeting that was created on CTMS 1.

For a visual representation of the call flow of an endpoint connecting to the RP, see Figure 1-15.

Endpoint Connecting to a Leaf:

1. Endpoint G dials 10001

2. Unified CM receives the call and because endpoint G is associated with NYMultiCSS, Unified CM looks up the corresponding partition and route pattern and routes the call to CTMS 2.

3. CTMS 2 accepts the call but determines that 10001 is not part of its configured route pattern (20000-20099) so it initiates another call using the same number to Unified CM.

4. Unified CM receives the call, looks up the dialed number (10001) and the configured Calling Search Space for CTMS2 and determines to route the call to CTMS 1 due to the SJNetMultipointPartition.

5. CTMS 1 accepts the call from CTMS 2 and the network multipoint link between CTMS 2 and CTMS 1 is established.

Note Subsequently, if endpoints H and I, part of the same CSS, dial 10001, they will be connected to CTMS 2 to participate in the network multipoint meeting with two CTMSs: CTMS 1 and CTMS 2.

For a visual representation of the call flow of an endpoint connecting to leaf, see Figure 1-16.

Endpoint Connecting to an Additional Leaf:

1. Endpoint A dials 10001

2. Unified CM receives the call and because endpoint A is associated with KCMultiCSS, Unified CM looks up the corresponding partition and route pattern and routes the call to CTMS 3.

3. CTMS 3 accepts the call but determines that 10001 is not part of its configured route pattern (30000 - 30099) so it initiates another call using the same number to Unified CM.

4. Unified CM receives the call, looks up the dialed number (10001) and the configured Calling Search Space for CTMS 3 and determines to route the call to CTMS 1 due to the SJNetMultipointPartition.

5. CTMS 1 accepts the call from CTMS 3 and the network multipoint link between CTMS 3 and CTMS 1 is established.

Subsequently, if endpoints B and C, part of the same CSS, dial 10001, they will be connected to CTMS 3 to participate in the network multipoint meeting with three CTMSs: CTMS 1, CTMS 2 and CTMS 3.

Although the Cisco TelePresence topology and the Unified CM setup described in this section are basic, the setup scales to more complex topologies that include more endpoints, CTMS devices, geographical areas, and Unified CM servers. As the topology changes and the need for network multipoint meetings increase, more partitions, CSSs, route patterns, and SIP trunks can be added to Unified CM and more static meetings created on the CTMS devices as needed.

Also, the sample Unified CM setup discussed in this section can be integrated into an existing topology where partitions, CSSs, and route patterns already exist, or deployed in a new topology.

Figure 1-15 Endpoint Connecting to the RP

Figure 1-16 Endpoint Connecting to Leaf

Note The Unified CM setup described in Table 1-7 allows any CTMS to function as either the RP or the leaf in a static network multipoint meeting. The CTMS on which the static meeting is created becomes the RP when the static meeting is started and the other CTMSs become leaves.

Additional Setup for Cisco TelePresence TC 5.0 or later Endpoints Registered with VCS

To enable communication between the Cisco TelePresence TC 5.0 endpoints and CTMS 1, as shown in Figure 1-17, some additional setup in Unified CM and VCS is required. Table 1-4 outlines the additional Unified CM setup that must be performed, while Table 1-5 outlines the VCS setup. The order in which the Unified CM and VCS setup are performed does not matter.

Create a SIP trunk for communication between Unified CM and the VCS with which Cisco TelePresence TC 5.0 endpoints are registered.

In the Trunk Configuration page, the following fields must be configured for TC 5.0 endpoint support:

•In the Inbound Calls section, the Calling Search Space field must include a CSS that routes a call from a TC 5.0 endpoint registered with VCS to a CTMS.

•In the SIP Information section, the Destination Address field must include the IP address of each VCS server in a cluster.

Note Regardless of the setting of the SIP Trunk Security Profile parameter, network multipoint meeting will be non-secure because secure network multipoint meetings are not supported.

2

Create a route pattern to support the manual addition of the TC 5.0 endpoints from a CTMS. (From the CTMS Administrative UI, you can manually add endpoints from the Active Meeting dialog box/Meeting Settings tab.)

In the Route Pattern Configuration page, the following fields must be configured for TC 5.0 endpoint support:

•For the Gateway/Route List parameter, select the SIP trunk in created in task 1.

•For the Call Classification parameter, select OnNet.

Table 1-5 VCS Setup for Cisco TelePresence TC 5.0 Endpoints

Task No.

Task

Notes

1

Create a zone for communication between the VCS with which Cisco TelePresence TC 5.0 endpoints are registered and Unified CM.

In the Create Zone page, the following fields must be configured for TC 5.0 endpoint support:

•For the Type parameter, select Neighbor.

•In the SIP panel, the Mode parameter should be set to On.

•In the Location panel, specify a single address for a single Unified CM or an address for each Unified CM in a cluster.

•In the Advanced panel, the Zone profile should be set to Cisco Unified Communications Manager.

2

Create a search rule.

In the Create Search Rule page, the following field must be configured for TC 5.0 endpoint support:

•For the Target parameter, select the zone that was created in task 1.

Verifying that Network Multipoint for Static Meetings is Functioning Properly

You can verify that network multipoint is functioning properly by starting a test static meeting into which endpoints supported by two CTMS devices join the meeting. After the meeting starts, you can access the Active Meeting Settings dialog box from each CTMS supporting the meeting.

Use the following procedure:

Step 1 After the meeting starts, log into the CTMS Administrative UI of one of the CTMS devices.

Step 2 Click Manage > Active Meetings in the left navigation.

Step 3 In the Active Meetings page, check the box next to the meeting you want to verify, and click Edit.

Step 5 To verify the same fields for the remote CTMS, click the link that appears in the Remote CTMS field. In the CTMS Administrative login page for the remote CTMS, enter the username and password, then repeat Step 2 through Step 4.

For a description of the fields in the Active Meetings page and Active Meeting Settings dialog box, see the "Managing CTMS Meetings" chapter in the Cisco TelePresence Multipoint Switch Release 1.9 Administration Guide, which you can access at this location:

The Event Recording feature enables you to record scripted corporate events, such as company meetings. A CTRS running release 1.8 (or later) records the event, while a CTMS running release 1.8 (or later) manages the recording session. For more information about Event Recording, see the Cisco TelePresence Multipoint Switch Release 1.8 Administration Guide, which you can access at this location:

When used during a network multipoint meeting, Event Recording must be set up on the CTMS that functions as the rendezvous point. In addition, after the event controller logs in to initiate a recording session with the CTRS, the call must be routed directly to the rendezvous point instead of through the leaf CTMS. To ensure that the call is routed directly to the rendezvous point, the following Event Recording-specific setup must be created in Unified CM.

Create an Event Recording-specific partition for each CTMS that can function as a rendezvous point during a network multipoint meeting.

-

2

Create an Event Recording-specific CSS.

In the CSS, include each partition created in Task 1 in the Selected Partitions list.

3

For each CTMS, create an Event Recording-specific route pattern.

For each route pattern, these fields must be configured for Event Recording support:

•Route Pattern—Specify a range of access numbers for Event Recording sessions on the CTMS. For example, 100[09][09].

•Route Partition—Specify the partition created for the CTMS in Task 1.

•Gateway/Route List—Specify the SIP trunk for the CTMS to which non-local calls can be routed.

•Route Option—Select "Route this pattern".

Note If not already done, we assume that the CTMS administrator will set up a corresponding route pattern on each CTMS.

4

In the existing SIP trunk for each CTRS, create a mapping to the Event Recording-specific CSS.

In the Trunk Configuration page, Inbound Calls section, the Calling Search Space field must include the CSS created in Task 2 so that non-local calls from the CTRS are routed to the CTMS that is functioning as the rendezvous point in the network multipoint meeting.

Understanding How Static Network Multipoint Meetings Work

Starting and Joining Static Network Multipoint Meetings

As with joining any static meeting, meeting participants must dial the static call-in number from their endpoints.

The transition from a static meeting to a static network multipoint meeting occurs when an endpoint in a different area than the CTMS on which the static meeting was created, also known as the host CTMS or rendezvous point, dials into the meeting.

For example, if the meeting was created on CTMS 1, and endpoint D dials into the meeting, the call is routed to the closest CTMS, in this case, CTMS 2. After CTMS 2 determines that the meeting is not a local meeting, it directs the call back to Unified CM. As a result of the network multipoint-specific setup, Unified CM routes the call to CTMS 1, the network multipoint link is established, and the endpoints supported by CTMS 2 join the meeting.

Likewise, if endpoint D departs from the meeting, and CTMS 2 is not supporting any other endpoints, the network multipoint link is brought down, and the meeting transitions to a non-network multipoint meeting.

The transition to and from a network multipoint meeting is dynamic, and meeting participants are unaware of the transition.

Resources

Static meetings are best-effort and rely on available unscheduled resources on the CTMS. This functionality is the same whether the meeting is a non-network multipoint or network multipoint meeting. However, in a network multipoint meeting, resources must be available on both participating CTMS devices.

If the host CTMS or rendezvous point does not have sufficient resources, endpoints that try to join the meeting after the resources are depleted are not allowed to join. If the other CTMS that supports the meeting, also known as the leaf CTMS, does not have sufficient resources, endpoints from the area it supports are not allowed to join.

Another consequence of the participating CTMS devices running out of resources is that no additional static or ad hoc meetings can be initiated on those devices.