📄 rfc2871.txt
字号:
Network Working Group J. RosenbergRequest for Comments: 2871 dynamicsoftCategory: Informational H. Schulzrinne Columbia University June 2000 A Framework for Telephony Routing over IPStatus 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 ................................ 16Rosenberg & 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 ............................ 251 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 toRosenberg & 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 IPRosenberg & 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⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -