[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4904

IPTEL WG                                                      V. Gurbani
Internet-Draft                                       Lucent Technologies
Expires: July 8, 2004                                        C. Jennings
                                                           Cisco Systems
                                                             J. Peterson
                                                                 NeuStar
                                                         January 8, 2004


               Representing trunk groups in tel/sip URIs
                    draft-ietf-iptel-trunk-group-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 8, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document describes a standardized mechanism to convey trunk
   group- related information in SIP and TEL URIs.  An extension to the
   "tel" URI is defined for this purpose.

   This work is being discussed on the iptel@ietf.org mailing list.







Gurbani, et al.           Expires July 8, 2004                  [Page 1]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


Table of Contents

   1.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Problem statement  . . . . . . . . . . . . . . . . . . . . .   3
   3.   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.   Requirements and rationale . . . . . . . . . . . . . . . . .   4
   4.1  sip URI or tel URI?  . . . . . . . . . . . . . . . . . . . .   4
   4.2  Trunk group namespace: global or local?  . . . . . . . . . .   5
   4.3  Originating trunk group and terminating trunk group  . . . .   5
   4.4  Intermediary processing of trunk groups  . . . . . . . . . .   5
   5.   Reference architecture . . . . . . . . . . . . . . . . . . .   6
   6.   Trunk group identifier: ABNF and examples  . . . . . . . . .   7
   7.   Example call flows . . . . . . . . . . . . . . . . . . . . .   8
   7.1  Trunk group in a Contact header  . . . . . . . . . . . . . .   8
   7.2  Trunk group in the R-URI . . . . . . . . . . . . . . . . . .   9
   8.   Security considerations  . . . . . . . . . . . . . . . . . .   9
   9.   IANA considerations  . . . . . . . . . . . . . . . . . . . .  10
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  10
   11.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   11.1 Changes from trunk-group-00  . . . . . . . . . . . . . . . .  10
        Normative References . . . . . . . . . . . . . . . . . . . .  10
        Informative References . . . . . . . . . . . . . . . . . . .  11
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  11
        Intellectual Property and Copyright Statements . . . . . . .  12



























Gurbani, et al.           Expires July 8, 2004                  [Page 2]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


1. 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].

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 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.
   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-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.  Absence 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
   [5] in a standardized manner.

3. Definitions

   Before we take the discussion of trunks any further, we must define
   both a trunk and a trunk group and explain the difference between the
   two. The following definitions are taken from [6].

      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



Gurbani, et al.           Expires July 8, 2004                  [Page 3]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


      systems in which all of the paths are interchangeable except where
      subgrouped.

   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 Public Switched Telephone Network (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 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 (TCIC)
   numbering scheme) which are grouped under a common administrative
   policy for routing.

   A SIP-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 (reference [7]
   provides one such way); once the trunk group has been decided upon,
   this document provides a standardized means to represent it.

4. Requirements and rationale

4.1 sip URI or tel URI?

   REQ 1: Trunk group information MUST be carried in the "tel" URI [5].

   The trunk group information can be carried in either the "sip" URI
   [3] or the "tel" URI [4,5].  Since trunks groups are intimately
   associated with the PSTN (Public Switched Telephone Network), 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-U anyway).
   Furthermore, using the tel URL also allows this format to be re-used
   by non-SIP VoIP protocols (which could include anything from MGCP or
   Megaco to H.323, if the proper IEs are created).

   Finally, once the trunk-group is defined for a "tel" URI, the
   normative procedures of Section 19.1.6 in [3] can be used to derive
   an equivalent "sip" URI from a "tel" URI, complete with the trunk



Gurbani, et al.           Expires July 8, 2004                  [Page 4]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


   group information.

4.2 Trunk group namespace: global or local?

   REQ 2: To prevent inadvertent inter-domain trunk group naming
   collisions, a name space MUST be defined which must be flexible
   enough to both accommodate local naming conventions and provide
   global naming semantics.

   Under normal operations, trunk groups have meaning only within an
   administrative domain (i.e. local scope).  However, to prevent
   inadvertent cross-domain trunk group collisions (which, given
   Murphy's law, will happen), a global scope appears to be useful.  The
   "phone-context" parameter of the tel URI is used to impose a
   namespace by specifying a domain where the trunk groups are
   understood.

   The use of the "phone-context" parameter in conjunction with this
   draft is mandatory; implementations choosing to include trunk groups
   in SIP signaling MUST be capable of parsing and generating the
   "phone-context" parameter of the tel URI.  If a receiver of a SIP
   request is not the owner of the domain specified in the
   "phone-context", it MUST treat the trunk group as if it was not
   there.

4.3 Originating trunk group and terminating trunk group

   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.

4.4 Intermediary processing of trunk groups

   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.





Gurbani, et al.           Expires July 8, 2004                  [Page 5]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


      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 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 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 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.

5. Reference architecture

   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.













Gurbani, et al.           Expires July 8, 2004                  [Page 6]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


                                              +-----+ TG2-1
                                              |     |-------->  To
        TG1-1  +-----+    +-------+     +---->| GW2 | TG2-2     PSTN
   From  ----->|     |    | SIP   |     |     |     |-------->
   PSTN        | GW1 |--->| Proxy |-----+     +-----+
         ----->|     |    +-------+     |     +-----+ TG3-1
               +-----+                  |     |     |-------->  To
                                        +---->| GW3 |           PSTN
                                              |     |-------->
                                              +-----+
   Figure 1: Reference architecture


   On requests arriving to the proxy from GW1, the proxy will have
   access to the trunk group TG1-1 if the request arrived on that
   particular trunk.  If the receiving gateway (GW1, in this case) wants
   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 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; [7] 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.

6.  Trunk group identifier: ABNF and examples

   The ABNF syntax [2] for a trunk group identifier is given below and
   extends the "par" production rule of the tel URI defined in [5]:


    par = parameter / extension / isdn-subaddress / trunk-group


    trunk-group = ";tgrp=" trunk-group-label
    trunk-group-label = *1( unreserved / escaped /
                            trunk-group-unreserved )
    trunk-group-unreserved = "/" / "&" / "+" / "$"

      trunk-group-unreserved is the intersection of param-unreserved
      defined in [5] and user-unreserved defined in [3].  Since the
      trunk group is an extension to the tel URI and will end up as the



Gurbani, et al.           Expires July 8, 2004                  [Page 7]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


      user portion of a SIP URI, the ABNF for it has to ensure that it
      can be adequately representated in both the constructs.

   Examples:


   tel:+15555551212;tgrp=tg55;phone-context=telco.example.com
   tel:0216;tgrp=TG-1;phone-context=+1-555-555

   The example URIs above extends the tel URI with a trunk group
   identifier. Transforming these "tel" URI to "sip" URIs yields,
   respectively:


   sip:+15555551212;tgrp=tg55;phone-context=telco.example.com@isp.example.net
   sip:0216;tgrp=TG-1;phone-context=+1-555-555@isp.example.net


7. Example call flows

7.1 Trunk group in a Contact header

   This call flow depicts a gateway accepting a call from the PSTN and
   conversing with its SIP proxy in order to further route the call
   (F1).  At some later time after the call has been established, the
   gateway receives a BYE (F2) to tear down the call (note the R-URI in
   the BYE).


   PSTN           Ingress      Proxy
                  Gateway
      |              |           |
      |Call Request  |           |
      +------------->|           |
      |              +---F1----->|
     ...            ...         ...
      |              |
      |              |<----F2---


   F1:
      INVITE sip:40216@isp.example.net SIP/2.0
      ...
      Contact: <sip:40216;tgrp=tg55;phone-context=isp.example.net@igwy.isp.example.net>
      ...

   F2:
      BYE sip:40216;tgrp=tg55;phone-context=isp.example.net@igwy.isp.example.net



Gurbani, et al.           Expires July 8, 2004                  [Page 8]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


      ...


7.2 Trunk group in the R-URI

   This call flow depicts a proxy sending a request to a gateway with a
   particular trunk group (F1).  The gateway sends the request to the
   PSTN; when the callee picks up the phone, a 200 OK is generated
   towards the UAC (F2).  Note the Contact of the 200 OK; it contains
   the trunk group information.  Subsequent requests from the UAC will
   contain this URI as the R-URI.


     UAC           Proxy       Egress
                               Gateway
      |              |            |
      |Call Request  |            |
      +------------->|            |
      |              +---F1------>|
      |              |            |---> Interface with PSTN and
      |              |            |     received Answer Complete Message (ACM)
      |              +<-------F2--+
      |              |            |
     ...            ...          ...

   F1:
      INVITE sip:+15555551212;tgrp=TG2-1;phone-context=isp.example.net@egwy.isp.example.net SIP/2.0
      ...
   F2:
      SIP/2.0 200 OK
      ...
      Contact: <sip:1212;tgrp=TG2-1;phone-context=isp.example.net@egwy.isp.example.net>


8. Security considerations

   The extension defined in this document does not add any additional
   security concerns beyond those already enumerated in [3] .  The trunk
   group information is carried in Request-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 reveal much information
   about a particular (human) user.  It does, however, reveal 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.
   If revealing this information is considered a privacy concern by a



Gurbani, et al.           Expires July 8, 2004                  [Page 9]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


   carrier, it should take precautions to hide it.

9. IANA considerations

   Section 9 of [5] 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.]

10. Acknowledgments

   The authors would like to acknowledge the efforts of all the
   participants in the SIPPING and IPTEL working group.  Special thanks
   to John Hearty, Alan Johnston, Rohan Mahy, Mike Pierce, Adam Roach,
   Jonathan Rosenberg, Bryan Byerly, Dave Oran, Tom Taylor, and Al
   Varney for insightful discussions and comments.

11. Changes

11.1 Changes from trunk-group-00
   1.  Changed tgrp=local syntax.
   2.  Introduction of "phone-context" parameter.
   3.  Redid the Examples section and added an architecture diagram.

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 2234, November 1997.

   [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]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
        2000.




Gurbani, et al.           Expires July 8, 2004                 [Page 10]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


   [5]  Schulzrinne, H. and A. Vaha-Sipila, "The tel URI for Telephone
        Calls", draft-ietf-iptel-rfc2806bis-02 (work in progress), July
        2003.

Informative References

   [6]  "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997,
        <http://www.telcordia.com>.

   [7]  Bangalore, M., Kumar, R., Rosenberg, J., Salama, H. and D. Shah,
        "A Telephony Gateway REgistration Protocol (TGREP)",
        draft-ietf-iptel-tgrep-02.txt (work in progress), December 2003.


Authors' Addresses

   Vijay Gurbani
   Lucent Technologies
   2000 Lucent Lane
   Rm 6G-440
   Naperville, IL  60566
   USA

   Phone: +1 630 224 0216
   EMail: vkg@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


   Jon Peterson
   NeuStar
   1800 Sutter St.
   Suite 570
   Concord, CA  94520
   USA

   Phone: +1 925 363 8720
   EMail: jon.peterson@neustar.biz




Gurbani, et al.           Expires July 8, 2004                 [Page 11]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Gurbani, et al.           Expires July 8, 2004                 [Page 12]


Internet-Draft        Trunk groups in tel/sip URIs          January 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Gurbani, et al.           Expires July 8, 2004                 [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/