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

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/