draft-ietf-sipcore-callinfo-spam-03.txt		draft-ietf-sipcore-callinfo-spam-04.txt
	SIPCORE H. Schulzrinne		SIPCORE H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track June 7, 2018		Intended status: Standards Track August 29, 2019
	Expires: December 9, 2018		Expires: March 1, 2020
	SIP Call-Info Parameters for Labeling Calls		SIP Call-Info Parameters for Labeling Calls
	draft-ietf-sipcore-callinfo-spam-03		draft-ietf-sipcore-callinfo-spam-04
	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 December 9, 2018.		This Internet-Draft will expire on March 1, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 4
	4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. REGISTER Response . . . . . . . . . . . . . . . . . . . . 6		6.1. REGISTER Response . . . . . . . . . . . . . . . . . . . . 7
	6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . 7		6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . 7
	7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 7		8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 8
	8.2. SIP Global Feature-Capability Indicator . . . . . . . . . 7		8.2. SIP Global Feature-Capability Indicator . . . . . . . . . 8
	8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 8		8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 8
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	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 may use a name
	misleads, e.g., "Cardholder Services". On the other hand, many calls		that misleads, e.g., "Cardholder Services". On the other hand, many
	from unknown numbers may be important to the called party, whether		calls from unknown numbers may be important to the called party,
	this is an emergency alert from their emergency management office or		whether this is an emergency alert from their emergency management
	a reminder about a doctor's appointment. Since many subscribers now		office or a reminder about a doctor's appointment. Since many
	reject all calls from unknown numbers, such calls may also		subscribers now reject all calls from unknown numbers, such calls may
	inadvertently be left unanswered. Users may also install smartphone		also inadvertently be left unanswered. Users may also install
	apps that can benefit from additional information in making decisions		smartphone apps that can benefit from additional information in
	as to whether to ring, reject or redirect a call to voicemail.		making decisions 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.
			This specification assumes that the user agent can trust its SIP
			provider to correctly label the nature of calls. This may not always
			be the case and not all SIP service providers will label calls, so
			users may need to draw on other, third-party, sources of call
			information beyond the scope of this specification or may decide to
			disregard the call labeling offered by their service provider.
			(Service providers may, for example, be reluctant to label calls as
			spam.) However, the SIP registrar already occupies a position of
			trust by necessity; also, the user agent is typically a customer of
			the operator of the registrar or within the same organization, e.g.,
			if the registrar is part of a PBX. Thus, the entity inserting the
			Call-Info header field and the UAS relying on it SHOULD be part of
			the same trust domain [RFC3324]. Conversely, the entity signing the
			caller information [RFC8224] is likely either to be the caller itself
			or the originating service provider, neither of which is likely to
			label the caller as a category unlikely to be answered by the called
			party.
			The service provider inserting the Call-Info header field may draw on
			a wide variety of sources. For example, service providers offering
			alerting or notification services (e.g., for packages or health
			alerts) may register their phone numbers, after suitable vetting, in
			shared databases. Government agencies could publish electronic
			directories of official telephone numbers, drawing on the historical
			precedent of the "blue pages" found in printed phone directories.
			Government regulators for financial services, health care providers
			and charitable organizations could provide sources of telephone
			numbers and service types belonging to such organizations. Finally,
			crowd-sourcing might also be used to populate databases of call
			types. In the United States, industry organizations have proposed
			variations of such caller databases to prevent accidental blocking of
			calls based on their statistics such as frequency or duration alone.
	Providers may also find the SIP Priority header ([RFC3261],		Providers may also find the SIP Priority header ([RFC3261],
	Section 20.26) field useful in helping called parties decide how to		Section 20.26) field useful in helping called parties decide how to
	respond to an incoming 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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in BCP 14, RFC 2119		"OPTIONAL" in this document are to be interpreted as described in BCP
	[RFC2119].		14 [RFC2119][RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. Overview of Operation		3. Overview of Operation
	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, with a purpose "info",
	labeling the nature of the call. The header field may be inserted by		for labeling the nature of the call. The header field may be
	the call originator, an intermediate proxy or B2BUA or the		inserted by the call originator, an intermediate proxy or B2BUA or
	terminating carrier, based on assertions by the caller, number-		the 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.
	Info header field MAY be signed using a future "ppt" extension to
	[I-D.ietf-stir-rfc4474bis].
	To ensure that an untrusted originating caller does not mislead the		To ensure that an untrusted originating caller does not mislead the
	called party, a new feature capability indicator [RFC6809], sip.call-		called party, a new feature capability indicator [RFC6809], sip.call-
	info.spam, in the REGISTER response signals whether the terminating		info.spam, in the REGISTER response signals whether the terminating
	carrier supports the feature described in this document and thus will		carrier supports the feature described in this document and thus will
	remove any untrusted 'spam', 'type', 'reason' and 'source' Call-Info		remove any untrusted 'confidence', 'origin', 'source' and 'type'
	header field information parameters. It is possible for the		Call-Info header field information parameters. It is possible for
	terminating carrier to support this feature by simply removing all		the terminating carrier to support this feature by simply removing
	parameters defined in the document, without inserting any of its own		all parameters defined in the document, without inserting any of its
	information, although this is likely to be unusual. A user agent		own 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
	value, rather than add parameters to an existing value. Thus, there		value, rather than add parameters to an existing value. Thus, one
	MAY be several Call-Info header instances of purpose "info" in one		SIP request MAY contain several Call-Info header instances of purpose
	request, either as a single header with a comma-separated list of		"info", either as a single header with a comma-separated list of
	header values or separate headers, or some combination.		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. All
			except the 'type' parameter are optional.
	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
	100, inclusive, with larger numbers indicating higher probability.		100, inclusive, with larger numbers indicating higher probability.
	The computation of the estimate is beyond the scope of this		The computation of the estimate is beyond the scope of this
	specification. If a 'type' is not specified, this parameter		specification. If a 'type' is not specified, this parameter
	estimates the likelihood that the call is unwanted spam by the		estimates the likelihood that the call is unwanted spam by the
	called party. If the confidence level is not specified, the		called party. If the confidence level is not specified, the
	sender considers the information reliable enough to act on,		sender considers the information reliable enough to act on,
	according to its local decision thresholds.		according to its local decision thresholds.
			origin The origin parameter provides free-text information, as a
			quoted-text (UTF8-encoded) string, about the source of the 'type'
			or 'confidence' parameter and is meant to be used for debugging,
			rather than for display to the end user. For example, it may
			indicate the name of an external information source, such as a
			list of known emergency alerters or a government agency.
			source The source parameter identifies the entity, by host name,
			domain or IP address, that inserted the 'confidence', 'origin' and
			'type' parameters. It uses the "host" ABNF syntax.
	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 delivered to user
	classification systems MAY use this information as one factor in		equipement. Automated call classification systems MAY use this
	deciding how to handle the call. Calls SHOULD be labeled with		information as one factor in deciding how to handle the call.
	types that may make it more likely that the caller will answer		Calls SHOULD be labeled with types that may make it more likely
	(e.g., for alert and health-related calls) if the entity inserting		that the caller will answer (e.g., for alert and health-related
	the information is confident that the calling party number is		calls) if the entity inserting the information is confident that
	valid, e.g., because the request has been signed		the calling party number is valid, e.g., because the request has
	[I-D.ietf-stir-rfc4474bis].		been signed [RFC8224].
	reason The reason parameter provides free-text information, as a
	string, about the source of the 'type' or 'confidence' parameter
	and is meant to be used for debugging, rather than for display to
	the end user. For example, it may indicate the name of an
	external information source, such as a list of known emergency
	alerters.
	source The source parameter identifies the entity, by host name,
	domain or IP address, that inserted the parameters above. It uses
	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.
	Each call is tagged with at most one type label, i.e., the labels are		Each call is tagged with at most one type label, i.e., the labels are
	meant to be mutually exclusive. The definitions are meant to be		meant to be mutually exclusive. The definitions are meant to be
	informal and reflect the common understanding of subscribers who are		informal and reflect the common understanding of subscribers who are
	not lawyers. By their very nature, this classification may sometimes		not lawyers. By their very nature, this classification may sometimes
	skipping to change at page 5, line 49 ¶		skipping to change at page 6, line 34 ¶
	government A call placed by a government entity, if no more specific		government A call placed by a government entity, if no more specific
	label such as "health" or "debt-collection" is known or applies.		label such as "health" or "debt-collection" is known or applies.
	health Informational calls by health plans, health care		health Informational calls by health plans, health care
	clearinghouses or health care provider, where health care means		clearinghouses or health care provider, where health care means
	care, services, or supplies related to the health of an		care, services, or supplies related to the health of an
	individual.		individual.
	informational Calls intended to convey information to the called		informational Calls intended to convey information to the called
	party about a transaction such as package delivery, appointment		party about a transaction such as package delivery, appointment
	reminder, order confirmation. This call type is only used if the		reminder, or order confirmation.
	calling party believes to have an established business
	relationship with the called party.
	not-for-profit A call placed by a not-for-profit organization,		not-for-profit A call placed by a not-for-profit organization,
	including for soliciting donations or providing information.		including for soliciting donations or providing information.
	personal A non-business, person-to-person, call, e.g., from a		personal A non-business, person-to-person, call, e.g., from a
	residential line or personal mobile number.		residential line or personal mobile number.
	political Calls related to elections or other political purposes.		political Calls related to elections or other political purposes.
	public-service Calls that provide the recipient information		public-service Calls that provide the recipient information
	regarding public services, e.g., school closings.		regarding public services, e.g., school closings.
	prison Calls from jails, prisons and other correctional facilities.		prison Calls from jails, prisons and other correctional facilities.
	spam A call that is likely unwanted, if not otherwise classified.		spam A call that is likely unwanted, if not otherwise classified.
	spoofed The calling number for this call has been spoofed.		spoofed The calling number for this call has been spoofed. (For
			example, the call has failed STIR validation [RFC8224] within the
			SIP service provider network or the telephone number is not a
			valid number or is known not to have been assigned.)
	survey A call that solicits the opinions or data of the called		survey A call that solicits the opinions or data of the called
	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
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 35 ¶
	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/		INVITE sip:alice@example.com SIP/2.0
	5974c8d942f120351143> ;source=carrier.example.com		...
	;purpose=info ;confidence=85 ;type=fraud ;reason="FTC list"		Call-Info: <http://wwww.example.com/5974c8d942f120351143>
			;source=carrier.example.com
			;purpose=info ;confidence=85 ;type=fraud
			;origin="FTC fraud list"
	7. ABNF		7. ABNF
			label-info-params = [ci-confidence] / [ci-source] / [ci-origin] / ci-type
	label-info-params = [ci-confidence] / [ci-type] / [ci-source] / [ci-reason]
	ci-confidence = "confidence" EQUAL 1*3DIGIT		ci-confidence = "confidence" EQUAL 1*3DIGIT
			ci-origin = "origin" EQUAL quoted-string
			ci-source = "source" EQUAL host
	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-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 'confidence', 'type', 'reason' and 'source'		This document defines the 'confidence', 'origin', 'source' and 'type'
	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] |		| [this RFC] | Call-Info | confidence | No |
			| Call-Info | origin | No | [this RFC] |
	| Call-Info | source | No | [this RFC] |		| Call-Info | source | 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 27 ¶		skipping to change at page 9, line 19 ¶
	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. B2BUAs or proxies that maintain user registrations MUST		capability. B2BUAs or proxies that maintain user registrations MUST
	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 UAS SHOULD only consider Call-Info header field information that
			originates from a registrar that is part of the same trust domain
			[RFC3324].
	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.
			Thus, a UAS SHOULD NOT trust the information in the "Call-Info"
			header field unless the SIP session between the entity inserting the
			header field and the UAS is protected by TLS [RFC8446].
			Labeling calls is likely only useful if the caller identity can be
			trusted, e.g., by having the call signaling requests signed
			[RFC8224], as otherwise spoofed calls would likely be mislabeled and
			thus increase the likelihood that the called party is mislead,
			answers unwanted calls or is defrauded. Thus, this information MUST
			only be added calls with an attestation level of "Full Attestation"
			[RFC8588] or for calls where the SIP entity inserting the header
			knows to have correct calling number information, e.g., because the
			call originated within the same PBX or the same carrier and the
			operating entity ensures that caller ID spoofing is highly unlikely
			within their realm of responsibility.
	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, Ben Campbell, Keith
	Holmberg, Paul Kyzivat and Dale Worley provided helpful comments on		Drage, Christer Holmberg, Paul Kyzivat and Dale Worley provided
	the document.		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>.
	[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,
	<https://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,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
			[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
			Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
			<https://www.rfc-editor.org/info/rfc3324>.
	[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,
	<https://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,
	<https://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,
	<https://www.rfc-editor.org/info/rfc6809>.		<https://www.rfc-editor.org/info/rfc6809>.
	11.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[I-D.ietf-stir-rfc4474bis]		[RFC8224] 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)", RFC 8224,
	(work in progress), February 2017.		DOI 10.17487/RFC8224, February 2018,
			<https://www.rfc-editor.org/info/rfc8224>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
			11.2. Informative References
	[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, <https://www.rfc-editor.org/info/rfc5039>.		January 2008, <https://www.rfc-editor.org/info/rfc5039>.
			[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token
			(PaSSporT) Extension for Signature-based Handling of
			Asserted information using toKENs (SHAKEN)", RFC 8588,
			DOI 10.17487/RFC8588, May 2019,
			<https://www.rfc-editor.org/info/rfc8588>.
	Author's Address		Author's Address
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	450 Computer Science Bldg.		450 Computer Science Bldg.
	New York, NY 10027		New York, NY 10027
	US		US
	Email: hgs@cs.columbia.edu		Email: hgs@cs.columbia.edu
End of changes. 35 change blocks.
	86 lines changed or deleted		160 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/