RFC 2871
A Framework for Telephony Routing over IP
RFC 2871: A Framework for Telephony Routing over IP ✨
- Network Working Group 🌸
- Number and title: RFC 2871, A Framework for Telephony Routing over IP
- Authors: J. Rosenberg (dynamicsoft) and H. Schulzrinne (Columbia University) 👑
- Category: Informational
- Date: June 2000
- Obsoletes and updates: this title block doesn't list anything it obsoletes or updates 🦋
Status of this Memo 📜
okay so this memo is just information for the Internet community 💖 it is NOT a standard of any kind, so nobody's required to follow it like a rule. distribution is totally unlimited, so share away 🫶
Copyright Notice ©
Copyright (C) The Internet Society (2000). All Rights Reserved. 💅
Abstract 🎀
so basically this doc is the framework for Telephony Routing over IP (TRIP) 📞✨ TRIP is how IP telephony gateways find out about each other's routing tables and swap them between providers. 🧚 the doc explains the problem of routing exchange, shows why the protocol is needed, lays out the architecture, defines terms, walks through the protocol elements and what they do, gives an overview of the services, and explains how all of it fits into the bigger picture of internet telephony. it's giving main character 👑
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
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 ✨
okay so this section basically repeats the abstract (ngl the vibe is very "previously on...") 🙈 the doc is a framework for Telephony Routing over IP (TRIP), which helps IP telephony gateway routing tables get discovered and exchanged between providers 📞 it defines the telephony routing exchange problem, explains why we need the protocol, presents the architecture, defines terminology, specifies the protocol elements and their functions, overviews the services, and talks about how it fits into internet telephony more broadly 💜
2 Terminology 📚
so we're defining some terms here 🫶 these definitions can be different from what they mean in other contexts, outside of gateway location. they're not meant to be general. they only mean what they mean here 💅
- Gateway: a device with circuit switched network connectivity and IP connectivity 🔌 it can start and end IP telephony signaling protocols, and it can start and end telephone network signaling protocols too. literally the bridge 🌈
- End User: usually (but not always) a human being 🧍♀️ this is the person who is the ultimate starter or receiver of calls 📲
- Calling Device: a physical thing that has IP connectivity 💻 an end user who wants to place a call is in charge of it. the end user might not be directly driving the calling device though. if the calling device is a PC, the end user is literally controlling it. but if the calling device is a telephony gateway, the end user might be reaching it through a telephone ☎️ (the phone-to-gateway glow-up 🎀)
- 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: an entity that can receive and send signaling messages for some IP telephony signaling protocol, like H.323 or SIP 📨 generally, a signaling server is a gatekeeper, a SIP server, or a call agent 💖
- Location Server (LS): a logical entity with IP connectivity that knows about gateways it can use to end calls heading toward the GSTN 🗺️ the LS is the main entity that takes part in Telephony Routing over IP, and it's usually the point of contact for end users trying to complete calls to the telephone network 👑 an LS might also be in charge of spreading gateway info to other LS's 📣 an LS can live alongside an H.323 gatekeeper or SIP server, but it doesn't have to ✨
- 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 that dictate how a location server handles the info it sends and receives via TRIP 📋 this covers rules for aggregating, propagating, generating, and accepting information 🫶
- End User Policy: the preferences an end user has about how a call heading toward the GSTN should be routed 🎯
- Peers: two LS's are peers when they have a persistent association between them that gateway information gets exchanged over 🤝
- Internal peers: peers that both live inside the same ITAD 🏠
- External peers: peers that live inside different ITADs 🌐
- Originating Location Server: a Location Server that is the first to generate a route to a gateway in its ITAD 🚀
- Telephony Routing Information Base (TRIB): the database of gateways an LS builds up from taking part in TRIP 🗃️ it's the LS's whole knowledge base, bestie 🧠
okay that's the end of part 1 🦋 more coming next so stay tuned 💅✨
3. Motivation and Problem Definition ✨
okay so IP telephony gateways keep multiplying and getting more heavily used 📈, and managing them is about to get seriously complicated 😭. One of the hardest jobs is gateway location, which also goes by gateway selection, path selection, gateway discovery, and gateway routing 🧚. Here's the setup: a calling device (a telephony gateway, or a PC running 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. The target lives in a circuit switched network and the caller is on an IP host, so a telephony gateway has to be used 🎀. The gateway is the conversion point for media and signaling, translating between the protocols on the IP network and the ones used in the circuit switched network 🦋.
The gateway is basically a relaying point for an application layer signaling protocol 💅. Lots of gateways could possibly complete the call from the caller on the IP network to the called party on the circuit switched network, so picking one is a non-trivial process 🙈. It's complicated for these reasons:
- Number of Candidate Gateways: as IP telephony gets widely deployed, the number of telephony gateways connecting the Internet to the GSTN is expected to get large 🌈. Being attached to the GSTN means a gateway has connectivity to the nearly one billion terminals reachable on that network. That means every gateway could theoretically complete a call to any terminal on the GSTN, so the number of candidate gateways for a call may be very large 😳.
- Business Relationships: the owner of a gateway is unlikely to make it available to just any user who wants to connect 🙅♀️. The gateway provides a useful service and incurs cost when completing calls towards the circuit switched network. So providers will, in many cases, want to charge for using their gateways 💸. That may restrict usage to users who have some kind of established relationship with the gateway provider.
- Provider Policy: the end user who wants a gateway service probably won't pay the gateway provider directly 🤷♀️. Instead, the end user may have a relationship with an IP telephony service provider that acts as an intermediary to gateway providers. That IP telephony service provider may have gateways of its own too. In that case, it may have policies about how its customers use gateways from other providers 📋. These policies must figure into the selection process.
- End User Policy: sometimes the end user has specific requirements for gateway selection 🎯. They might need a specific feature, or prefer a certain provider. These need to be taken into account too 🫶.
- Capacity: not all gateways are created equal 👑. Some are large and can support hundreds or even thousands of simultaneous calls. Others, like residential gateways, may only support one or two calls 🏠. The selection process should let gateway capacity play a role, and it's 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 not every gateway supports 🙃.
From all of this, it's super evident that gateway selection is driven largely by the policies of various parties and by the relationships those parties have established 💜. So there can't be a global "directory of gateways" where users look up phone numbers 🚫. Instead, information about gateway availability has to be exchanged between providers and, subject to policy, made available locally and then propagated to other providers 📡. This lets each provider build its own local database of available gateways, and that database is very different for each provider depending on its policy 🧩.
So we can conclude that a protocol is needed between administrative domains to exchange gateway routing information 🔥. That protocol is Telephony Routing over IP (TRIP) 🦋. TRIP provides a specific set of functions:
- Establishment and maintenance of peering relationships between providers;
- Exchange and synchronization of telephony gateway routing information between providers;
- Prevention of stable routing loops for IP telephony signaling protocols;
- Propagation of learned gateway routing information to other providers in a timely and scalable fashion;
- 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 looks like a mapping problem 🗺️: given an input telephone number, determine, based on some criteria, the address of a telephony gateway. That's why gateway location is often called a "phone number to IP address translation problem". It's an over-simplification though 🙈. There are at least three separate problems that can all be classified as a "phone number to IP address translation problem", and only one of them is addressed by TRIP:
- 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.
- 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.
- 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 example is delivering an Instant Message to a PC when the user's phone rings 🔔. To do this, a switch in the GSTN is routing a call towards a phone number, and it wants to send an Instant Message to the PC for that user. The switch has to somehow access the IP network so it can determine the IP address of the PC corresponding to the user with the given phone number 🕵️♀️. This mapping is a name to address translation problem, where the name just happens to be a string of digits. Translation like this is best supported by directory protocols 📒. This problem is not addressed by TRIP.
The second mapping is needed to facilitate calls from traditional phones to IP terminals 📞➡️💻. When a user on the GSTN wants to call a user with a terminal on the IP network, they need to dial a number that identifies that terminal. That number could be an IP address. But IP addresses are often ephemeral, assigned on demand by DHCP [4] or by dialup network access servers using PPP [5] 😵. The number could also be a hostname, obtained through some translation of groups of numbers to letters. However, that's cumbersome 🙄. It has instead been proposed to assign phone numbers to IP telephony terminals 🌸. A caller on the GSTN would then dial this number like 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 is a name to address translation problem, and it's best handled by a directory protocol. It is not addressed by TRIP.
The first mapping function is fundamentally an address to route translation problem 💅. This is the problem TRIP considers. 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 🧱. That's exactly why a directory protocol isn't appropriate for TRIP, even though 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:
- TRIP runs at the application layer, not the network layer, where BGP resides.
- TRIP runs between servers which may be separated by many intermediate networks and IP service providers. BGP runs between routers that are usually adjacent.
- The information exchanged between TRIP peers describes routes to application layer devices, not IP routers, as is done with BGP.
- 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.
- 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 😱.
- 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 🤯.
- 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 mean that TRIP borrows many of the concepts from BGP, but 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 in IP telephony 🌈✨.
6.1 Clearinghouses 🎀
okay so a clearinghouse is basically the hub provider 💅 It's a provider that acts as an exchange point between a bunch of other providers, and those are called its members. Each member signs on with the clearinghouse. As part of the deal, the member makes its gateways available to the other members, and in return, the members get access to the gateways owned by everyone else in the clearinghouse 🫶 When a gateway from one member makes a call, the clearinghouse is the one really running the show, because it plays a key role in deciding which member ends up terminating the call 👑
TRIP can be used here to swap gateway routes between the members and the clearinghouse. Check out Figure 1 for the vibe 🦋
------ ------
| | | |
| M1 | TRIP TRIP | M2 |
| |\ | | /| |
------ \ | | / ------
\ \ / -------------- \ / /
------ \----| |----/ ------
| | | | | |
| M3 |--------| Clearinghouse|--------| M4 |
| | | | | |
------ /----| |----\ ------
/ -------------- \
------ / \ ------
| |/ \| |
| M5 | | M6 |
| | | |
------ ------
Figure 1: TRIP in the Clearinghouse ApplicationThere are 6 member companies here, M1 through M6, and each one uses TRIP to send and receive gateway routes with the clearinghouse provider. Six girlies, one hub, zero chaos 🌈
6.2 Confederations 🧚
okay now picture a confederation 🫧 It's a group of providers who all agree to share gateways with each other in a full mesh, so there's no central clearinghouse needed. Every provider is directly connected to every other one, and it's giving equal footing 💜 Figure 2 shows what this looks like, and TRIP would run between each pair of providers.
------ ------
| |------| |
| M1 | | M2 |
| |\ /| |
------ \ / ------
| \/ |
| /\ |<-----TRIP
------ / \ ------
| |/ \| |
| M3 | | M4 |
| |------| |
------ ------
Figure 2: TRIP for Confederations6.3 Gateway Wholesalers 🍓
this one is giving pyramid energy 🔺 There are a number of large providers of telephony gateways at the top. Each of these resells its gateway services to medium sized providers, and those medium providers resell to local providers, who finally sell directly to consumers 💅 It's effectively a pyramidal relationship, as you can see in Figure 3.
------
| |
| M1 |
| |
------
/ \ <------- TRIP
------ ------
| | | |
| M2 | | M3 |
| | | |
------ ------
/ \ / \
------ ------ ------
| | | | | |
| M4 | | M5 | | M6 |
| | | | | |
------ ------ ------
Figure 3: TRIP for WholesalersNote that in this example, provider M5 resells gateways from both M2 and M3, which is such a plot twist 🙈
7 Architecture ✨
okay, so Figure 4 is the big picture of how TRIP is put together 🗺️
ITAD1 ITAD2
----------------- ------------------
| | | |
| ---- | | ---- |
| | GW | | | | EU | |
| ---- \ ---- | | ---- / ---- |
| | LS | ---------------- | LS | |
| ---- ---- | / ---- \ ---- |
| | GW | / | /| | EU | |
| ---- | / | ---- |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | |
| ---- |
| | LS | |
| / ---- \ |
| ---- || ---- |
| | GW | || | EU | |
| ---- || ---- |
| ---- || ---- |
| | GW | / \ | EU | |
| ---- ---- |
| |
---------------------
ITAD3
Figure 4: TRIP Architectureso there are a bunch of Internet Telephony administrative domains (ITAD's) 🏰 and each one has at least one Location Server (LS). The LS's learn about the gateways in their domain through an out-of-band means, called the intra-domain protocol 🕵️♀️ That protocol is the lines between the GW and LS elements in ITAD1 in the Figure. The LS's also have associations with other LS's, and that's how they swap gateway information. These associations are set up administratively, which means they happen once the IT administrative domains have some kind of agreement in place about exchanging gateway info 🤝 In the figure, the LS in ITAD1 is connected to the LS in ITAD2, which is connected to the LS in ITAD3.
Now the fun part 🎀 Through Telephony Routing over IP (TRIP), the LS in ITAD2 learns about the two gateways in ITAD1. End users (EUs) in ITAD2 get to see that info through the front-end. The front-end is a non-TRIP protocol or mechanism that's used to access the LS databases 💅 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. Aggregation, the ultimate glow-up 🌸
8 Elements 💖
the Figure 4 architecture is made up of a few elements. These include the IT administrative domain, the end user, the gateway, and the location server 🧚
8.1 IT Administrative Domain 🏰
an IT administrative domain is made up of zero or more gateways, at least one Location Server, and zero or more end users. The gateways and LS's are the ones under the administrative control of a single authority, which means there's one authority in charge of the policies and configuration of the gateways and LS's 👑
an IT administrative domain doesn't have to be the same thing as an autonomous system 🙃 An AS is a set of physically connected networks, but an IT administrative domain can include elements on disparate networks, and even within disparate autonomous systems. Very flexible, very iconic.
The end users in an IT administrative domain are basically the customers of that domain 🛍️ They want to complete calls towards the telephone network, so they need access to gateways. An end user can be a customer of one IT administrative domain for one call, and then a customer of a different one for the next call. Loyalty is not required lol 💅
An IT administrative domain doesn't need to have any gateways. In that case, its LS learns about gateways in other domains and makes them available to the end users within its domain. The IT administrative domain is effectively a virtual IP telephony gateway provider, because it provides gateway service but may not actually own or administer any gateways 🦋
An IT administrative domain doesn't need to have any end users either. In that case, it provides "wholesale" gateway service, making its gateways available to customers in other IT administrative domains 🍓
And an IT administrative domain doesn't need gateways or end users at all 💀 In that case, the ITAD only has LS's. It acts as a reseller: it learns about other gateways, then aggregates and propagates that information to other ITAD's that do have customers. Middle-person era, but make it useful ✨
8.2 Gateway 📞
a gateway is a logical device with both IP connectivity and connectivity to some other network, usually a public or private telephone network 📱 Its job is to translate the media and signaling protocols from one network technology to the other, so the users of the system get a transparent connection 🫶
A gateway has a bunch of attributes that characterize the service it provides. The most fundamental one is the range of phone numbers it's willing to provide service for. That range can be broken into subranges, and each subrange can be associated with some cost metric or cost token. This token shows some notion of cost or preference for completing calls for that part of the telephone number range 🔢
A gateway also has attributes that characterize the volume of service 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. Together, these two show some notion of the gateway's capacity 📈 The metric helps Location Servers decide to route calls to gateways in proportion to the value of the metric, which gives you a simple form of load balancing ⚖️
A gateway also has attributes that characterize the type of service it provides. This includes, but isn't limited to, the signaling protocols supported, the telephony features provided, the speech codecs understood, and the encryption algorithms implemented. These attributes may be important when selecting a gateway 🎧 Without baseline required features across all gateways (an admirable, but difficult goal), this set of attributes is required in order to select a gateway that communications can be established with. End users with specific requirements for the call may want to use this info too. For example, a user asking for a business class call may need certain call features to be supported 💼
Some of these attributes are transported in TRIP to describe gateways, and others aren't. It depends on whether the metric can be reasonably aggregated, and whether it's something that must be conveyed in TRIP before the call is set up (as opposed to being negotiated or exchanged by the signaling protocols themselves) 🧐 The philosophy of TRIP is to keep it simple and favor scalability over an abundance of information. TRIP's attribute set is readily extensible, and flags let an LS reasonably process attributes it doesn't recognize. Future-proof and literally so cute 🌈💖
8.3 End Users
An end user is an entity (usually a human being) who wants to finish a call through a gateway, going from an IP network to a terminal on a telephone network 📞✨ This could be someone logged on at a PC with some Internet telephony software 💻. It could also be someone connected to the IP network through an ingress telephone gateway, which they accessed from a telephone handset 📱. That's what's known as "phone to phone" service, with the IP network used for interexchange transport 🦋
End users might or might not know a telephony routing service is running when they complete a call toward the telephone network 🤷♀️ If they do know, they may have preferences for how the call gets completed 💅 Those preferences might include call features that must be supported, quality metrics, owner or administrator, and cost preferences 💸
TRIP doesn't dictate how those preferences get mixed with the provider's preferences to pick the final gateway 🙅♀️ It also doesn't support transporting those preferences to the LS 🙈 That transport can happen through the front end, or through some non-protocol means 🌸
8.4 Location Server
The Location Server (LS) is the main functional entity of TRIP 👑 It's a logical device with access to a database of gateways called the Telephony Routing Information Base (TRIB) 🗂️ That database gets built by combining the set of locally available gateways with 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. That exported set is built from the local gateways and the remote gateways (learned through TRIP), again based on policy. So policy is basically the star of the show when it comes to LS operation ⭐ This flow of information is shown in Figure 5 🦋
|
|Intra-domain protocol
\ /
Local
Gateways
TRIP--> Gateways POLICY Gateways -->TRIP
IN Out
|
\ /
Telephony Routing
Information Base
Figure 5: Flow of Information in TRIPThe TRIB that builds up in the LS lets it make decisions about IP telephony call routing 🧠 When a signaling message shows up at a signaling server, headed for a telephone network address, the LS's database can provide info that helps figure out which gateway (or extra signaling server) to forward the message to 📨 That's why an LS may be coresident with a signaling server 💖 When they aren't coresident, some kind of communication between the LS and the signaling server is needed 🤝 TRIP doesn't specifically address that communication, although it's possible TRIP might meet the needs of such a protocol 🤔
An ITAD must have at least one LS to participate in TRIP 🎀 An ITAD can have more than one LS, for load balancing, easier management, or any other reason 🌈 If it does, those LS's might need to talk to each other to synchronize databases and share what they learned from external peers 🫶 This is often called the interior component of an inter-domain protocol, and TRIP includes that function ✨
Figure 5 shows an LS learning about gateways inside the ITAD through an intra-domain protocol 🛰️ But there doesn't need to be an intra-domain protocol 🙃 An LS can work without knowing about any locally run gateways. Or it might know about locally run gateways through static configuration 📝 An LS can also be co-resident with a gateway, in which case it would know about the gateway it's co-resident with 🍓
9 Element Interactions
9.1 Gateways and Location Servers
Gateways somehow have to propagate info about their characteristics to an LS within the same ITAD 📡 That LS may then further propagate this info outside 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 way the info gets propagated is outside the scope of TRIP 🙈 The protocol used to make that happen is generally called an intra-domain protocol 🔧
One way the info 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 where service info gets automatically propagated from SA's to DA's. That's how an LS can learn about gateways in the ITAD 💜
Another option for the intra-domain protocol is the registration procedures of SIP or H.323 📲 Those registration procedures give users a way to tell a gatekeeper or SIP server about their address. A registration procedure like that could be extended so a gateway can effectively register too 💅
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'll be able to learn about all those gateways in its ITAD 🥹
The intra-domain protocol used may be different from one IT administrative domain to another, and it's 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 might learn about gateways through static configuration, or it might not know about any local gateways at all 🫠
9.2 Location Server to Location Server
The interaction between LS's is what TRIP defines 💫 LS's within the same ITAD use TRIP to synchronize info amongst themselves 🔄 LS's within different ITADs use TRIP to exchange gateway info according to policy 🌸 In the first case the LS's are called internal peers, and in the second case, external peers 👯♀️
LS's talk to each other through persistent associations 💌 An LS may be connected to one or more other LS's. LS's don't need to 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 get configured to communicate with each other once their administrators have an agreement in place to exchange gateway info 📜 TRIP doesn't provide an autodiscovery procedure for peer LS's to find each other, but one could possibly be used ✨ That kind of procedure might be useful for finding a backup peer LS when a crash happens 🛟 Alternatively, in an environment where business relationships between peers get more standardized, peers might be allowed to discover each other through protocols like the Service Location Protocol (SLP) [9] 🧚♀️ Whether autodiscovery should or should not be used is up to the administrator's discretion 👑
The syntax and semantics of the messages exchanged over the association between LS's are dictated by TRIP 📖 The protocol doesn't dictate the nature of the agreements that must be in place 🤝 TRIP just provides a transport means to exchange whatever gateway routing info the administrators of the system deem appropriate 🚚 The details are in the TRIP protocol specification itself 🔍
The rules that govern which gateway info gets generated, propagated, and accepted by a gateway are called a location server policy 📏 TRIP doesn't dictate or mandate any specific policy 🙅♀️
9.2.1 Nature of Exchanged Information
The info exchanged by the LS's is a set of routing objects 🎁 Each routing object minimally consists of a range of telephone numbers that are reachable, and an IP address or host name, which is the application-layer "next hop" toward a gateway that can reach that range 📞 Routing objects are learned from the intra-domain protocol, from 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 it's communicating with) 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 picking which objects to aggregate and propagate, as long as they stay within the bounds of correct protocol operation (i.e., no loops are formed) 🔁 The selection can be based on info learned through TRIP, or through any out of band means 🌟
A routing object may have additional info that characterizes the service at the gateway 🧾 These attributes include things like protocols, features supported, and capacity 🎀 More attributes can provide useful info, but they come at a cost 💸 Aggregation gets difficult with more and more info, which impacts the scalability of the protocol 😭
Aggregation plays a central role in TRIP 🔥 To facilitate scalability, routing objects can be combined into larger aggregates before they're propagated 📦 The mechanisms for doing this are specified in TRIP. Aggregating application layer routes to gateways is a non-trivial problem 🧩 There's a fundamental tradeoff between aggregatability and verbosity ⚖️ The more info present in a TRIP routing object, the harder it is to aggregate 🙃
Let's look at a simple example with two gateways, A and B, that can reach some sets of telephone numbers, X and Y, respectively 🦋 C is an LS for the ITAD where A and B are resident. C learns about 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 picks the last approach and sends a single routing object to one of its peers, D, containing address range Z and its own address, since it's also a signaling server. D is also a signaling server 🫶
Now some calling device, E, wants to place a phone call to telephone number T, which happens to be in 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 address T is within range Z. Since D received a routing object from C containing address range Z, it forwards the call setup message to C 🏃♀️ C then sees that T is within range X, so it forwards the call setup to A 🎯 A terminates the call signaling and initiates a call toward the telephone network, and the call is officially connected 🎉💖
9.2.2 Quality of Service
Okay so one thing you totally need to check when picking a gateway is "QoS" 💅. Will a call through this gateway have 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.). Figuring out the gateway part takes intricate knowledge of underlying network topologies and of where the caller is located 🌸. That's handled by QoS routing protocols, and it's outside the scope of TRIP, so not our problem, bestie 🫶
However, gateway capacity is not dependent on the caller location or path characteristics 🦋. That's why 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
Next up, pricing 💸. 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.
- 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 🌈.
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.
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:
- 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 😬.
- 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 🔐
Okay, bestie, this section is SERIOUS. Security is an important component in TRIP 😭.
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 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 ✨
Okay bestie, here's the reading list 📚 Every reference is kept exactly as written, so you can chase down any of them.
[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.
[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 💌
Meet the two people who wrote this, and how to reach them 🦋
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
Email: jdrosen@dynamicsoft.comHenning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
Email: schulzrinne@cs.columbia.edu16. Full Copyright Statement ⚖️
Legal bits, bestie, so I'm keeping this word-for-word. No vibes-based edits here 🫶
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. 💖
📦 where this page comes from
- ietf: rfc2871 2000-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms