doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc2871.txt b/doc/rfc/rfc2871.txt
new file mode 100644
index 0000000..349b21e
--- /dev/null
+++ b/doc/rfc/rfc2871.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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:
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 5]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+      o Establishment and maintenance of peering relationships between
+        providers;
+
+      o Exchange and synchronization of telephony gateway routing
+        information between providers;
+
+      o Prevention of stable routing loops for IP telephony signaling
+        protocols;
+
+      o Propagation of learned gateway routing information to other
+        providers in a timely and scalable fashion;
+
+      o Definition of the syntax and semantics of the data which
+        describe telephony gateway routes.
+
+   TRIP can be generally summarized as an inter-domain IP telephony
+   gateway routing protocol.
+
+4 Related Problems
+
+   At a high level, the problem TRIP solves appears to be a mapping
+   problem: given an input telephone number, determine, based on some
+   criteria, the address of a telephony gateway. For this reason, the
+   gateway location problem is often called a "phone number to IP
+   address translation problem". This is an over-simplification,
+   however. There are at least three separate problems, all of which can
+   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 a
+        circuit switched network, determine the IP address of a
+        gateway capable of completing a call to that phone number.
+
+      o Given a phone number that corresponds to a specific host on
+        the Internet (this host may have a phone number in order to
+        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 terminal
+        on a circuit switched network, determine the IP address of an
+        IP terminal which is owned by the same user.
+
+   The last of these three mapping functions is useful for services
+   where the PC serves as an interface for the phone. One such service
+   is the delivery of an instant message to a PC when the user's phone
+   rings. To deliver this service, a switch in the GSTN is routing a
+   call towards a phone number. It wishes to send an Instant Message to
+   the PC for this user. This switch must somehow have access to the IP
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 6]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+   network, in order to determine the IP address of the PC corresponding
+   to the user with the given phone number. The mapping function is a
+   name to address translation problem, where the name happens to be
+   represented by a string of digits. Such a translation function is
+   best supported by directory protocols. This problem is not addressed
+   by TRIP.
+
+   The second of these mappings is needed to facilitate calls from
+   traditional phones to IP terminals. When a user on the GSTN wishes to
+   call a user with a terminal on the IP network, they need to dial a
+   number identifying that terminal. This number could be an IP address.
+   However, IP addresses are often ephemeral, assigned on demand by DHCP
+   [4] or by dialup network access servers using PPP [5]. The number
+   could be a hostname, obtained through some translation of groups of
+   numbers to letters. However, this is cumbersome. It has been proposed
+   instead to assign phone numbers to IP telephony terminals. A caller
+   on the GSTN would then dial this number as they would any other. This
+   number serves as an alternate name for the IP terminal, in much the
+   same way its hostname serves as a name. A switch in the GSTN must
+   then access the IP network, and obtain the mapping from this number
+   to an IP address for the PC. Like the previous case, this problem is
+   a name to address translation problem, and is best handled by a
+   directory protocol. It is not addressed by TRIP.
+
+   The first mapping function, however, is fundamentally an address to
+   route translation problem. It is this problem which is considered by
+   TRIP. As discussed in Section 3, this mapping depends on local
+   factors such as policies and provider relationships. As a result, the
+   database of available gateways is substantially different for each
+   provider, and needs to be built up through specific inter-provider
+   relationships. It is for this reason that a directory protocol is not
+   appropriate for TRIP, whereas it is appropriate for the others.
+
+5 Relationship with BGP
+
+   TRIP can be classified as a close cousin of inter-domain IP routing
+   protocols, such as BGP [6]. However, there are important differences
+   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 many
+        intermediate networks and IP service providers. BGP runs
+        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 routes
+        to application layer devices, not IP routers, as is done with
+        BGP.
+
+      o TRIP assumes the existence of an underlying IP transport
+        network. This means that servers which exchange TRIP routing
+        information need not act as forwarders of signaling messages
+        that are routed based on this information. This is not true in
+        BGP, where the peers must also act as forwarding points (or
+        name an adjacent forwarding hop) for IP packets.
+
+      o The purpose of TRIP is not to establish global connectivity
+        across all ITADs. It is perfectly reasonable for there to be
+        many small islands of TRIP connectivity. Each island
+        represents a closed set of administrative relationships.
+        Furthermore, each island can still have complete connectivity
+        to the entire GSTN. This is in sharp contrast to BGP, where
+        the goal is complete connectivity across the Internet. If a
+        set of AS's are isolated from some other set because of a BGP
+        disconnect, no IP network connectivity exists between them.
+
+      o Gateway routes are far more complex than IP routes (since they
+        reside at the application, not the network layer), with many
+        more parameters which may describe them.
+
+      o BGP exchanges prefixes which represent a portion of the IP
+        name space. TRIP exchanges phone number ranges, representing a
+        portion of the GSTN numbering space. The organization and
+        hierarchies in these two namespaces are different.
+
+   These differences means that TRIP borrows many of the concepts from
+   BGP, but that it is still a different protocol with its own specific
+   set of functions.
+
+6 Example Applications of TRIP
+
+   TRIP is a general purpose tool for exchanging IP telephony routes
+   between providers. TRIP does not, in any way, dictate the structure
+   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 Clearinghouses
+
+   A clearinghouse is a provider that serves as an exchange point
+   between a number of other providers, called the members of the
+   clearinghouse. Each member signs on with the clearinghouse. As part
+   of the agreement, the member makes their gateways available to the
+   other members of the clearinghouse. In exchange, the members have
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 8]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+   access to the gateways owned by the other members of the
+   clearinghouse. When a gateway belonging to one member makes a call,
+   the clearinghouse plays a key role in determining which member
+   terminates the call.
+
+   TRIP can be applied here as the tool for exchanging routes between
+   the members and the clearinghouse. This is shown in Figure 1.
+
+   There are 6 member companies, M1 through M6. Each uses TRIP to send
+   and receive gateway routes with the clearinghouse provider.
+
+6.2 Confederations
+
+   We refer to a confederation as a group of providers which all agree
+   to share gateways with each other in a full mesh, without using a
+   central clearinghouse. Such a configuration is shown in Figure 2.
+   TRIP would run between each pair of providers.
+
+6.3 Gateway Wholesalers
+
+          ------                                  ------
+         |      |                                |      |
+         | M1   |    TRIP                 TRIP   |  M2  |
+         |      |\    |                    |    /|      |
+          ------  \   |                    |   /  ------
+                   \ \ /   -------------- \ / /
+          ------    \----|              |----/    ------
+         |      |        |              |        |      |
+         | M3   |--------| Clearinghouse|--------|  M4  |
+         |      |        |              |        |      |
+          ------    /----|              |----\    ------
+                   /      --------------      \
+          ------  /                            \  ------
+         |      |/                              \|      |
+         | M5   |                                |  M6  |
+         |      |                                |      |
+          ------                                  ------
+
+
+          Figure 1: TRIP in the Clearinghouse Application
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                      [Page 9]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+                       ------        ------
+                      |      |------|      |
+                      | M1   |      |  M2  |
+                      |      |\    /|      |
+                       ------  \  /  ------
+                         |      \/     |
+                         |      /\     |<-----TRIP
+                       ------  /  \  ------
+                      |      |/    \|      |
+                      | M3   |      |  M4  |
+                      |      |------|      |
+                       ------        ------
+
+
+                 Figure 2: TRIP for Confederations
+
+   In this application, there are a number of large providers of
+   telephony gateways. Each of these resells its gateway services to
+   medium sized providers. These, in turn, resell to local providers who
+   sell directly to consumers. This is effectively a pyramidal
+   relationship, as shown in Figure 3.
+
+                             ------
+                            |      |
+                            |  M1  |
+                            |      |
+                             ------
+                           /       \ <------- TRIP
+                      ------        ------
+                     |      |      |      |
+                     |  M2  |      |  M3  |
+                     |      |      |      |
+                      ------        ------
+                     /      \      /      \
+               ------        ------        ------
+              |      |      |      |      |      |
+              | M4   |      | M5   |      | M6   |
+              |      |      |      |      |      |
+               ------        ------        ------
+
+                Figure 3: TRIP for Wholesalers
+
+   Note that in this example, provider M5 resells gateways from both M2
+   and M3.
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 10]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+7 Architecture
+
+   Figure 4 gives the overall architecture of TRIP.
+
+           ITAD1                                ITAD2
+      -----------------                ------------------
+     |                  |             |                  |
+     |  ----            |             |           ----   |
+     | | GW |           |             |          | EU |  |
+     |  ----  \  ----   |             |  ----  /  ----   |
+     |          | LS | ---------------- | LS |           |
+     |  ----     ----   |             /  ----  \  ----   |
+     | | GW | /         |            /|          | EU |  |
+     |  ----            |           / |           ----   |
+     |                  |          /  |                  |
+      ------------------          /    ------------------
+                                 /
+                                /
+                     --------- /----------
+                    |         |           |
+                    |        ----         |
+                    |       | LS |        |
+                    |     /  ---- \       |
+                    |  ----   ||   ----   |
+                    | | GW |  ||  | EU |  |
+                    |  ----   ||   ----   |
+                    |  ----   ||   ----   |
+                    | | GW | /  \ | EU |  |
+                    |  ----        ----   |
+                    |                     |
+                     ---------------------
+                              ITAD3
+
+                  Figure 4: TRIP Architecture
+
+   There are a number of Internet Telephony administrative domains
+   (ITAD's), each of which has at least one Location Server (LS). The
+   LS's, through an out-of-band means, called the intra-domain protocol,
+   learn about the gateways in their domain. The intra-domain protocol
+   is represented by the lines between the GW and LS elements in ITAD1
+   in the Figure. The LS's have associations with other LS's, over which
+   they exchange gateway information. These associations are established
+   administratively, and are set up when the IT administrative domains
+   have some kind of agreements in place regarding exchange of gateway
+   information. In the figure, the LS in ITAD1 is connected to the LS in
+   ITAD2, which is in turn connected to the LS in ITAD3. Through
+   Telephony Routing over IP (TRIP), the LS in ITAD2 learns about the
+   two gateways in ITAD1. This information is accessed by end users
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 11]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+   (EUs) in ITAD2 through the front-end. The front-end is a non-TRIP
+   protocol or mechanism by which the LS databases are accessed. In
+   ITAD3, there are both EUs and gateways. The LS in ITAD3 learns about
+   the gateways in ITAD1 through a potentially aggregated advertisement
+   from the LS in ITAD2.
+
+8 Elements
+
+   The architecture in Figure 4 consists of a number of elements. These
+   include the IT administrative domain, end user, gateway, and location
+   server.
+
+8.1 IT Administrative Domain
+
+   An IT administrative domain consists of zero or more gateways, at
+   least one Location Server, and zero or more end users. The gateways
+   and LS's are those which are under the administrative control of a
+   single authority. This means that there is one authority responsible
+   for dictating the policies and configuration of the gateways and
+   LS's.
+
+   An IT administrative domain need not be the same as an autonomous
+   system. While an AS represents a set of physically connected
+   networks, an IT administrative domain may consist of elements on
+   disparate networks, and even within disparate autonomous systems.
+
+   The end users within an IT administrative domain are effectively the
+   customers of that IT administrative domain. They are interested in
+   completing calls towards the telephone network, and thus need access
+   to gateways. An end user may be a customer of one IT administrative
+   domain for one call, and then a customer of a different one for the
+   next call.
+
+   An IT administrative domain need not have any gateways. In this case,
+   its LS learns about gateways in other domains, and makes these
+   available to the end users within its domain. In this case, the IT
+   administrative domain is effectively a virtual IP telephony gateway
+   provider. This is because it provides gateway service, but may not
+   actually own or administer any gateways.
+
+   An IT administrative domain need not have any end users. In this
+   case, it provides "wholesale" gateway service, making its gateways
+   available to customers in other IT administrative domains.
+
+   An IT administrative domain need not have gateways nor end users. In
+   this case, the ITAD only has LS's. The ITAD acts as a reseller,
+   learning about other gateways, and then aggregating and propagating
+   this information to other ITAD's which do have customers.
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 12]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+8.2 Gateway
+
+   A gateway is a logical device which has both IP connectivity and
+   connectivity to some other network, usually a public or private
+   telephone network. The function of the gateway is to translate the
+   media and signaling protocols from one network technology to the
+   other, achieving a transparent connection for the users of the
+   system.
+
+   A gateway has a number of attributes which characterize the service
+   it provides. Most fundamental among these are the range of phone
+   numbers to which it is willing to provide service. This range may be
+   broken into subranges, and associated with each, some cost metric or
+   cost token. This token indicates some notion of cost or preference
+   for completing calls for this part of the telephone number range.
+
+   A gateway has attributes which characterize the volume of service
+   which it can provide. These include the number of ports it has (i.e.,
+   the number of simultaneous phone calls it can support), and the
+   access link speed. These two together represent some notion of the
+   capacity of the gateway. The metric is useful for allowing Location
+   Servers to decide to route calls to gateways in proportion to the
+   value of the metric, thus achieving a simple form of load balancing.
+
+   A gateway also has attributes which characterize the type of service
+   it provides. This includes, but is not limited to, signaling
+   protocols supported, telephony features provided, speech codecs
+   understood, and encryption algorithms which are implemented. These
+   attributes may be important in selecting a gateway. In the absence of
+   baseline required features across all gateways (an admirable, but
+   difficult goal), such a set of attributes is required in order to
+   select a gateway with which communications can be established. End
+   users which have specific requirements for the call (such as a user
+   requesting a business class call, in which case certain call features
+   may need to be supported) may wish to make use of such information as
+   well.
+
+   Some of these attributes are transported in TRIP to describe
+   gateways, and others are not. This depends on whether the metric can
+   be reasonably aggregated, and whether it is something which must be
+   conveyed in TRIP before the call is set up (as opposed to negotiated
+   or exchanged by the signaling protocols themselves). The philosophy
+   of TRIP is to keep it simple, and to favor scalability above
+   abundance of information. TRIP's attribute set is readily extensible.
+   Flags provide information that allow unknown attributes to be
+   reasonably processed by an LS.
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 13]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+8.3 End Users
+
+   An end user is an entity (usually a human being) which wishes to
+   complete a call through a gateway from an IP network to a terminal on
+   a telephone network. An end user may be a user logged on at a PC with
+   some Internet telephony software. The end user may also be connected
+   to the IP network through an ingress telephone gateway, which the
+   user accessed from telephone handset. This is the case for what is
+   referred to as "phone to phone" service with the IP network used for
+   interexchange transport.
+
+   End users may, or may not be aware that there is a telephony routing
+   service running when they complete a call towards the telephone
+   network. In cases where they are aware, end users may have
+   preferences for how a call is completed. These preferences might
+   include call features which must be supported, quality metrics, owner
+   or administrator, and cost preferences.
+
+   TRIP does not dictate how these preferences are combined with those
+   of the provider to yield the final gateway selection. Nor does TRIP
+   support the transport of these preferences to the LS. This transport
+   can be accomplished using the front end, or by some non-protocol
+   means.
+
+8.4 Location Server
+
+   The Location Server (LS) is the main functional entity of TRIP.  It
+   is a logical device which has access to a database of gateways,
+   called the Telephony Routing Information Base (TRIB). This database
+   of gateways is constructed by combining the set of locally available
+   gateways and the set of remote gateways (learned through TRIP) based
+   on policy. The LS also exports a set of gateways to its peer LS's in
+   other ITAD's. The set of exported gateways is constructed from the set
+   of local gateways and the set of remote gateways (learned through
+   TRIP) based on policy. As such, policy plays a central role in the LS
+   operation. This flow of information is shown in Figure 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 14]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+                          |
+                          |Intra-domain protocol
+                         \ /
+                        Local
+                       Gateways
+
+
+   TRIP-->  Gateways    POLICY     Gateways -->TRIP
+                IN                     Out
+                             |
+                            \ /
+                      Telephony Routing
+                      Information Base
+
+            Figure 5: Flow of Information in TRIP
+
+   The TRIB built up in the LS allows it to make decisions about IP
+   telephony call routing. When a signaling message arrives at a
+   signaling server, destined for a telephone network address, the LS's
+   database can provide information which is useful for determining a
+   gateway or an additional signaling server to forward the signaling
+   message to. For this reason, an LS may be coresident with a signaling
+   server. When they are not coresident, some means of communication
+   between the LS and the signaling server is needed. This communication
+   is not specifically addressed by TRIP, although it is possible that
+   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, communications
+   between these LS's may need to take place in order to synchronize
+   databases and share information learned from external peers. This is
+   often referred to as the interior component of an inter-domain
+   protocol. TRIP includes such a function.
+
+   Figure 5 shows an LS learning about gateways within the ITAD by means
+   of an intra-domain protocol. There need not be an intra-domain
+   protocol. An LS may operate without knowledge of any locally run
+   gateways. Or, it may know of locally run gateways, but through static
+   configuration. An LS may also be co-resident with a gateway, in which
+   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 Interactions
+
+9.1 Gateways and Location Servers
+
+   Gateways must somehow propagate information about their
+   characteristics to an LS within the same ITAD. This LS may, in turn,
+   further propagate this information outside of the ITAD by means of
+   TRIP. This LS is called an originating LS for that gateway. When an
+   LS nis not coresident with the gateway, the means by which the
+   information gets propagated is not within the scope of TRIP.  The
+   protocol used to accomplish this is generally called an intra-domain
+   protocol.
+
+   One way in which the information can be propagated is with the
+   Service Location Protocol (SLP) [7]. The gateway can contain a
+   Service Agent (SA), and the LS can act as a Directory Agent (DA). SLP
+   defines procedures by which service information is automatically
+   propagated to DA's from SA's. In this fashion, an LS can learn about
+   gateways in the ITAD.
+
+   An alternate mechanism for the intra-domain protocol is via the
+   registration procedures of SIP or H.323. The registration procedures
+   provide a means by which users inform a gatekeeper or SIP server
+   about their address. Such a registration procedure could be extended
+   to allow a gateway to effectively register as well.
+
+   LDAP [8] might also be used for the intra-domain protocol.  A gateway
+   can use LDAP to add an entry for itself into the database. If the LS
+   also plays the role of the LDAP server, it will be able to learn
+   about all those gateways in its ITAD.
+
+   The intra-domain protocol which is used may be different from IT
+   administrative domain to IT administrative domain, and is a matter of
+   local configuration. There may also be more than one intra-domain
+   protocol in a particular ITAD. An LS can also function without an
+   intra-domain protocol. It may learn about gateways through static
+   configuration, or may not know of any local gateways.
+
+9.2 Location Server to Location Server
+
+   The interaction between LS's is what is defined by TRIP.  LS's within
+   the same ITAD use TRIP to synchronize information amongst themselves.
+   LS's within different ITADs use TRIP to exchange gateway information
+   according to policy. In the former case the LS's are referred to as
+   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. An
+   LS may be connected to one or more other LS's. LS's need not be
+   physically adjacent or part of the same autonomous system. The
+   association between a pair of LS's is normally set up
+   administratively. Two LS's are configured to communicate with each
+   other when their administrators have an agreement in place to
+   exchange gateway information. While TRIP does not provide an
+   autodiscovery procedure for peer LS's to discover each other, one
+   could possibly be used. Such a procedure might be useful for finding
+   a backup peer LS when a crash occurs. Alternatively, in an
+   environment where the business relationships between peers become
+   more standardized, peers might be allowed to discover each other
+   through protocols like the Service Location Protocol (SLP) [9].
+   Determination about whether autodiscovery should or should not be
+   used is at the discretion of the administrator.
+
+   The syntax and semantics of the messages exchanged over the
+   association between LS's are dictated by TRIP.  The protocol does not
+   dictate the nature of the agreements which must be in place. TRIP
+   merely provides a transport means to exchange whatever gateway
+   routing information is deemed appropriate by the administrators of
+   the system. Details are provided in the TRIP protocol specification
+   itself.
+
+   The rules which govern which gateway information is generated,
+   propagated, and accepted by a gateway is called a location server
+   policy. TRIP does not dictate or mandate any specific policy.
+
+9.2.1 Nature of Exchanged Information
+
+   The information exchanged by the LS's is a set of routing objects.
+   Each routing object minimally consists of a range of telephone
+   numbers which are reachable, and an IP address or host name which is
+   the application-layer "next hop" towards a gateway which can reach
+   that range. Routing objects are learned from the intra-domain
+   protocol, static configuration, or from LS's in remote ITAD's. An LS
+   may aggregate these routing objects together (merging ranges of
+   telephone numbers, and replacing the IP address with its own IP
+   address, or with the IP address of a signaling server with which the
+   LS is communicating) and then propagate them to another LS. The
+   decision about which objects to aggregate and propagate is known as a
+   route selection operation. The administrator has great latitude in
+   selecting which objects to aggregate and propagate, so long as they
+   are within the bounds of correct protocol operation (i.e., no loops
+   are formed). The selection can be made based on information learned
+   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 characterizes
+   the service at the gateway. These attributes include things like
+   protocols, features supported, and capacity. Greater numbers of
+   attributes can provide useful information, however, they come at a
+   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 facilitate
+   scalability, routing objects can be combined into larger aggregates
+   before being propagated. The mechanisms by which this is done are
+   specified in TRIP. Aggregation of application layer routes to
+   gateways is a non-trivial problem. There is a fundamental tradeoff
+   between aggregatability and verbosity. The more information that is
+   present in a TRIP routing object, the more difficult it is to
+   aggregate.
+
+   Consider a simple example of two gateways, A and B, capable of
+   reaching some set of telephone numbers, X and Y, respectively. C is
+   an LS for the ITAD in which A and B are resident. C learns of A and B
+   through some other means. As it turns out, X and Y can be combined
+   into a single address range, Z. C has several options. It can
+   propagate just the advertisement for A, just the advertisement for B,
+   propagate both, or combine them and propagate the aggregate
+   advertisement. In this case C chooses the latter approach, and sends
+   a single routing object to one of its peers, D, containing address
+   range Z and its own address, since it is also a signaling server. D
+   is also a signaling server.
+
+   Some calling device, E, wishes to place a phone call to telephone
+   number T, which happens to be in the address range X. E is configured
+   to use D as its default H.323 gatekeeper. So, E sends a call setup
+   message to D, containing destination address T. D determines that the
+   address T is within the range Z. As D had received a routing object
+   from C containing address range Z, it forwards the call setup message
+   to C. C, in turn, sees that T is within range X, and so it forwards
+   the call setup to A, which terminates the call signaling and
+   initiates a call towards the telephone network.
+
+9.2.2 Quality of Service
+
+   One of the factors which is useful to consider when selecting a
+   gateway is "QoS" - will a call through this gateway suffer
+   sufficiently low loss, delay, and jitter? The quality of a call
+   depends on two components - the QoS on the path between the caller
+   and gateway, and the capacity of the gateway itself (measured in
+   terms of number of circuits available, link capacity, DSP resources,
+   etc.). Determination of the latter requires intricate knowledge of
+
+
+
+
+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 outside
+   the scope of TRIP.
+
+   However, gateway capacity is not dependent on the caller location or
+   path characteristics. For this reason, a capacity metric of some form
+   is supported by TRIP. This metric represents the static capacity of
+   the gateway, not the dynamic available capacity which varies
+   continuously during the gateways operation. LS's can use this metric
+   as a means of load balancing of calls among gateways. It can also be
+   used as an input to any other policy decision.
+
+9.2.3 Cost Information
+
+   Another useful attribute to propagate is a pricing metric. This might
+   represent the amount a particular gateway might charge for a call.
+   The metric can be an index into a table that defines a pricing
+   structure according to a pre-existing business arrangement, or it can
+   contain a representation of the price itself. TRIP itself does not
+   define a pricing metric, but one can and should be defined as an
+   extension. Using an extension for pricing means more than one such
+   metric can be defined.
+
+10 The Front End
+
+   As a result of TRIP, the LS builds up a database (the TRIB) of
+   gateway routes. This information is made available to various
+   entities within the ITAD. The way in which this information is made
+   available is called the front end. It is the visible means by which
+   TRIP services are exposed outside of the protocol.
+
+10.1 Front End Customers
+
+   There are several entities which might use the front end to access
+   the TRIB. These include, but are not limited to:
+
+     Signaling Servers: Signaling servers receive signaling messages
+        (such as H.323 or SIP messages) whose purpose is the initiation
+        of IP telephony calls. The destination address of these calls
+        may be a phone number corresponding to a terminal on the GSTN.
+        In order to route these calls to an appropriate gateway, the
+        signaling server will need access to the database built up in
+        the LS.
+
+     End Users: End users can directly query the LS to get routing
+        information. This allows them to provide detailed information on
+        their requirements. They can then go and contact the next hop
+        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 for
+        maintenance and management functions.
+
+   When a signaling server contacts the LS to route a phone number, it
+   is usually doing so because a calling device (on behalf of an end
+   user) has attempted to set up a call. As a result, signaling servers
+   effectively act as proxies for end users when accessing the LS
+   database. The communication between the calling devices and their
+   proxies (the signaling servers) is through the signaling protocol.
+
+   The advantage of this proxy approach is that the actual LS
+   interaction is hidden from the calling device. Therefore, whether the
+   call is to a phone number or IP address is irrelevant. The routing in
+   the case of phone numbers takes place transparently. Proxy mode is
+   also advantageous for thin clients (such as standalone IP telephones)
+   which do not have the interfaces or processing power for a direct
+   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 the
+   end user). In some cases, the end user may have requirements as to
+   how they would like the call to be routed. These include preferences
+   about cost, quality, administrator, or call services and protocols.
+   These requirements are called the end user policy. In the proxy
+   approach, the user effectively accesses the service through the
+   signaling protocol. The signaling protocol is not likely to be able
+   to support expression of complex call routing preferences from end
+   users (note however, that SIP does support some forms of caller
+   preferences for call routing [10]). Therefore, direct access from the
+   end user to the LS can provide much richer call routing services.
+
+   When the end user policy is presented to the LS (either directly or
+   through the signaling protocol), it is at the discretion of the LS
+   how to make use of it. The location server may have its own policies
+   regarding how end user preferences are handled.
+
+10.2 Front End Protocols
+
+   There are numerous protocols that can be used in the front end to
+   access the LS database. TRIP does not specify or restrict the
+   possibilities for the front end. It is not clear that it is necessary
+   or even desirable for there to be a single standard for the front
+   end. The various protocols have their strengths and weaknesses. One
+   may be the right solution in some cases, and another in different
+   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 fit
+        exactly this kind of function. SLP is ideal for locating servers
+        described by a set of attributes. In this case, the server is a
+        gateway (or next hop towards the gateway), and the attributes
+        are the end user policy. The end user is an SLP UA, and the LS
+        is an SLP DA. The Service Query is used to ask for a gateway
+        with a particular set of attributes.
+
+     Open Settlements Protocol (OSP): OSP [11] is a client server
+        protocol. It allows the client to query a server with a phone
+        number, and get back the address of a next hop, along with
+        authorization tokens to use for the call. In this case, the
+        server can be an LS. The routing table it uses to respond to OSP
+        queries is the one built up using TRIP.
+
+     Lightweight Directory Access Protocol (LDAP): LDAP is used for
+        accessing distributed databases. Since the LS server contains a
+        database, LDAP could be used to query it.
+
+     Web Page: The LS could have a web front end. Users could enter
+        queries into a form, and the matching gateways returned in the
+        response. This access mechanism is more appropriate for human
+        access, however. A signaling server would not likely access the
+        front end through a web page.
+
+     TRIP: The protocols discussed above are all of the query-response
+        type. There is no reason why the LS access must be of this form.
+        It is perfectly acceptable for the access to be through complete
+        database synchronization, so that the entity accessing the LS
+        database effectively has a full copy of it. If this approach
+        were desired, TRIP itself is an appropriate mechanism. This
+        approach has obvious drawbacks, but nothing precludes it from
+        being done.
+
+11 Number Translations
+
+   The model for TRIP is that of many gateways, each of which is willing
+   to terminate calls towards some set of phone numbers. Often, this set
+   will be based on the set of telephone numbers which are in close
+   geographic proximity to the gateway. For example, a gateway in New
+   York might be willing to terminate calls to the 212 and 718 area
+   codes. Of course, it is up to the administrator to decide on what
+   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 example
+   of such numbers are freephone and LNP numbers. In the telephone
+   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 to
+   these kinds of numbers, this usage is highly discouraged. Since TRIP
+   is a routing protocol, the routes it propagates should be to routable
+   numbers, not to names which are eventually translated to routable
+   numbers. Numerous problems arise when TRIP is used to propagate
+   routes to these numbers:
+
+      o Often, these numbers have only local significance. Calls to a
+        freephone number made from New York might terminate in a New
+        York office of a company, while calls made from California
+        will terminate in a California branch. If this freephone
+        number is injected into TRIP by a gateway in New York, it
+        could be propagated to other LS's with end users in
+        California. If this route is used, calls may be not be routed
+        as intended.
+
+      o The call signaling paths might be very suboptimal. Consider a
+        gateway in New York that advertises a ported number that maps
+        to a phone in California. This number is propagated by TRIP,
+        eventually being learned by an LS with end users in
+        California. When one of them dials this number, the call is
+        routed over the IP network towards New York, where it hits the
+        gateway, and then is routed over the GSTN back to California.
+        This is a waste of resources. Had the ported number been
+        translated before the gateway routing function was invoked, a
+        California gateway could have been accessed directly.
+
+   As a result, it is more efficient to perform translations of these
+   special numbers before the LS routing databases are accessed. How
+   this translation is done is outside the scope of TRIP. It can be
+   accomplished by the calling device before making the call, or by a
+   signaling server before it accesses the LS database.
+
+12 Security Considerations
+
+   Security is an important component in TRIP. The TRIP model assumes a
+   level of trust between peer LS's that exchange information. This
+   information is used to propagate information which determines where
+   calls will be routed. If this information were incorrect, it could
+   cause complete misrouting of calls. This enables a significant denial
+   of service attack. The information might also be propagated to other
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 22]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+   ITADs, causing the problem to potentially spread. As a result, mutual
+   authentication of peer LS's is critical. Furthermore, message
+   integrity is required.
+
+   TRIP messages may contain potentially sensitive information. They
+   represent the routing capabilities of an ITAD. Such information might
+   be used by corporate competitors to determine the network topology
+   and capacity of the ITAD. As a result, encryption of messages is also
+   supported in TRIP.
+
+   As routing objects can be passed via one LS to another, there is a
+   need for some sort of end to end authentication as well. However,
+   aggregation will cause the routing objects to be modified, and
+   therefore authentication can only take place from the point of last
+   aggregation to the receiving LS's.
+
+13 Acknowledgments
+
+   The authors would like to thank Randy Bush, Mark Foster, Dave Oran,
+   Hussein Salama, and Matt Squire for their useful comments on this
+   document.
+
+14 Bibliography
+
+   [1]  International Telecommunication Union, "Visual telephone systems
+        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, RFC
+        1661, July 1994.
+
+   [6]  Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
+        1771, March 1995.
+
+   [7]  Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
+        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 Access
+        Protocol", RFC 1777, March 1995.
+
+   [9]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+        Location Protocol, Version 2", RFC 2608, June 1999.
+
+   [10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences and
+        callee capabilities", Work in progress.
+
+   [11] European Telecommunications Standards Institute (ETSI),
+        Telecommunications and Internet Protocol Harmonization Over
+        Networks (TIPHON), "Inter-domain pricing, authorization, and
+        usage exchange," Technical Specification 101 321 version 1.4.2,
+        ETSI, 1998.
+
+15 Authors' Addresses
+
+   Jonathan Rosenberg
+   dynamicsoft
+   72 Eagle Rock Avenue
+   First Floor
+   East Hanover, NJ 07936
+
+   Email: jdrosen@dynamicsoft.com
+
+
+   Henning Schulzrinne
+   Columbia University
+   M/S 0401
+   1214 Amsterdam Ave.
+   New York, NY 10027-7003
+
+   Email: schulzrinne@cs.columbia.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 24]
+
+RFC 2871                     TRIP Framework                    June 2000
+
+
+16.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne      Informational                     [Page 25]
+