IP电话系统和呼叫路由技术(2)

第2讲 H.323 IP电话系统的域间呼叫路由

赵志峰1, 2, 3

　　杨永康2　　仇佩亮1

（1. 浙江大学博士后科研流动站　　杭州310027）

（2. 东方通信博士后科研工作站　　杭州310053）

（3. 解放军理工大学通信工程学院　　南京210007）

　　摘 要 本文首先分析了对H.323域间通信进行单独研究的必要性。然后介绍了ITU-T对该问题研究的最新进展。在介绍了域间模型、地址模版等基本概念和域间通信使用的消息等内容后，给出了H.323域间呼叫路由的详细工作过程。文章还对域间呼叫路由方式进行了举例分析。最后给出了需要进一步研究的问题。

　　关键词 H.323 IP电话系统 呼叫路由 域间模型 对等单元 地址模版

1 引言

　　随着H.323 IP电话系统在全球的广泛应用，要实现这些系统的互联互通，必须要解决管理域间的呼叫路由问题。而H.323的早期版本（版本1和2）没有考虑域间通信。

　　在我国制定IP电话总体技术要求时[1]，考虑了国际IP电话的互通问题，并提出了两种使用RAS消息进行地址解析的方法：顶级网守作为对方网关和顶级网守作为对等网守。在第一种方案中，国内顶级网守使用ARQ（Admission Request）消息以网关的身份请求国外网守进行地址解析。在第二种方案中，国内顶级网守使用LRQ（Location Request）消息请求国外网守进行地址解析。

　　为了解决H.323系统的域间通信问题，研究人员对RAS协议用于域间地址解析进行了深入的研究，发现了以下问题：

　　· RAS协议的ARQ被设计用于端点向网守发起接纳请求，不适合用作网守间和域间的接纳认证手段。域间通信需要更高级的认证和授权手段。

　　· 使用LRQ进行地址解析时，每个呼叫都需要主叫网守、中间网守和被叫网守的参与。当应用到域间时，这种路由方式带来的开销、时延都非常大。

　　· 管理域互通时，应尽量将互通涉及的问题留在网络边界处，不要对域内的工作方式和域内实体的功能做过多的要求和改动。但使用RAS进行域间通信时（如LRQ），不可避免地要域内实体的支持。

　　因此，ITU-T认为RAS协议并不适合作为域间通信的手段，需要对域间互通单独进行研究。经过数年的努力，ITU-T于1999年5月发布了H.225.0 Annex G Version 1[2]，专门为H.323系统域间网守互通制定了标准。从此确立了H.323系统域间通信的框架。随着对H.323系统移动性支持研究的加深，ITU-T将对移动性支持和域内、域间通信的消息和参数纳入了统一的标准H.501[3]，并对H.225.0 Annex G进行了修订，使其可以用于域内和域间通信，并于2002年11月发布了H.225.0 Annex G Version 2 [4]。

2 基本概念

2.1 域间模型

　　H.225.0 Annex G使用的域间模型，引入了边界单元的概念。边界单元是H.323管理域与其他管理域的互通实体，它为域外的功能实体呼叫本管理域内的功能实体进行多媒体通信提供接入支持。边界单元控制着一个管理域的对外视图。边界单元可以单独设置，也可以跟网守、网关一起设置。图中的后端服务指那些提供认证、记费等功能的实体。

　　H.225.0 Annex G Version 1只适用于参考点A，即边界单元之间的通信。而Version 2中指出，它可以用于参考点A、B、C。所有使用H.225.0 Annex G Version 2协议进行交互的功能实体又被称作“对等单元”（包括边界单元）。H.225.0 Annex G规定了对等单元互相交换自己可以解析的地址信息的流程。边界单元则交换本管理域可解析的地址信息。由于现有的标准仍主要关注域间通信，因此下文我们重点对边界单元进行讨论。

2.2 地址模板和描述符

　　地址模板和描述符是H.225.0 Annex G使用的两个非常重要的术语。地址模板和路由表项的作用类似，它包括：（目的地）别名地址、（完成至该目的地呼叫的）费用、使用的协议过程等信息。别名地址可以使用通配符“*”来表示批量地址。以下是地址模板的例子：

　　地址模板可以静态配置，也可以通过H.225.0 Annex G中定义的过程来交换和获取。边界单元通过相互交互地址模板来向其他边界单元通告呼叫路由信息，以对域间呼叫提供路由支持。当边界单元交互了各自的地址模板后，若其收到来自管理域内部的地址解析请求，它就可以根据自己获取的地址模板信息对被叫地址进行解析。这样不仅加快了地址解析的速度，还保护了管理域内部结构信息的私密性。

　　描述符是指一组地址模板的集合，通过描述符ID来标识。引入描述符的目的是为了方便地址模板的管理。

3 主要消息及作用

　　H.225.0 Annex G使用了H.501定义的大部分消息，本节只对与呼叫路由相关的消息进行简要介绍。

3.1 业务联系类消息

　　消息有四个：ServiceRequest、ServiceConfirmation、ServiceRejection和ServiceRelease。

　　ServiceRequest的作用是用于对等单元之间建立业务联系。业务联系主要包括双方的标识信息和双方通信时使用的安全机制。只有建立业务联系的对等单元才可进行后续的交互。

　　ServiceConfirmation和ServiceRejection分别用于确认和拒绝建立业务联系。

　　ServiceRelease的作用是供已建立业务联系的对等单元解除业务联系使用。

3.2 描述符分发类消息

　　这类消息有两个子类：描述符ID相关类和描述符相关类。

　　描述符ID相关类消息有三个：DescriptorIDRequest、DescriptorIDConfirmation、DescriptorIDRejection。

　　DescriptorIDRequest用于一个实体向其对等单元查询对方管理域内的描述符ID列表。

　　DescriptorIDConfirmation和DescriptorIDRejection分别对请求进行确认和拒绝。

　　描述符类消息有五个：DescriptorRequest、DescriptorConfirmation、DescriptorRejection、Descriptor Update、DescriptorUpdateAck。
DescriptorRequest用于一个实体向其对等单元请求一个特定的描述符。描述符是从此前发送的描述符ID请求过程得到的。对等单元可以确认（返回描述符）或拒绝该请求。

　　DescriptorUpdate用于一个实体向其对等单元通告自己的描述符ID或描述符信息已发生改变（包含一个更新列表），对等单元应对相关的描述符信息进行更新。该请求可以以单播或多播的形式发送。对等单元可以使用DescriptorUpdateAck对该消息进行确认。

3.3 地址解析类消息
此类消有三个：AccessRequest、AccessConfir mation、AccessRejection。

　　AccessRequest用于一个实体请求其对等单元对一个特定的别名地址进行解析。如地址解析成功，对等单元将在AccessConfirmation中包含解析出来的地址模板列表进行确认，否则以AccessRejection拒绝该请求。

　　由此可见，管理域内部的网守（对等单元）也可以使用AccessRequest请求解析地址。这相当区间的地址解析，因此H.225.0 Annex G可以取代LRQ用于域内网守间的通信。
3.4 其他消息

　　其他消息包括使用情况报告类消息、呼叫验证类消息、请求处理中消息、非标准类消息等。因他们与呼叫路由关系不大，其详细内容和作用就不在此介绍了。

4 工作过程

4.1 建立业务联系

　　功能实体（对等单元）启动后，首先要与其对等单元建立业务联系。获取对等单元H.225.0 Annex G传输层地址信息的方式有多种。可以为一个功能实体静态配置对等单元信息，也可以通过域名系统来动态地获取对等单元的信息。

　　功能实体使用ServiceRequest消息请求与对等单元建立业务联系，商议两者在后续通信过程中使用的安全机制。成功建立业务联系后，两个对等单元就可进行后续的消息交互。

　　任何一个对等单元都可使用ServiceRelease来解除与对方的业务联系。解除的原因有多种。提出方还可向对方提供其他候选的对等单元列表，供对方以后建立业务联系用。

4.2 地址模板信息的来源

　　一个对等单元有三种获取地址模板信息的途径。

　　第一种是静态配置。一个对等单元应维护它管辖的所有管理区的模板信息。这可以通过使用局数据来静态配置。也可以通过其他动态途径来维护（比如登记和去登记）。一个管理域的边界单元在向外提供地址模板时，可以根据策略提供不同详细程度的地址模板。

　　第二种是通过接收描述符来获取。对等单元可以使用DescriptorRequest消息向其他对等单元请求地址模板。收到响应后，将收到的地址模板保存下来，直到这些地址模板信息过期。一个对等单元在自己的地址模板信息改变时，可以使用Descriptor-
Update消息来通知其他对等单元。收到更新消息的对等单元将根据消息内容修改自己存储的地址模板。

　　第三种是通过地址解析响应来获取。对等单元可能向其他对等单元发送AccessRequest来请求解析某个特定的地址。收到解析响应后，对等单元可将收到的解析结果保存下来，直到该地址模板信息过期。

4.3 地址模板信息的交换

　　地址模板信息的交换过程对等单元首先向其他对等单元发送描述符ID请求，以获取对方拥有的描述符ID列表。然后对等单元发送描述符请求消息，以获取感兴趣的描述符。此外，当边界单元的描述符信息发生变化时，它使用描述符更新消息通知其他边界单元，使它们保存的相关信息能够得到即时更新。

4.4 地址解析过程

　　当对等单元收到来自本管理域内部的地址解析请求时，它查找自己保存的地址模板。如果有多个地址模板满足条件，就根据一定的策略对这些地址模板进行排序（比如按最长匹配排序，或“发送Setup”要优于“发送AccessRequest”）。排完序后，将所有满足条件的地址模板返回给请求者。如果满足条件的地址模板中没有一个包含“发送Setup”，说明对等单元没有能够“完全”解析该地址。对等单元就向适当的对等单元发送“AccessRequest”地址解析请求。解析到地址后对等单元将包含“发送Setup”的地址模板返回请求者，并将解析结果保存，以供下次解析使用。

　　当边界单元收到来自另一个管理域的边界网关的“AccessRequest”地址解析请求时，它查找自己保存的地址模板。如果多个地址模板满足条件，先按照最长匹配原则排序，然后按照“发送 xx”的消息类型排序（Setup要优于AccessRequest）。如果“AccessRequest”消息的跳数已经被减为零，但边界单元没有找到合适的地址模板，它将返回“AccessReject”来表示解析失败。如果“AccessRequest”消息的跳数没有被减为零，并且匹配的地址模板表明“发送AccessRequest”，边界单元可以选择将地址解析请求消息转发给匹配模板中指明的对等单元，也可以选择直接将找到的地址模板返回。当有多个地址模板满足要求时，边界单元将返回所有的匹配地址模板。

　　在发送地址解析请求时，发送者可以包含“特定呼叫”标记，这样的话这个解析结果将仅对本次呼叫有用，解析结果将不会被保存。

5 应用举例

　　本节以H.225.0 Annex G Version 2提供的例子作为实例，对管理域间的通信及呼叫路由进行描述，以使描述更加直观和易于理解。

5.1 拓扑结构

　　在我们的例子中，假设有三个管理域A、B和C。这三个管理域之间的关系是全互联关系。每个管理域管辖不同前缀号码的用户。

　　三个管理域的边界网关配置的地址模板信息。其中管理域A的边界网关包含了一个描述符D1，管理域B的边界网关包含了两个描述符D2和D3，管理域C的边界网关包含了两个描述符D4和D5。

5.2 交换地址模板信息

　　三个管理域首先使用4. 1节的流程建立相互间的业务联系。

　　然后使用4. 3节的流程交换地址模板信息（先请求描述符ID，然后请求描述符信息）。地址模板信息交换完毕后，管理域A的边界网关BEA将获取管理域B的边界网关BEB保存的两个描述符D2和D3。BEB也将获取BEA的描述符D1。

5.3 呼叫过程

　　网守收到ARQ后向边界单元BEA发送LRQ（如果GKA1也是对等单元，也可发送AccessReque-
st）请求解析被叫地址。边界单元查找其地址模板信息，发现地址描述符D2中的“1908*”可以匹配。但优于该匹配项的发送消息部分是“AccessRequest”，目的是BEB的Annex G地址。BEA就向BEB发送AccessRequest请求解析地址。BEB收到AccessRequest后，解析被叫地址，将终端T2的呼叫信令地址返回。终端T1收到接入确认后，直接向T2的呼叫信令地址发送Setup发起呼叫。

　　呼叫流程二给出了另一个例子：管理域A中的终端T1呼叫管理域B中的某个终端。终端T1首先向其网守GKA1发送ARQ请求接入，被叫号码为“19089532000”。网守收到ARQ后向边界单元BEA发送LRQ请求解析被叫地址。边界单元查找其地址模板信息，发现地址描述符D3中的“1908953*”可以匹配，且发送消息部分是“Setup”。BEA直接将解析结果返回。终端T1收到响应后，根据解析结果向管理域B的网关GWB1发送Setup消息请求建立呼叫。

6 结束语

　　随着IP电话系统的大规模商用，域间的互通问题显得非常重要。为了实现域间的呼叫路由，ITU-T专门制定了H.323的域间通信框架H.225.0 Annex G。在H.501的支持下，H.225.0 Annex G的新版本试图将域间和域内网守间的通信纳入同一个框架。但目前的重点还只限于域间通信。如何将之用于域内网守间通信并处理好与LRQ的关系需要进一步研究。

参 考 文 献

[1] 中华人民共和国信息产业部. IP电话/传真业务总体技术要求（Version2）. 2001年

[2] ITU-T Recommendation H.225.0 Annex G (Version 1) (1999), Communication between Administrative Domains

[3] ITU-T Recommendation H.501 (2002), Protocol for Mobility Management and Intra/inter-domain Communication
in Multimedia Systems.

[4] ITU-T Recommendation H.225.0 Revised Annex G (Version 2) (2002), Communication between and within Administrative Domains

----《中国数据通信》