summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4904.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4904.txt')
-rw-r--r--doc/rfc/rfc4904.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc4904.txt b/doc/rfc/rfc4904.txt
new file mode 100644
index 0000000..b0b711c
--- /dev/null
+++ b/doc/rfc/rfc4904.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group V. Gurbani
+Request for Comments: 4904 Bell Laboratories, Alcatel-Lucent
+Category: Standards Track C. Jennings
+ Cisco Systems
+ June 2007
+
+
+ Representing Trunk Groups in tel/sip
+ Uniform Resource Identifiers (URIs)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document describes a standardized mechanism to convey trunk
+ group parameters in sip and tel Uniform Resource Identifiers (URIs).
+ An extension to the tel URI is defined for this purpose.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 1]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+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 . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 2]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+1. Background
+
+ 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 switches, a group of trunks that connect 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 [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 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) that are
+ grouped under a common administrative policy for routing.
+
+ A Session Initiation Protocol (SIP) [3] 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
+
+
+
+Gurbani & Jennings Standards Track [Page 3]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ carriers can transport a call to a particular phone number, the phone
+ number itself is not sufficient 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.
+ As used in this document, trunks are necessarily tied to gateways,
+ and a proxy that uses trunk groups during routing of the request to a
+ particular gateway knows and controls which gateway the call will be
+ routed to, and knows what trunking resources are present on that
+ gateway.
+
+ As another example, consider the case where an IP network is being
+ used as a transit network between two PSTN networks. Here, a SIP
+ proxy can apply the originating trunk group to its routing logic to
+ ensure that the same ingress and egress carrier is chosen.
+
+ How the proxy picked a particular trunk group is outside the scope of
+ this document ([6] provides one such way); however, once trunk group
+ has been decided upon, this document provides a standardized means to
+ represent it in the signaling messages.
+
+2. Problem Statement
+
+ Currently, there isn't any standardized manner of transporting trunk
+ groups between Internet signaling entities. This leads to ambiguity
+ on at least two fronts:
+
+ 1. Positional ambiguity: A SIP proxy that wants to send a call to
+ an egress Voice over IP (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 an incoming call
+ notification to its default outbound proxy.
+
+ 2. 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 groups 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, interoperability will suffer, as a proxy
+ vendor must conform to the expectations of a gateway as to where it
+ expects trunk group parameters to be present (and vice versa).
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 4]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ The aim of this specification is to outline how to structure and
+ represent the trunk group parameters as an extension to the tel URI
+ [4] in a standardized manner.
+
+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].
+
+4. Requirements and Rationale
+
+ This section captures the motivations for the design decisions for
+ the specification of a trunk group. These motivations are captured
+ as a set of requirements that are used to 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].
+
+ The trunk group parameters can be carried in either the sip URI or
+ the tel URI. Since trunk 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 URI, in whole or in part, in its R-URI anyway).
+ Furthermore, using the tel URI 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 [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.
+
+ 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 prevent them. The judicious use of namespaces is a
+ solution to this problem. Thus, it seems appropriate to scope the
+ trunk group through a namespace.
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 5]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ Note: 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 preceded 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.
+
+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 or the terminating trunk groups. Thus, it is
+ required that both of these trunk groups be carried in SIP requests.
+
+4.4. Intermediary Processing of Trunk Groups
+
+ REQ 4: 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.
+
+5. Trunk Group Identifier: ABNF and Examples
+
+ The Augmented Backus Naur Form [2] syntax for a trunk group
+ identifier is given below and 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].
+
+
+
+
+Gurbani & Jennings Standards Track [Page 6]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ Trunk groups are identified by two parameters: "tgrp" and "trunk-
+ context"; both parameters MUST be present in a tel URI to identify a
+ trunk group. Collectively, these two parameters are called "trunk
+ group parameters" in this specification.
+
+ All implementations conforming to this specification MUST generate
+ both of these parameters when using trunk groups. If an
+ implementation receives a tel URI with only one of the "tgrp" or
+ "trunk-context" parameter, it MUST act as if there were not any trunk
+ group parameters present at all in that URI. Whether or not to
+ further process such an URI is up to the discretion of the
+ implementation; however, if a decision is made to process it, the
+ implementation MUST act as if there were not any trunk group
+ parameters present in the URI.
+
+ 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 [4], except that unlike
+ the "phone-context" parameter, the "trunk-context" parameter can
+ appear in either a local or global tel URI.
+
+ Semantically, the "trunk-context" parameter establishes a scope of
+ the trunk group specified in the "tgrp" parameter, i.e., whether it
+ is valid at a single gateway, a set of gateways, or an entire domain
+ managed by a service provider. The "trunk-context" can contain four
+ discrete value types:
+
+ 1. The value in the "trunk-context" literally identifies a host (a
+ gateway), in which case, the trunk groups are scoped to the
+ specific host.
+
+ 2. The value in the "trunk-context" is a subdomain (e.g.,
+ "north.example.com"), which identifies a subset of the gateways
+ in a domain across which the trunk groups are shared.
+
+ 3. The value in the "trunk-context" is a service provider domain
+ (e.g., "example.com"), which identifies all gateways in the
+ specific domain.
+
+ 4. The value in the "trunk-context" is a global number or any number
+ of its leading digits; this is useful for provider-wide scoping
+ and does not lend itself very well to specifying trunk groups
+ across a gateway or a set of gateways.
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 7]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ 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 specified in Section 4 of
+ [4], and the base comparison rules of a sip URI are specified in
+ Section 19.1.4 of [3].
+
+ Examples:
+
+ 1. 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.com
+
+ Transforming this tel URI to a sip URI yields:
+ sip:5550100;phone-context=+1-630;tgrp=TG-1;
+ trunk-context=example.com@isp.example.net;user=phone
+
+
+ 2. Trunk group in a global number, with a domain name
+ trunk-context:
+
+ tel:+16305550100;tgrp=TG-1;trunk-context=example.com
+
+ Transforming this tel URI to a sip URI yields:
+ sip:+16305550100;tgrp=TG-1;
+ trunk-context=example.com@isp.example.net;user=phone
+
+
+ 3. Trunk group in a global number, with a number prefix trunk-
+ context:
+
+ tel:+16305550100;tgrp=TG-1;trunk-context=+1-630
+
+ Transforming this tel URI to a sip URI yields:
+ sip:+16305550100;tgrp=TG-1;
+ trunk-context=+1-630@isp.example.net;user=phone
+
+6. Normative Behavior of SIP Entities Using Trunk Groups
+
+ The terminating (or egress) trunk group parameters MUST be specified
+ in the R-URI. This is an indication from a SIP entity to the next
+ downstream entity that a specific terminating (or egress) trunk group
+ should be used.
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 8]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ 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. Furthermore,
+ this also satisfies REQ 4, since a SIP network intermediary can
+ modify the R-URI to include the trunk group parameters.
+
+ Conversely, the appearance of the trunk group parameters in the
+ Contact header URI signifies the trunk group over which the call
+ arrived on, i.e., the originating (or ingress) trunk group. Thus,
+ the originating (or ingress) trunk group MUST appear in the Contact
+ header of a SIP request.
+
+ The behavior described in this section effectively addresses REQ 3.
+
+6.1. User Agent Client Behavior
+
+ A User Agent Client (UAC) initiating a call that uses trunk groups
+ and supports this specification MUST include the trunk group
+ parameters in the Contact header URI (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
+ parameters). The trunk group parameters in the Contact header
+ represent the originating trunk group. As a consequence of the
+ processing rules for the Contact header defined in RFC 3261 [3],
+ subsequent requests in the dialog towards this user agent will
+ contain this Contact URI in the R-URI. Note that the user part of
+ this URI, which contains the trunk group parameters, will be copied
+ as a consequence of this processing.
+
+ Note: Arguably, the originating trunk group can be part of the
+ From URI. However, semantically, the URI in a From header is an
+ abstract identifier that 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.
+
+ If the UAC is aware of the routing topology, it MAY insert the
+ destination trunk group parameters in the R-URI of the request.
+ However, in most deployments, the UAC will use the services of a
+ proxy to further route the request, and it will be up to the proxy to
+ insert such parameters in the R-URI (see Section 6.3).
+
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 9]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+6.2. User Agent Server Behavior
+
+ To the processing User Agent Server (UAS) associated with a gateway,
+ the trunk group parameters in the R-URI implies that 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 particular trunk group are occupied, it MAY send a 603 Decline
+ final response.
+
+ 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 specified in the parameters. In
+ such a case, it MAY reject the request with a 404 final response; or
+ if it makes a decision to process the request in any case, 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 specified in the "trunk-context", it MUST treat the
+ value in the "tgrp" parameter as if it were not there. Whether or
+ not to process the request further is up to the discretion of the
+ processing entity; the request MAY be rejected with a 404 final
+ response. Alternatively, if a decision is made to process the
+ request further, the processing entity MUST disregard the values in
+ the "trunk-context" and the "tgrp" parameters since it is not
+ authoritatively responsible for the value specified in "trunk-
+ context".
+
+6.3. Proxy Behavior
+
+ A proxy server receiving a request that contains the trunk group
+ parameter in the Contact header SHOULD NOT change these parameters as
+ the request traverses through it. Changing these parameters may have
+ adverse consequences, since the UAC that populated the parameters did
+ so on some authoritative knowledge that the proxy may not be privy
+ to. Instead, the proxy SHOULD pass the trunk group parameters in the
+ Contact header unchanged to the client transaction that the proxy
+ creates to send the request downstream.
+
+ A proxy that is aware of the routing topology and supports this
+ specification 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 present in
+ the R-URI, the proxy SHOULD NOT change them unless it has further
+ authoritative information about the routing topology than the
+ upstream client did when it originally inserted the trunk group
+ parameters in the R-URI.
+
+
+
+
+Gurbani & Jennings Standards Track [Page 10]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ Depending on the specific situation, it is perfectly reasonable
+ for a proxy not to insert the destination trunk group parameters
+ in the R-URI. Consider, for instance, a proxy that understands
+ the originating trunk group parameters and, in accordance with
+ local policy, uses these to route the request to a destination
+ other than a PSTN gateway.
+
+7. Example Call Flows
+
+7.1. Reference Architecture
+
+ Consider Figure 1, which depicts a SIP proxy in a routing
+ relationship with three gateways in its domain, GW1, GW2, and GW3.
+ Requests arrive at the SIP proxy through 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 also has two trunk groups
+ configured, TG3-1 and TG2-2 (TG2-2 is shared between gateways 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 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
+ that 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 specification; [6] 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
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 11]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ 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.
+
+7.2. Basic Call Flow
+
+ This example uses the reference architecture of Figure 1. Gateways
+ GW1, GW2, and GW3, and the SIP proxy are assumed to be owned by 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 Flow
+
+ 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 the Contact header of the request destined 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 the R-URI. The request is then sent to GW2.
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 12]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ 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 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 parameters, 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.
+
+ 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>
+ ...
+
+ 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, and assume that 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 will contain, as
+ its user portion, the calling party number from the incoming SS7
+ signaling information. The trunk group parameters 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 tel URI containing 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 tel URI is subsequently converted to a sip
+ URI to be inserted in the Contact header of the SIP request going
+ downstream from the gateway.
+
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 13]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ Note: The tel scheme does not allow for an empty URI; thus, the
+ global-number or local-number production rule of the tel URI [4]
+ 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.
+
+7.3. Inter-Domain Call Flow
+
+ This example demonstrates the advantage of namespaces in trunk
+ groups. 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.
+
+ example.com example.net
+ /-------------------------\ /-----------\
+ GW1 SIP Proxy 1 SIP Proxy 2
+ From | | |
+ PSTN-->| | |
+ +---F1--------->| |
+ | +---F2----------->|
+ | | |
+ ... ... ...
+ | +<--F3------------+
+ ... ... ...
+
+ Inter-Domain Call Flow
+
+
+ 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 executes its routing logic and re-targets the
+ R-URI to refer to a resource in 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>
+ ...
+
+
+
+
+Gurbani & Jennings Standards Track [Page 14]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ In F3, the example.net domain sends a request in the backwards
+ direction. The example.net domain does not interpret the trunk group
+ parameters in the Contact header since they do not belong to that
+ domain. The Contact header, including the trunk group parameters, is
+ simply used as the R-URI in a subsequent request going towards the
+ example.com domain.
+
+ 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
+
+ The trunk group parameters are carried in R-URIs and Contact headers;
+ they are simply a modifier of an address. 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. For example, an attacker who knows the name of a toll-free
+ trunk on a gateway may modify the trunk group in the R-URI to
+ effectively receive free service, or he may modify the trunk group in
+ a R-URI to affect 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.
+
+ Although this specification imparts more information to 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 that 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.
+
+ A question naturally arises: how does the receiver determine 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.
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 15]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ 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 these considerations, 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.
+
+ The privacy information revealed with a trunk group does not
+ generally advertise much information about a particular (human) user.
+ It does, however, convey two pieces of potentially private
+ information that 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 parameters and reveal potentially sensitive information
+ on 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.
+
+ 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.
+
+
+
+
+Gurbani & Jennings Standards Track [Page 16]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+ 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 ensure that
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 17]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 18]
+
+RFC 4904 Trunk Groups in tel/sip URIs June 2007
+
+
+Full 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.
+
+
+
+
+
+
+
+Gurbani & Jennings Standards Track [Page 19]
+