TOC |
|
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 29, 2010.
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.
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 and SIP URI address schemes.
1.
Introduction
2.
Terminology
3.
Parameter Definitions
4.
Usage
5.
Security Considerations
6.
IANA Considerations
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
TOC |
SS7 ISUP[ITU‑ISUP] (International Telecommunications Union, “Recommendation Q.763: Signalling System No. 7: ISDN user part formats and codes,” December 1999.) 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 [RFC3966] (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.) 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. This document proposes a method of carrying CPC data in SIP messages.
In some networks (including North America), the Originating Line Information (OLI) parameter defined in ANSI ISUP [ANSI‑ISUP] (American National Standards Institute, “ANSI T1.113-2000, Signaling System No. 7, ISDN User Part,” 2000.) 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 http://www.nanpa.com/number_resource_info/ani_ii_assignments.html. 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. This document proposes a method of carrying OLI data in SIP messages.
Other use cases may exist where is it useful to transfer information about the endpoint even when interworking with the PSTN does not occur. In such cases, the calling party's catagory or originating line identity can be added when the calling party is identified by either a tel URI or a SIP URI.
TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
TOC |
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 [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) syntax is as follows. The 'par' production is defined in RFC 3966 [RFC3966] (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.). 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 = "isup-oli"
- cpc-value = 8*8BIT / "ordinary" / "test" / "operator" / "payphone" / "unknown" / genvalue
- oli-value = 8*8BIT / "hotel" / "prison" / "cellular" / "cellular-roaming" / genvalue
- genvalue = 1*(alphanum / "-" / "." )
The semantics of these CPC and OLI 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.
- hotel: The calling station is in a hotel or motel.
- prison: The calling station is in a prison.
- cellular: The calling station is a radio-telephone operating in its home network.
- cellular-roaming: The calling station is a radio-telephone roaming in another network.
The 8 bit values are assigned by ITU-T/ANSI [ITU‑ISUP] (International Telecommunications Union, “Recommendation Q.763: Signalling System No. 7: ISDN user part formats and codes,” December 1999.)[ANSI‑ISUP] (American National Standards Institute, “ANSI T1.113-2000, Signaling System No. 7, ISDN User Part,” 2000.) and for the OLI, are binary equivalaents of the decimal codes used in the II digits of the ANI sequence for in-band signalling system http://www.nanpa.com/number_resource_info/ani_ii_assignments.html.
The "cpc" and "isup-oli" URI parameters are optional parameters. At the most, one "cpc" and/or one "isup-oli" parameter may be included in a URI of the calling party. In SIP the calling party is generally identified by the identity given in the From header field, or alternatively, in the P-Asserted-Identity header field if this is used. Usage is discussed in the following sections of this document.
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 field [RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.):
P-Asserted-Identity: <tel: +17005554141;cpc=payphone>
The "isup-oli" URI parameter usage is given in the following example, which uses the SIP URI representation of telephone numbers:
From: <sip: +1700554141@example.com;isup-oli=00011101>;tag=1928301774
The "isup-oli" parameter with value 00011101 indicates that the device that the call is initiated from is located within a prison. An "isup-oli" with value "prison" is equally valid.
For the case where a call is originared by a SIP UA where the caller is identified by a SIP URI that does not contain a telephone number, "isup-oli" URI parameter usage is given in the following example, which uses the SIP URI representation of telephone numbers:
P-Asserted-Identity: <sip: alice@example.com;isup-oli=cellular>
The "isup-oli" parameter with value "cellular" indicates that the device that the call is initiated from is a mobile device operating in its home cellular network.
TOC |
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 "isup-oli" URI parameters will be used primarily by gateways that interwork ISUP or ANI II networks with SIP networks. However, scenarios where interworking with the PSTN does not occur are not precluded. 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.
While the CPC and OLI could be conveyed using the ISUP tunneling mechanism described in RFC 3372 [RFC3372] (Vemuri, A. and J. Peterson, “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,” September 2002.), 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 "isup-oli" parameters provides a convenient way for SIP intermediaries to make routing decisions based on the CPC and OLI information without having to implement an ISUP parser. The "cpc" and "isup-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] (Vemuri, A. and J. Peterson, “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,” September 2002.). 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.
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 "isup-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 "isup-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 "isup-oli" URI parameter, then the SIP intermediary silently ignores the URI parameter in accordance with RFC 3261[RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
At most, one instance of the "cpc" parameter and/or one instance of the "isup-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.
TOC |
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 "isup-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 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 "isup-oli" parameters as well. For more information about privacy issues in SIP see RFC 3323[RFC3323] (Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.). The mechanism described in RFC 3325 [RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.) 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] (Watson, M., “Short Term Requirements for Network Asserted Identity,” November 2002.).
Making a call with a falsified CPC or OLI (i.e. "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 "isup-oli" URI parameter. The RECOMMENDED mechanism to protect the entire calling party address along with the "cpc" or "isup-oli" URI parameter is the SIP Identity mechanism [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) . Alternatively, agents within an administrative domain or federation of domains MAY use the mechanism described in RFC 3325[RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.) to place the "cpc" or "isup-oli" URI parameter in a P-Asserted-Identity header field. When such mechanism is used, the "cpc" or "isup-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.
When the end-device, acting as a UAC originating a call, is not trusted, the value of a "cpc" or "isup-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 SIP URI or 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
TOC |
This document extends the registry of URI parameters for the Tel URI and SIP URI as defined RFC 3969[RFC3969] (Camarillo, G., “The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP),” December 2004.) and RFC 5341[RFC5341] (Jennings, C. and V. Gurbani, “The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry,” September 2008.). Two new URI parameters for the Tel URI and SIP URI schemes are defined in this document as follows:
Parameter Name: cpc, isup-oli
Predefined Values: Yes
Reference: This document
TOC |
The original version of this document was written by Jon Peterson as a result of spliiting the appendix from draft-ietf-sip-privacy-04 and subsequently authored by Rohan Mahy.
This document is based on draft-mahy-iptel-cpc-06.
TOC |
TOC |
TOC |
[RFC4474] | Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” RFC 4474, August 2006 (TXT). |
[ANSI-ISUP] | American National Standards Institute, “ANSI T1.113-2000, Signaling System No. 7, ISDN User Part,” 2000. |
[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 (TXT). |
[RFC3372] | Vemuri, A. and J. Peterson, “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,” BCP 63, RFC 3372, September 2002 (TXT). |
[RFC3323] | Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” RFC 3323, November 2002 (TXT). |
[RFC3324] | Watson, M., “Short Term Requirements for Network Asserted Identity,” RFC 3324, November 2002 (TXT). |
TOC |
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 |