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/