一个IP电话路由框架

本备忘录的状态

本备忘录为Internet团体提供了相关信息，但并未规定任何形式的标准。本备忘录的发

布不受任何限制。

摘要

本文介绍了一种IP电话路由（TRIP）的框架，它为供给商提供了相互之间发现和交换

IP电话网关路由表的支持。文档定义了IP电话路由交换的问题以及协议需要的动机。文中

介绍了一种TRIP体系结构框架，定义了术语，规定了不同的协议元素及其功能，概述了协

议提供的服务，并讨论了如何将其应用于更广泛的Internet电话中。

1．简介 2

2．术语 2

3．动机与存在的问题 3

4．相关问题 4

5．与BGP的关系 5

6．TRIP应用举例 5

6.1Clearinghouses-交换中心 5

6.2Confederations-联邦 5

6.3GatewayWholesalers-网关批发商 6

7．体系结构 7

8．基本要素 8

8.1ITAD 8

8.2网关 9

8.3端用户 9

8.4区域服务器 9

9．要素间的交互 10

9.1网关与区域服务器交互 10

9.2区域服务器之间的交互 10

10．前端 12

10.1前端客户 12

10.2前端协议 13

11．号码翻译 13

12．安全考虑 14

13．鸣谢 14

14．参考资料 14

15．作者地址 15

致谢 16

1．简介

本文档介绍了一种IP电话路由（TRIP）的框架，它为供给商提供了相互之间发现和交换

IP电话网关路由表的支持。文档定义了IP电话路由交换的问题以及协议需要的动机。文中提

出了一种TRIP体系结构的框架，定义了术语集合，规定了不同的协议元素及其功能，概述了

协议提供的服务，并讨论了如何将其应用于更广泛的Internet电话中。

2．术语

我们定义了如下的术语，注重：这些术语在网关领域以外可能还有其它定义，因此我们的定

义不是通用的，仅在此有特定含义：

网关（Gateway）:连接电路开关网络和IP网络的设备，可以发起和结束IP电话信令

协议，并发起和结束电话网络信令协议。

端用户（EndUser）:端用户是呼叫的发起方或者接受方，可能是人，也可能是设备。

呼叫设备（CallingDevice）:呼叫设备是一个有IP连接性的物理设备，处于控制呼叫

的端用户管辖之下。假如呼叫设备是PC机，则端用户可以直接控制它；假如呼叫设备是电

话网关，则端用户只能通过电话来访问它。

关守（Gatekeeper）:H.323关守，定义于[1]。

会话初始协议服务器（SIPServer）:会话初始协议代理或重定向服务器，定义于[2]。

呼叫代理（CallAgent）:MGCP呼叫代理，定义于[3]。

全球开关电话网（GSTN）:GSTN是全球电路开关网络。

信令服务器（SignalingServer）:信令服务器功能是为IP电话信令协议接收和发送信令

消息，如H.323或SIP。通常，信令服务器是一个关守，SIP服务器，或者呼叫代理。

区域服务器（LocationServer(LS)）:一个具有IP连接性的逻辑设备，可以知道那些网

关可用于终止对GSTN的呼叫。LS是参与TRIP的主要设备，通常是端用户完成与电话网

络呼叫的联系点。它也负责向其它LS传播网关信息。LS可以同H.323关守或SIP服务器共

存。

Internet电话治理域（InternetTelephonyAdministrativeDomain(ITAD)）:单个治理机构

控制下的资源集合（网关和区域服务器）。端用户是ITAD的客户。

提供商（Provider）:ITAD的治理员。

区域服务器策略（LocationServerPolicy）:区域服务器处理通过TRIP发送和接收信息

的规则集。其中包括聚集，传播，产生和接受信息的规则。

端用户策略:关于到GSTN的呼叫如何路由的端用户收选项。

对等体（Peers）:当两个LS有稳固联系，能够交换网关信息时，它们就构成对等体。

内部对等体（Internalpeers）:对等体的两方位于同一个ITAD。

外部对等体（Externalpeers）:对等体位于不同的ITAD。

源区域服务器（OriginatingLocationServer）:ITAD中第一个产生到网关的路由的区域服务

器。

电话路由信息库（TelephonyRoutingInformationBase(TRIB)）:LS建立的网关数据库，

用于保存TRIP的参与结果。

3．动机与存在的问题

随着IP电话网关数量和使用的增加，对它们操作的治理也越来越复杂。其中最困难的问

题就是网关定位，也叫做网关选择，路径选择，网关发现和网关路由。当呼叫设备要呼叫一

个开关电路网络中的终端电话号码时就会出现这一问题。由于目标位于开关电路网络，并且

呼叫者是从一个IP宿主机上发起呼叫，因此必须使用电话网关。网关作为媒体和信令的转

换点，负责在IP网络协议和电路开关网络协议之间进行转换。

网关在本质上是应用层信令协议的接力点。由于有很多网关都可以完成由IP网络的呼叫

设备到电路开关网络用户的呼叫，从中选择一个网关并不是一项简单的工作。以下原因使得

这一过程很复杂：

候选网关数量：由于IP电话的广泛应用，连接Internet和GSTN的电话网关的数量也

很庞大。连接到GSTN上意味着网关同该网络的数十亿终端建立了连接性。这就是说每个

网关都在理论上可以完成到GSTN上任何终端的呼叫。同样地，候选网关的数量也非常庞

大。

商业关系（BusinessRelationships）:事实上，网关的治理者未必想让任何人都能随心

所欲地使用网关。网关提供了一定的服务，并在完成到电路开关网络时要进行一定的开销。

因此，网关的提供商需要对网关的使用收费。此举就限制了网关供给商的客户对网关的使用。

供给商策略（ProviderPolicy）:要访问网关的端用户多半都不是直接向网关提供商付

费，而是同IP电话服务供给商建立联系，并由后者作为到网关的中间人。IP电话服务提供

商自己也可以拥有网关。这时，IP电话服务供给商就要根据客户对来自其它供给商的各种

网关的使用建立一定的策略。选择过程要考虑这些策略。

端用户策略（EndUserPolicy）:在某些情况下，端用户也可根据网关选择提出特定需

求。他可能需要能够提供非凡服务的供给商，或者有自己的首选供给商。这些都要作为计费

的环节。

容量（Capacity）:网关并不是完全相同的。有些大，支持成百上千的并发请求。有些

住宅区网关，则只支持1到2路呼叫。选择网关的过程应该考虑到网关的容量。非凡地，要

根据网关的容量采取一定的负载均衡措施。

协议和特征兼容性（ProtocolandFeatureCompatibilities）:呼叫方可能使用某些网关不支持

的专用信令或媒体协议。

根据以上讨论，很明显，网关的选择要受到很多因素的驱动，包括不同团体的策略，以及它

们相互间的关系。因此，不可能有一个全局的“网关目录”供用户查询。此外，网关的可用

性信息交换必须由供给商完成，并且服从于选择策略，首先在本地可用，然后再传播给其它

供给商。这就答应每个供给商建立自己的本地可用网关数据库-根据每个供给商的策略不同。

因此我们得出结论，在治理域之间进行网关路由信息交换需要一个专用协议。提供这些

功能的协议就是TRIP。TRIP功能如下：

o建立和维护供给商之间的对等关系；

o在供给商之间交换和同步电话网关路由信息；

o保护IP电话信令协议的稳定路由循环；

o及时并以可缩放形式向其它供给商传播网关路由信息；

o定义描述电话网关路由的语法和语义。

总之，TRIP是一个域间IP电话网关路由协议。

4．相关问题

TRIP解决的高层问题主要是映射：给定一个电话号码，根据规则判定电话网关。因此，

网关定位问题常称为“电话号码到IP地址转换问题”。当然，这是一个相当简化的说法，

其中至少应包括3个单独的问题，它们统一归类为“电话号码到IP地址转换问题”，但只

有一个是通过TRIP寻址：

o给定一个电路开关网络的终端电话号码，判定能够完成呼叫的网关的IP地址。

o给定Internet上一个特定主机（为了便于从电路开关网络呼叫，该主机有一个电话

号码）的电话号码，判定其IP地址。

o给定电路开关网络的终端用户的电话号码，判定该用户拥有的IP终端的IP地址。

最后一个映射主要用于PC服务器作为电话接口的场合。其中一项服务就是当用户的电

话响铃时向PC发送一条即时消息。为了发送该服务，GSTN的交换机要向电话号码路由一

个呼叫。它希望能为用户向PC机发送一个即时消息。交换机必须能访问IP网络，判定电

话号码用户PC机的IP地址。映射函数要解决名称到地址的转换，名称由一串数字表示。

目录协议能最好地支持这样的转换。TRIP不解决该问题。

第二个映射主要用于处理从传统电话到IP终端的呼叫。当GSTN用户想呼叫IP网络的

一个终端用户时，他需要拨终端的号码。该号码可以是IP地址，但由于IP地址多通过DHCP[4]

分配或拨号网络访问服务器通过PPP[5]分配，所以往往是暂时的。该号码也可以是主机名，

通过一些翻译方法可以将号码变为字符串，但这样也很麻烦。因此建议为每个IP电话终端

分配一个电话号码。GSTN用户可以直接拨号。和主机名一样，该号码也作为IP终端的别

名。GSTN交换机必须能访问IP网络，并得到号码到主机IP的映射。正如前面的例子，该

问题是名称到地址的转换问题，也由目录协议处理，不属于TRIP的范畴。

第一种映射是一个基本的地址到路由的转换问题。属于TRIP要考虑和处理的对象。正

如第三节所讨论的，这一映射取决于本地因素，比如策略和供给商关系等。因此，对于每个

供给商而言，可用的本地网关数据库不尽相同，并要通过特定的供给商关系来建立。正由于

这个原因，尽管可以更好的处理另外两个映射问题，目录协议处理该映射问题不如TRIP协

议。

5．与BGP的关系

TRIP可归类为域间路由协议的近亲，如BGP[6]。不过，两者之间还是有很重大的区别：

oTRIP运行在应用层，而不象BGP在网络层。

oTRIP运行在许多中间网络和IP服务供给商分隔的服务器之间。BGP则在邻近的路

由器之间。

oTRIP对等体之间交换的信息描述了到应用层设备的路径，而不象BGP是IP路由器。

oTRIP假定存在底层的IP传输网络。这意味着交换TRIP路由信息的服务器不需要

转发信息路由的信令消息。而在BGP中却非如此，对等体必须作为IP包的转发点（或为一

个相邻跳命名）。

oTRIP的目的不是建立跨ITAD的全局连接。但建立到许多TRIP小岛的连接却是非

常可行的。每个小岛表示一个治理关系闭包。此外，每个岛都有到GSTN的全连接。这同

BGP形成了鲜明对比，BGP的目标是通过Internet的全连接。假如由于BGP断连，一个AS

从其他中分离出来，则它们之间就没有任何IP网络连接了。

o由于位于应用层，而不是网络层，网关路径比IP路由复杂得多，用于描述的参数

也多的多。

oBGP交换代表IP命名空间的部分前缀。TRIP交换电话号码区，表示GSTN编码空

间的一部分。两种命名空间的组织和层次均不相同。

这些区别说明TRIP从BGP借鉴了很多方法，但也有很多自己的特征，与BGP是不同

的协议。

6．TRIP应用举例

TRIP是用于交换IP电话路径的工具，但并没有规定供给商之间的关系结构。因此，有

很多针对各种IP电话用例的TRIP应用。

6.1Clearinghouses-交换中心

一个clearinghouse是作为称为clearinghouse成员的其它供给商交换节点的供给商。每个

成员要在clearinghouse注册。作为协议的一部分，成员要将其网关向其它成员开放。在交

换时，成员可以访问其他成员拥有的网关。当一个成员的网关产生呼叫时，clearinghouse在

决定由哪个成员来终止呼叫时要起要害作用。

在此，TRIP可作为成员之间交换路径的工具，如图1所示。

图中有6个成员公司，M1到M6。每个成员都利用TRIP同clearinghouse供给商之间发

送和接收网关路径。

6.2Confederations-联邦

我们将视为一组供给商，他们遵循彼此之间以全交叉方式共享网关的协议，而不用通过

中心clearinghouse。这样的配置见图2。每对TRIP之间都运行TRIP。

6.3GatewayWholesalers-网关批发商

------------

M1TRIPTRIPM2

------\/------

\\/--------------\//

------\--------/------

M3--------Clearinghouse--------M4

------/--------\------

/--------------------/\------

/M5M6

------------

图1:交换中心应用中的TRIP

------------

------

M1M2

------\/------

/\<-----TRIP

------/\------

/M3M4

------

------------

图2:联邦形式的TRIP

在本应用中，有大量的电话网关大型供给商。每个都向中等规模的供给商转售其业务。

依次，直到转售给为用户提供直接服务的本地供给商。图3表示了这种高效的金字塔关系：

------

/\<-------TRIP

------------

M2M3

------------

/\/------------------

M4M5M6

------------------

图3:批发商模式的TRIP

注重在该例中，M5同时从M2和M3购买网关。

7．体系结构

图4给出了TRIP的体系结构。

ITAD1ITAD2

-----------------------------------

--------

GWEU

----\--------/----

LS----------------LS

--------/----\----

GW//EU

----/----

------------------/------------------

---------/----------

----

/------------

GWEU

--------

GW/\EU

--------

---------------------

ITAD3

图4:TRIP体系结构

网络上有许多ITAD(InternetTelephonyadministrativedomain),每个ITAD至少有一个区

域服务器。这些区域服务器，通过称为域内协议的带外方式了解域内网关的信息。图中

ITAD1，域内协议用GW和LS元素之间的连线表示。这些区域服务器可以同其他区域服务

器联合，通过这种方式交换网关信息。首先由IT治理者签订一些适于交互网关信息的协议，

然后通过治理手段建立起这些联合。在图中，ITAD1的LS联到了ITAD2的LS，ITAD2的

LS又依次联到了ITAD3的LS。通过TRIP，ITAD2的LS可以了解ITAD1上的两个网关。

这些信息由ITAD2上的终端用户透过前端（front－end）进行访问。这个前端是一个非TRIP

协议或访问LS数据库的装置。在ITAD3中，既有终端用户，又有网关。ITAD3的LS通过

ITAD2上LS的宣传来了解ITAD1上的网关。

8．基本要素

图4的体系结构中包括下列元素：ITAD，端用户，网关，区域服务器。

8.1ITAD

一个ITAD由局域服务器（至少一个）、网关（零个或多个）和终端用户（零个或多个）

组成。网关和局域服务器是在单一权威组织的行政治理之下的。这意味这只有一个权威负责

制订策略和配置网关和局域服务器。

一个ITAD不同于一个自治系统。AS描述物理连接的网络，而ITAD可以由完全不同

的网络上的要素组成，甚至在不同的AS治理之下。一个IT治理域的终端用户是他的有效

客户。他们希望完成通向电话网的呼叫，并且需要访问网关。在一次呼叫中，端用户可以是

一个ITAD的客户，在下一次呼叫中又是另一个IT治理域的客户。

一个ITAD可以没有网关。这时局域服务器要了解其他域的网关，使这些网关可为它的

域内的终端用户使用。于是ITAD就成为一个有效地虚拟IP电话网关的供给商。因为它能

提供网关服务，却不必真的拥有或治理网关。

一个IT治理域也可以没有端用户。这时它可以提供“批发”网关服务，为其他IT治理

域里的顾客提供网关服务。

一个IT治理域可以既没有网关也没有端用户。这时的ITAD中只有局域服务器，ITAD

扮演转售商的角色，了解其他网关，然后综合并将这些信息传播给其他有顾客的ITAD.

8.2网关

网关是一个逻辑装置，既有IP连通性，又与其他网络（通常是共有或私人电话网）连

通，网关的功能是将一种网络的媒体和信令协议转换为另一种，为系统用户实现透明连接。

网关有许多属性标志它所提供的服务。这些属性中最基本的是它所提供服务的电话号码

范围。这个范围可以分为几个段，彼此之间以一些耗费度量参数和耗费标记联系。标记可以

标示出这部分电话号码范围呼叫的消费或爱好倾向。有些属性标志网关所提供的服务量。其

中包括它所拥有的端口数（它所能支持的同时呼叫的数量）和访问速度。这两个属性共同标

志了网关的容量。该度量可帮助局域服务器根据度量值按比例决定路由，从而实现简单的负

载平衡。

网关也有些属性标志它所提供的服务类型。其中包括支持的信令协议、提供的电话特征、

可识别的语音编码和实现的加密算法等。这些属性对于选择网关是很重要的。在缺乏对所有

网关特征基线标准的情况下（这是一个美好但很难达到的目标），为了选择一个网关完成通

信，我们需要这样一组属性。对呼叫有非凡要求的终端用户（例如：一个用户需要商业类呼

叫，这种呼叫需要一些特定呼叫特征的支持）也希望利用这些信息。

在TRIP上，有些属性用来描述网关，另一些属性则不是。这取决于度量能否被合理的

综合，以及呼叫建立之前是否还要传递一些属性（同信令协议本身的协商和交换相对）。TRIP

的思想是保持简洁，支持大量信息的缩放性。TRIP的属性设置是轻易扩展的。一些标记允

许局域服务器处理未知属性。

8.3端用户

端用户通常是一个希望通过网关完成从IP网到电话网终端呼叫的实体（通常是人）。终

端用户可以是登录到有Internet电话软件的PC机的用户，也可以是通过入口电话网关连接

到IP网上的电话用户。这就是我们提到过的“电话到电话”服务，IP网络用于交换传输。

当终端用户完成一次到电话网呼叫时，他们可能知道，也可能不知道有电话路由服务正

在运行。在终端用户知道的情况下，他们可以选择呼叫完成的方式。这些选择包括，必须支

持的特征、质量度量、所有者或者治理者和耗费选择等。

TRIP既不指定这些选择如何与提供商的选择联合决定最终网关，也不支持这些选择传

递到LS。使用前端或者用一些非协议方法可以完成这种传输。

8.4区域服务器

局域服务器(LS)是TRIP的主要功能实体。它是一个访问网关数据库的逻辑设备，这个

数据库称为电话路由信息库(TRIB)。网关数据库由可用的本地网关和一些基于策略的远程网

关构成。LS也为其他ITAD网中的对等LS输出网关集合。这组输出的网关由本地网关和基

于策略的远程网关（通过TRIP了解）构成。同样，在LS操作中策略扮演了核心的角色。图

5所示为这种信息流。

Intra-domainprotocol

Local

Gateways

TRIP-->GatewaysPOLICYGateways-->TRIP

INOut

TelephonyRouting

InformationBase

图5:TRIP信息流

LS中建立的TRIB答应它决定IP电话呼叫路由，当一个去往电话网地址的信令消息到达信

令服务器时，LS的数据库能提供的信息可帮助它判定将信令消息转发给哪一个网关或附加

信令服务器。基于这个原因，LS可与信号服务器合一。假如不在一起，则他们之间需要一

些通信方法。这些通信不是由TRIP来寻址的，尽管TRIP可以满足这样的协议的需求。

要想参与TRIP，ITAD中至少得有一个LS。出于负载平衡，治理方便或者一些其他原因，

ITAD可以有多个LS。这时，为了实现数据库同步和共享其他外部同级服务器信息，在这些

LS之间也要进行一些通信。通常这种通信作为域间协议的内部组件。TRIP就包含这样的功

能。

图5显示了LS正通过域内协议了解ITAD内的其他网关。其实没必要有域内协议。LS运行

时可以不用了解任何运行的本地网关。或者，它可以通过静态配置了解运行的本地网关。

LS也可以与网关在一起，这样它就要了解与它在一起的网关。

9．要素间的交互

9.1网关与区域服务器交互

网关必须以某种方式向同一个ITAD内的LS散播他的特征信息。LS可以进一步通过TRIP

将这些信息传播到ITAD外。该LS称为该网关的源LS。当LS与网关不在一起时，信息的传

播方式不属TRIP的范畴。完成这一功能的协议称为域内协议。

信息散播的一种方式是使用服务定位协议。网关可以包含一个服务代理，LS可以作为

目录代理。服务定位协议规定了服务信息自动由DA传播到SA的步骤。通过这种方式，LS

可以了解ITAD中的网关。

另一种域内协议的机制是通过SIP或者H.323的注册过程。注册过程提供了一种方法，

用户可以通知关守或SIP服务器他们的地址。这一注册程序可扩展为答应网关有效地注册。

LDAP[8]也可用作域内协议。网关利用LDAP为自己添加一条记录到数据库。假如LS也

要作为LDAP服务器，那么它就能了解所在ITAD上的所有网关。

不同的ITAD可以使用不同的域内协议，域内协议属于本地配置。在一个特定的ITAD

中可以有多个域内协议。没有域内协议，LS照样可以工作。它可以通过静态配置了解网关，

或者可以不了解任何网关。

9.2区域服务器之间的交互

LS间的交互由TRIP定义。同一个TRIP内的LS使用TRIP来同步信息。不同LS内的LS根据策略使

用TRIP来交换网关信息。前者中LS作为内部对等体，后者中为外部对等体。

LS之间通过固定连接进行通信。一个LS可以连接到一个或多个LS。LS不必物理上相

邻，也不必在同一个自治系统内。一对LS间的联系通常是以治理手段建立。首先两个LS

的治理员要就交换网关信息达成适当的协议，然后他们就配置为彼此之间可以通信。TRIP

并不提供LS间彼此查找的自动搜索程序。当发生崩溃时，这样的程序可以用来发现对等备

份LS。在对等体商业关系变得更加标准化的环境中，对等体间可以通过象SLP等协议相互

查找。是否使用自动搜索由治理员决定。

通过LS联合交换的信息的语法和语义由TRIP规定。协议没有规定协定合适的种类。TRIP

仅提供传输方式交换系统治理员认为合适网关路由信息。在TRIP规范中有具体说明。

控制网关信息产生、传播、接受的规则称为LS策略。TRIP没有规定或要求任何特定策

略。

9.2.1交换信息概述

LS交换的信息是一组路由对象。每个路由对象至少包含可达的电话号码范围和IP地址

或主机名（向可到达该范围网关的应用层下一跳）。路由对象可通过域内协议、静态配置或

者远程ITAD的LS来了解。LS可以将这些路由对象聚合到一起（合并电话码的范围，用自

己的或与LS通信的信令服务器的IP地址代替那些IP地址，）然后传播给另一个LS。决定

哪一个对象进行聚合和传播称为路由选择操作。治理员在决定对哪一个对象进行聚合和传播

上有很大的选择自由，只要他们在正确的协议操作范围内（无回路形成）。选择可以基于通

过TRIP了解到的信息，或者任何其他带外方式。

路由对象可以有表述网关服务特征的附加信息。这些属性包括协议、支持特征和容量等

等。属性越多可以提供有益的信息就越多，但是，它们也会带来开销。越来越多的信息会使

集合操作变得困难，严重影响协议的伸缩性。

聚合在TRIP中起核心的作用。为了提高伸缩性，路由对象在传播之前可以聚合为更大

的集合。TRIP中描述了这种机制。应用层的集合路由到网关并不是一个简单的问题。在聚

合和冗长之间存在着基本的权衡。TRIP路由对象中信息越多，聚合就越困难。

考虑一个两个网关的简单例子。网关A和B分别可以到达电话号码区X和Y，。C是A、

B所在ITAD中的一个LS。C通过一些方法了解A和B。当他工作时，X和Y被合并为一个单

一地址范围Z。C有几个选项。它可以散播A的信息，也可以散播B的信息，也可以同时散

播A和B，或者将他们合并然后再散播。在本例中，C选择后一种方式，发送一个路由对象

到一个对等体D，其中包含地址范围Z和它自己的地址，由于它也是一个信令服务器。D也

是一个信令服务器。

呼叫装置E希望拨一个电话号码T,该号码恰巧在地址范围X内。E被配置使用D作为他

的默认H.323关守。于是E发送一个呼叫建立信息给D，其中包含目的地址T。D判定出地

址T在Z内。由于D已经接受了一个来自于C的包含地址范围Z的路由对象，它将呼叫建立

消息转发给C。接着，C发现T在地址范围X内，于是它继续将消息发到A，A结束呼叫信令

并向电话网发起一个呼叫。

9.2.2服务质量

当选择网关时，一个值得考虑的因素是服务质量（QoS），即呼叫通过这个网关所经历的

损失、延时和波动等。呼叫的质量取决于两个因素：呼叫者和网关之间路径上的服务质量和

网关本身的能力（衡量可依据电路门数、链路容量、DSP资源等等）。后者的确定需要复杂

的底层网络拓扑知识和呼叫者定位知识。这些因素由QoS路由协议控制，不属于TRIP的范

围。

但是，网关容量不靠呼叫者的位置或者路径特征。因此，TRIP支持一些形式的容量度

量。这种度量表述了网关的静态容量，而不是网关工作期间不断变化的动态可用容量。LS

可用该度量作为网关间对呼叫负载平衡的手段。它也可用作对任何其他策略判定的输入。

9.2.3费用信息

对传播的另一个有用属性是费用度量。它可以表示为一个特定的网关对呼叫的收费。它

可以是一个到根据预先存在的商业协议而定义了价格结构的表的索引，或者它本身就表示了

费用。TRIP本身不定义价格度量，但可以且应该作为一个扩展定义。使用一个价格扩展意

味着可以定义更多的度量。

10．前端

作为TRIP的一个结果，LS建立了一个网关路由的数据库（即TRIB）。这些信息被ITAD

中各种实体所利用。这种将信息加工成可用的方法称为前端。通过这种明显的方式TRIP服

务被暴露在协议外。

10.1前端客户

目前有以下几种实体（可能不止这几种）会使用前端来访问TRIB：

信令服务器：信令服务器接受信令消息（例如H.323或者SIP消息），这些消息用于初

始化IP电话呼叫。这些呼叫的目的地址可以是一个与GSTN终端相对应的电话号码。为了将

这些呼叫路由到一个合适的网关，信令服务器需要访问建在LS上的数据库。

端用户：端用户可以直接查询LS取得路由信息。此举答应他们提供需求的细节信息。

然后，他们可以联系通往被呼叫电话号码的下一跳信令服务器或者网关。

治理员：治理员需要访问TRIB来完成维护和治理功能。

当一个信号服务器联系LS路由电话号码时，它通常正在这么做，因为呼叫设备（代表

端用户）已经尝试要建立一个呼叫。结果，信令服务器作为端用户的代理高效地访问LS数

据库。呼叫设备和他们的代理人（信令服务器）之间通过信令协议通信。

这种代理方法的优点是使真实的LS交互对于呼叫设备隐藏起来。因此，不管呼叫是电

话号码还是IP地址都无所谓。假如是电话号码，则路由透明地发生。代理模式令一个优点

是方便了瘦客户端，因为它们没有接口或者处理能力直接查询局域服务器（例如：单独的

IP电话）。这种代理方法的优点同样也是它的缺点-真实的LS交互对于呼叫设备（即端用户）

隐藏起来了。在某些情况下，端用户需要知道呼叫如何被路由，包括花费、质量、治理员、

或者呼叫服务和协议。这些需求称为端用户策略。在代理方法中，用户能通过信令协议高效

地访问服务。信号协议不可能为端用户支持复杂的呼叫路由首选项的表述。（注重：SIP可

以为呼叫路由支持一些形式的呼叫者首选项。）因此，由端用户直接访问局域数据库可以提

供更丰富的呼叫路由服务。当端用户策略被提交到LS时（或者直接或者通过信令协议），LS

判定如何使用它。LS有它自己的策略来处理端用户首选项。

10.2前端协议

有许多协议可用于前端访问LS数据库。TRIP不指定或限制对于前端访问的可能性。目

前并不清楚是否应该制定一个单一的前端访问标准。每个协议各有优缺点。有些适用于一些

场合，而另一些则适用于其它场合。

当前的前端协议有：

ServiceLocationProtocol(SLP):服务定位协议，SLP设计为可以精确地满足这种

功能。SLP对于由属性集描述的定位服务器非常理想。这时服务器是一个网关，或者通向网

关的下一跳，而属性则是端用户策略。端用户是一个SLPUA，并且LS是一个SLPDA。服务查

询（ServiceQuery）用于通过特定属性集寻找网关。

OpenSettlementsProtocol(OSP):开放结算协议，OSP[11]是一个客户/服务器协

议。它答应客户通过电话号码查询服务器，并得到下一跳的地址，以及用于呼叫的认证令牌。

此时，服务器可以是LS。响应OSP查询的路由表就是用TRIP建立起来的。

LightweightDirectoryAccessProtocol(LDAP):轻量目录访问协议，LDAP用于访

问分布式数据库。由于LS上有数据库，LDAP可以用来进行查询。

WebPage:Web页面，LS也可以有Web前端。用户可以将查询输入form，响应中就返回

匹配的网关。这种访问机制更适合于人直接访问。不过信令服务器可不喜欢通过Web页面来

访问前端。

TRIP:前面讨论的协议都是关于查询响应类型。至于为什么LS访问必须是这种形式并

没有什么理由。通过完全数据库同步访问也是可以接受的，这样一来，访问LS的实体就有一

个完全的备份。虽然这种方法有明显的缺点，不过不妨碍具体实施。

11．号码翻译

TRIP模型有许多网关，每个网关都可以完成通往一些电话号码集的呼叫。通常，这些

电话号码集按照在地理上与网关相近来划分的。例如。一个纽约的网关可以完成区号为212

到718的呼叫。当然，实际上是治理员决定那些号码由那个网关完成。

但是，某些电话号码根本不是GSTN终端，而是服务或者虚拟地址。例如：免费电话和

LNP。在电话网络中，它们被真实的映射到可路由的电话号码，通常都要基于复杂的公式。

典型的例子是基于time-of-day的转换。

由于没有什么措施可以保护网关不受到这种号码的广告可达性的影响，因此不鼓励采用

这种用法。TRIP是一个路由协议，它传播的路由应该是可路由号码，不是最终转化为可路

由号码的名字。当TRIP用于传播到达这些号码的路由的时候，会产生很多问题：

? 通常，这些号码仅在局部有意义。从纽约呼叫一个免费电话可以终结于纽约某个公

司的办公室，从加利福尼亚呼叫的仅可以在加利福尼亚完成。假如这个免费电话在

纽约通过网关接入TRIP，它将被传播到加利福尼亚端用户使用的LS。假如使用了

这个路由，则呼叫可能无法按照用户的意愿进行。

? 呼叫信令路径可能远远达不到最佳。设想一个在纽约的网关广告一个映射到加利福

尼亚的电话的端口号码。该号码由TRIP传播，最终被加利福尼亚端用户使用的LS

了解。当一个用户拨这个号码时，呼叫由IP网络路由到纽约，找到符合的网关，

然后由GSTN路由返回加利福尼亚。这样做十分浪费资源。假如网关路由功能启用

之前端口号码已经被转换，就可以直接访问加利福尼亚的网关。

因此，在LS路由数据库访问之前完成这些特定号码的转换应该更高效。怎样完成这一

转换不属于TRIP的范围。它可以由呼叫设备在在呼叫之前完成，或者在访问LS数据库之前

由信令服务器完成。

12．安全考虑

安全是TRIP的重要组成部分。TRIP模型假设交换信息的对等LS之间相互信任的。这

些消息被用于传播确定呼叫路由的信息。假如信息是错误的，将导致一个错误的路由。这会

造成一种严重的拒绝服务攻击。这些信息也可以被传播到其他的ITAD，致使问题潜在的扩

散。结果，对等LS的相互认证是很要害的，而且，信息的完整性也要保证。

TRIP消息可以包含潜在的敏感信息。他们表示了一个ITAD的路由容量。这样的信息可

以被竞争对手利用来判定ITAD网络的拓扑和容量。因此，TRIP也支持消息加密。

由于路由对象可以在LS间传递，也需要某种形式的端到端认证。但是聚合会导致路由

对象改变，因此认证只能从接收LS的最后一个聚合点开始进行。

13．鸣谢

感谢RandyBush,MarkFoster,DaveOran,HusseinSalama,和MattSquire为本文提出的有

益见解。

14．参考资料

[1]InternationalTelecommunicationUnion,"Visualtelephonesystems

andequipmentforlocalareanetworkswhichprovideanon-

guaranteedqualityofservice,"RecommendationH.323,

TelecommunicationStandardizationSectorofITU,Geneva,

Switzerland,May1996.

[2]Handley,M.,Schulzrinne,H.,Schooler,E.andJ.Rosenberg,

"SIP:SessionInitiationProtocol",RFC2543,March1999.

[3]Arango,M.,Dugan,A.,Elliott,I.,Huitema,C.andS.Pickett,

"MediaGatewayControlProtocol(MGCP)Version1.0",RFC2705,

October1999.

[4]Droms,R.,"DynamicHostConfigurationProtocol",RFC2131,

March1997.

[5]Simpson,W.,"ThePoint-to-PointProtocol(PPP),"STD51,RFC

1661,July1994.

[6]RekhterY.andT.Li,"ABorderGatewayProtocol4(BGP-4)",RFC

1771,March1995.

[7]Veizades,J.,Guttman,E.,Perkins,C.andS.Kaplan,"Service

LocationProtocol",RFC2165,June1997.

[8]Yeong,W.,Howes,T.andS.Kille,"LightweightDirectoryAccess

Protocol",RFC1777,March1995.

[9]Guttman,E.,Perkins,C.,Veizades,J.andM.Day,"Service

LocationProtocol,Version2",RFC2608,June1999.

[10]SchulzrinneH.andJ.Rosenberg,"SIPcallerpreferencesand

calleecapabilities",Workinprogress.

[11]EuropeanTelecommunicationsStandardsInstitute(ETSI),

TelecommunicationsandInternetProtocolHarmonizationOver

Networks(TIPHON),"Inter-domainpricing,authorization,and

usageexchange,"TechnicalSpecification101321version1.4.2,

ETSI,1998.

15．作者地址

JonathanRosenberg

dynamicsoft

72EagleRockAvenue

FirstFloor

EastHanover,NJ07936

Email:jdrosen@dynamicsoft.com

HenningSchulzrinne

ColumbiaUniversity

M/S0401

1214AmsterdamAve.

NewYork,NY10027-7003

Email:schulzrinne@cs.columbia.edu

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto

others,andderivativeworksthatcommentonorotherwiseeXPlainit

orassistinitsimplementationmaybeprepared,copied,published

anddistributed,inwholeorinpart,withoutrestrictionofany

kind,providedthattheabovecopyrightnoticeandthisparagraphare

includedonallsUChcopiesandderivativeworks.However,this

documentitselfmaynotbemodifiedinanyway,suchasbyremoving

thecopyrightnoticeorreferencestotheInternetSocietyorother

Internetorganizations,exceptasneededforthepurposeof

developingInternetstandardsinwhichcasetheproceduresfor

copyrightsdefinedintheInternetStandardsprocessmustbe

followed,orasrequiredtotranslateitintolanguagesotherthan

English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe

revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan

"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING

TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING

BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION

HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF

MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

致谢

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe

InternetSociety.