draft-ietf-sipcore-callinfo-spam-00.txt   draft-ietf-sipcore-callinfo-spam-01.txt 
SIPCORE H. Schulzrinne SIPCORE H. Schulzrinne
Internet-Draft FCC Internet-Draft FCC
Intended status: Standards Track March 7, 2017 Intended status: Standards Track July 17, 2017
Expires: September 8, 2017 Expires: January 18, 2018
SIP Call-Info Parameters for Labeling Calls SIP Call-Info Parameters for Labeling Calls
draft-ietf-sipcore-callinfo-spam-00 draft-ietf-sipcore-callinfo-spam-01
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, spam probability and references to
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http://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 September 8, 2017. This Internet-Draft will expire on January 18, 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 (http://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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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
2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. REGISTER Response . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . 6
8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 6 7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 7
8.2. SIP Global Feature-Capability Indicator . . . . . . . . . 7 8.2. SIP Global Feature-Capability Indicator . . . . . . . . . 7
8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 7 8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
This document describes a new set of optional parameters and usage This document describes a new set of optional parameters and usage
for the SIP [RFC3261] Call-Info header field, purpose "info", for for the SIP [RFC3261] Call-Info header field, purpose "info", for
labeling the nature of the call. The header field may be inserted by labeling the nature of the call. The header field may be inserted by
the call originator, an intermediate proxy or B2BUA or the the call originator, an intermediate proxy or B2BUA or the
terminating carrier, based on assertions by the caller, number- terminating carrier, based on assertions by the caller, number-
indexed databases, call analytics or other sources of information. indexed databases, call analytics or other sources of information.
The SIP provider serving the called party MUST remove any parameters The SIP provider serving the called party MUST remove any parameters
enumerated in this specification that it does not trust. The Call- enumerated in this specification that it does not trust. The Call-
Info header field MAY be signed using a future "ppt" extension to Info header field MAY be signed using a future "ppt" extension to
[I-D.ietf-stir-rfc4474bis]. To ensure that an untrusted originating [I-D.ietf-stir-rfc4474bis].
caller does not mislead the called party, a new feature tag,
sip.call-info.spam, indicates whether the terminating carrier will
remove untrusted information.
SIP entities MUST add a new Call-Info "info" header field instance, To ensure that an untrusted originating caller does not mislead the
rather than add parameters to an existing one. Thus, there MAY be called party, a new feature capability indicator [RFC6809], sip.call-
several Call-Info header fields of purpose "info" in one request. info.spam, in the REGISTER response signals whether the terminating
carrier supports the feature described in this document and thus will
remove any untrusted 'spam', 'type', 'reason' and 'source' Call-Info
header field information parameters. It is possible for the
terminating carrier to support this feature by simply removing all
parameters defined in the document, without inserting any of its own
information, although this is likely to be unusual. A user agent
MUST ignore any of the parameters defined in this document unless the
feature capability indicator is present in the response to the
REGISTER request. An example of the REGISTER response is shown in
Section 6.1.
SIP proxies or B2BUAs MUST add a new Call-Info "info" header field
instance, rather than add parameters to an existing one. Thus, there
MAY be several Call-Info header fields of purpose "info" in one
request.
As defined in [RFC3261], the Call-Info header field contains a URI As defined in [RFC3261], the Call-Info header field contains a URI
that can provide additional information about the caller or call. that can provide additional information about the caller or call.
For example, many call filtering services provide a web page with For example, many call filtering services provide a web page with
crowd-sourced information about the calling number. If the entity crowd-sourced information about the calling number. If the entity
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.) 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 spam The spam parameter carries an estimated probability that the
call will not be wanted by the called party, expressed as a whole- call will not be wanted by the called party, expressed as a whole-
number percentage between 0 and 100, inclusive, with larger number percentage between 0 and 100, inclusive, with larger
numbers indicating higher probability. The computation of the numbers indicating higher probability. The computation of the
skipping to change at page 6, line 16 skipping to change at page 6, line 27
party. party.
telemarketing Calls placed in order to induce the purchase of a telemarketing Calls placed in order to induce the purchase of a
product or service to the called party. product or service to the called party.
trusted The call is being placed by a trusted entity and falls trusted The call is being placed by a trusted entity and falls
outside the other categories listed. This may include call backs, outside the other categories listed. This may include call backs,
e.g., from a conferencing service, or messages from e.g., from a conferencing service, or messages from
telecommunication carriers and utilities. telecommunication carriers and utilities.
6. Example 6. Examples
"Call-Info: <http://wwww.example.com/5974c8d942f120351143> 6.1. REGISTER Response
;source=carrier.example.com ;purpose=info ;spam=85 ;type=fraud
;reason="FTC list"" The example below shows a partial REGISTER response showing that the
registrar and proxy will remove any untrusted Call-Info header
elements.
SIP/2.0 200 OK
...
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>;tag=34095828jh
...
Feature-Caps: *sip.call-info.spam
6.2. INVITE Request
Call-Info: <http://wwww.example.com/
5974c8d942f120351143> ;source=carrier.example.com
;purpose=info ;spam=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-spam] / [ci-type] / [ci-source] / [ci-reason]
ci-spam = "spam" EQUAL 1*3DIGIT ci-spam = "spam" 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)
skipping to change at page 7, line 36 skipping to change at page 8, line 21
Additional values are allocated by expert review [RFC5226]; only the Additional values are allocated by expert review [RFC5226]; only the
token value, using the ABNF iana-token, and a brief description, token value, using the ABNF iana-token, and a brief description,
typically no more than a few sentences, is required. The ABNF for typically no more than a few sentences, is required. The ABNF for
iana-token is defined in [RFC3261]. A specification is not required. iana-token is defined in [RFC3261]. A specification is not required.
9. Security Considerations 9. Security Considerations
The security considerations in [RFC3261] (Section 20.9) apply. A The security considerations in [RFC3261] (Section 20.9) apply. A
user agent MUST ignore the parameters defined in this document unless user agent MUST ignore the parameters defined in this document unless
the SIP REGISTER response contained the sip.call-info.spam feature the SIP REGISTER response contained the sip.call-info.spam feature
capability. SIP entities MUST remove any parameters defined here capability. B2BUAs or proxies that maintain user registrations MUST
that were provided by untrusted third parties. remove any parameters defined in this document that were provided by
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 and Paul Kyzivat the initial list of call types. Keith Drage, Christer Holmberg and
provided helpful comments on the document. 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>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 31 skipping to change at page 9, line 12
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://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>. <http://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", BCP 26, 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>. <http://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>. <http://www.rfc-editor.org/info/rfc6809>.
11.2. Informative References 11.2. Informative References
 End of changes. 15 change blocks. 
30 lines changed or deleted 60 lines changed or added

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