目录

简介

先决条件

要求

使用的组件

背景信息

CUCM 8.5之前的呼叫路由机制（不在所有Active Unified CM节点上运行功能）

使用案例1:注册到节点1的IP电话。未配置RouteList。

用例2:注册到节点1的IP电话。注册到节点2的RouteList。

用例3:注册到节点1的IP电话。注册到节点2的RouteList。

结论

负载均衡

CUCM 8.5后呼叫路由机制（在所有正在使用的活动Unified CM节点功能上运行）

SIP中继 — 在所有节点和路由本地规则上运行

路由列表 — 在所有节点和路由本地规则上运行

简介

本文档介绍Cisco Unified Communications Manager用于确定哪些CUCM节点用于通过会话发起协议(SIP)或基于H.323的中继发出呼叫的操作方式。

先决条件

要求

思科建议您事先了解以下主题：

- 思科统一通信管理器(CUCM)基本呼叫路由概念

使用的组件

本文档中的信息基于Cisco Unified Communications Manager(CUCM)8.x及更高版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

SIP中继和H.323网关不向CUCM注册（与MGCP网关不同）。 相反，与连接到中继或网关的设备池关联的CUCM组确定它们将处于活动状态的位置。例如，如果它们在2或3个节点上处于活动状态，CUCM会利用什么机制来决定在哪个服务器上发送呼叫。

本文档旨在说明如何制定呼叫路由决策以及如何通过SIP中继或H.323实现出站呼叫的负载均衡。

CUCM 8.5之前的呼叫路由机制（不在所有Active Unified CM节点上运行功能）

一般逻辑：对于出站呼叫，CUCM完成数字分析后，会将呼叫扩展到RouteList或终端设备。  （RouteList注册到特定节点，具体取决于CUCM组）

RouteList控件标识设备列表并查询设备管理器。

设备管理器提供设备进程ID(PID)(例如：(2,100,25,45)，在本例中，设备在节点2上处于活动状态)

RouteList控制检查设备的状态（目标设备处于活动状态、空闲或忙碌），并将呼叫扩展到中继或网关。

由于SIP中继/H.323网关可以在多个节点上处于活动状态，因此现在问题开始由设备管理器选择哪个节点作为活动PID?

这些使用案例场景进一步说明了这一点：

使用案例1:注册到节点1的IP电话。未配置RouteList。

在此SIP中继中，节点1和4上处于活动状态。

- 一般逻辑保持不变，CUCM对注册电话的节点1执行数字分析。由于未配置RouteList，因此路由模式直接与SIP中继关联。

- 节点1上的CUCM查询节点1上的设备管理器。

- 设备管理器(DM)始终首先检查本地表，如果有本地设备，则返回本地设备，以避免不必要的集群间通信/流量。

在这种情况下，SIP中继在注册电话的节点1上处于活动状态，因此CUCM每次都会从节点1扩展呼叫。 此处不应用随机逻辑，并且由于呼叫从节点1扩展，因此不存在负载均衡。

用例2:注册到节点1的IP电话。注册到节点2的RouteList。

在此SIP中继中，节点2和4上处于活动状态。

- 在数字分析(DA)结果后，CUCM节点1将呼叫扩展到节点2中的路由列表控制。

- 节点2上的RouteList Control查询节点2上的设备管理器。

- DM始终首先检查本地表，如果有本地设备，则返回本地设备（在本例中，SIP中继是节点2的本地设备）。

因此，无论电话注册在何处，由于RouteList注册到节点2，并且Sip中继在同一节点上处于活动状态，所有呼叫都来自节点2。同样，不应用随机逻辑。

用例3:注册到节点1的IP电话。注册到节点2的RouteList。

在此H323网关在节点1和4上处于活动状态。

- 在DA结果后，节点1上的CUCM将呼叫扩展到节点2上的RouteList控制。

- 节点2上的RouteList控件查询节点2上的设备管理器。

- 设备管理器(DM)始终首先检查本地表，并返回本地设备无。

- 设备管理器查找RemoteTable，并看到H.323网关在节点1和4上处于活动状态。

它应用随机逻辑，并随机为RouteList控制提供主动PID。由于呼叫是在节点1和节点4之间随机发送的，因此呼叫在CUCM中实现负载均衡。

结论

CUCM检查SIP中继/H.323网关是否与呼叫设备处于同一节点上的活动状态。如果是，则始终使用本地节点发送呼出。

如果SIP中继/H.323网关在与呼叫设备相同的节点上未处于活动状态，则它会从中继/设备处于活动状态的节点随机源。

注意：主叫设备可以是电话或路由列表。 如果路由模式与RouteList匹配，则主叫方为RouteList。如果路由模式直接与SIP/H.323设备关联，则主叫方是电话。

负载均衡

如果要实现负载均衡，则建议不要将SIP/H.323网关与CUCM节点关联的RouteList或电话共置，即如果它们在同一节点上都处于活动状态，则从本地节点（始终）发出呼叫。

换句话说，需要配置SIP中继/H.323网关，使其在注册了RouteList或电话的节点上不处于活动状态。

从CUCM 8.6版开始，CUCM引入了一项新功能，称为Run on all active Unified CM Nodes for both RouteList/SIP trunks。

这是有效平衡出站呼叫并减少集群内交换的信号数的另一种方法。

CUCM 8.5后呼叫路由机制（在所有正在使用的活动Unified CM节点功能上运行）

在CUCM 8.5及更高版本中，思科在sip中继和路由列表中引入了一项新功能，称为在所有活动的unified CM节点上运行。这基本上消除了SIP中继和分配给它们的CUCM组上的路由列表的依赖关系。这意味着您可以有三台以上的CUCM服务器，这些服务器会发起和终止来自SIP中继和到SIP中继的呼叫。

SIP中继 — 在所有节点和路由本地规则上运行

当在SIP中继上选中Run on all Active Unified CM Nodes选项时，Unified CM会在集群内的每个呼叫处理用户上创建SIP中继守护程序实例，从而允许在任何呼叫处理用户上进行或接收SIP中继呼叫。（在此功能之前，使用Unified CM组，每个中继最多可选择三个节点。）

启用“在所有活动Unified CM节点上运行”后，出站SIP中继呼叫源自接收入站呼叫（例如，从电话或中继）的同一节点（基于本地路由规则）。 在所有活动Unified CM节点上运行功能将覆盖中继的Unified CM组配置。

对于SIP中继，路由本地规则的工作方式如下：

对于出站SIP中继呼叫，当来自注册电话或入站中继的呼叫到达Unified CM节点时，Unified CM会检查所选出站中继的实例是否存在于入站呼叫到达的同一节点上。如果是，Unified CM使用此节点建立出站中继呼叫。

强烈建议在SIP中继上的所有活动Unified CM节点上启用运行，因为此功能允许出站呼叫从集群内的任何呼叫处理节点发起并接收。在所有活动Unified CM节点上运行还可以消除在通过出站SIP中继建立之前在同一集群内的呼叫处理节点之间设置呼叫。

与所有Unified CM SIP中继一样，与中继关联的SIP守护程序仅接受来自终端系统的入站呼叫，终端系统具有在中继的目标地址字段中定义的IP地址。

当多个到同一目的地的SIP中继使用相同的呼叫处理节点时，必须为每个中继定义唯一的传入和目的端口号，以允许唯一标识每个中继。

路由列表 — 在所有节点和路由本地规则上运行

虽然这并不是SIP中继功能，但在所有节点上运行路由列表可以为路由列表和路由组中的中继提供优势。在所有节点上运行路由列表可通过使用本地路由规则来改善出站呼叫分配，以避免不必要的集群内呼叫建立流量。

对于路由列表，路由本地规则的工作方式如下：

对于使用路由列表的出站呼叫（以及关联的路由组和中继），当来自注册电话或入站中继的呼叫到达具有路由列表实例的节点时，Unified CM会检查所选出站中继的实例是否与路由列表位于同一节点上。如果是，Unified CM使用此节点建立出站中继呼叫。

- 如果路由列表和中继都启用了Run on all Active Unified CM Nodes，则出站呼叫分配取决于入站呼叫到达的节点。

- 如果所选出站中继使用Unified CM组而不是在所有节点上运行，则如果所选出站中继的实例存在于入站呼叫到达的同一节点上，Unified CM将应用路由本地规则。

- 如果此节点上不存在中继实例，则Unified CM将呼叫（在集群内）转发到中继处于活动状态的节点。

- 如果路由列表未启用在所有活动Unified CM节点上运行，则路由列表实例将在集群内的一个节点（路由列表的Unified CM组的主节点）上处于活动状态。

- 如果所选出站中继在路由列表的Unified CM组的主节点上也处于活动状态，则应用“路由本地”规则，导致出站呼叫分配次优，因为所有出站中继呼叫都来自此节点。

思科强烈建议在所有路由列表和SIP中继上的所有活动Unified CM节点上运行。