📄 rfc2871.txt
字号:
Network Working Group J. Rosenberg
Request for Comments: 2871 dynamicsoft
Category: Informational H. Schulzrinne
Columbia University
June 2000
A Framework for Telephony Routing over IP
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document serves as a framework for Telephony Routing over IP
(TRIP), which supports the discovery and exchange of IP telephony
gateway routing tables between providers. The document defines the
problem of telephony routing exchange, and motivates the need for the
protocol. It presents an architectural framework for TRIP, defines
terminology, specifies the various protocol elements and their
functions, overviews the services provided by the protocol, and
discusses how it fits into the broader context of Internet telephony.
Table of Contents
1 Introduction ........................................ 2
2 Terminology ......................................... 2
3 Motivation and Problem Definition ................... 4
4 Related Problems .................................... 6
5 Relationship with BGP ............................... 7
6 Example Applications of TRIP ........................ 8
6.1 Clearinghouses ...................................... 8
6.2 Confederations ...................................... 9
6.3 Gateway Wholesalers ................................. 9
7 Architecture ........................................ 11
8 Elements ............................................ 12
8.1 IT Administrative Domain ............................ 12
8.2 Gateway ............................................. 13
8.3 End Users ........................................... 14
8.4 Location Server ..................................... 14
9 Element Interactions ................................ 16
Rosenberg & Schulzrinne Informational [Page 1]
RFC 2871 TRIP Framework June 2000
9.1 Gateways and Location Servers ....................... 16
9.2 Location Server to Location Server .................. 16
9.2.1 Nature of Exchanged Information ..................... 17
9.2.2 Quality of Service .................................. 18
9.2.3 Cost Information .................................... 19
10 The Front End ....................................... 19
10.1 Front End Customers ................................. 19
10.2 Front End Protocols ................................. 20
11 Number Translations ................................. 21
12 Security Considerations ............................. 22
13 Acknowledgments ..................................... 23
14 Bibliography ........................................ 23
15 Authors' Addresses .................................. 24
16 Full Copyright Statement ............................ 25
1 Introduction
This document serves as a framework for Telephony Routing over IP
(TRIP), which supports the discovery and exchange of IP telephony
gateway routing tables between providers. The document defines the
problem of telephony routing exchange, and motivates the need for the
protocol. It presents an architectural framework for TRIP, defines
terminology, specifies the various protocol elements and their
functions, overviews the services provided by the protocol, and
discusses how it fits into the broader context of Internet telephony.
2 Terminology
We define the following terms. Note that there are other definitions
for these terms, outside of the context of gateway location. Our
definitions aren't general, but refer to the specific meaning here:
Gateway: A device with some sort of circuit switched network
connectivity and IP connectivity, capable of initiating and
terminating IP telephony signaling protocols, and capable of
initiating and terminating telephone network signaling
protocols.
End User: The end user is usually (but not necessarily) a human
being, and is the party who is the ultimate initiator or
recipient of calls.
Calling Device: The calling device is a physical entity which has
IP connectivity. It is under the direction of an end user who
wishes to place a call. The end user may or may not be directly
controlling the calling device. If the calling device is a PC,
Rosenberg & Schulzrinne Informational [Page 2]
RFC 2871 TRIP Framework June 2000
the end user is directly controlling it. If, however, the
calling device is a telephony gateway, the end user may be
accessing it through a telephone.
Gatekeeper: The H.323 gatekeeper element, defined in [1].
SIP Server: The Session Initiation Protocol proxy or redirect
server defined in [2].
Call Agent: The MGCP call agent, defined in [3].
GSTN: The Global Switched Telephone Network, which is the worldwide
circuit switched network.
Signaling Server: A signaling server is an entity which is capable
of receiving and sending signaling messages for some IP
telephony signaling protocol, such as H.323 or SIP. Generally
speaking, a signaling server is a gatekeeper, SIP server, or
call agent.
Location Server (LS): A logical entity with IP connectivity which
has knowledge of gateways that can be used to terminate calls
towards the GSTN. The LS is the main entity that participates in
Telephony Routing over IP. The LS is generally a point of
contact for end users for completing calls to the telephony
network. An LS may also be responsible for propagation of
gateway information to other LS's. An LS may be coresident with
an H.323 gatekeeper or SIP server, but this is not required.
Internet Telephony Administrative Domain (ITAD): The set of
resources (gateways and Location Servers) under the control of a
single administrative authority. End users are customers of an
ITAD.
Provider: The administrator of an ITAD.
Location Server Policy: The set of rules which dictate how a
location server processes information it sends and receives via
TRIP. This includes rules for aggregating, propagating,
generating, and accepting information.
End User Policy: Preferences that an end user has about how a call
towards the GSTN should be routed.
Peers: Two LS's are peers when they have a persistent association
between them over which gateway information is exchanged.
Rosenberg & Schulzrinne Informational [Page 3]
RFC 2871 TRIP Framework June 2000
Internal peers: Peers that both reside within the same ITAD.
External peers: Peers that reside within different ITADs.
Originating Location Server: A Location Server which first
generates a route to a gateway in its ITAD.
Telephony Routing Information Base (TRIB): The database of gateways
an LS builds up as a result of participation in TRIP.
3 Motivation and Problem Definition
As IP telephony gateways grow in terms of numbers and usage, managing
their operation will become increasingly complex. One of the
difficult tasks is that of gateway location, also known as gateway
selection, path selection, gateway discovery, and gateway routing.
The problem occurs when a calling device (such as a telephony gateway
or a PC with IP telephony software) on an IP network needs to
complete a call to a phone number that represents a terminal on a
circuit switched telephone network. Since the intended target of the
call resides in a circuit switched network, and the caller is
initiating the call from an IP host, a telephony gateway must be
used. The gateway functions as a conversion point for media and
signaling, converting between the protocols used on the IP network,
and those used in the circuit switched network.
The gateway is, in essence, a relaying point for an application layer
signaling protocol. There may be many gateways which could possibly
complete the call from the calling device on the IP network to the
called party on the circuit switched network. Choosing such a gateway
is a non-trivial process. It is complicated because of the following
issues:
Number of Candidate Gateways: It is anticipated that as IP
telephony becomes widely deployed, the number of telephony
gateways connecting the Internet to the GSTN will become large.
Attachment to the GSTN means that the gateway will have
connectivity to the nearly one billion terminals reachable on
this network. This means that every gateway could theoretically
complete a call to any terminal on the GSTN. As such, the
number of candidate gateways for completing a call may be very
large.
Business Relationships: In reality, the owner of a gateway is
unlikely to make the gateway available to any user who wishes to
connect to it. The gateway provides a useful service, and incurs
cost when completing calls towards the circuit switched network.
As a result, providers of gateways will, in many cases, wish to
Rosenberg & Schulzrinne Informational [Page 4]
RFC 2871 TRIP Framework June 2000
charge for use of these gateways. This may restrict usage of the
gateway to those users who have, in some fashion, an established
relationship with the gateway provider.
Provider Policy: In all likelihood, an end user who wishes to make
use of a gateway service will not compensate the gateway
provider directly. The end user may have a relationship with an
IP telephony service provider which acts as an intermediary to
providers of gateways. The IP telephony service provider may
have gateways of its own as well. In this case, the IP telephony
service provider may have policies regarding the usage of
various gateways from other providers by its customers. These
policies must figure into the selection process.
End User Policy: In some cases, the end user may have specific
requirements regarding the gateway selection. The end user may
need a specific feature, or have a preference for a certain
provider. These need to be taken into account as well.
Capacity: All gateways are not created equal. Some are large,
capable of supporting hundreds or even thousands of simultaneous
calls. Others, such as residential gateways, may only support
one or two calls. The process for selecting gateways should
allow gateway capacity to play a role. It is particularly
desirable to support some form of load balancing across gateways
based on their capacities.
Protocol and Feature Compatibilities: The calling party may be
using a specific signaling or media protocol that is not
supported by all gateways.
From these issues, it becomes evident that the selection of a gateway
is driven in large part by the policies of various parties, and by
the relationships established between these parties. As such, there
cannot be a global "directory of gateways" in which users look up
phone numbers. Rather, information on availability of gateways must
be exchanged by providers, and subject to policy, made available
locally and then propagated to other providers. This would allow each
provider to build up its own local database of available gateways -
such a database being very different for each provider depending on
policy.
From this, we can conclude that a protocol is needed between
administrative domains for exchange of gateway routing information.
The protocol that provides these functions is Telephony Routing over
IP (TRIP). TRIP provides a specific set of functions:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -