draft-ietf-sipcore-status-unwanted-05.txt		draft-ietf-sipcore-status-unwanted-06.txt
	SIPCORE H. Schulzrinne		SIPCORE H. Schulzrinne
	Internet-Draft FCC		Internet-Draft FCC
	Intended status: Standards Track April 19, 2017		Intended status: Standards Track May 8, 2017
	Expires: October 21, 2017		Expires: November 9, 2017
	A SIP Response Code for Unwanted Calls		A SIP Response Code for Unwanted Calls
	draft-ietf-sipcore-status-unwanted-05		draft-ietf-sipcore-status-unwanted-06
	Abstract		Abstract
	This document defines the 607 (Unwanted) SIP response code, allowing		This document defines the 607 (Unwanted) SIP response code, allowing
	called parties to indicate that the call or message was unwanted.		called parties to indicate that the call or message was unwanted.
	SIP entities may use this information to adjust how future calls from		SIP entities may use this information to adjust how future calls from
	this calling party are handled for the called party or more broadly.		this calling party are handled for the called party or more broadly.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 October 21, 2017.		This Internet-Draft will expire on November 9, 2017.
	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 16 ¶		skipping to change at page 2, line 16 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3		2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3		4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 5		5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 5
	5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 5		5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	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]: they might be fraudulent, illegal telemarketing or the		[RFC5039]: they might be fraudulent, illegal 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. Carriers and other service providers may		solicitation by charities. Carriers and other service providers may
	want to help their subscribers avoid receiving such calls, using a		want to help their subscribers avoid receiving such calls, using a
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	3. Motivation		3. Motivation
	None of the existing 4xx, 5xx or 6xx response codes signify that this		None of the existing 4xx, 5xx or 6xx response codes signify that this
	SIP request is unwanted by the called party. For example, 603		SIP request is unwanted by the called party. For example, 603
	(Decline) might be used if the called party is currently at dinner or		(Decline) might be used if the called party is currently at dinner or
	in a meeting, but does not want to indicate any specific reason. As		in a meeting, but does not want to indicate any specific reason. As
	described in Section 21.6.2 [RFC3261], a 603 response may include a		described in Section 21.6.2 [RFC3261], a 603 response may include a
	Retry-After header field to indicate a better time to attempt the		Retry-After header field to indicate a better time to attempt the
	call. Thus, the call is rejected due to the called party's		call. Thus, the call is rejected due to the called party's
	(temporary) disposition. As described in Section 4, the called party		(temporary) status. As described in Section 4, the called party
	invokes the "unwanted call" user interface and 607 (Unwanted)		invokes the "unwanted call" user interface and 607 (Unwanted)
	response indicating that it is instead the caller's identity that is		response indicating that it is instead the caller's identity that is
	causing the call to be rejected. The particular response code number		causing the call to be rejected.
	was chosen to reflect the distaste felt by many upon receiving such
	calls.
	4. Behavior of SIP Entities		4. Behavior of SIP Entities
	The response code 607 MAY be used in a failure response for an		The response code 607 MAY be used in a failure response for an
	INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to		INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to
	indicate that the offered communication is unwanted. The response		indicate that the offered communication is unwanted. The response
	code MAY also be used as the value of the "cause" parameter of a SIP		code MAY also be used as the value of the "cause" parameter of a SIP
	reason-value in a Reason header field [RFC3326], typically when the		reason-value in a Reason header field [RFC3326], typically when the
	called party user agent issues a BYE request terminating an incoming		called party user agent issues a BYE request terminating an incoming
	call or a forking proxy issues a CANCEL request after receiving a 607		call or a forking proxy issues a CANCEL request after receiving a 607
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 7 ¶
	The SIP entities receiving this response code are not obligated to		The SIP entities receiving this response code are not obligated to
	take any particular action beyond those appropriate for 6xx		take any particular action beyond those appropriate for 6xx
	responses. Following the default handling for 6xx responses in		responses. Following the default handling for 6xx responses in
	[RFC5057], the 607 response destroys the transaction. The service		[RFC5057], the 607 response destroys the transaction. The service
	provider delivering calls or messages to the user issuing the		provider delivering calls or messages to the user issuing the
	response MAY take a range of actions, for example, add the calling		response MAY take a range of actions, for example, add the calling
	party to a personal blacklist specific to the called party, use the		party to a personal blacklist specific to the called party, use the
	information as input when computing the likelihood that the calling		information as input when computing the likelihood that the calling
	party is placing unwanted calls ("crowd sourcing"), initiate a		party is placing unwanted calls ("crowd sourcing"), initiate a
	traceback request, or report the calling party identity to consumer		traceback request, or report the calling party identity to consumer
	complaint databases operated by government authorities.		complaint databases. As discussed in Section Section 6, reversing
			the 'unwanted' labeling is beyond the scope of this mechanism, as it
			will likely require a mechanism other than call signaling.
	The user experience is envisioned to be somewhat similar to email		The user experience is envisioned to be somewhat similar to email
	spam buttons where the detailed actions of the email provider remain		spam buttons where the detailed actions of the email provider remain
	opaque to the user.		opaque to the user.
	Call handling for unwanted calls is likely to involve a combination		The mechanism described here is only one of many inputs likely to be
	of heuristics, analytics, and machine learning. These may use call		used by call filtering algorithms operated by service providers,
	characteristics such as call duration and call volumes for a		using data on calls from a particular identifier such as a telephone
	particular caller, as well changes in those metrics over time, as		number to establish handling for future calls from the same
	well as user feedback. Implementations will have to make appropriate		identifier. Call handling for unwanted calls is likely to involve a
	trade-offs between falsely labeling a caller as unwanted and		combination of heuristics, analytics, and machine learning. These
	delivering unwanted calls.		may use call characteristics such as call duration and call volumes
			for a particular caller, including changes in those metrics over
			time, as well as user feedback via non-SIP approaches and the
			mechanism described here. Implementations will have to make
			appropriate trade-offs between falsely labeling a caller as unwanted
			and delivering unwanted calls.
	Systems receiving 607 responses could decide to treat pre-call and		Systems receiving 607 responses could decide to treat pre-call and
	mid-call responses differently, given that the called party has had		mid-call responses differently, given that the called party has had
	access to call content for mid-call rejections.		access to call content for mid-call rejections.
	Depending on the implementation, the response code does not		Depending on the implementation, the response code does not
	necessarily automatically block all calls from that caller identity.		necessarily automatically block all calls from that caller identity.
	The same user interface action might also trigger addition of the		The same user interface action might also trigger addition of the
	caller identity to a local, on-device blacklist or graylist, e.g.,		caller identity to a local, on-device blacklist or graylist, e.g.,
	causing such calls to be flagged or alerted with a different ring		causing such calls to be flagged or alerted with a different ring
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 22 ¶
	blacklist. For example, the list may be shown on a web page or the		blacklist. For example, the list may be shown on a web page or the
	subscriber may be notified by periodic email reminders. Any		subscriber may be notified by periodic email reminders. Any
	additions to a global or carrier-wide list of unwanted callers needs		additions to a global or carrier-wide list of unwanted callers needs
	to consider that any user-initiated mechanism will suffer from an		to consider that any user-initiated mechanism will suffer from an
	unavoidable rate of false positives and tailor their algorithms		unavoidable rate of false positives and tailor their algorithms
	accordingly, e.g., by comparing the fraction of delivered calls for a		accordingly, e.g., by comparing the fraction of delivered calls for a
	particular caller that are flagged as unwanted rather than just the		particular caller that are flagged as unwanted rather than just the
	absolute number, and considering time-weighted filters that give more		absolute number, and considering time-weighted filters that give more
	credence to recent feedback.		credence to recent feedback.
			If an attacker on an unsecured network can spoof SIP responses for a
			significant number of call recipients, it may be able to convince the
			call filtering algorithm to block legitimate calls. Use of TLS to
			protect signaling mitigates against this risk.
	Since caller identities are routinely re-assigned to new subscribers,		Since caller identities are routinely re-assigned to new subscribers,
	algorithms are advised to consider whether the caller identity has		algorithms are advised to consider whether the caller identity has
	been re-assigned to a new subscriber and possibly reset any related		been re-assigned to a new subscriber and possibly reset any related
	rating. (In some countries, there are services that track which		rating. (In some countries, there are services that track which
	telephone numbers have been disconnected before they are re-assigned		telephone numbers have been disconnected before they are re-assigned
	to a new subscriber.)		to a new subscriber.)
	Some call services such as 3PCC [RFC3725] and call transfer [RFC3665]		Some call services such as 3PCC [RFC3725] and call transfer [RFC5359]
	increase the complexity of identifying who (if anyone) should be		increase the complexity of identifying who (if anyone) should be
	impacted by the receipt of 607 within BYE. Such services might cause		impacted by the receipt of 607 within BYE. Such services might cause
	the wrong party to be flagged or prevent flagging the desired party.		the wrong party to be flagged or prevent flagging the desired party.
	For both individually-authenticated and unauthenticated calls,		For both individually-authenticated and unauthenticated calls,
	recipients of response code 607 may want to distinguish responses		recipients of response code 607 may want to distinguish responses
	sent before and after the call has been answered, ascertaining		sent before and after the call has been answered, ascertaining
	whether either response timing suffers from a lower false-positive		whether either response timing suffers from a lower false-positive
	rate.		rate.
	7. Acknowledgements		7. Acknowledgements
	Tolga Asveren, Ben Campbell, Peter Dawes, Martin Dolly, Keith Drage,		Tolga Asveren, Ben Campbell, Peter Dawes, Spencer Dawkins, Martin
	Vijay Gurbani, Christer Holmberg, Olle Johansson, Paul Kyzivat, Jean		Dolly, Keith Drage, Vijay Gurbani, Christer Holmberg, Olle Johansson,
	Mahoney, Marianne Mohali, Adam Montville, Al Morton, Denis Ovsienko,		Paul Kyzivat, Jean Mahoney, Marianne Mohali, Adam Montville, Al
	Brian Rosen, Brett Tate, Chris Wendt, Dale Worley and Peter Yee (Gen-		Morton, Denis Ovsienko, Brian Rosen, Brett Tate, Chris Wendt, Dale
	ART reviewer) provided helpful comments.		Worley and Peter Yee (Gen-ART reviewer) provided helpful comments.
	8. References		8. References
	8.1. Normative References		8.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 7, line 35 ¶		skipping to change at page 7, line 44 ¶
	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.
	[RFC3323] Peterson, J., "A Privacy Mechanism for the Session		[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
	Initiation Protocol (SIP)", RFC 3323,		Initiation Protocol (SIP)", RFC 3323,
	DOI 10.17487/RFC3323, November 2002,		DOI 10.17487/RFC3323, November 2002,
	<http://www.rfc-editor.org/info/rfc3323>.		<http://www.rfc-editor.org/info/rfc3323>.
	[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
	K. Summers, "Session Initiation Protocol (SIP) Basic Call
	Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665,
	December 2003, <http://www.rfc-editor.org/info/rfc3665>.
	[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.		[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
	Camarillo, "Best Current Practices for Third Party Call		Camarillo, "Best Current Practices for Third Party Call
	Control (3pcc) in the Session Initiation Protocol (SIP)",		Control (3pcc) in the Session Initiation Protocol (SIP)",
	BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,		BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
	<http://www.rfc-editor.org/info/rfc3725>.		<http://www.rfc-editor.org/info/rfc3725>.
	[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",		[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
	RFC 3966, DOI 10.17487/RFC3966, December 2004,		RFC 3966, DOI 10.17487/RFC3966, December 2004,
	<http://www.rfc-editor.org/info/rfc3966>.		<http://www.rfc-editor.org/info/rfc3966>.
	[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, <http://www.rfc-editor.org/info/rfc5039>.
	[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session		[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
	Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057,		Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057,
	November 2007, <http://www.rfc-editor.org/info/rfc5057>.		November 2007, <http://www.rfc-editor.org/info/rfc5057>.
			[RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan,
			S., and K. Summers, "Session Initiation Protocol Service
			Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359,
			October 2008, <http://www.rfc-editor.org/info/rfc5359>.
	Author's Address		Author's Address
	Henning Schulzrinne		Henning Schulzrinne
	FCC		FCC
	445 12th Street SW		445 12th Street SW
	Washington, DC 20554		Washington, DC 20554
	US		US
	Email: henning.schulzrinne@fcc.gov		Email: henning.schulzrinne@fcc.gov
End of changes. 13 change blocks.
	29 lines changed or deleted		39 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/