draft-ietf-sipcore-callinfo-spam-02.txt   draft-ietf-sipcore-callinfo-spam-03.txt 
SIPCORE H. Schulzrinne SIPCORE H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Standards Track October 30, 2017 Intended status: Standards Track June 7, 2018
Expires: May 3, 2018 Expires: December 9, 2018
SIP Call-Info Parameters for Labeling Calls SIP Call-Info Parameters for Labeling Calls
draft-ietf-sipcore-callinfo-spam-02 draft-ietf-sipcore-callinfo-spam-03
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, confidence and references to additional label calls as to their type, confidence and references to additional
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 https://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 May 3, 2018. This Internet-Draft will expire on December 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. REGISTER Response . . . . . . . . . . . . . . . . . . . . 6 6.1. REGISTER Response . . . . . . . . . . . . . . . . . . . . 6
6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . 6 6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . 7
7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 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 . . . . . . . . . . . . . . 8 8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 44 skipping to change at page 3, line 44
header field information parameters. It is possible for the header field information parameters. It is possible for the
terminating carrier to support this feature by simply removing all terminating carrier to support this feature by simply removing all
parameters defined in the document, without inserting any of its own parameters defined in the document, without inserting any of its own
information, although this is likely to be unusual. A user agent information, although this is likely to be unusual. A user agent
MUST ignore any of the parameters defined in this document unless the MUST ignore any of the parameters defined in this document unless the
feature capability indicator is present in the response to the feature capability indicator is present in the response to the
REGISTER request. An example of the REGISTER response is shown in REGISTER request. An example of the REGISTER response is shown in
Section 6.1. Section 6.1.
SIP proxies or B2BUAs MUST add a new Call-Info "info" header field SIP proxies or B2BUAs MUST add a new Call-Info "info" header field
instance, rather than add parameters to an existing one. Thus, there value, rather than add parameters to an existing value. Thus, there
MAY be several Call-Info header fields of purpose "info" in one MAY be several Call-Info header instances of purpose "info" in one
request. request, either as a single header with a comma-separated list of
header values or separate headers, or some combination.
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.) 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.
confidence The 'confidence' parameter carries an estimated confidence The 'confidence' parameter carries an estimated
probability that the call is of the nature indicated in the 'type' probability that the call is of the nature indicated in the 'type'
parameter, expressed as a whole-number percentage between 0 and parameter, expressed as a whole-number percentage between 0 and
skipping to change at page 6, line 40 skipping to change at page 6, line 46
The example below shows a partial REGISTER response showing that the The example below shows a partial REGISTER response showing that the
registrar and proxy will remove any untrusted Call-Info header registrar and proxy will remove any untrusted Call-Info header
elements. elements.
SIP/2.0 200 OK SIP/2.0 200 OK
... ...
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 ;confidence=85 ;type=fraud ;reason="FTC list" ;purpose=info ;confidence=85 ;type=fraud ;reason="FTC list"
7. ABNF 7. ABNF
label-info-params = [ci-confidence] / [ci-type] / [ci-source] / [ci-reason] label-info-params = [ci-confidence] / [ci-type] / [ci-source] / [ci-reason]
skipping to change at page 8, line 33 skipping to change at page 8, line 35
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. Tolga Asveren, Keith Drage, Christer the initial list of call types. Tolga Asveren, Keith Drage, Christer
Holmberg and Paul Kyzivat provided helpful comments on the document. Holmberg, Paul Kyzivat and Dale Worley 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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 10 change blocks. 
13 lines changed or deleted 15 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/