DISPATCH Working Group M. Patel
Internet-Draft Nortel
Intended status: Standards Track R. Jesske
Expires: April 11, 2010 Deutsche Telekom
M. Dolly
AT&T
October 8, 2009
Uniform Resource Identifier (URI) Parameters for indicating the Calling
Party's Catagory and Originating Line Identity
draft-patel-dispatch-cpc-oli-parameter-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 April 11, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Patel, et al. Expires April 11, 2010 [Page 1]
Internet-Draft CPC and OLI URI Parameters October 2009
Abstract
This document defines two new URI parameters to describe the calling
party's category and toll class of service originating line
information which are parameters also used in SS7 ISUP and other
telephony signalling protocols. The intended use of these URI
parameters is for the "tel" URI or equivalent SIP URI representation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Parameter Definitions . . . . . . . . . . . . . . . . . . . . 4
4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Patel, et al. Expires April 11, 2010 [Page 2]
Internet-Draft CPC and OLI URI Parameters October 2009
1. Introduction
SS7 ISUP[ITU-ISUP] defines a Calling Party's Category (CPC) parameter
that characterizes the station used to originate a call and carries
other important state that can describe the originating party. One
example of such information is the call may originate from a
payphone; such information can be used by the network to handle the
call in a specific way. When telephone numbers are contained in
URIs, such as the tel URI or equivalent SIP URI, it may be desirable
to communicate any CPC associated with that telephone number or, in
the context of a call, the party calling from it. [RFC3966]
In some networks (including North America), the Originating Line
Information (OLI) parameter defined in ANSI ISUP is used to carry
information related to the calling party and the class of service for
a call. Legacy multifrequency (MF) signalling networks carry this
information in the ANI II Digits [ANSI-ISUP]. The call can originate
from a multitude of devices or stations. For example, a coin operated
phone or a phone located inside a prison can be used to originate a
call. In such cases, it can be desirable to handle calls originating
from such stations in a specific manner, or to restrict certain
services to the calling party. A URI parameter specified in this
document is designed to carry data related to these sources as
well. [1]
The following sections describe the formal syntax of the "cpc" and
"oli" parameters and their usage.
Emergency registration is possible only when the UE has sufficient
credentials to register with its home network and can detect that an
emergency session is initiated. Unfortunately, marking of the
emergency registration can not be fulfilled by the use of the Service
URN.
In some countries, it is a regulatory requirement that devices be
able to place emegency calls in circumstances where other calls may
not be permitted. When a UAC issues an emergency marked REGISTER
request it informs the registrar that the contact address and the
address-of-record being registered are to be used for emergency
calls, and roaming and barring restrictions should not be applied for
the registered address-of-record.
This document proposes a way to mark a REGISTER request as an
emergency registration.
Patel, et al. Expires April 11, 2010 [Page 3]
Internet-Draft CPC and OLI URI Parameters October 2009
2. Terminology
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 [RFC2119].
3. Parameter Definitions
The Calling Party's Category (CPC) and the Originating Line
Information (OLI) are represented as URI parameters for the tel URI
scheme and the SIP URI representation of telephone numbers. The ABNF
syntax is as follows. The 'par' production is defined in RFC 3966
[RFC5234][RFC3966]. The "/=" syntax indicates an extension of the
production on the left-hand side:
par /= cpc / oli
cpc = cpc-tag "=" cpc-value
oli = oli-tag "=" oli-value
cpc-tag = "cpc"
oli-tag = "oli"
cpc-value = "ordinary" / "test" / "operator" / "payphone" /
"unknown" / genvalue
oli-value = 2*(DIGIT)
genvalue = 1*(alphanum / "-" / "." )
The semantics of these CPC values are described below:
ordinary: The caller has been identified, and has no special
features.
test: This is a test call that has been originated as part of a
maintenance procedure.
operator: The call was generated by an operator position.
payphone: The calling station is a payphone.
unknown: The CPC could not be ascertained.
The two digit OLI values are decimal codes assigned and administered
by NANPA.
The "cpc" and "oli" URI parameters are optional parameters. At the
most, one "cpc" and/or one "oli" parameter may be included in a URI
of the calling party.
An example of the syntax of the "cpc" parameter is given below:
From: <tel:+17005554141;cpc=payphone>;tag=1928301774
Alternatively, the tel URI may be included in the P-Asserted-Identity
header [RFC3325]:
Patel, et al. Expires April 11, 2010 [Page 4]
Internet-Draft CPC and OLI URI Parameters October 2009
P-Asserted-Identity: <tel: +17005554141;cpc=payphone>
The "oli" URI parameter usage is given in the following example,
which uses the SIP URI representation of telephone numbers: :
From: <sip: +1700554141@example.com;oli=29>;tag=1928301774
The "oli" parameter with value 29 indicates that the device that the
call is initiated from is located within a prison.
4. Usage
The CPC and OLI are generally useful only when describing the
originator of a telephone call or the station from where a telephone
call is originated. Therefore, when this parameter is used in an
application such as SIP, it is recommended that the parameter be
applied to URIs that characterize the originator of a call (such as a
SIP URI or tel URI in the P-Asserted-Identity header field or the
From header field of a SIP message). Note that many Calling Party's
Category values from the PSTN are intentionally excluded from the
"cpc" parameter as they are either meaningless outside of the PSTN or
can be represented using another existing concept. For example, the
language of an operator can be expressed more richly using the
Accept-Language header in SIP than in the "cpc" parameter. Similarly
the priority of a call is a characteristic of the call and not the
calling party.
It is anticipated that "cpc" and "oli" URI parameters will be used
primarily by gateways that interwork ISUP or ANI II networks with SIP
networks. Various SIP network intermediaries might consult the CPC
or OLI information as they make routing decisions, although no
specific behavior is prescribed in this document. While no specific
mapping of the various ISUP parameters that contain CPC or OLI data
is offered in this document, creating such a mapping would be
trivial.. It is proposed that use of this URI parameter is
restricted to the Contact header included in the REGISTER request
(and the 2xx response to the REGISTER request) related to an
emergency call only. The "sos" URI parameter MUST NOT be considered
as a replacement for the Service URN for emergency calls originated
by a UA.
While the CPC and OLI could be conveyed using the ISUP tunneling
mechanism described in RFC 3372 , this technique is widely regarded
by the implementation community as overkill for the problem of
conveying CPC and OLI information. For example, the "cpc" and "oli"
parameters provides a convenient way for SIP intermediaries to make
routing decisions based on the CPC and OLI information without having
Patel, et al. Expires April 11, 2010 [Page 5]
Internet-Draft CPC and OLI URI Parameters October 2009
to implement an ISUP parser. The "cpc" and "oli" URI parameters
provide a simple, convenient form of CPC and OLI interoperability of
SIP with ISUP and ANI II, which is otherwise poorly addressed in RFC
3372 [RFC3372]. Indeed when a SIP intermediary makes routing
decisions for a call where both the originating and the terminating
gateways natively use ANI II, the ISUP tunneling approach is
especially unattractive, requiring each of the three devices to
perform a translation into an otherwise unneeded PSTN protocol.
[RFC3372]
If the "cpc" URI parameter is not present, consumers of the CPC
information should treat the URI as if it specified a CPC of
"ordinary". If the "oli" URI parameter is not present, consumers of
the OLI information should treat the URI as if no OLI information is
provided. If a SIP intermediary does not support the "cpc" or "oli"
URI parameters and receives a SIP message where the calling party URI
in the From or P-Asserted-header fields includes a "cpc" or "oli" URI
parameter, then the SIP intermediary silently ignores the URI
parameter in accordance with RFC 3261. [RFC3261]
At most, one instance of the "cpc" parameter and/or one instance of
the "oli" parameter can be associated with a particular URI within a
SIP request. It is recommended that the "cpc" and "oli" URI
parameters are associated with URIs included in the P-Asserted-
Identity header field. Where the P-Asserted-Identity header field is
not supported or included, another header field used to carry a URI
to characterize the originator of a call may be used. One example of
such a header field is the From header field. The following section
discusses further the motivation behind this recommendation.
5. Security Considerations
There are three potential risks specific to the information provided
by the Calling Party's Category or Originating Line Identity:
- leakage of potentially private information;
- the threat of tampering with the CPC or OLI to add false CPC or OLI
values; and
- the threat of tampering with the CPC or OLI to remove actual CPC or
OLI values.
The information contained in the "cpc" or "oli" parameter may be of a
private nature, and it may not be appropriate for this value to be
revealed to the destination user (typically it would not be so
revealed in the PSTN). However, the calling party's category is
Patel, et al. Expires April 11, 2010 [Page 6]
Internet-Draft CPC and OLI URI Parameters October 2009
often discoverable or easily guessable from the calling party's phone
number. For that reason it is unlikely that this information is
significantly more privacy sensitive than the telephone number
itself. The same techniques used to provide complete or partial
telephone number privacy in SIP are appropriate to apply to the "cpc"
and "oli" parameters as well. For more information about privacy
issues in SIP see RFC 3323[RFC3323] . The mechanism described in RFC
3325 [RFC3325]may also be relevant for maintaining partial privacy or
the CPC or OLI within a trusted administrative domain or federation
of domains as described in RFC 3324. [RFC3324]
Making a call with a falsified CPC or OLI (ex: hospital, police, or
operator) could allow the caller to gain access to resources or
information not otherwise available. Likewise removing an
"undesirable" CPC or OLI value (ex: prison or hotel) could allow the
caller to bypass various restrictions in the telephone network. For
that reason, agents which expect CPC or OLI values SHOULD take care
to insure the integrity and authenticity of the "cpc" or "oli" URI
parameter. The RECOMMENDED mechanism to protect the entire calling
party address along with the "cpc" or "oli" URI parameter is the SIP
Identity [5] mechanism. Alternatively, agents within an
administrative domain or federation of domains MAY use the mechanism
described in RFC 3325to place the "cpc" or "oli" URI parameter in a
P-Asserted-Identity header field. When such mechanism is used, the
"cpc" or "oli" URI parameter is added by a network entity or SIP
intermediary if knowledge of the calling party's category or
originating line identity (class of service) is known. [RFC3325]
When the end-device, acting as a UAC originating a call, is not
trusted, the value of a "cpc" or "oli" URI parameter included by the
UAC may be removed or modified by a trusted network entity. If a
request containing CPC or OLI is sent towards a non-trusted entity,
this information should be removed.
The SIP Identity mechanism provides a signature over the URI in the
From header field of a SIP request. It can sign a tel URI alone or a
tel URI embedded in a SIP or SIPS URI, but it provides stronger
protection against tampering when the tel URI is embedded in a SIP or
SIPS URI. Because there is no direct correlation between a tel URI
and an Internet domain, the receiver can use a list of domains from
which it will trust CPC or OLI information, or a list of root
certificates which are associated with trusting CPC or OLI
information.
Otherwise, this mechanism adds no new security considerations to
those discussed in RFC 3261. [RFC3261]
Patel, et al. Expires April 11, 2010 [Page 7]
Internet-Draft CPC and OLI URI Parameters October 2009
6. IANA Considerations
This document extends the registry of URI parameters for the Tel URI
and SIP URI as defined RFC 3969and RFC 5341 [RFC3969]. Two new URI
parameters for the Tel URI and SIP URI schemes are defined in this
document as follows: [RFC5341]
Parameter Name: cpc, oli
Predefined Values: Yes
Reference: This document
7. Acknowledgements
The original version of this document was written by Jon Peterson and
subsequently authored by Rohan Mahy.
This document is based on draft-mahy-iptel-cpc-06
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC5341] Jennings, C. and V. Gurbani, "The Internet Assigned Number
Authority (IANA) tel Uniform Resource Identifier (URI)
Parameter Registry", RFC 5341, September 2008.
[RFC3261] 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.
Patel, et al. Expires April 11, 2010 [Page 8]
Internet-Draft CPC and OLI URI Parameters October 2009
[ITU-ISUP]
International Telecommunications Union, "Recommendation
Q.763: Signalling System No. 7: ISDN user part formats and
codes", December 1999, <http://www.itu.int>.
8.2. Informative References
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-13 (work in progress),
July 2009.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[3GPP.23.167]
3GPP, "IP Multimedia Subsystem (IMS) emergency sessions",
3GPP TS 23.167 7.11.0, December 2008.
[ANSI-ISUP]
American National Standards Institute, "ANSI T1.113-2000,
Signaling System No. 7, ISDN User Part", 2000,
<http://www.ansi.org>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
URIs
[1] <http://www.nanpa.com/number_resource_info/
ani_ii_assignments.html>
Patel, et al. Expires April 11, 2010 [Page 9]
Internet-Draft CPC and OLI URI Parameters October 2009
Authors' Addresses
Milan Patel
Nortel
Maidenhead Office Park, Westacott Way
Maidenhead, Berkshire, UK
Email: milanpa@nortel.com
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307, Germany
Email: r.jesske@telekom.de
Martin Dolly
AT&T
200 Laurel Ave
Middletown, NJ,, US
Email: mdolly@att.com
Patel, et al. Expires April 11, 2010 [Page 10]