GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4904

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4904.txt · Last modified: 2007/06/04 19:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki