INTERNET-DRAFT                                             IPTEL WG
October 2002                                       Vijay K. Gurbani
Expires: April 2003                       Lucent Technologies, Inc.
                                                    Cullen Jennings
                                                Cisco Systems, Inc.
                                                       Jon Peterson
                                                            NeuStar


Document: draft-ietf-iptel-trunk-group-00.txt

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

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.

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.

 Problem

   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



draft-iptel-trunk-group-00.txt                                 [Page 1]

 
Representing trunk groups in sip/tel URIs                   October 2002


      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: There isn't any standardized grammar to
      represent trunk groups, leading to the 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 I-D is to outline how to structure and represent the
   trunk group information in URIs.  The next section contains
   definitions for trunks, trunk groups and presents a reference
   architecture to aid in the discussion that follows.  Section 3
   contains the various issues we have identified thus far and derives
   requirements from these.  It also provides recommendations on how to
   meet the requirements.  Section 4 provides the ABNF and examples for
   a trunk group identifier. Section 5 has a call flow, and section 6
   contains security considerations.

 Introduction

2.1 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 [4].

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



draft-iptel-trunk-group-00.txt                                 [Page 2]

 
Representing trunk groups in sip/tel URIs                   October 2002


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

2.2 Architecture

      <Pull in architecture from Jon P.'s iptel-gwreg-arch I-D>

 Issues

3.1 "sip" URI or "tel" URI?

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

   The trunk group information can be carried in either the "sip" URI
   [1] or the "tel" URI [2, 3].  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 [1] can be used to derive
   an equivalent "sip" URI from a "tel" URI, complete with the trunk-
   group parameter.

3.2 Trunk-group namespace: global or local?

   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.

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

3.3 Originating trunk group and terminating trunk group




draft-iptel-trunk-group-00.txt                                 [Page 3]

 
Representing trunk groups in sip/tel URIs                   October 2002


   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.

   REQ 4: SIP network intermediaries (proxy server and redirect servers)
   should be able to add the destination trunk group attribute to SIP
   sessions as a route is selected for a call.

   If the trunk group parameter appears in a R-URI of a request, it
   represents the destination trunk group.

        This is consistent with using the R-URI as a routing
        element; SIP routing entities may use the trunk group
        parameter in the R-URI to make intelligent routing
        decisions.  Furthermore, this also satisfies REQ 4, since
        a SIP network intermediary can modify the R-URI to
        include the trunk group information.

   If the trunk group parameter appears in a Contact header of a request
   establishing a session (for the purpose of this I-D, that request is
   an INVITE only), then it represents the trunk group that a UAC is
   using for that dialog (originating trunk group).  Subsequent requests
   destined to that UA MUST copy the trunk group from the Contact header
   into the R-URI.

        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.

 Trunk group identifier: ABNF and examples

   The syntax for a trunk group identifier is as follows:

    trunk-group = "tgrp" EQUAL trunk-group-token



draft-iptel-trunk-group-00.txt                                 [Page 4]

 
Representing trunk groups in sip/tel URIs                   October 2002


    trunk-group-token = trunk-group-namespace "=" trunk-group-label
    trunk-group-namespace = "local" / trunk-group-namespace-name
    trunk-group-namespace-name = *1(unreserved / escaped /
                                    trunk-group-unreserved )
    trunk-group-label = *1( unreserved / escaped /
                            trunk-group-unreserved / "=" )
    trunk-group-unreserved = "&" / "+" / "$" / "," / "?" / "/"

   This I-D defines a "local" namespace for trunk group names having
   local significance only (i.e. the name is valid for a particular
   administrative domain).  Organizations that need a global namespace
   for their trunk groups MUST register a global namespace string with
   IANA, thus guaranteeing uniqueness for the namespace.

   Example: tel:+14085551212;tgrp=local=tg55/3

   The example URI above extends the tel URI with a trunk group
   identifier having local significance only.  Transforming this "tel"
   URI to a "sip" URI yields:

      sip:+14085551212;tgrp=local=tg55/3@someprovider.il.us

 Example call flows

   The following call flow depicts a call request arriving at a SIP
   proxy through a PSTN gateway on a certain trunk group.  The gateway
   treats the trunk group over which the call arrives as an originating
   trunk group and stores this information in the Contact header (F1).
   It then formats and sends an INVITE request to its controlling proxy
   for further routing (F1).  The proxy chooses an appropriate next hop
   server (which may be yet another gateway) and modifies the R-URI,
   adding a destination trunk group before sending it downstream (F2).

   After the session has been established, the UA playing the part of
   the UAS during session establishment sends a BYE request to teardown
   the session (F3).  Note that the R-URI of this request is the Contact
   header from the INVITE request, complete with the trunk group
   parameter.


                    Ingress                         Next downstream
      PSTN          Gateway          Proxy          SIP server
       |              |                |              |
       | Call Request |                |              |
       +------------->| F1             |              |
       |              +--------------->| F2           |
       |              |                +------------->|
      ...            ...              ...            ...



draft-iptel-trunk-group-00.txt                                 [Page 5]

 
Representing trunk groups in sip/tel URIs                   October 2002


       |              |                |           F3 |
       |              |                |<-------------+
       |              |                |              |


   F1:

    INVITE sip:+12025551212@someprovider.il.us SIP/2.0
    ...
    Contact: <sip:gateway1.someprovider.il.us;tgrp=local=1001BSTAOMA01MN>

   F2:

    INVITE sip:+12025551212;tgrp=local=tg89@UA.someprovider.il.us SIP/2.0
    ...
    Contact: <sip:gateway1.someprovider.il.us;tgrp=local=1001BSTAOMA01MN>

    F3:
    BYE sip:gateway1.someprovider.il.us;tgrp=local=1001BSTAOMA01MN SIP/2.0
    ...

 Security considerations

   The extension defined in this I-D does not add any additional
   security concerns beyond the normal SIP one.  The trunk group
   information is carried in Request-URIs and Conatct headers; it is
   simply a modifier of an address, and the trust imparted to that
   address is not affected by such a modifier.  It does, however,
   introduce an additional means for network topology and information
   about which trunks a domain uses to be propagated beyond that domain.
   If this is a privacy concern, then the domain should take precautions
   to hide that information before it leaves their trust boundary.

  IANA considerations

   <To fill in>

 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, Tom Taylor, and Al Varney for insightful
   discussions and comments.

AUTHORS' ADDRESSES

   Vijay K. Gurbani                           Cullen Jennings



draft-iptel-trunk-group-00.txt                                 [Page 6]

 
Representing trunk groups in sip/tel URIs                   October 2002


   Email: vkg@lucent.com                      Email: fluffy@cisco.com

   Jon Peterson
   jon.peterson@neustar.biz


Normative References:

   []  J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
        Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
        Session Initiation Protocol", IETF RFC 3216, June 2002,
        <http://www.ietf.org/rfc/rfc3261.txt>

   []  A. Vaha-Sipila, "URLs for Telephone Calls", IETF RFC 2806,
        April 2000, <http://www.ietf.org/rfc/rfc2806.txt>

   []  H. Sculzrinne, A. Vaha-Sipila, "The tel URI for Telephone
        Calls", IETF Internet-Draft, Expires December 2002, Work in
        Progress, <http://www.ietf.org/internet-drafts/draft-antti-
        rfc2806bis-05.txt>
Informative References


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

FULL COPYRIGHT STATEMENT

   "Copyright (C) The Internet Society (date). 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 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 assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING



draft-iptel-trunk-group-00.txt                                 [Page 7]

 
Representing trunk groups in sip/tel URIs                   October 2002


   TASK FORCE DISCLAIMS 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.















































draft-iptel-trunk-group-00.txt                                 [Page 8]