--- 1/draft-ietf-sipcore-callinfo-spam-01.txt 2017-10-30 15:14:05.669785102 -0700 +++ 2/draft-ietf-sipcore-callinfo-spam-02.txt 2017-10-30 15:14:05.693785677 -0700 @@ -1,55 +1,55 @@ SIPCORE H. Schulzrinne -Internet-Draft FCC -Intended status: Standards Track July 17, 2017 -Expires: January 18, 2018 +Internet-Draft Columbia University +Intended status: Standards Track October 30, 2017 +Expires: May 3, 2018 SIP Call-Info Parameters for Labeling Calls - draft-ietf-sipcore-callinfo-spam-01 + draft-ietf-sipcore-callinfo-spam-02 Abstract Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to - label calls as to their type, spam probability and references to - additional information. + label calls as to their type, confidence and references to additional + information. Status of This Memo This Internet-Draft is submitted 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/. + Drafts is at https://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 January 18, 2018. + This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 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 + (https://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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 @@ -77,33 +77,33 @@ In many countries, an increasing number of calls are unwanted [RFC5039], as they might be fraudulent, telemarketing or the receiving party does not want to be disturbed by, say, surveys or solicitation by charities. Currently, called parties have to rely exclusively on the caller's number or, if provided, caller name, but unwanted callers may not provide their true name or use a name that misleads, e.g., "Cardholder Services". On the other hand, many calls from unknown numbers may be important to the called party, whether this is an emergency alert from their emergency management office or a reminder about a doctor's appointment. Since many subscribers now - reject all calls from unknown numbers, such calls may also be + reject all calls from unknown numbers, such calls may also inadvertently be left unanswered. Users may also install smartphone apps that can benefit from additional information in making decisions - as to whether to ring, reject or redirect a call. + as to whether to ring, reject or redirect a call to voicemail. To allow called parties to make more informed decisions on how to handle incoming calls from unknown callers, we describe a new set of parameters for the SIP [RFC3261] Call-Info header field for labeling the nature of the call. - Providers may also find the SIP Priority header (Section 20.26) field - useful in helping called parties decide how to respond to an incoming - call. + Providers may also find the SIP Priority header ([RFC3261], + Section 20.26) field useful in helping called parties decide how to + respond to an incoming call. 2. Normative Language 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 BCP 14, RFC 2119 [RFC2119]. 3. Overview of Operation @@ -144,49 +144,49 @@ inserting the header field does not have information it wants to link to, it MUST use an empty data URL [RFC2397] as a placeholder, as in "data:". (The Call-Info header field syntax makes the URI itself mandatory.) An example is shown in Section 6.2. 4. Parameters All of the parameters listed below are optional and may appear in any combination and order. Their ABNF is defined in Section 7. - spam The spam parameter carries an estimated probability that the - call will not be wanted by the called party, expressed as a whole- - number percentage between 0 and 100, inclusive, with larger - numbers indicating higher probability. The computation of the - estimate is beyond the scope of this specification. If not - specified, the entity inserting the Call-Info information is - making no claims about the likelihood of being unwanted. Note - that call types other than "spam" may have a non-zero spam rating, - as these calls may also be unwanted by some fraction of the - recipients, even if they are not illegal in a particular - jurisdiction. + confidence The 'confidence' parameter carries an estimated + probability that the call is of the nature indicated in the 'type' + parameter, expressed as a whole-number percentage between 0 and + 100, inclusive, with larger numbers indicating higher probability. + The computation of the estimate is beyond the scope of this + specification. If a 'type' is not specified, this parameter + estimates the likelihood that the call is unwanted spam by the + called party. If the confidence level is not specified, the + sender considers the information reliable enough to act on, + according to its local decision thresholds. type The type parameter indicates the type of the call or caller. It is drawn from an extensible set of values, with the initial set listed below. Gateways to analog phone systems MAY include the label in caller name (CNAM) information. Automated call classification systems MAY use this information as one factor in deciding how to handle the call. Calls SHOULD be labeled with types that may make it more likely that the caller will answer (e.g., for alert and health-related calls) if the entity inserting the information is confident that the calling party number is valid, e.g., because the request has been signed [I-D.ietf-stir-rfc4474bis]. reason The reason parameter provides free-text information, as a - string, about the source of the type or spam parameter and is - meant to be used for debugging, rather than for display to the end - user. For example, it may indicate the name of an external - information source, such as a list of known emergency alerters. + string, about the source of the 'type' or 'confidence' parameter + and is meant to be used for debugging, rather than for display to + the end user. For example, it may indicate the name of an + external information source, such as a list of known emergency + alerters. source The source parameter identifies the entity, by host name, domain or IP address, that inserted the parameters above. It uses the "host" ABNF syntax. 5. Call Types The following initial set of types are defined. The call types are generally based on the caller's telephone number or possibly an assertion by a trusted caller, as the content cannot be not known. @@ -274,48 +274,48 @@ ... From: Bob ;tag=a73kszlfl To: Bob ;tag=34095828jh ... Feature-Caps: *sip.call-info.spam 6.2. INVITE Request Call-Info: ;source=carrier.example.com - ;purpose=info ;spam=85 ;type=fraud ;reason="FTC list" + ;purpose=info ;confidence=85 ;type=fraud ;reason="FTC list" 7. ABNF - label-info-params = [ci-spam] / [ci-type] / [ci-source] / [ci-reason] - ci-spam = "spam" EQUAL 1*3DIGIT + label-info-params = [ci-confidence] / [ci-type] / [ci-source] / [ci-reason] + ci-confidence = "confidence" EQUAL 1*3DIGIT ci-type = "type" EQUAL ("business" / "debt-collection" / "emergency-alert" / "fraud" / "government" / "health" / "informational" / "not-for-profit" / "personal" / "political" / "public-service" / "prison" / "spam" / "spoofed" / "survey" / "telemarketing" / "trusted" / iana-token) ci-source = "source" EQUAL host ci-reason = "reason" EQUAL quoted-string 8. IANA Considerations 8.1. SIP Call-Info Header Field Parameters - This document defines the 'spam', 'type', 'reason' and 'source' + This document defines the 'confidence', 'type', 'reason' and 'source' parameters in the Call-Info header in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. +--------------+----------------+-------------------+------------+ | Header Field | Parameter Name | Predefined Values | Reference | +--------------+----------------+-------------------+------------+ | Call-Info | reason | No | [this RFC] | | Call-Info | source | No | [this RFC] | - | Call-Info | spam | No | [this RFC] | + | Call-Info | confidence | No | [this RFC] | | Call-Info | type | Yes | [this RFC] | +--------------+----------------+-------------------+------------+ 8.2. SIP Global Feature-Capability Indicator This document defines the feature capability sip.call-info.spam in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809]. Name sip.call-info.spam @@ -347,70 +347,70 @@ remove any parameters defined in this document that were provided by untrusted third parties. The protection offered against rogue SIP entities by the feature capability relies on protecting the REGISTER response against man-in- the-middle attacks that maliciously add the capability indicator. 10. Acknowledgements Jim Calme and other members of the Robocall Strikeforce helped draft - the initial list of call types. Keith Drage, Christer Holmberg and - Paul Kyzivat provided helpful comments on the document. + the initial list of call types. Tolga Asveren, Keith Drage, Christer + Holmberg and Paul Kyzivat provided helpful comments on the document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998, - . + . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, - . + . [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, - . + . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, - . + . [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, November 2012, - . + . 11.2. Informative References [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 (work in progress), February 2017. [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, - January 2008, . + January 2008, . Author's Address Henning Schulzrinne - FCC - 445 12th Street SW - Washington, DC 20554 + Columbia University + 450 Computer Science Bldg. + New York, NY 10027 US - Email: henning.schulzrinne@fcc.gov + Email: hgs@cs.columbia.edu