IPTEL WG V. Gurbani
Internet-Draft Lucent Technologies
Expires: August 15, 2005 C. Jennings
Cisco Systems
February 14, 2005
Representing trunk groups in tel/sip Uniform Resource Identifiers
(URIs)
draft-ietf-iptel-trunk-group-03.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 August 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
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 August 15, 2005 [Page 1]
Internet-Draft Trunk groups in tel/sip URIs February 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 . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 10
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
11.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Gurbani & Jennings Expires August 15, 2005 [Page 2]
Internet-Draft Trunk groups in tel/sip URIs February 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 August 15, 2005 [Page 3]
Internet-Draft Trunk groups in tel/sip URIs February 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 August 15, 2005 [Page 4]
Internet-Draft Trunk groups in tel/sip URIs February 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. The use of the "phone-context" parameter
of the tel URI appears to provide a satisfactory manner of imposing a
namespace on trunk group names by specifying a global number or any
number of its leading digits (e.g., +33) or a domain name (see
Section 5.1.5 of [4]) .
The use of the "phone-context" parameter in conjunction with this
draft is REQUIRED; implementations choosing to include trunk groups
information 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.
Gurbani & Jennings Expires August 15, 2005 [Page 5]
Internet-Draft Trunk groups in tel/sip URIs February 2005
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
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
Gurbani & Jennings Expires August 15, 2005 [Page 6]
Internet-Draft Trunk groups in tel/sip URIs February 2005
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.
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
Gurbani & Jennings Expires August 15, 2005 [Page 7]
Internet-Draft Trunk groups in tel/sip URIs February 2005
the tel URI defined in [4]:
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 [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.
Examples:
tel:+15555551212;phone-context=telco.example.com;tgrp=tg55
tel:0216;phone-context=+1-555-555;tgrp=TG-1
The example URIs above extends the tel URI with a trunk group
identifier. Transforming these "tel" URI to "sip" URIs yields,
respectively:
sip:+15555551212;phone-context=telco.example.com;tgrp=tg55@
isp.example.net
sip:0216;phone-context=+1-555-555;tgrp=TG-1@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----->|
... ... ...
Gurbani & Jennings Expires August 15, 2005 [Page 8]
Internet-Draft Trunk groups in tel/sip URIs February 2005
| |
| |<----F2---
F1:
INVITE sip:40216@isp.example.net SIP/2.0
...
Contact: <sip:40216;phone-context=isp.example.net;tgrp=tg55@
igwy.isp.example.net>
...
F2:
BYE sip:40216;phone-context=isp.example.net;tgrp=tg55@
igwy.isp.example.net SIP/2.0
...
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
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 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
Gurbani & Jennings Expires August 15, 2005 [Page 9]
Internet-Draft Trunk groups in tel/sip URIs February 2005
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;phone-context=isp.example.net;tgrp=TG2-1@
egwy.isp.example.net SIP/2.0
...
F2:
SIP/2.0 200 OK
...
Contact: <sip:1212;phone-context=isp.example.net;tgrp=TG2-1@
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 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.
Gurbani & Jennings Expires August 15, 2005 [Page 10]
Internet-Draft Trunk groups in tel/sip URIs February 2005
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.
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 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 August 15, 2005 [Page 11]
Internet-Draft Trunk groups in tel/sip URIs February 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 August 15, 2005 [Page 12]
Internet-Draft Trunk groups in tel/sip URIs February 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 August 15, 2005 [Page 13]
