Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs)

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.

Call routing in the Public Switched Telephone Network (PSTN) is accomplished by routing calls over specific circuits (commonly referred to as "trunks") between Time Division Multiplexed (TDM) circuit switches. In large switches, a group of trunks that connects to the same target switch or network is called a "trunk group." Consequently, trunk groups have labels, which are used as the main indication for the previous and next TDM switch participating in routing the call. Formally, we define a trunk and trunk group and related terminology as follows (definition of "trunk" and "trunk group" is from ). 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. 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 64kbps (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 the introduction of ubiquitous digital trunking, which resulted in the allocation of DS0s between end offices in minimum groups of 24 (in North America), it has become common to refer to bundles of DS0s as a trunk. Strictly speaking, however, a trunk is a single DS0 between two PSTN end offices - however, for the purposes of this document, the PSTN interface of a gateway acts effectively as an end office (i.e. if the gateway interfaces with Signaling System 7 (SS7), it has its own SS7 point code, and so on). A trunk group, then, is a bundle of DS0s (that need not be numerically contiguous in an SS7 Trunk Circuit Identification Code numbering scheme) which are grouped under a common administrative policy for routing. A Session Initiation Protocol (SIP) to PSTN gateway may have trunks that are connected to different carriers. It is entirely reasonable for a SIP proxy to choose -- based on factors not enumerated in this document -- which carrier a call is sent to when it proxies a session setup request to the gateway. Since multiple carriers can terminate a particular PSTN phone number, the phone number itself is not sufficient enough to identify the carrier at the gateway. An additional piece of information in the form of a trunk group can be used to further pare down the choices at the gateway. How the proxy picked a particular trunk group is outside the scope of this document ( provides one such way); once the trunk group has been decided upon, this document provides a standardized means to represent it.

Currently, there isn't any standardized manner of transporting trunk-groups between Internet signaling entities. This leads to ambiguity on at least two fronts: Positional ambiguity: A SIP proxy that wants to send a call to an egress VoIP gateway may insert the trunk-group as a parameter in the user portion of the Request-URI (R-URI), or it may insert it as a parameter to the R-URI itself. This ambiguity persists in the reverse direction as well, that is, when an ingress VoIP gateway wants to send a incoming call notification to its default outbound proxy. Semantic ambiguity: The lack of any standardized grammar to represent trunk groups leads to the unfortunate choice of ad hoc names and values. VoIP routing entities in the Internet, such as SIP proxies, may be interested in using trunk-group information for normal operations. To that extent, any standards-driven requirements will enable proxies from one vendor to interoperate with gateways from yet another vendor. Absent such guidelines, inter-operability will suffer as a proxy vendor must conform to the expectations of a gateway as to where it expects trunk-group information to be present (and vice versa). The aim of this Internet draft is to outline how to structure and represent the trunk group information as an extension to the tel URI in a standardized manner.

REQ 1: Trunk group information MUST be defined as an extension to the "tel" URI . The trunk group information can be carried in either the "sip" URI or the "tel" URI. Since trunks groups are intimately associated with the PSTN, it seems reasonable to define them as extensions to the "tel" URI (any SIP request that goes to a gateway could reasonably be expected to have a tel URL, in whole or in part, in its R-URI anyway). Furthermore, using the tel URL also allows this format to be reused by non-SIP VoIP protocols (which could include anything from MGCP or Megaco to H.323, if the proper information elements are created). Finally, once the trunk-group is defined for a "tel" URI, the normative procedures of Section 19.1.6 of can be used to derive an equivalent "sip" URI from a "tel" URI, complete with the trunk group information.

REQ 2: Inter-domain trunk group name collisions MUST be prevented. Under normal operations, trunk groups are pertinent only within an administrative domain (i.e. local scope). However, given that inadvertent cross-domain trunk group name collisions may occur, it is desirable to to prevent these. The judicious use of namespaces is a solution to this problem. A trunk group in a URI MUST belong to a namespace. At first glance, it would appear that the use of the tel URI's "phone-context" parameter provides a satisfactory means of imposing a namespace on a trunk group. The "phone-context" parameter identifies the scope of validity of a local telephone number. And therein lies the problem. Semantically, a "phone-context" tel URI parameter is applicable only to a local telephone number and not a global one (i.e., one preceeded by a '+'). Trunk groups, on the other hand, may appear in local or global telephone numbers. Thus, what is needed is a new parameter with equivalent functionality of the "phone-context" parameter of the tel URI, but one that is equally applicable to local and global telephone numbers.

REQ 3: Originating trunk group and destination trunk group SHOULD be able to appear separately and concurrently in a SIP message. SIP routing entities can make informed routing decisions based on either the originating or the terminating trunk groups. Thus a requirement that both of these trunk groups need to be carried in SIP requests. Instead of having two parameters, one for the originating trunk group and the other for a terminating trunk group, the placement of the trunk group parameter in a SIP Contact header or the R-URI, respectively, signifies the intent. A proxy (or any other intermediary -- see next section) MAY insert a trunk group appears in the R-URI; to the next downstream entity this signifies an egress (or terminating) trunk group to be used. Conversely, when a trunk group parameter appears in the Contact header, this signifies the trunk group over which the call came over, i.e., the ingress (or orgininating) trunk group.

REQ 4: SIP network intermediaries (proxy server and redirect servers) should be able to add the destination trunk group attribute to SIP sessions as a route is selected for a call. If the trunk group parameter appears in a R-URI of a request, it represents the destination trunk group. 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. Furthermore, this also satisfies REQ 4, since a SIP network intermediary can modify the R-URI to include the trunk group information. To the processing User Agent Server (UAS), a trunk group in the R-URI implies that it should use the named trunk group for the outbound call. If a UAS supports trunk groups but is not configured with the particular trunk group identified in the R-URI, it SHOULD not use any other trunk group other than the one requested. A User Agent Client (UAC) that initiates a call and supports this draft MAY include the trunk group in the Contact header. If it does so, the trunk group in the Contact header represents the originating trunk group. Subsequent requests destined to that UAC MUST copy the trunk group from the Contact header into the R-URI. Note that a Contact URI MUST be a sip or sips URI, thus, what appears in the Contact header is a SIP translation of the tel URI, complete with the trunk group information. Arguably, the originating trunk group can be part of the From URI. However, semantically, the URI in a From header is an abstract identifier which represents the resource thus identified on a long-term basis. The presence of a trunk group, on the other hand, signifies a binding that is valid for the duration of the session only; a trunk group has no significance once the session is over. Thus, the Contact URI is the best place to impart this information since it has exactly those semantics.

Consider Figure 1, which depicts a SIP proxy in a routing relationship with three gateways in its domain, GW1, GW2, and GW3. Among other sources of request arrival (not shown in Figure) at the proxy is GW1. Gateways GW2 and GW3 are used as egress gateways from the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. GW3 has only one trunk group configured (TG3-1).

To TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN From ----->| | | SIP | | | |--------> PSTN | GW1 |--->| Proxy |-----+ +-----+ ----->| | +-------+ | +-----+ TG3-1 +-----+ | | |--------> To +---->| GW3 | PSTN | |--------> +-----+ Figure 1: Reference architecture ]]> GW1 in Figure 1 is always cognizant of any requests that arrive over trunk group TG1-1. If it wishes to propagate the ingress trunk group to the proxy, it MUST arrange for the trunk group to appear in the Contact header of the SIP request destined to the proxy. The proxy will, in turn, propagate the ingress trunk group in the Contact header further downstream. The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is assumed that the proxy has access to a routing table for GW2 and GW3 which includes the appropriate trunk groups to use when sending a call to the PSTN (exactly how this table is constructed is out of scope for this draft; is one way to do so, a manually created and maintained routing table is another). When the proxy sends a request to either of the egress gateways, and the gateway routing table is so configured that a trunk group is required by the gateway, the proxy MUST arrange for the trunk group to appear in the SIP R-URI of the request destined to that gateway.

The Augmented Backus Naur Form syntax for a trunk group identifier is given below and extends the "par" production rule of the tel URI defined in :

par = parameter / extension / isdn-subaddress / trunk-group trunk-group = ";tgrp=" trunk-group-label ";trunk-context=" trunk-context trunk-group-label = *1( unreserved / escaped / trunk-group-unreserved ) trunk-group-unreserved = "/" / "&" / "+" / "$" trunk-context = descriptor trunk-group-unreserved is the intersection of param-unreserved defined in and user-unreserved defined in . Since the trunk group is an extension to the tel URI and will end up as the user portion of a SIP URI, the ABNF for it has to ensure that it can be adequately represented in both the constructs. descriptor is defined in . The "trunk-context" and "tgrp" parameter SHOULD use lower-case characters as tel URIs may be used within contexts where comparisons are case sensitive. The "trunk-context" parameter imposes a namespace on the trunk group by specifying a global number or any number of its leading digits (e.g., +33), or a domain name. Syntactically, it is modeled after the "phone-context" parameter of the tel URI , and semantically, it serves an equivalent function except that unlike the "phone-context" parameter, the "trunk-context" parameter can appear in either a local or global tel URI. If the receiver of a SIP request is not the owner of the domain (or global prefix) specified in the "trunk-context", it MUST treat the trunk group as if it was not there. For equivalency purposes, two URIs containing trunk group identifiers are equivalent according to the base comparison rules of the URIs AND the values of their "tgrp" and "trunk-context" parameters MUST match. The base comparison rules of a tel URI are specified in Section 4 of , and the base comparison rules of a sip URI are specified in Section 19.1.4 of . Examples: 1. Trunk group in a local number, with a phone-context parameter (mind the line breaks added for readibility):

tel:5551212;phone-context=+1-630;tgrp=TG-1; trunk-context=example.com Transforming this tel URI to a sip URI yields: sip:5551212;phone-context=+1-630;tgrp=TG-1; trunk-context=example.com@isp.example.net 2. Trunk group in a global number:

tel:+16305551212;tgrp=TG-1;trunk-context=example.com Transforming this tel URI to a sip URI yields: sip:+16305551212;tgrp=TG-1;trunk-context=example.com@ isp.example.net 3. Trunk group in a global number:

tel:+16305551212;tgrp=TG-1;trunk-context=+1-630 Transforming this tel URI to a sip URI yields: sip:+16305551212;tgrp=TG-1;trunk-context=+1-630@isp.example.net

This example uses the reference architecture of Figure 1. Gateways GW1, GW2, GW3 and the SIP proxy are assumed to be owned by a service provider whose domain is example.com.

| | | +---F1--------->| | | +---F2----------->| ... ... ... | | | | | | --> Send to PSTN | | | and receive Answer | | | Complete Message (ACM) ----------------------------------------- Call in progress ----------------------------------------- | | | | |<-----------F3---+ +<--------------+ | ... ... ... ]]> In the call flow below, certain headers and messages have been omitted for brevity. In F1, GW1 receives a call setup request from the PSTN over a certain trunk group. GW1 arranges for this trunk group to appear in in the Contact header of the request destined to the SIP proxy.

]]> In F2, the SIP proxy translates the R-URI and adds a destination trunk group to the R-URI. The request is then sent to GW2.

Contact: ]]> Once the call is established, either end can tear the call down. For illustrative purposes, F3 depicts GW2 tearing the call down. Note that the Contact from F1, including the trunk group information, is now the R-URI of the request. When GW1 gets this request, it can associate the call with the appropriate trunk group to deallocate resources.

]]> It is worth documenting the behavior when an incoming call from the PSTN is received at a gateway without a calling party number. Consider Figure 1; in it, GW1 gets a call request from the PSTN without a calling party number. This is not an uncommon case, and may happen for a variety of reasons, including privacy and interworking between different signaling protocols before the request reached GW1. Under normal circumstances (i.e., instances where the calling party number is present in signaling), GW1 would derive a sip URI to insert into the Contact header. This sip URI may contain, as its user portion, the calling party number from from the incoming SS7 signaling information. The trunk group information then becomes part of the user portion as discussed previously. If a gateway receives an incoming call where the calling party number is not available, it MUST create a sip URI that has, as its user portion, a token that is generated locally and has local significance to the gateway. Details of generating such a token are implementation dependent; potential candidates include the gateway line number or port number where the call was accepted. This sip URI is subsequently inserted in the Contact header of the SIP request going downstream from the gateway. The tel scheme does not allow for an empty URI; thus the global-number or local-number production rule of the tel URI cannot contain an empty string. Consequently, the behavior in the above paragraph is mandated for cases where the incoming SS7 signaling message does not contain a calling party number.

This example demonstrates the advantage of namespaces in trunk group. In the example flow below, GW1 and SIP Proxy 1 belong to the example.com domain and SIP Proxy 2 belongs to another domain, example.net. A call arrives at GW1 (F1) and is routed to the example.net domain. In the call flow below, certain headers and messages have been omitted for brevity.

| | | +---F1--------->| | | +---F2----------->| ... ... ... ]]>

]]> In F2, the SIP proxy executes its routing logic and re-targets the R-URI to refer to a resource in example.net domain.

Contact: ]]> Once the request is in the domain of example.net, the namespace imposed by the "trunk-context" parameter in the Contact header prevents collisions with similiar trunk groups maintained by the example.net domain.

The extension defined in this document does not add any additional security concerns beyond those already enumerated in . The trunk group information is carried in R-URIs and Contact headers; it is simply a modifier of an address, and the trust imparted to that address is not affected by such a modifier. The privacy information revealed with trunk groups does not generally advertise much information about a particular (human) user. It does, however, convey two pieces of potentially private information which may be considered sensitive by carriers. First, it may reveal how a carrier may be performing least-cost routing and peering; and secondly, it does introduce an additional means for network topology and information of a carrier. It is up to the discretionary judgment of the carrier if it wants to include the trunk group information and reveal potentially sensitive information on its network topology.

Section 9 of creates a registry for tel URI parameters. This document updates the registry with the following entry: Parameter name: tgrp Description: A trunk group on which an incoming call was received at an ingress gateway or a trunk group on which an outgoing call should be placed at an egress gateway. This parameter is not mandatory. Syntax restrictions: Details on the syntax are explained in RFC AAAA. A phone-context parameter must occur in any tel URL that contains a tgrp parameter. Reference: RFC AAAA [Note to RFC editor: Please replace AAAA with the RFC number assigned to this document.] Parameter name: trunk-context Description: The context for a trunk group; imposes a namespace. This parameter is not mandatory. Syntax restrictions: Details on the syntax are explained in RFC AAAA. A trunk-context parameter must occur in any tel URL that contains a tgrp parameter. Reference: RFC AAAA [Note to RFC editor: Please replace AAAA with the RFC number assigned to this document.]

The authors would like to acknowledge the efforts of the participants of the SIPPING and IPTEL working group, especially 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.