[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

DISPATCH Working Group                                          M. Patel
Internet-Draft                          InterDigital Communications, LLC
Intended status: Standards Track                               R. Jesske
Expires: December 10, 2010                              Deutsche Telekom
                                                                M. Dolly
                                                            June 8, 2010

Uniform Resource Identifier (URI) Parameters for indicating the Calling
           Party's Category and Originating Line Information


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

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 10, 2010.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Patel, et al.           Expires December 10, 2010               [Page 1]

Internet-Draft         CPC and OLI URI Parameters              June 2010

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Parameter Definitions . . . . . . . . . . . . . . . . . . . . . 3
   4.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Patel, et al.           Expires December 10, 2010               [Page 2]

Internet-Draft         CPC and OLI URI Parameters              June 2010

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 [RFC3966] 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] 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
   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.

   The primary use case for these parameters is for interworking CPC and
   OLI information between SIP and ISUP.  Other use cases may exist
   where it is useful to transfer information about the endpoint even
   when interworking with the PSTN does not occur.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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
   [RFC5234] syntax is as follows.  The 'par' production is defined in
   RFC 3966 [RFC3966].  The "/=" syntax indicates an extension of the
   production on the left-hand side:

Patel, et al.           Expires December 10, 2010               [Page 3]

Internet-Draft         CPC and OLI URI Parameters              June 2010

      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" / "mobile-hplmn" / "mobile-vplmn" / genvalue
      oli-value = 2*(DIGIT)
      genvalue = 1*(alphanum / "-" / "." )

   The semantics of these CPC and OLI values are described below:
      ordinary: The caller has been identified, and has no special
      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.
      mobile-hplmn: The call was generated by a mobile device in its
      home PLMN.
      mobile-vplmn: The call was generated by a mobile device in a
      vistited PLMN.

   The decimal coded values for "oli" are assigned and administered
   NANPA and are the decimal codes used in the ANI II digits of the ANI
   sequence for in-band signalling system

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

   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;oli=29@example.com>;tag=1928301774

Patel, et al.           Expires December 10, 2010               [Page 4]

Internet-Draft         CPC and OLI URI Parameters              June 2010

   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
   tel URI or SIP 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.  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], 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 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.

   If the "cpc" URI parameter is not present, consumers of the CPC

Patel, et al.           Expires December 10, 2010               [Page 5]

Internet-Draft         CPC and OLI URI Parameters              June 2010

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

   - 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 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 "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
   of the CPC or OLI within a trusted administrative domain or
   federation of domains as described in RFC 3324[RFC3324].

Patel, et al.           Expires December 10, 2010               [Page 6]

Internet-Draft         CPC and OLI URI Parameters              June 2010

   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 (i.e. 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 mechanism [RFC4474]
   .  Alternatively, agents within an administrative domain or
   federation of domains MAY use the mechanism described in RFC
   3325[RFC3325] to 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 information (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 "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

   Otherwise, this mechanism adds no new security considerations to
   those discussed in RFC 3261[RFC3261].

6.  IANA Considerations

   This document extends the registry of URI parameters for the Tel URI
   as defined RFC 3969[RFC3969].  Two new URI parameters for the Tel URI
   scheme are defined in this document as follows:

   Parameter Name: cpc, oli

   Predefined Values: Yes

   Reference: This document

Patel, et al.           Expires December 10, 2010               [Page 7]

Internet-Draft         CPC and OLI URI Parameters              June 2010

7.  Acknowledgements

   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.

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.

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

              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

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

              American National Standards Institute, "ANSI T1.113-2000,
              Signaling System No. 7, ISDN User Part", 2000,

Patel, et al.           Expires December 10, 2010               [Page 8]

Internet-Draft         CPC and OLI URI Parameters              June 2010

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

Authors' Addresses

   Milan Patel
   InterDigital Communications, LLC

   Email: Milan.Patel@interdigital.com

   Roland Jesske
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt, 64307, Germany

   Email: r.jesske@telekom.de

   Martin Dolly
   200 Laurel Ave
   Middletown, NJ,, US

   Email: mdolly@att.com

Patel, et al.           Expires December 10, 2010               [Page 9]

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