rfc2871.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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