As per Relevance of the word signaling, we have this rfc below:
Network Working Group J.
Request for Comments: 2871
Category: Informational H.
Columbia
June 2000
A Framework for Telephony Routing over
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document serves as a framework for Telephony Routing over
(TRIP), which supports the discovery and exchange of IP
gateway routing tables between providers. The document defines
problem of telephony routing exchange, and motivates the need for
protocol. It presents an architectural framework for TRIP,
terminology, specifies the various protocol elements and
functions, overviews the services provided by the protocol,
discusses how it fits into the broader context of Internet telephony
Table of
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
This document serves as a framework for Telephony Routing over
(TRIP), which supports the discovery and exchange of IP
gateway routing tables between providers. The document defines
problem of telephony routing exchange, and motivates the need for
protocol. It presents an architectural framework for TRIP,
terminology, specifies the various protocol elements and
functions, overviews the services provided by the protocol,
discusses how it fits into the broader context of Internet telephony
2
We define the following terms. Note that there are other
for these terms, outside of the context of gateway location.
definitions aren't general, but refer to the specific meaning here
Gateway: A device with some sort of circuit switched
connectivity and IP connectivity, capable of initiating
terminating IP telephony signaling protocols, and capable
initiating and terminating telephone network
protocols
End User: The end user is usually (but not necessarily) a
being, and is the party who is the ultimate initiator
recipient of calls
Calling Device: The calling device is a physical entity which
IP connectivity. It is under the direction of an end user
wishes to place a call. The end user may or may not be
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,
calling device is a telephony gateway, the end user may
accessing it through a telephone
Gatekeeper: The H.323 gatekeeper element, defined in [1].
SIP Server: The Session Initiation Protocol proxy or
server defined in [2].
Call Agent: The MGCP call agent, defined in [3].
GSTN: The Global Switched Telephone Network, which is the
circuit switched network
Signaling Server: A signaling server is an entity which is
of receiving and sending signaling messages for some
telephony signaling protocol, such as H.323 or SIP.
speaking, a signaling server is a gatekeeper, SIP server,
call agent
Location Server (LS): A logical entity with IP connectivity
has knowledge of gateways that can be used to terminate
towards the GSTN. The LS is the main entity that participates
Telephony Routing over IP. The LS is generally a point
contact for end users for completing calls to the
network. An LS may also be responsible for propagation
gateway information to other LS's. An LS may be coresident
an H.323 gatekeeper or SIP server, but this is not required
Internet Telephony Administrative Domain (ITAD): The set
resources (gateways and Location Servers) under the control of
single administrative authority. End users are customers of
ITAD
Provider: The administrator of an ITAD
Location Server Policy: The set of rules which dictate how
location server processes information it sends and receives
TRIP. This includes rules for aggregating, propagating
generating, and accepting information
End User Policy: Preferences that an end user has about how a
towards the GSTN should be routed
Peers: Two LS's are peers when they have a persistent
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
generates a route to a gateway in its ITAD
Telephony Routing Information Base (TRIB): The database of
an LS builds up as a result of participation in TRIP
3 Motivation and Problem
As IP telephony gateways grow in terms of numbers and usage,
their operation will become increasingly complex. One of
difficult tasks is that of gateway location, also known as
selection, path selection, gateway discovery, and gateway routing
The problem occurs when a calling device (such as a telephony
or a PC with IP telephony software) on an IP network needs
complete a call to a phone number that represents a terminal on
circuit switched telephone network. Since the intended target of
call resides in a circuit switched network, and the caller
initiating the call from an IP host, a telephony gateway must
used. The gateway functions as a conversion point for media
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
signaling protocol. There may be many gateways which could
complete the call from the calling device on the IP network to
called party on the circuit switched network. Choosing such a
is a non-trivial process. It is complicated because of the
issues
Number of Candidate Gateways: It is anticipated that as
telephony becomes widely deployed, the number of
gateways connecting the Internet to the GSTN will become large
Attachment to the GSTN means that the gateway will
connectivity to the nearly one billion terminals reachable
this network. This means that every gateway could
complete a call to any terminal on the GSTN. As such,
number of candidate gateways for completing a call may be
large
Business Relationships: In reality, the owner of a gateway
unlikely to make the gateway available to any user who wishes
connect to it. The gateway provides a useful service, and
cost when completing calls towards the circuit switched network
As a result, providers of gateways will, in many cases, wish
Rosenberg & Schulzrinne Informational [Page 4]
RFC 2871 TRIP Framework June 2000
charge for use of these gateways. This may restrict usage of
gateway to those users who have, in some fashion, an
relationship with the gateway provider
Provider Policy: In all likelihood, an end user who wishes to
use of a gateway service will not compensate the
provider directly. The end user may have a relationship with
IP telephony service provider which acts as an intermediary
providers of gateways. The IP telephony service provider
have gateways of its own as well. In this case, the IP
service provider may have policies regarding the usage
various gateways from other providers by its customers.
policies must figure into the selection process
End User Policy: In some cases, the end user may have
requirements regarding the gateway selection. The end user
need a specific feature, or have a preference for a
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
calls. Others, such as residential gateways, may only
one or two calls. The process for selecting gateways
allow gateway capacity to play a role. It is
desirable to support some form of load balancing across
based on their capacities
Protocol and Feature Compatibilities: The calling party may
using a specific signaling or media protocol that is
supported by all gateways
From these issues, it becomes evident that the selection of a
is driven in large part by the policies of various parties, and
the relationships established between these parties. As such,
cannot be a global "directory of gateways" in which users look
phone numbers. Rather, information on availability of gateways
be exchanged by providers, and subject to policy, made
locally and then propagated to other providers. This would allow
provider to build up its own local database of available gateways -
such a database being very different for each provider depending
policy
From this, we can conclude that a protocol is needed
administrative domains for exchange of gateway routing information
The protocol that provides these functions is Telephony Routing
IP (TRIP). TRIP provides a specific set of functions
Rosenberg & Schulzrinne Informational [Page 5]
RFC 2871 TRIP Framework June 2000
o Establishment and maintenance of peering relationships
providers
o Exchange and synchronization of telephony gateway
information between providers
o Prevention of stable routing loops for IP telephony
protocols
o Propagation of learned gateway routing information to
providers in a timely and scalable fashion
o Definition of the syntax and semantics of the data
describe telephony gateway routes
TRIP can be generally summarized as an inter-domain IP
gateway routing protocol
4 Related
At a high level, the problem TRIP solves appears to be a
problem: given an input telephone number, determine, based on
criteria, the address of a telephony gateway. For this reason,
gateway location problem is often called a "phone number to
address translation problem". This is an over-simplification
however. There are at least three separate problems, all of which
be classified as a "phone number to IP address translation problem",
and only one of which is addressed by TRIP
o Given a phone number that corresponds to a terminal on
circuit switched network, determine the IP address of
gateway capable of completing a call to that phone number
o Given a phone number that corresponds to a specific host
the Internet (this host may have a phone number in order
facilitate calls to it from the circuit switched network),
determine the IP address of this host
o Given a phone number that corresponds to a user of a
on a circuit switched network, determine the IP address of
IP terminal which is owned by the same user
The last of these three mapping functions is useful for
where the PC serves as an interface for the phone. One such
is the delivery of an instant message to a PC when the user's
rings. To deliver this service, a switch in the GSTN is routing
call towards a phone number. It wishes to send an Instant Message
the PC for this user. This switch must somehow have access to the
Rosenberg & Schulzrinne Informational [Page 6]
RFC 2871 TRIP Framework June 2000
network, in order to determine the IP address of the PC
to the user with the given phone number. The mapping function is
name to address translation problem, where the name happens to
represented by a string of digits. Such a translation function
best supported by directory protocols. This problem is not
by TRIP
The second of these mappings is needed to facilitate calls
traditional phones to IP terminals. When a user on the GSTN wishes
call a user with a terminal on the IP network, they need to dial
number identifying that terminal. This number could be an IP address
However, IP addresses are often ephemeral, assigned on demand by
[4] or by dialup network access servers using PPP [5]. The
could be a hostname, obtained through some translation of groups
numbers to letters. However, this is cumbersome. It has been
instead to assign phone numbers to IP telephony terminals. A
on the GSTN would then dial this number as they would any other.
number serves as an alternate name for the IP terminal, in much
same way its hostname serves as a name. A switch in the GSTN
then access the IP network, and obtain the mapping from this
to an IP address for the PC. Like the previous case, this problem
a name to address translation problem, and is best handled by
directory protocol. It is not addressed by TRIP
The first mapping function, however, is fundamentally an address
route translation problem. It is this problem which is considered
TRIP. As discussed in Section 3, this mapping depends on
factors such as policies and provider relationships. As a result,
database of available gateways is substantially different for
provider, and needs to be built up through specific inter-
relationships. It is for this reason that a directory protocol is
appropriate for TRIP, whereas it is appropriate for the others
5 Relationship with
TRIP can be classified as a close cousin of inter-domain IP
protocols, such as BGP [6]. However, there are important
between BGP and TRIP
o TRIP runs at the application layer, not the network layer
where BGP resides
o TRIP runs between servers which may be separated by
intermediate networks and IP service providers. BGP
between routers that are usually adjacent
Rosenberg & Schulzrinne Informational [Page 7]
RFC 2871 TRIP Framework June 2000
o The information exchanged between TRIP peers describes
to application layer devices, not IP routers, as is done
BGP
o TRIP assumes the existence of an underlying IP
network. This means that servers which exchange TRIP
information need not act as forwarders of signaling
that are routed based on this information. This is not true
BGP, where the peers must also act as forwarding points (
name an adjacent forwarding hop) for IP packets
o The purpose of TRIP is not to establish global
across all ITADs. It is perfectly reasonable for there to
many small islands of TRIP connectivity. Each
represents a closed set of administrative relationships
Furthermore, each island can still have complete
to the entire GSTN. This is in sharp contrast to BGP,
the goal is complete connectivity across the Internet. If
set of AS's are isolated from some other set because of a
disconnect, no IP network connectivity exists between them
o Gateway routes are far more complex than IP routes (since
reside at the application, not the network layer), with
more parameters which may describe them
o BGP exchanges prefixes which represent a portion of the
name space. TRIP exchanges phone number ranges, representing
portion of the GSTN numbering space. The organization
hierarchies in these two namespaces are different
These differences means that TRIP borrows many of the concepts
BGP, but that it is still a different protocol with its own
set of functions
6 Example Applications of
TRIP is a general purpose tool for exchanging IP telephony
between providers. TRIP does not, in any way, dictate the
or nature of the relationships between those providers. As a result
TRIP has applications for a number of common cases for IP telephony
6.1
A clearinghouse is a provider that serves as an exchange
between a number of other providers, called the members of
clearinghouse. Each member signs on with the clearinghouse. As
of the agreement, the member makes their gateways available to
other members of the clearinghouse. In exchange, the members
Rosenberg & Schulzrinne Informational [Page 8]
RFC 2871 TRIP Framework June 2000
access to the gateways owned by the other members of
clearinghouse. When a gateway belonging to one member makes a call
the clearinghouse plays a key role in determining which
terminates the call
TRIP can be applied here as the tool for exchanging routes
the members and the clearinghouse. This is shown in Figure 1.
There are 6 member companies, M1 through M6. Each uses TRIP to
and receive gateway routes with the clearinghouse provider
6.2
We refer to a confederation as a group of providers which all
to share gateways with each other in a full mesh, without using
central clearinghouse. Such a configuration is shown in Figure 2.
TRIP would run between each pair of providers
6.3 Gateway
------ ------
| | | |
| M1 | TRIP TRIP | M2 |
| |\ | | /| |
------ \ | | / ------
\ \ / -------------- \ / /
------ \----| |----/ ------
| | | | | |
| M3 |--------| Clearinghouse|--------| M4 |
| | | | | |
------ /----| |----\ ------
/ -------------- \
------ / \ ------
| |/ \| |
| M5 | | M6 |
| | | |
------ ------
Figure 1: TRIP in the Clearinghouse
Rosenberg & Schulzrinne Informational [Page 9]
RFC 2871 TRIP Framework June 2000
------ ------
| |------| |
| M1 | | M2 |
| |\ /| |
------ \ / ------
| \/ |
| /\ |<-----
------ / \ ------
| |/ \| |
| M3 | | M4 |
| |------| |
------ ------
Figure 2: TRIP for
In this application, there are a number of large providers
telephony gateways. Each of these resells its gateway services
medium sized providers. These, in turn, resell to local providers
sell directly to consumers. This is effectively a
relationship, as shown in Figure 3.
------
| |
| M1 |
| |
------
/ \ <-------
------ ------
| | | |
| M2 | | M3 |
| | | |
------ ------
/ \ / \
------ ------ ------
| | | | | |
| M4 | | M5 | | M6 |
| | | | | |
------ ------ ------
Figure 3: TRIP for
Note that in this example, provider M5 resells gateways from both M
and M3.
Rosenberg & Schulzrinne Informational [Page 10]
RFC 2871 TRIP Framework June 2000
7
Figure 4 gives the overall architecture of TRIP
ITAD1 ITAD
----------------- ------------------
| | | |
| ---- | | ---- |
| | GW | | | | EU | |
| ---- \ ---- | | ---- / ---- |
| | LS | ---------------- | LS | |
| ---- ---- | / ---- \ ---- |
| | GW | / | /| | EU | |
| ---- | / | ---- |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | |
| ---- |
| | LS | |
| / ---- \ |
| ---- || ---- |
| | GW | || | EU | |
| ---- || ---- |
| ---- || ---- |
| | GW | / \ | EU | |
| ---- ---- |
| |
---------------------
ITAD
Figure 4: TRIP
There are a number of Internet Telephony administrative
(ITAD's), each of which has at least one Location Server (LS).
LS's, through an out-of-band means, called the intra-domain protocol
learn about the gateways in their domain. The intra-domain
is represented by the lines between the GW and LS elements in ITAD
in the Figure. The LS's have associations with other LS's, over
they exchange gateway information. These associations are
administratively, and are set up when the IT administrative
have some kind of agreements in place regarding exchange of
information. In the figure, the LS in ITAD1 is connected to the LS
ITAD2, which is in turn connected to the LS in ITAD3.
Telephony Routing over IP (TRIP), the LS in ITAD2 learns about
two gateways in ITAD1. This information is accessed by end
Rosenberg & Schulzrinne Informational [Page 11]
RFC 2871 TRIP Framework June 2000
(EUs) in ITAD2 through the front-end. The front-end is a non-
protocol or mechanism by which the LS databases are accessed.
ITAD3, there are both EUs and gateways. The LS in ITAD3 learns
the gateways in ITAD1 through a potentially aggregated
from the LS in ITAD2.
8
The architecture in Figure 4 consists of a number of elements.
include the IT administrative domain, end user, gateway, and
server
8.1 IT Administrative
An IT administrative domain consists of zero or more gateways,
least one Location Server, and zero or more end users. The
and LS's are those which are under the administrative control of
single authority. This means that there is one authority
for dictating the policies and configuration of the gateways
LS's
An IT administrative domain need not be the same as an
system. While an AS represents a set of physically
networks, an IT administrative domain may consist of elements
disparate networks, and even within disparate autonomous systems
The end users within an IT administrative domain are effectively
customers of that IT administrative domain. They are interested
completing calls towards the telephone network, and thus need
to gateways. An end user may be a customer of one IT
domain for one call, and then a customer of a different one for
next call
An IT administrative domain need not have any gateways. In this case
its LS learns about gateways in other domains, and makes
available to the end users within its domain. In this case, the
administrative domain is effectively a virtual IP telephony
provider. This is because it provides gateway service, but may
actually own or administer any gateways
An IT administrative domain need not have any end users. In
case, it provides "wholesale" gateway service, making its
available to customers in other IT administrative domains
An IT administrative domain need not have gateways nor end users.
this case, the ITAD only has LS's. The ITAD acts as a reseller
learning about other gateways, and then aggregating and
this information to other ITAD's which do have customers
Rosenberg & Schulzrinne Informational [Page 12]
RFC 2871 TRIP Framework June 2000
8.2
A gateway is a logical device which has both IP connectivity
connectivity to some other network, usually a public or
telephone network. The function of the gateway is to translate
media and signaling protocols from one network technology to
other, achieving a transparent connection for the users of
system
A gateway has a number of attributes which characterize the
it provides. Most fundamental among these are the range of
numbers to which it is willing to provide service. This range may
broken into subranges, and associated with each, some cost metric
cost token. This token indicates some notion of cost or
for completing calls for this part of the telephone number range
A gateway has attributes which characterize the volume of
which it can provide. These include the number of ports it has (i.e.,
the number of simultaneous phone calls it can support), and
access link speed. These two together represent some notion of
capacity of the gateway. The metric is useful for allowing
Servers to decide to route calls to gateways in proportion to
value of the metric, thus achieving a simple form of load balancing
A gateway also has attributes which characterize the type of
it provides. This includes, but is not limited to,
protocols supported, telephony features provided, speech
understood, and encryption algorithms which are implemented.
attributes may be important in selecting a gateway. In the absence
baseline required features across all gateways (an admirable,
difficult goal), such a set of attributes is required in order
select a gateway with which communications can be established.
users which have specific requirements for the call (such as a
requesting a business class call, in which case certain call
may need to be supported) may wish to make use of such information
well
Some of these attributes are transported in TRIP to
gateways, and others are not. This depends on whether the metric
be reasonably aggregated, and whether it is something which must
conveyed in TRIP before the call is set up (as opposed to
or exchanged by the signaling protocols themselves). The
of TRIP is to keep it simple, and to favor scalability
abundance of information. TRIP's attribute set is readily extensible
Flags provide information that allow unknown attributes to
reasonably processed by an LS
Rosenberg & Schulzrinne Informational [Page 13]
RFC 2871 TRIP Framework June 2000
8.3 End
An end user is an entity (usually a human being) which wishes
complete a call through a gateway from an IP network to a terminal
a telephone network. An end user may be a user logged on at a PC
some Internet telephony software. The end user may also be
to the IP network through an ingress telephone gateway, which
user accessed from telephone handset. This is the case for what
referred to as "phone to phone" service with the IP network used
interexchange transport
End users may, or may not be aware that there is a telephony
service running when they complete a call towards the
network. In cases where they are aware, end users may
preferences for how a call is completed. These preferences
include call features which must be supported, quality metrics,
or administrator, and cost preferences
TRIP does not dictate how these preferences are combined with
of the provider to yield the final gateway selection. Nor does
support the transport of these preferences to the LS. This
can be accomplished using the front end, or by some non-
means
8.4 Location
The Location Server (LS) is the main functional entity of TRIP.
is a logical device which has access to a database of gateways
called the Telephony Routing Information Base (TRIB). This
of gateways is constructed by combining the set of locally
gateways and the set of remote gateways (learned through TRIP)
on policy. The LS also exports a set of gateways to its peer LS's
other ITAD's. The set of exported gateways is constructed from the
of local gateways and the set of remote gateways (learned
TRIP) based on policy. As such, policy plays a central role in the
operation. This flow of information is shown in Figure 5.
Rosenberg & Schulzrinne Informational [Page 14]
RFC 2871 TRIP Framework June 2000
|
|Intra-domain
\ /
TRIP--> Gateways POLICY Gateways -->
IN
|
\ /
Telephony
Information
Figure 5: Flow of Information in
The TRIB built up in the LS allows it to make decisions about
telephony call routing. When a signaling message arrives at
signaling server, destined for a telephone network address, the LS'
database can provide information which is useful for determining
gateway or an additional signaling server to forward the
message to. For this reason, an LS may be coresident with a
server. When they are not coresident, some means of
between the LS and the signaling server is needed. This
is not specifically addressed by TRIP, although it is possible
TRIP might meet the needs of such a protocol
An ITAD must have at least one LS in order to participate in TRIP
An ITAD may have more than one LS, for purposes of load balancing
ease of management, or any other reason. In that case,
between these LS's may need to take place in order to
databases and share information learned from external peers. This
often referred to as the interior component of an inter-
protocol. TRIP includes such a function
Figure 5 shows an LS learning about gateways within the ITAD by
of an intra-domain protocol. There need not be an intra-
protocol. An LS may operate without knowledge of any locally
gateways. Or, it may know of locally run gateways, but through
configuration. An LS may also be co-resident with a gateway, in
case it would know about the gateway that it is co-resident with
Rosenberg & Schulzrinne Informational [Page 15]
RFC 2871 TRIP Framework June 2000
9 Element
9.1 Gateways and Location
Gateways must somehow propagate information about
characteristics to an LS within the same ITAD. This LS may, in turn
further propagate this information outside of the ITAD by means
TRIP. This LS is called an originating LS for that gateway. When
LS nis not coresident with the gateway, the means by which
information gets propagated is not within the scope of TRIP.
protocol used to accomplish this is generally called an intra-
protocol
One way in which the information can be propagated is with
Service Location Protocol (SLP) [7]. The gateway can contain
Service Agent (SA), and the LS can act as a Directory Agent (DA).
defines procedures by which service information is
propagated to DA's from SA's. In this fashion, an LS can learn
gateways in the ITAD
An alternate mechanism for the intra-domain protocol is via
registration procedures of SIP or H.323. The registration
provide a means by which users inform a gatekeeper or SIP
about their address. Such a registration procedure could be
to allow a gateway to effectively register as well
LDAP [8] might also be used for the intra-domain protocol. A
can use LDAP to add an entry for itself into the database. If the
also plays the role of the LDAP server, it will be able to
about all those gateways in its ITAD
The intra-domain protocol which is used may be different from
administrative domain to IT administrative domain, and is a matter
local configuration. There may also be more than one intra-
protocol in a particular ITAD. An LS can also function without
intra-domain protocol. It may learn about gateways through
configuration, or may not know of any local gateways
9.2 Location Server to Location
The interaction between LS's is what is defined by TRIP. LS's
the same ITAD use TRIP to synchronize information amongst themselves
LS's within different ITADs use TRIP to exchange gateway
according to policy. In the former case the LS's are referred to
internal peers, and in the latter case, external peers
Rosenberg & Schulzrinne Informational [Page 16]
RFC 2871 TRIP Framework June 2000
LS's communicate with each other through persistent associations.
LS may be connected to one or more other LS's. LS's need not
physically adjacent or part of the same autonomous system.
association between a pair of LS's is normally set
administratively. Two LS's are configured to communicate with
other when their administrators have an agreement in place
exchange gateway information. While TRIP does not provide
autodiscovery procedure for peer LS's to discover each other,
could possibly be used. Such a procedure might be useful for
a backup peer LS when a crash occurs. Alternatively, in
environment where the business relationships between peers
more standardized, peers might be allowed to discover each
through protocols like the Service Location Protocol (SLP) [9].
Determination about whether autodiscovery should or should not
used is at the discretion of the administrator
The syntax and semantics of the messages exchanged over
association between LS's are dictated by TRIP. The protocol does
dictate the nature of the agreements which must be in place.
merely provides a transport means to exchange whatever
routing information is deemed appropriate by the administrators
the system. Details are provided in the TRIP protocol
itself
The rules which govern which gateway information is generated
propagated, and accepted by a gateway is called a location
policy. TRIP does not dictate or mandate any specific policy
9.2.1 Nature of Exchanged
The information exchanged by the LS's is a set of routing objects
Each routing object minimally consists of a range of
numbers which are reachable, and an IP address or host name which
the application-layer "next hop" towards a gateway which can
that range. Routing objects are learned from the intra-
protocol, static configuration, or from LS's in remote ITAD's. An
may aggregate these routing objects together (merging ranges
telephone numbers, and replacing the IP address with its own
address, or with the IP address of a signaling server with which
LS is communicating) and then propagate them to another LS.
decision about which objects to aggregate and propagate is known as
route selection operation. The administrator has great latitude
selecting which objects to aggregate and propagate, so long as
are within the bounds of correct protocol operation (i.e., no
are formed). The selection can be made based on information
through TRIP, or through any out of band means
Rosenberg & Schulzrinne Informational [Page 17]
RFC 2871 TRIP Framework June 2000
A routing object may have additional information which
the service at the gateway. These attributes include things
protocols, features supported, and capacity. Greater numbers
attributes can provide useful information, however, they come at
cost. Aggregation becomes difficult with more and more information
impacting the scalability of the protocol
Aggregation plays a central role in TRIP. In order to
scalability, routing objects can be combined into larger
before being propagated. The mechanisms by which this is done
specified in TRIP. Aggregation of application layer routes
gateways is a non-trivial problem. There is a fundamental
between aggregatability and verbosity. The more information that
present in a TRIP routing object, the more difficult it is
aggregate
Consider a simple example of two gateways, A and B, capable
reaching some set of telephone numbers, X and Y, respectively. C
an LS for the ITAD in which A and B are resident. C learns of A and
through some other means. As it turns out, X and Y can be
into a single address range, Z. C has several options. It
propagate just the advertisement for A, just the advertisement for B
propagate both, or combine them and propagate the
advertisement. In this case C chooses the latter approach, and
a single routing object to one of its peers, D, containing
range Z and its own address, since it is also a signaling server.
is also a signaling server
Some calling device, E, wishes to place a phone call to
number T, which happens to be in the address range X. E is
to use D as its default H.323 gatekeeper. So, E sends a call
message to D, containing destination address T. D determines that
address T is within the range Z. As D had received a routing
from C containing address range Z, it forwards the call setup
to C. C, in turn, sees that T is within range X, and so it
the call setup to A, which terminates the call signaling
initiates a call towards the telephone network
9.2.2 Quality of
One of the factors which is useful to consider when selecting
gateway is "QoS" - will a call through this gateway
sufficiently low loss, delay, and jitter? The quality of a
depends on two components - the QoS on the path between the
and gateway, and the capacity of the gateway itself (measured
terms of number of circuits available, link capacity, DSP resources
etc.). Determination of the latter requires intricate knowledge
Rosenberg & Schulzrinne Informational [Page 18]
RFC 2871 TRIP Framework June 2000
underlying network topologies, and of where the caller is located
This is something handled by QoS routing protocols, and is
the scope of TRIP
However, gateway capacity is not dependent on the caller location
path characteristics. For this reason, a capacity metric of some
is supported by TRIP. This metric represents the static capacity
the gateway, not the dynamic available capacity which
continuously during the gateways operation. LS's can use this
as a means of load balancing of calls among gateways. It can also
used as an input to any other policy decision
9.2.3 Cost
Another useful attribute to propagate is a pricing metric. This
represent the amount a particular gateway might charge for a call
The metric can be an index into a table that defines a
structure according to a pre-existing business arrangement, or it
contain a representation of the price itself. TRIP itself does
define a pricing metric, but one can and should be defined as
extension. Using an extension for pricing means more than one
metric can be defined
10 The Front
As a result of TRIP, the LS builds up a database (the TRIB)
gateway routes. This information is made available to
entities within the ITAD. The way in which this information is
available is called the front end. It is the visible means by
TRIP services are exposed outside of the protocol
10.1 Front End
There are several entities which might use the front end to
the TRIB. These include, but are not limited to
Signaling Servers: Signaling servers receive signaling
(such as H.323 or SIP messages) whose purpose is the
of IP telephony calls. The destination address of these
may be a phone number corresponding to a terminal on the GSTN
In order to route these calls to an appropriate gateway,
signaling server will need access to the database built up
the LS
End Users: End users can directly query the LS to get
information. This allows them to provide detailed information
their requirements. They can then go and contact the next
signaling server or gateway towards that phone number
Rosenberg & Schulzrinne Informational [Page 19]
RFC 2871 TRIP Framework June 2000
Administrators: Administrators may need to access the TRIB
maintenance and management functions
When a signaling server contacts the LS to route a phone number,
is usually doing so because a calling device (on behalf of an
user) has attempted to set up a call. As a result, signaling
effectively act as proxies for end users when accessing the
database. The communication between the calling devices and
proxies (the signaling servers) is through the signaling protocol
The advantage of this proxy approach is that the actual
interaction is hidden from the calling device. Therefore, whether
call is to a phone number or IP address is irrelevant. The routing
the case of phone numbers takes place transparently. Proxy mode
also advantageous for thin clients (such as standalone IP telephones
which do not have the interfaces or processing power for a
query of the LS
The disadvantage of the proxy approach is the same as its advantage -
the LS interaction is hidden from the calling device (and thus
end user). In some cases, the end user may have requirements as
how they would like the call to be routed. These include
about cost, quality, administrator, or call services and protocols
These requirements are called the end user policy. In the
approach, the user effectively accesses the service through
signaling protocol. The signaling protocol is not likely to be
to support expression of complex call routing preferences from
users (note however, that SIP does support some forms of
preferences for call routing [10]). Therefore, direct access from
end user to the LS can provide much richer call routing services
When the end user policy is presented to the LS (either directly
through the signaling protocol), it is at the discretion of the
how to make use of it. The location server may have its own
regarding how end user preferences are handled
10.2 Front End
There are numerous protocols that can be used in the front end
access the LS database. TRIP does not specify or restrict
possibilities for the front end. It is not clear that it is
or even desirable for there to be a single standard for the
end. The various protocols have their strengths and weaknesses.
may be the right solution in some cases, and another in
cases
Rosenberg & Schulzrinne Informational [Page 20]
RFC 2871 TRIP Framework June 2000
Some of the possible protocols for the front end are
Service Location Protocol (SLP): SLP has been designed to
exactly this kind of function. SLP is ideal for locating
described by a set of attributes. In this case, the server is
gateway (or next hop towards the gateway), and the
are the end user policy. The end user is an SLP UA, and the
is an SLP DA. The Service Query is used to ask for a
with a particular set of attributes
Open Settlements Protocol (OSP): OSP [11] is a client
protocol. It allows the client to query a server with a
number, and get back the address of a next hop, along
authorization tokens to use for the call. In this case,
server can be an LS. The routing table it uses to respond to
queries is the one built up using TRIP
Lightweight Directory Access Protocol (LDAP): LDAP is used
accessing distributed databases. Since the LS server contains
database, LDAP could be used to query it
Web Page: The LS could have a web front end. Users could
queries into a form, and the matching gateways returned in
response. This access mechanism is more appropriate for
access, however. A signaling server would not likely access
front end through a web page
TRIP: The protocols discussed above are all of the query-
type. There is no reason why the LS access must be of this form
It is perfectly acceptable for the access to be through
database synchronization, so that the entity accessing the
database effectively has a full copy of it. If this
were desired, TRIP itself is an appropriate mechanism.
approach has obvious drawbacks, but nothing precludes it
being done
11 Number
The model for TRIP is that of many gateways, each of which is
to terminate calls towards some set of phone numbers. Often, this
will be based on the set of telephone numbers which are in
geographic proximity to the gateway. For example, a gateway in
York might be willing to terminate calls to the 212 and 718
codes. Of course, it is up to the administrator to decide on
phone numbers the gateway is willing to call
Rosenberg & Schulzrinne Informational [Page 21]
RFC 2871 TRIP Framework June 2000
However, certain phone numbers don't represent GSTN terminals at all
but rather they represent services or virtual addresses. An
of such numbers are freephone and LNP numbers. In the
network, these are actually mapped to routable telephone numbers
often based on complex formulae. A classic example is time-of-day
based translation
While nothing prevents a gateway from advertising reachability
these kinds of numbers, this usage is highly discouraged. Since
is a routing protocol, the routes it propagates should be to
numbers, not to names which are eventually translated to
numbers. Numerous problems arise when TRIP is used to
routes to these numbers
o Often, these numbers have only local significance. Calls to
freephone number made from New York might terminate in a
York office of a company, while calls made from
will terminate in a California branch. If this
number is injected into TRIP by a gateway in New York,
could be propagated to other LS's with end users
California. If this route is used, calls may be not be
as intended
o The call signaling paths might be very suboptimal. Consider
gateway in New York that advertises a ported number that
to a phone in California. This number is propagated by TRIP
eventually being learned by an LS with end users
California. When one of them dials this number, the call
routed over the IP network towards New York, where it hits
gateway, and then is routed over the GSTN back to California
This is a waste of resources. Had the ported number
translated before the gateway routing function was invoked,
California gateway could have been accessed directly
As a result, it is more efficient to perform translations of
special numbers before the LS routing databases are accessed.
this translation is done is outside the scope of TRIP. It can
accomplished by the calling device before making the call, or by
signaling server before it accesses the LS database
12 Security
Security is an important component in TRIP. The TRIP model assumes
level of trust between peer LS's that exchange information.
information is used to propagate information which determines
calls will be routed. If this information were incorrect, it
cause complete misrouting of calls. This enables a significant
of service attack. The information might also be propagated to
Rosenberg & Schulzrinne Informational [Page 22]
RFC 2871 TRIP Framework June 2000
ITADs, causing the problem to potentially spread. As a result,
authentication of peer LS's is critical. Furthermore,
integrity is required
TRIP messages may contain potentially sensitive information.
represent the routing capabilities of an ITAD. Such information
be used by corporate competitors to determine the network
and capacity of the ITAD. As a result, encryption of messages is
supported in TRIP
As routing objects can be passed via one LS to another, there is
need for some sort of end to end authentication as well. However
aggregation will cause the routing objects to be modified,
therefore authentication can only take place from the point of
aggregation to the receiving LS's
13
The authors would like to thank Randy Bush, Mark Foster, Dave Oran
Hussein Salama, and Matt Squire for their useful comments on
document
14
[1] International Telecommunication Union, "Visual telephone
and equipment for local area networks which provide a non
guaranteed quality of service," Recommendation H.323,
Telecommunication Standardization Sector of ITU, Geneva
Switzerland, May 1996.
[2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[3] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett
"Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
October 1999.
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[5] Simpson, W., "The Point-to-Point Protocol (PPP)," STD 51,
1661, July 1994.
[6] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
1771, March 1995.
[7] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "
Location Protocol", RFC 2165, June 1997.
Rosenberg & Schulzrinne Informational [Page 23]
RFC 2871 TRIP Framework June 2000
[8] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
Protocol", RFC 1777, March 1995.
[9] Guttman, E., Perkins, C., Veizades, J. and M. Day, "
Location Protocol, Version 2", RFC 2608, June 1999.
[10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences
callee capabilities", Work in progress
[11] European Telecommunications Standards Institute (ETSI),
Telecommunications and Internet Protocol Harmonization
Networks (TIPHON), "Inter-domain pricing, authorization,
usage exchange," Technical Specification 101 321 version 1.4.2,
ETSI, 1998.
15 Authors'
Jonathan
72 Eagle Rock
First
East Hanover, NJ 07936
Email: jdrosen@dynamicsoft.
Henning
Columbia
M/S 0401
1214 Amsterdam Ave
New York, NY 10027-7003
Email: schulzrinne@cs.columbia.
Rosenberg & Schulzrinne Informational [Page 24]
RFC 2871 TRIP Framework June 2000
16. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Rosenberg & Schulzrinne Informational [Page 25]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
