idnits 2.17.1 draft-ietf-sipcore-callinfo-spam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 30 characters in excess of 72. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 291 has weird spacing: '... Name sip.c...' -- The document date (March 7, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE H. Schulzrinne 3 Internet-Draft FCC 4 Intended status: Standards Track March 7, 2017 5 Expires: September 8, 2017 7 SIP Call-Info Parameters for Labeling Calls 8 draft-ietf-sipcore-callinfo-spam-00 10 Abstract 12 Called parties often wish to decide whether to accept, reject or 13 redirect calls based on the likely nature of the call. For example, 14 they may want to reject unwanted telemarketing or fraudulent calls, 15 but accept emergency alerts from numbers not in their address book. 16 This document describes SIP Call-Info parameters and a feature tag 17 that allow originating, intermediate and terminating SIP entities to 18 label calls as to their type, spam probability and references to 19 additional information. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 8, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 58 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 6 64 8.2. SIP Global Feature-Capability Indicator . . . . . . . . . 7 65 8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 7 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 11.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 In many countries, an increasing number of calls are unwanted 76 [RFC5039], as they might be fraudulent, telemarketing or the 77 receiving party does not want to be disturbed by, say, surveys or 78 solicitation by charities. Currently, called parties have to rely 79 exclusively on the caller's number or, if provided, caller name, but 80 unwanted callers may not provide their true name or use a name that 81 misleads, e.g., "Cardholder Services". On the other hand, many calls 82 from unknown numbers may be important to the called party, whether 83 this is an emergency alert from their emergency management office or 84 a reminder about a doctor's appointment. Since many subscribers now 85 reject all calls from unknown numbers, such calls may also be 86 inadvertently be left unanswered. Users may also install smartphone 87 apps that can benefit from additional information in making decisions 88 as to whether to ring, reject or redirect a call. 90 To allow called parties to make more informed decisions on how to 91 handle incoming calls from unknown callers, we describe a new set of 92 parameters for the SIP [RFC3261] Call-Info header field for labeling 93 the nature of the call. 95 Providers may also find the SIP Priority header (Section 20.26) field 96 useful in helping called parties decide how to respond to an incoming 97 call. 99 2. Normative Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in BCP 14, RFC 2119 104 [RFC2119]. 106 3. Overview of Operation 108 This document describes a new set of optional parameters and usage 109 for the SIP [RFC3261] Call-Info header field, purpose "info", for 110 labeling the nature of the call. The header field may be inserted by 111 the call originator, an intermediate proxy or B2BUA or the 112 terminating carrier, based on assertions by the caller, number- 113 indexed databases, call analytics or other sources of information. 114 The SIP provider serving the called party MUST remove any parameters 115 enumerated in this specification that it does not trust. The Call- 116 Info header field MAY be signed using a future "ppt" extension to 117 [I-D.ietf-stir-rfc4474bis]. To ensure that an untrusted originating 118 caller does not mislead the called party, a new feature tag, 119 sip.call-info.spam, indicates whether the terminating carrier will 120 remove untrusted information. 122 SIP entities MUST add a new Call-Info "info" header field instance, 123 rather than add parameters to an existing one. Thus, there MAY be 124 several Call-Info header fields of purpose "info" in one request. 126 As defined in [RFC3261], the Call-Info header field contains a URI 127 that can provide additional information about the caller or call. 128 For example, many call filtering services provide a web page with 129 crowd-sourced information about the calling number. If the entity 130 inserting the header field does not have information it wants to link 131 to, it MUST use an empty data URL [RFC2397] as a placeholder, as in 132 "data:". (The Call-Info header field syntax makes the URI itself 133 mandatory.) 135 4. Parameters 137 All of the parameters listed below are optional and may appear in any 138 combination and order. Their ABNF is defined in Section 7. 140 spam The spam parameter carries an estimated probability that the 141 call will not be wanted by the called party, expressed as a whole- 142 number percentage between 0 and 100, inclusive, with larger 143 numbers indicating higher probability. The computation of the 144 estimate is beyond the scope of this specification. If not 145 specified, the entity inserting the Call-Info information is 146 making no claims about the likelihood of being unwanted. Note 147 that call types other than "spam" may have a non-zero spam rating, 148 as these calls may also be unwanted by some fraction of the 149 recipients, even if they are not illegal in a particular 150 jurisdiction. 152 type The type parameter indicates the type of the call or caller. 153 It is drawn from an extensible set of values, with the initial set 154 listed below. Gateways to analog phone systems MAY include the 155 label in caller name (CNAM) information. Automated call 156 classification systems MAY use this information as one factor in 157 deciding how to handle the call. Calls SHOULD be labeled with 158 types that may make it more likely that the caller will answer 159 (e.g., for alert and health-related calls) if the entity inserting 160 the information is confident that the calling party number is 161 valid, e.g., because the request has been signed 162 [I-D.ietf-stir-rfc4474bis]. 164 reason The reason parameter provides free-text information, as a 165 string, about the source of the type or spam parameter and is 166 meant to be used for debugging, rather than for display to the end 167 user. For example, it may indicate the name of an external 168 information source, such as a list of known emergency alerters. 170 source The source parameter identifies the entity, by host name, 171 domain or IP address, that inserted the parameters above. It uses 172 the "host" ABNF syntax. 174 5. Call Types 176 The following initial set of types are defined. The call types are 177 generally based on the caller's telephone number or possibly an 178 assertion by a trusted caller, as the content cannot be not known. 179 Each call is tagged with at most one type label, i.e., the labels are 180 meant to be mutually exclusive. The definitions are meant to be 181 informal and reflect the common understanding of subscribers who are 182 not lawyers. By their very nature, this classification may sometimes 183 be erroneous, e.g., if a number has been re-assigned to another 184 entity or if crowd-sourced information is wrong, and thus should be 185 treated as a hint or estimate. Each entity inserting type 186 information will need to define its own policy as to the level of 187 certainty it requires before it inserts type information. 189 Other strings may be used; there does not appear to be a need for 190 defining vendor-defined strings as the likelihood of confusion 191 between a service-provider-specific usage and a later extension to 192 the list appears low. Additional labels are registered with IANA. 194 business Calls placed by businesses, i.e., an entity or enterprise 195 entered into for profit. This type is used if no other, more 196 precise, category fits. 198 debt-collection Calls related to collecting of debt owed or alleged 199 to be owed by the called party. 201 emergency-alert Calls that provide the recipient warnings and alerts 202 regarding a pending or on-going emergency. (This call type is 203 unrelated to emergency calls placed by individuals using emergency 204 numbers such as 9-1-1 or 1-1-2.) 206 fraud The call is considered to be fraudulent. 208 government A call placed by a government entity, if no more specific 209 label such as "health" or "debt-collection" is known or applies. 211 health Informational calls by health plans, health care 212 clearinghouses or health care provider, where health care means 213 care, services, or supplies related to the health of an 214 individual. 216 informational Calls intended to convey information to the called 217 party about a transaction such as package delivery, appointment 218 reminder, order confirmation. This call type is only used if the 219 calling party believes to have an established business 220 relationship with the called party. 222 not-for-profit A call placed by a not-for-profit organization, 223 including for soliciting donations or providing information. 225 personal A non-business, person-to-person, call, e.g., from a 226 residential line or personal mobile number. 228 political Calls related to elections or other political purposes. 230 public-service Calls that provide the recipient information 231 regarding public services, e.g., school closings. 233 prison Calls from jails, prisons and other correctional facilities. 235 spam A call that is likely unwanted, if not otherwise classified. 237 spoofed The calling number for this call has been spoofed. 239 survey A call that solicits the opinions or data of the called 240 party. 242 telemarketing Calls placed in order to induce the purchase of a 243 product or service to the called party. 245 trusted The call is being placed by a trusted entity and falls 246 outside the other categories listed. This may include call backs, 247 e.g., from a conferencing service, or messages from 248 telecommunication carriers and utilities. 250 6. Example 252 "Call-Info: 253 ;source=carrier.example.com ;purpose=info ;spam=85 ;type=fraud 254 ;reason="FTC list"" 256 7. ABNF 258 label-info-params = [ci-spam] / [ci-type] / [ci-source] / [ci-reason] 259 ci-spam = "spam" EQUAL 1*3DIGIT 260 ci-type = "type" EQUAL ("business" / "debt-collection" / "emergency-alert" / "fraud" / 261 "government" / "health" / "informational" / "not-for-profit" / 262 "personal" / "political" / "public-service" / "prison" / "spam" / 263 "spoofed" / "survey" / "telemarketing" / "trusted" / 264 iana-token) 265 ci-source = "source" EQUAL host 266 ci-reason = "reason" EQUAL quoted-string 268 8. IANA Considerations 270 8.1. SIP Call-Info Header Field Parameters 272 This document defines the 'spam', 'type', 'reason' and 'source' 273 parameters in the Call-Info header in the "Header Field Parameters 274 and Parameter Values" registry defined by [RFC3968]. 276 +--------------+----------------+-------------------+------------+ 277 | Header Field | Parameter Name | Predefined Values | Reference | 278 +--------------+----------------+-------------------+------------+ 279 | Call-Info | reason | No | [this RFC] | 280 | Call-Info | source | No | [this RFC] | 281 | Call-Info | spam | No | [this RFC] | 282 | Call-Info | type | Yes | [this RFC] | 283 +--------------+----------------+-------------------+------------+ 285 8.2. SIP Global Feature-Capability Indicator 287 This document defines the feature capability sip.call-info.spam in 288 the "SIP Feature-Capability Indicator Registration Tree" registry 289 defined in [RFC6809]. 291 Name sip.call-info.spam 293 Description This feature-capability indicator when used in a 294 REGISTER response indicates that the server will add, inspect, 295 alter and possibly remove the Call-Info header field parameters 296 defined in the reference. 298 Reference [this RFC] 300 8.3. SIP Call-Info Type Parameter 302 This specification establishes the "Call-Info Type" sub-registry 303 under http://www.iana.org/assignments/sip-parameters. Call-Info 304 "type" parameters are used in the "type" parameter in the SIP Call- 305 Info header field. The initial values are listed in Section 5. 306 Additional values are allocated by expert review [RFC5226]; only the 307 token value, using the ABNF iana-token, and a brief description, 308 typically no more than a few sentences, is required. The ABNF for 309 iana-token is defined in [RFC3261]. A specification is not required. 311 9. Security Considerations 313 The security considerations in [RFC3261] (Section 20.9) apply. A 314 user agent MUST ignore the parameters defined in this document unless 315 the SIP REGISTER response contained the sip.call-info.spam feature 316 capability. SIP entities MUST remove any parameters defined here 317 that were provided by untrusted third parties. 319 The protection offered against rogue SIP entities by the feature 320 capability relies on protecting the REGISTER response against man-in- 321 the-middle attacks that maliciously add the capability indicator. 323 10. Acknowledgements 325 Jim Calme and other members of the Robocall Strikeforce helped draft 326 the initial list of call types. Keith Drage and Paul Kyzivat 327 provided helpful comments on the document. 329 11. References 331 11.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 339 DOI 10.17487/RFC2397, August 1998, 340 . 342 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 343 A., Peterson, J., Sparks, R., Handley, M., and E. 344 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 345 DOI 10.17487/RFC3261, June 2002, 346 . 348 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 349 (IANA) Header Field Parameter Registry for the Session 350 Initiation Protocol (SIP)", BCP 98, RFC 3968, 351 DOI 10.17487/RFC3968, December 2004, 352 . 354 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 355 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 356 DOI 10.17487/RFC5226, May 2008, 357 . 359 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 360 Indicate Support of Features and Capabilities in the 361 Session Initiation Protocol (SIP)", RFC 6809, 362 DOI 10.17487/RFC6809, November 2012, 363 . 365 11.2. Informative References 367 [I-D.ietf-stir-rfc4474bis] 368 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 369 "Authenticated Identity Management in the Session 370 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 371 (work in progress), February 2017. 373 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 374 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 375 January 2008, . 377 Author's Address 379 Henning Schulzrinne 380 FCC 381 445 12th Street SW 382 Washington, DC 20554 383 US 385 Email: henning.schulzrinne@fcc.gov