[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: November 25, 2005                                   C. Jennings
                                                           Cisco Systems
                                                            May 24, 2005


Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs)
                  draft-ietf-iptel-trunk-group-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 November 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a standardized mechanism to convey trunk
   group- related information in sip and tel Uniform Resource
   Identifiers (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 & Jennings      Expires November 25, 2005               [Page 1]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


Table of Contents

   1.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Problem statement  . . . . . . . . . . . . . . . . . . . . .   4
   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  . . . . . . . . .   6
   5.   Reference architecture . . . . . . . . . . . . . . . . . . .   7
   6.   Trunk group identifier: ABNF and examples  . . . . . . . . .   8
   7.   Example call flows . . . . . . . . . . . . . . . . . . . . .   9
     7.1  Example 1  . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.2  Example 2  . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.   Security considerations  . . . . . . . . . . . . . . . . . .  12
   9.   IANA considerations  . . . . . . . . . . . . . . . . . . . .  12
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  13
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1   Normative References . . . . . . . . . . . . . . . . . .  13
     11.2   Informative References . . . . . . . . . . . . . . . . .  14
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  14
        Intellectual Property and Copyright Statements . . . . . . .  15




























Gurbani & Jennings      Expires November 25, 2005               [Page 2]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


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

   Call routing in the Public Switched Telephone Network (PSTN) is
   accomplished by routing calls over specific circuits (commonly
   referred to as "trunks") between Time Division Multiplexed (TDM)
   circuit switches.  In large switches, a group of trunks that connects
   to the same target switch or network is called a "trunk group."
   Consequently, trunk groups have labels, which are used as the main
   indication for the previous and next TDM switch participating in
   routing the call.

   Formally, we define a trunk and trunk group and related terminology
   as follows (definition of "trunk" and "trunk group" is from [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.

      Digital Signal 0 (DS0): Digital Signal X is a term for a series of
      standard digital transmission rates based on DS0, a transmission
      rate of 64kbps (the bandwidth normally used for one telephone
      voice channel).  The European E-carrier system of transmission
      also operates using the DS series as a base multiple.

   Since the introduction of ubiquitous digital trunking, which resulted
   in the allocation of DS0s between end offices in minimum groups of 24
   (in North America), it has become common to refer to bundles of DS0s
   as a trunk.  Strictly speaking, however, a trunk is a single DS0
   between two PSTN end offices - however, for the purposes of this
   document, the PSTN interface of a gateway acts effectively as an end
   office (i.e. if the gateway interfaces with Signaling System 7 (SS7),
   it has its own SS7 point code, and so on).  A trunk group, then, is a
   bundle of DS0s (that need not be numerically contiguous in an SS7
   Trunk Circuit Identification Code numbering scheme) which are grouped
   under a common administrative policy for routing.

   A Session Initiation Protocol (SIP) [3] to PSTN gateway may have



Gurbani & Jennings      Expires November 25, 2005               [Page 3]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


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

3.  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.  Absent such guidelines, inter-operability will suffer as a
   proxy vendor must conform to the expectations of a gateway as to
   where it expects trunk-group information to be present (and vice
   versa).

   The aim of this Internet draft is to outline how to structure and
   represent the trunk group information as an extension to the tel URI
   [4] in a standardized manner.

4.  Requirements and rationale

4.1  sip URI or tel URI?

   REQ 1: Trunk group information MUST be defined as an extension to the



Gurbani & Jennings      Expires November 25, 2005               [Page 4]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


   "tel" URI [4].

   The trunk group information can be carried in either the "sip" URI or
   the "tel" URI.  Since trunks groups are intimately associated with
   the PSTN, it seems reasonable to define them as extensions to the
   "tel" URI (any SIP request that goes to a gateway could reasonably be
   expected to have a tel URL, in whole or in part, in its R-URI
   anyway).  Furthermore, using the tel URL also allows this format to
   be reused by non-SIP VoIP protocols (which could include anything
   from MGCP or Megaco to H.323, if the proper information elements are
   created).

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

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 to prevent these.  The judicious use of namespaces is a
   solution to this problem.  A trunk group in a URI MUST belong to a
   namespace.

      At first glance, it would appear that the use of the tel URI's
      "phone-context" parameter provides a satisfactory means of
      imposing a namespace on a trunk group.  The "phone-context"
      parameter identifies the scope of validity of a local telephone
      number.  And therein lies the problem.  Semantically, a "phone-
      context" tel URI parameter is applicable only to a local telephone
      number and not a global one (i.e., one preceeded by a '+').  Trunk
      groups, on the other hand, may appear in local or global telephone
      numbers.  Thus, what is needed is a new parameter with equivalent
      functionality of the "phone-context" parameter of the tel URI, but
      one that is equally applicable to local and global telephone
      numbers.

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



Gurbani & Jennings      Expires November 25, 2005               [Page 5]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


   requirement that both of these trunk groups need to be carried in SIP
   requests.

   Instead of having two parameters, one for the originating trunk group
   and the other for a terminating trunk group, the placement of the
   trunk group parameter in a SIP Contact header or the R-URI,
   respectively, signifies the intent.  A proxy (or any other
   intermediary -- see next section) MAY insert a trunk group appears in
   the R-URI; to the next downstream entity this signifies an egress (or
   terminating) trunk group to be used.

   Conversely, when a trunk group parameter appears in the Contact
   header, this signifies the trunk group over which the call came over,
   i.e., the ingress (or orgininating) trunk group.

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.

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

   To the processing User Agent Server (UAS), a trunk group in the R-URI
   implies that it should use the named trunk group for the outbound
   call.  If a UAS supports trunk groups but is not configured with the
   particular trunk group identified in the R-URI, it SHOULD not use any
   other trunk group other than the one requested.

   A User Agent Client (UAC) that initiates a call and supports this
   draft MAY include the trunk group in the Contact header.  If it does
   so, the trunk group in the Contact header represents the originating
   trunk group.  Subsequent requests destined to that UAC MUST copy the
   trunk group from the Contact header into the R-URI.  Note that a
   Contact URI MUST be a sip or sips URI, thus, what appears in the
   Contact header is a SIP translation of the tel URI, complete with the
   trunk group information.

      Arguably, the originating trunk group can be part of the From URI.
      However, semantically, the URI in a From header is an abstract
      identifier which represents the resource thus identified on a



Gurbani & Jennings      Expires November 25, 2005               [Page 6]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


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


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


   GW1 in Figure 1 is always cognizant of any requests that arrive over
   trunk group TG1-1.  If it wishes to propagate the ingress trunk group
   to the proxy, it MUST arrange for the trunk group to appear in the
   Contact header of the SIP request destined to the proxy.  The proxy
   will, in turn, propagate the ingress trunk group in the Contact
   header further downstream.

   The proxy uses GW2 and GW3 as egress gateways to the PSTN.  It is
   assumed that the proxy has access to a routing table for GW2 and GW3
   which includes the appropriate trunk groups to use when sending a
   call to the PSTN (exactly how this table is constructed is out of
   scope for this draft; [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 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.





Gurbani & Jennings      Expires November 25, 2005               [Page 7]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


6.   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-group = ";tgrp=" trunk-group-label ";trunk-context="
      trunk-context
    trunk-group-label = *1( unreserved / escaped /
                            trunk-group-unreserved )
    trunk-group-unreserved = "/" / "&" / "+" / "$"
    trunk-context = descriptor

      trunk-group-unreserved is the intersection of param-unreserved
      defined in [4] and user-unreserved defined in [3].  Since the
      trunk group is an extension to the tel URI and will end up as the
      user portion of a SIP URI, the ABNF for it has to ensure that it
      can be adequately represented in both the constructs.
      descriptor is defined in [4].


   The "trunk-context" and "tgrp" parameter SHOULD use lower-case
   characters as tel URIs may be used within contexts where comparisons
   are case sensitive.

   The "trunk-context" parameter imposes a namespace on the trunk group
   by specifying a global number or any number of its leading digits
   (e.g., +33), or a domain name.  Syntactically, it is modeled after
   the "phone-context" parameter of the tel URI [4], and semantically,
   it serves an equivalent function except that unlike the "phone-
   context" parameter, the "trunk-context" parameter can appear in
   either a local or global tel URI.

   If the receiver of a SIP request is not the owner of the domain (or
   global prefix) specified in the "trunk-context", it MUST treat the
   trunk group as if it was not there.

   For equivalency purposes, two URIs containing trunk group identifiers
   are equivalent according to the base comparison rules of the URIs AND
   the values of their "tgrp" and "trunk-context" parameters MUST match.
   The base comparison rules of a tel URI are specified in Section 4 of
   [4], and the base comparison rules of a sip URI are specified in
   Section 19.1.4 of [3].

   Examples:



Gurbani & Jennings      Expires November 25, 2005               [Page 8]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


   1.  Trunk group in a local number, with a phone-context parameter
   (mind the line breaks added for readibility):

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

   2.  Trunk group in a global number:

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

   3.  Trunk group in a global number:

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


7.  Example call flows

7.1  Example 1

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


         GW1           SIP Proxy           GW2
   From   |               |                 |
   PSTN-->|               |                 |
          +---F1--------->|                 |
          |               +---F2----------->|
         ...             ...               ...
          |               |                 |
          |               |                 | --> Send to PSTN
          |               |                 | and receive Answer
          |               |                 | Complete Message (ACM)
         -----------------------------------------
         Call in progress
         -----------------------------------------
          |               |                 |
          |               |<-----------F3---+
          +<--------------+                 |



Gurbani & Jennings      Expires November 25, 2005               [Page 9]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


         ...             ...               ...

   In the call flow below, certain headers and messages have been
   omitted for brevity.  In F1, GW1 receives a call setup request from
   the PSTN over a certain trunk group.  GW1 arranges for this trunk
   group to appear in in the Contact header of the request destined to
   the SIP proxy.


   F1:
   INVITE sip:+16305554554@example.com
   ...
   Contact: <sip:4554;phone-context=example.com;tgrp=TG1-1;
      trunk-context=example.com@gw1.example.com>

   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.


   F2:
   INVITE sip:+16305554554;tgrp=TG2-1;trunk-context=example.com@
      gw2.example.com
   ...
   Record-Route: <sip:proxy.example.com;lr>
   Contact: <sip:4554;phone-context=example.com;tgrp=TG1-1;
      trunk-context=example.com@gw1.example.com>

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


   F3:
   BYE sip:4554;phone-context=example.com;tgrp=TG1-1;
     trunk-context=example.com@gw1.example.com
   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; in it, GW1 gets a call request from the PSTN
   without a calling party number.  This is not an uncommon case, and
   may happen for a variety of reasons, including privacy and
   interworking between different signaling protocols before the request
   reached GW1.  Under normal circumstances (i.e., instances where the



Gurbani & Jennings      Expires November 25, 2005              [Page 10]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


   calling party number is present in signaling), GW1 would derive a sip
   URI to insert into the Contact header.  This sip URI may contain, as
   its user portion, the calling party number from from the incoming SS7
   signaling information.  The trunk group information then becomes part
   of the user portion as discussed previously.

   If a gateway receives an incoming call where the calling party number
   is not available, it MUST create a sip URI that has, as its user
   portion, a token that is generated locally and has local significance
   to the gateway.  Details of generating such a token are
   implementation dependent; potential candidates include the gateway
   line number or port number where the call was accepted.  This sip URI
   is subsequently inserted in the Contact header of the SIP request
   going downstream from the gateway.

      The tel scheme does not allow for an empty URI; thus the global-
      number or local-number production rule of the tel URI [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.2  Example 2

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



              example.com             example.net
       /-------------------------\   /-----------\
         GW1          SIP Proxy 1     SIP Proxy 2
   From   |               |                 |
   PSTN-->|               |                 |
          +---F1--------->|                 |
          |               +---F2----------->|
         ...             ...               ...


   F1:
   INVITE sip:+16305554554@example.com
   ...
   Contact: <sip:4554;phone-context=example.com;tgrp=TG1-1;
      trunk-context=example.com@gw1.example.com>




Gurbani & Jennings      Expires November 25, 2005              [Page 11]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


   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:+16305554554@example.net
   ...
   Record-Route: <sip:proxy.example.com;lr>
   Contact: <sip:4554;phone-context=example.com;tgrp=TG1-1;
      trunk-context=example.com@gw1.example.com>

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

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 R-URIs and Contact headers; it is
   simply a modifier of an address, and the trust imparted to that
   address is not affected by such a modifier.  The privacy information
   revealed with trunk groups does not generally advertise much
   information about a particular (human) user.  It does, however,
   convey two pieces of potentially private information which may be
   considered sensitive by carriers.  First, it may reveal how a carrier
   may be performing least-cost routing and peering; and secondly, it
   does introduce an additional means for network topology and
   information of a carrier.  It is up to the discretionary judgment of
   the carrier if it wants to include the trunk group information and
   reveal potentially sensitive information on its network topology.

9.  IANA considerations

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






Gurbani & Jennings      Expires November 25, 2005              [Page 12]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


      Syntax restrictions: Details on the syntax are explained in RFC
      AAAA.  A phone-context parameter must occur in any tel URL that
      contains a tgrp parameter.

      Reference: RFC AAAA
      [Note to RFC editor: Please replace AAAA with the RFC number
      assigned to this document.]
      Parameter name: trunk-context

      Description: The context for a trunk group; imposes a namespace.

      This parameter is not mandatory.

      Syntax restrictions: Details on the syntax are explained in RFC
      AAAA.  A trunk-context parameter must occur in any tel URL that
      contains a tgrp parameter.

      Reference: RFC AAAA
      [Note to RFC editor: Please replace AAAA with the RFC number
      assigned to this document.]

10.  Acknowledgments

   The authors would like to acknowledge the efforts of the participants
   of the SIPPING and IPTEL working group, especially Bryan Byerly, John
   Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike
   Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran,
   Takuya Sawada, Tom Taylor, and Al Varney.

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 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]  Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966,
        December 2004.






Gurbani & Jennings      Expires November 25, 2005              [Page 13]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


11.2  Informative References

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

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


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



















Gurbani & Jennings      Expires November 25, 2005              [Page 14]


Internet-Draft        Trunk groups in tel/sip URIs              May 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Gurbani & Jennings      Expires November 25, 2005              [Page 15]


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