RFC 4904
Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
RFC 4904 🎀 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
Okay bestie, here's the title block tea ☕. This is RFC 4904, called Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs). It came out of the Network Working Group in June 2007 and it's a Standards Track doc 💅, so it's a real spec, not just vibes.
The authors are V. Gurbani from Bell Laboratories, Alcatel-Lucent, and C. Jennings from Cisco Systems 🫶. The title block doesn't list anything this RFC obsoletes or updates, so it stands on its own ✨.
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (C) The IETF Trust (2007) 💜.
Abstract 🦋
This doc explains a standardized way to carry trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). To make it happen, they define an extension to the tel URI ✨.
Table of Contents 🧚
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements and Rationale . . . . . . . . . . . . . . . . . . 5
4.1. sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 5
4.2. Trunk Group Namespace: Global or Local? . . . . . . . . . 5
4.3. Originating Trunk Group and Terminating Trunk Group . . . 6
4.4. Intermediary Processing of Trunk Groups . . . . . . . . . 6
5. Trunk Group Identifier: ABNF and Examples . . . . . . . . . . 6
6. Normative Behavior of SIP Entities Using Trunk Groups . . . . 8
6.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 9
6.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 10
6.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10
7. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Reference Architecture . . . . . . . . . . . . . . . . . . 11
7.2. Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 12
7.3. Inter-Domain Call Flow . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 171. Background 🌸
Okay so, call routing in the Public Switched Telephone Network (PSTN) happens by sending calls over specific circuits (commonly called "trunks") between Time Division Multiplexed (TDM) circuit switches 📞. In switches, a group of trunks that connect to the same target switch or network is called a "trunk group". That means trunk groups have labels, and those labels are the main clue for which TDM switch came before and which one comes next in routing the call 🔥.
Formally, the doc defines a trunk, a trunk group, and related terms like this (the definitions of "trunk" and "trunk group" come from [5]):
Trunk: In a network, a communication path connecting two switching systems used in the establishment of an end-to-end connection. In selected applications, it may have both its terminations in the same switching system.
Trunk Group: A set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable. A single trunk group can be shared across multiple switches for redundancy purposes.
Digital Signal 0 (DS0): Digital Signal X is a term for a series of standard digital transmission rates based on DS0, a transmission rate of 64 kbps (the bandwidth normally used for one telephone voice channel). The European E-carrier system of transmission also operates using the DS series as a base multiple.
Since ubiquitous digital trunking showed up, DS0s get allocated between end offices in minimum groups of 24 (in North America), and people started calling bundles of DS0s a trunk 💅. Strictly speaking, though, a trunk is a single DS0 between two PSTN end offices. For this doc's purposes, the PSTN interface of a gateway acts effectively as an end office (so if the gateway talks to Signaling System 7 (SS7), it has its own SS7 point code, and so on) 🧚. A trunk group, then, is a bundle of DS0s (they don't need to be numerically contiguous in an SS7 Trunk Circuit Identification Code numbering scheme) that are grouped under a common administrative policy for routing ✨.
A Session Initiation Protocol (SIP) [3] to PSTN gateway may have trunks that connect to different carriers 🦋. It's totally reasonable for a SIP proxy to pick which carrier a call goes to, based on factors this doc doesn't list, when it proxies a session setup request to the gateway. Since multiple carriers can carry a call to a particular phone number, the phone number on its own isn't enough to identify the carrier at the gateway 🙈. A trunk group is extra info that can narrow down the choices at the gateway. In this doc, trunks are always tied to gateways, so a proxy that uses trunk groups to route a request to a particular gateway knows and controls which gateway the call goes to, and knows what trunking resources that gateway has 💜.
Another example: picture an IP network acting as a transit network between two PSTN networks. A SIP proxy can use the originating trunk group in its routing logic so the same ingress and egress carrier gets chosen 🌈.
How the proxy picked a particular trunk group is outside this doc's scope (though [6] gives one way to do it) 🙃. Once a trunk group has been decided on, this doc gives a standardized way to represent it in signaling messages 🎀.
2. Problem Statement 🌧️
Right now there isn't any standardized way to carry trunk groups between Internet signaling entities 😭. That causes confusion on at least two fronts:
- Positional ambiguity: A SIP proxy that wants to send a call to an egress Voice over IP (VoIP) gateway might put the trunk group as a parameter in the user portion of the Request-URI (R-URI), or it might put it as a parameter on the R-URI itself 🤷♀️. The same mess shows up in reverse, when an ingress VoIP gateway wants to send an incoming call notification to its default outbound proxy.
- Semantic ambiguity: Since there's no standardized grammar for representing trunk groups, people end up picking ad hoc names and values, which is an unfortunate look 💀.
VoIP routing entities on the Internet, like SIP proxies, may want to use trunk groups for normal operations 💅. So any standards-driven requirements will let proxies from one vendor work with gateways from another vendor 🫶. Without those guidelines, interoperability will suffer, because a proxy vendor has to match what a gateway expects about where trunk group parameters should be present (and the other way around) 😤.
The goal of this spec is to lay out how to structure and represent trunk group parameters as an extension to the tel URI [4] in a standardized way 👑.
3. Conventions 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Keep those in mind as you read, because they're the official vocab ✨.
4. Requirements and Rationale 🧠
This section is where the design choices get their reasons 💖. The motivations are written up as a set of requirements, and those requirements guide the eventual trunk group specification in this document.
4.1. sip URI or tel URI? 🤔
REQ 1: Trunk group parameters must be defined as an extension to the tel URI [4].
Trunk group parameters can be carried in either a sip URI or a tel URI 💅. Since trunk groups are closely tied to the PSTN, it makes sense to define them as extensions to the tel URI. (Any SIP request going to a gateway could reasonably be expected to have a tel URI, in whole or in part, in its R-URI anyway 🙌.) Using the tel URI also lets non-SIP VoIP protocols reuse this format, which could include anything from MGCP or Megaco to H.323, if the right information elements get created 🌸.
Finally, once the trunk group is defined for a tel URI, the normative procedures of Section 19.1.6 of [3] can be used to derive an equivalent sip URI from a tel URI, complete with the trunk group parameters 🦋.
4.2. Trunk Group Namespace: Global or Local? 🏷️
REQ 2: Inter-domain trunk group name collisions must be prevented.
Normally, trunk groups only matter inside one administrative domain (that's local scope) 🏠. But inadvertent cross-domain trunk group name collisions can happen, so preventing them is desirable 🚫. Using namespaces well is the fix for this, so it makes sense to scope the trunk group through a namespace 💜.
Note: At first glance, the tel URI's "phone-context" parameter looks like it could give a trunk group a namespace, and honestly that's a fair first thought 🙃. But here's the catch: the "phone-context" parameter says what scope a local telephone number is valid in. Semantically, a "phone-context" tel URI parameter only applies to a local telephone number, not a global one (the kind preceded by a '+') 💀. Trunk groups, on the other hand, can show up in local or global telephone numbers. So what's needed is a new parameter that works like the "phone-context" parameter of the tel URI, but applies equally to local and global telephone numbers 🎀.
4.3. Originating Trunk Group and Terminating Trunk Group 🚪
REQ 3: Originating trunk group and destination trunk group must be able to appear separately and concurrently in a SIP message.
SIP routing entities can make informed routing decisions based on either the originating trunk group or the terminating trunk group 🧭. So both of these trunk groups have to be carried in SIP requests 🫶.
4.4. Intermediary Processing of Trunk Groups ✨
okay so REQ 4 is giving middleman energy 🦋 SIP network intermediaries (proxy servers and redirect servers) should be able to add the destination trunk group attribute to SIP sessions as a route is selected for a call. they're basically the hype crew that helps route the call and can tag it with where it's going 💅
5. Trunk Group Identifier: ABNF and Examples 🎀
the Augmented Backus Naur Form [2] syntax for a trunk group identifier is down below, and it extends the "par" production rule of the tel URI defined in [4] 🌸
par = parameter / extension / isdn-subaddress / trunk-group /
trunk-context
trunk-group = ";tgrp=" trunk-group-label
trunk-context = ";trunk-context=" descriptor
trunk-group-label = 1*( unreserved / escaped /
trunk-group-unreserved )
trunk-group-unreserved = "/" / "&" / "+" / "$"descriptor is defined in [4]. unreserved is defined in [3] and [4]. escaped is defined in [3].
okay so trunk groups are identified by two parameters, "tgrp" and "trunk-context", and BOTH of them MUST be present in a tel URI to identify a trunk group 🫶 we call these two together the "trunk group parameters" in this spec, bc we're literally extra like that ✨
every implementation that follows this spec MUST generate both of these parameters when it's using trunk groups 💖 now if somebody receives a tel URI with only one of the "tgrp" or "trunk-context" parameters, it MUST act like there were no trunk group parameters at all in that URI 😭 whether they bother processing that URI any further is totally up to them, BUT if they do decide to process it, they MUST still act like there were no trunk group parameters in there 🙈
the "trunk-context" parameter gives the trunk group a namespace by naming a global number (or any number of its leading digits, like +33), or a domain name 🌈 it's modeled after the "phone-context" parameter of the tel URI [4], except that unlike "phone-context", the "trunk-context" can show up in either a local or global tel URI 🧚
semantically, the "trunk-context" sets the scope of the trunk group in the "tgrp" parameter. like, is it only valid at one gateway, a whole set of gateways, or an entire domain run by a service provider? 👑 the "trunk-context" can have four different value types:
- the value in the "trunk-context" literally identifies a host (a gateway), so the trunk groups are scoped to that one specific host.
- the value in the "trunk-context" is a subdomain (e.g., "north.example.com"), which identifies a subset of the gateways in a domain that the trunk groups are shared across.
- the value in the "trunk-context" is a service provider domain (e.g., "example.com"), which identifies all gateways in that specific domain.
- the value in the "trunk-context" is a global number or any number of its leading digits. this is useful for provider-wide scoping, but it doesn't really lend itself to specifying trunk groups across one gateway or a set of gateways 💀
for equivalency purposes, two URIs containing trunk group parameters are equivalent according to the base comparison rules of the URIs. the base comparison rules of a tel URI are in Section 4 of [4], and the base comparison rules of a sip URI are in Section 19.1.4 of [3] 🦋
Examples:
- Trunk group in a local number, with a phone-context parameter (line breaks added for readability):
tel:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.comtransforming this tel URI into a sip URI gives you:
sip:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone- Trunk group in a global number, with a domain name trunk-context:
tel:+16305550100;tgrp=TG-1;trunk-context=example.comtransforming this tel URI into a sip URI gives you:
sip:+16305550100;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone- Trunk group in a global number, with a number prefix trunk-context:
tel:+16305550100;tgrp=TG-1;trunk-context=+1-630transforming this tel URI into a sip URI gives you:
sip:+16305550100;tgrp=TG-1;
trunk-context=+1-630@isp.example.net;user=phone6. Normative Behavior of SIP Entities Using Trunk Groups 👑
the terminating (or egress) trunk group parameters MUST be specified in the R-URI 💅 this is how a SIP entity tells the next downstream entity which specific terminating (or egress) trunk group to use. main character signal, no cap ✨
Note: this is consistent with using the R-URI as a routing element. SIP routing entities may use the trunk group parameter in the R-URI to make intelligent routing decisions. ALSO this satisfies REQ 4, since a SIP network intermediary can modify the R-URI to include the trunk group parameters 🫶
now the flip side: the trunk group parameters showing up in the Contact header URI signify the trunk group the call arrived on, which is the originating (or ingress) trunk group 🦋 so the originating (or ingress) trunk group MUST appear in the Contact header of a SIP request. it's the whole "where did this come from" vibe 🌸
the behavior described in this section effectively addresses REQ 3 💖
6.1. User Agent Client Behavior 🎀
a User Agent Client (UAC) that's starting a call using trunk groups and supports this spec MUST include the trunk group parameters in the Contact header URI. a Contact URI MUST be a sip or sips URI, so what goes in the Contact header is a SIP translation of the tel URI, complete with the trunk group parameters 🧚 those parameters in the Contact header represent the originating trunk group. because of the processing rules for the Contact header defined in RFC 3261 [3], later requests in the dialog toward this user agent will carry this Contact URI in the R-URI. and yes, the user part of this URI (the one with the trunk group parameters) gets copied as a result of this processing 🌈
Note: arguably, the originating trunk group could be part of the From URI. HOWEVER, semantically, the URI in a From header is an abstract identifier for the resource it names on a long-term basis. a trunk group, on the other hand, is a binding that's only valid for the duration of the session. once the session is over, the trunk group means nothing 💀 so the Contact URI is the best place for this info, since it has exactly those semantics 🫶
if the UAC knows the routing topology, it MAY insert the destination trunk group parameters in the R-URI of the request. but in most deployments the UAC will use a proxy to route the request further, and it'll be up to the proxy to insert those parameters in the R-URI (see Section 6.3) 🍓
6.2. User Agent Server Behavior 🌸
okay so to the processing User Agent Server (UAS) that's attached to a gateway, the trunk group parameters in the R-URI mean it should use the named trunk group for the outbound call 🦋 if a UAS supports trunk groups but finds that all the trunk circuit identification codes for that trunk group are occupied, it MAY send a 603 Decline final response 😭
if a UAS supports trunk groups but isn't configured with the trunk group named in the R-URI, it SHOULD NOT use any other trunk group besides the one specified in the parameters 🙈 in that case it MAY reject the request with a 404 final response. OR, if it decides to process the request anyway, it MUST disregard the values in the "trunk-context" and the "tgrp" parameters ✨
if the receiver of a SIP request is not authoritatively responsible for the value in the "trunk-context", it MUST treat the value in the "tgrp" parameter as if it weren't there 💅 whether to process the request further is up to the discretion of the processing entity, and the request MAY be rejected with a 404 final response. alternatively, if they decide to process it further, the processing entity MUST disregard the values in the "trunk-context" and the "tgrp" parameters, since it isn't authoritatively responsible for the value specified in "trunk-context" 👑
6.3. Proxy Behavior 🧚
a proxy server that gets a request containing the trunk group parameter in the Contact header SHOULD NOT change these parameters as the request moves through it 💜 changing them could cause adverse consequences, since the UAC that filled them in did so based on authoritative knowledge the proxy might not be privy to 🌈 instead, the proxy SHOULD pass the trunk group parameters in the Contact header through unchanged to the client transaction the proxy creates to send the request downstream ✨
a proxy that knows the routing topology and supports this spec MAY insert destination trunk group parameters in the R-URI if none are present (see Sections 7.1 and 7.2 for an example) 🦋 however, if destination trunk group parameters are already in the R-URI, the proxy SHOULD NOT change them unless it has further authoritative information about the routing topology than the upstream client had when it originally inserted the trunk group parameters in the R-URI 🫶
Depending on the specific situation, it's perfectly reasonable for a proxy NOT to insert the destination trunk group parameters in the R-URI. for example, picture a proxy that understands the originating trunk group parameters and, following local policy, uses them to route the request to a destination other than a PSTN gateway 🙈
7. Example Call Flows ✨
7.1. Reference Architecture ✨
Okay, picture Figure 1 🦋: a SIP proxy with three gateways in its domain, GW1, GW2, and GW3. Requests come into the proxy through GW1. GW2 and GW3 are the egress gateways that send calls out of the domain. GW2 has two trunk groups, TG2-1 and TG2-2. GW3 also has two, TG3-1 and TG2-2, and TG2-2 is shared between GW2 and GW3 💅
+-----+ TG2-1
| |--------> To
TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN
From ----->| | | SIP | | | |-------->
PSTN | GW1 |--->| Proxy |-----+ +-----+
----->| | +-------+ | +-----+ TG3-1
+-----+ | | |--------> To
+---->| GW3 | TG2-2 PSTN
| |-------->
+-----+
Reference ArchitectureGW1 always knows which trunk group a request came in on over TG1-1 🎀. If it wants the proxy to know that too, it has to put the trunk group in the Contact header of the SIP request it sends to the proxy. The proxy then passes that ingress trunk group along, further downstream, in the Contact header.
The proxy uses GW2 and GW3 as egress gateways to the PSTN. It's assumed the proxy has a routing table for GW2 and GW3 that lists the right trunk groups to use when sending a call to the PSTN. How that table gets built is out of scope for this spec, so [6] is one way to do it and a manually created and maintained routing table is another 🌸. When the proxy sends a request to either egress gateway, and that gateway's routing table is set up so the gateway needs a trunk group, the proxy has to put the trunk group in the SIP R-URI of the request going to that gateway.
7.2. Basic Call Flow 🧚
This example uses the reference architecture from Figure 1. GW1, GW2, GW3, and the SIP proxy are all assumed to belong to a service provider whose domain is example.com 💜
GW1 SIP Proxy GW2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
... ... ...
| | | Send to PSTN
| | | --> and receive Answer
| | | Complete Message
-----------------------------------------
Call in progress
-----------------------------------------
| | |
| |<-----------F3---+
+<--------------+ |
... ... ...
Basic Call FlowIn the flow below, some headers and messages have been left out to keep it short 🙈. In F1, GW1 gets a call setup request from the PSTN over a certain trunk group, and it puts that trunk group in the Contact header of the request it sends to the SIP proxy.
F1:
INVITE sip:+16305550100@example.com;user=phone SIP/2.0
...
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...In F2, the SIP proxy translates the R-URI and adds a destination trunk group to it. Then the request goes to GW2 ✨
F2:
INVITE sip:+16305550100;tgrp=TG2-1;
trunk-context=example.com@gw2.example.com;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...Once the call is up, either end can hang up 📞. For illustration, F3 shows GW2 doing the hang-up. Notice that the Contact from F1, trunk group parameters and all, is now the R-URI of this request. When GW1 receives it, GW1 can match the call to the right trunk group and free up its resources 🔥
F3:
BYE sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone SIP/2.0
Route: <sip:proxy.example.com;lr>
...Now, here's a case worth documenting 👀: a call comes in from the PSTN to a gateway with no calling party number. Using Figure 1, say GW1 gets a call request from the PSTN without one. This isn't rare at all 💀. It can happen for lots of reasons, including privacy, or interworking between signaling protocols before the request reaches GW1. Normally, when the calling party number is in the signaling, GW1 would derive a sip URI to put in the Contact header. That sip URI carries the calling party number from the incoming SS7 signaling as its user portion, and the trunk group parameters become part of that user portion too, as we covered earlier 🌈
If a gateway gets an incoming call with no calling party number, it MUST create a tel URI. That tel URI holds a token the gateway generates locally, and the token only has meaning inside that gateway 🫶. How you generate the token is up to the implementation. Possible choices include the gateway line number or the port number where the call was accepted. The tel URI then gets converted into a sip URI and goes into the Contact header of the SIP request heading downstream from the gateway 🍓
Note: The tel scheme doesn't allow an empty URI, so the global-number or local-number production rule of the tel URI [4] can't contain an empty string. That's why the behavior in the paragraph above is required for cases where the incoming SS7 signaling message has no calling party number 🙈
7.3. Inter-Domain Call Flow 🦋
This example shows why namespaces are useful in trunk groups 💖. Here, GW1 and SIP Proxy 1 belong to the example.com domain, and SIP Proxy 2 belongs to a different domain, example.net. A call arrives at GW1 (F1) and gets routed into the example.net domain. Some headers and messages are left out below to keep things tidy ✨
example.com example.net
/-------------------------\ /-----------\
GW1 SIP Proxy 1 SIP Proxy 2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
| | |
... ... ...
| +<--F3------------+
... ... ...
Inter-Domain Call FlowF1:
INVITE sip:+16305550100@example.com;user=phone SIP/2.0
...
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...In F2, the SIP proxy runs its routing logic and points the R-URI at a resource in the example.net domain 🧚
F2:
INVITE sip:+16305550100@example.net;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...In F3, the example.net domain sends a request in the other direction 🔄. The example.net domain doesn't interpret the trunk group parameters in the Contact header, because those parameters don't belong to that domain. So the Contact header, trunk group parameters included, just gets used as the R-URI of a later request heading back toward example.com. That's the namespace doing its job 👑
F3:
BYE sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone
Route: <sip:proxy.example.com;lr>
...8. Security Considerations 🔥
okay bestie, this part is serious business, so let's get into it 🫶
The trunk group parameters are carried in R-URIs and Contact headers. They're literally just a modifier on an address 💅 So any existing trust relationship between the originator of a request and an intermediary (or final recipient) that processes the request is not affected by such a modifier.
Maliciously modifying a trunk group of a R-URI in transit may cause the receiving entity (say, a gateway) to prefer one trunk over another, thus leading to attacks that use resources not privy to the call. 😭
Like, an attacker who knows the name of a toll-free trunk on a gateway could modify the trunk group in the R-URI to effectively receive free service. Or they could modify the trunk group in an R-URI to mess with the flow of traffic across trunks 💀 Similarly, modifying the trunk group in a Contact header may cause the routing intermediary to erroneously associate a call with a different source than it would normally be associated with. Chaotic.
Although this specification puts more information into the R-URI and the Contact header in the form of trunk groups, the class of attacks and possible protection mechanism are the same as those specified for baseline SIP systems [3]. The Security Session Initiation Protocol Secure (SIPS) scheme and the resulting Transport Layer Security (TLS) mechanism SHOULD be used to provide integrity protection, thereby mitigating these attacks 🛡️
Now the big question: how does the receiver figure out whether the sender is authorized to use the resources represented by the trunk group parameters? 🤔 There are two cases to consider: intra-domain signaling exchange as discussed in Section 7.2, and inter-domain signaling exchange as discussed in Section 7.3.
In the intra-domain case, a proxy receiving trunk group parameters from an upstream user agent (typically a gateway) should only accept them using the SIPS URI scheme. Furthermore, it should use HTTP Digest to challenge and properly authorize the sender. A user agent (or a gateway) receiving the trunk group parameters from a proxy will not be able to challenge the proxy using HTTP Digest, but it should examine the X.509 certificate of the proxy to determine whether the proxy is authorized to insert the resources represented by the trunk group parameters into the signaling flow 🎀
In the inter-domain case, a receiving proxy may depend on the identity stored in the X.509 certificate of the sending proxy to determine whether the sender is authorized to insert the resources represented by the trunk group parameters in the signaling message ✨
Because of all this, the trunk group parameters are only applicable within a set of network nodes among which there is mutual trust. If a node receives a call signaling request from an upstream node that it does not trust, it SHOULD remove the trunk group parameters 🚫
Privacy check 🙈 The privacy information revealed with a trunk group doesn't generally advertise much about a particular (human) user. It does, however, convey two pieces of potentially private information that carriers may consider sensitive. First, it may reveal how a carrier is performing least-cost routing and peering. Secondly, it adds another means for network topology and information of a carrier to be exposed 🍓 It's up to the discretionary judgment of the carrier whether to include the trunk group parameters and reveal potentially sensitive information about its network topology. If confidentiality is desired, TLS SHOULD be used to protect this information while in transit 🔒
9. IANA considerations 🌸
This specification does not require any IANA considerations. Easy 🦋
The tel URI parameters introduced in this document are registered with IANA through the tel URI parameter registry document [7] ✨
10. Acknowledgments 🫶
The authors would like to acknowledge the efforts of the participants of the SIPPING and IPTEL working group, especially Jeroen van Bemmel, Bryan Byerly, John Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran, Takuya Sawada, Tom Taylor, and Al Varney 👑
Jon Peterson was also instrumental in the original formulation of this work 🧚
Alex Mayrhofer brought up the issue of lexicographic ordering of tel URI parameters when it is converted to a sip or sips URI 💜
Ted Hardie, Sam Hartman, and Russ Housley took pains to make sure the text around URI comparisons and security considerations was as unambiguous as possible 🙌
11. References 📚
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966,
December 2004.11.2. Informative References
[5] "Telcordia Notes on the Network", Telcordia SR-2275, Issue 04,
October 2000, <http://telecom-info.telcordia.com>.
[6] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D.
Shah, "A Telephony Gateway REgistration Protocol (TGREP)", Work
in Progress, January 2007.
[7] Jennings, C. and V. Gurbani, "The Internet Assigned Number
Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
Registry", Work in Progress, December 2006.Authors' Addresses 💌
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane
Rm 9F-546
Lisle, IL 60532
USA
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/3
San Jose, CA 95134
USA
Phone: +1 408 421 9990
EMail: fluffy@cisco.comFull Copyright Statement ©️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🧾
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society ✨
📦 where this page comes from
- ietf: rfc4904 2007-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms