idnits 2.17.1 draft-ietf-sipcore-callinfo-spam-02.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 3 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 321 has weird spacing: '... Name sip.c...' -- The document date (October 30, 2017) is 2341 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 Columbia University 4 Intended status: Standards Track October 30, 2017 5 Expires: May 3, 2018 7 SIP Call-Info Parameters for Labeling Calls 8 draft-ietf-sipcore-callinfo-spam-02 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, confidence and references to additional 19 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 https://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 May 3, 2018. 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.1. REGISTER Response . . . . . . . . . . . . . . . . . . . . 6 62 6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . 6 63 7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 7 66 8.2. SIP Global Feature-Capability Indicator . . . . . . . . . 7 67 8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 8 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 11.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 In many countries, an increasing number of calls are unwanted 78 [RFC5039], as they might be fraudulent, telemarketing or the 79 receiving party does not want to be disturbed by, say, surveys or 80 solicitation by charities. Currently, called parties have to rely 81 exclusively on the caller's number or, if provided, caller name, but 82 unwanted callers may not provide their true name or use a name that 83 misleads, e.g., "Cardholder Services". On the other hand, many calls 84 from unknown numbers may be important to the called party, whether 85 this is an emergency alert from their emergency management office or 86 a reminder about a doctor's appointment. Since many subscribers now 87 reject all calls from unknown numbers, such calls may also 88 inadvertently be left unanswered. Users may also install smartphone 89 apps that can benefit from additional information in making decisions 90 as to whether to ring, reject or redirect a call to voicemail. 92 To allow called parties to make more informed decisions on how to 93 handle incoming calls from unknown callers, we describe a new set of 94 parameters for the SIP [RFC3261] Call-Info header field for labeling 95 the nature of the call. 97 Providers may also find the SIP Priority header ([RFC3261], 98 Section 20.26) field useful in helping called parties decide how to 99 respond to an incoming call. 101 2. Normative Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14, RFC 2119 106 [RFC2119]. 108 3. Overview of Operation 110 This document describes a new set of optional parameters and usage 111 for the SIP [RFC3261] Call-Info header field, purpose "info", for 112 labeling the nature of the call. The header field may be inserted by 113 the call originator, an intermediate proxy or B2BUA or the 114 terminating carrier, based on assertions by the caller, number- 115 indexed databases, call analytics or other sources of information. 116 The SIP provider serving the called party MUST remove any parameters 117 enumerated in this specification that it does not trust. The Call- 118 Info header field MAY be signed using a future "ppt" extension to 119 [I-D.ietf-stir-rfc4474bis]. 121 To ensure that an untrusted originating caller does not mislead the 122 called party, a new feature capability indicator [RFC6809], sip.call- 123 info.spam, in the REGISTER response signals whether the terminating 124 carrier supports the feature described in this document and thus will 125 remove any untrusted 'spam', 'type', 'reason' and 'source' Call-Info 126 header field information parameters. It is possible for the 127 terminating carrier to support this feature by simply removing all 128 parameters defined in the document, without inserting any of its own 129 information, although this is likely to be unusual. A user agent 130 MUST ignore any of the parameters defined in this document unless the 131 feature capability indicator is present in the response to the 132 REGISTER request. An example of the REGISTER response is shown in 133 Section 6.1. 135 SIP proxies or B2BUAs MUST add a new Call-Info "info" header field 136 instance, rather than add parameters to an existing one. Thus, there 137 MAY be several Call-Info header fields of purpose "info" in one 138 request. 140 As defined in [RFC3261], the Call-Info header field contains a URI 141 that can provide additional information about the caller or call. 142 For example, many call filtering services provide a web page with 143 crowd-sourced information about the calling number. If the entity 144 inserting the header field does not have information it wants to link 145 to, it MUST use an empty data URL [RFC2397] as a placeholder, as in 146 "data:". (The Call-Info header field syntax makes the URI itself 147 mandatory.) An example is shown in Section 6.2. 149 4. Parameters 151 All of the parameters listed below are optional and may appear in any 152 combination and order. Their ABNF is defined in Section 7. 154 confidence The 'confidence' parameter carries an estimated 155 probability that the call is of the nature indicated in the 'type' 156 parameter, expressed as a whole-number percentage between 0 and 157 100, inclusive, with larger numbers indicating higher probability. 158 The computation of the estimate is beyond the scope of this 159 specification. If a 'type' is not specified, this parameter 160 estimates the likelihood that the call is unwanted spam by the 161 called party. If the confidence level is not specified, the 162 sender considers the information reliable enough to act on, 163 according to its local decision thresholds. 165 type The type parameter indicates the type of the call or caller. 166 It is drawn from an extensible set of values, with the initial set 167 listed below. Gateways to analog phone systems MAY include the 168 label in caller name (CNAM) information. Automated call 169 classification systems MAY use this information as one factor in 170 deciding how to handle the call. Calls SHOULD be labeled with 171 types that may make it more likely that the caller will answer 172 (e.g., for alert and health-related calls) if the entity inserting 173 the information is confident that the calling party number is 174 valid, e.g., because the request has been signed 175 [I-D.ietf-stir-rfc4474bis]. 177 reason The reason parameter provides free-text information, as a 178 string, about the source of the 'type' or 'confidence' parameter 179 and is meant to be used for debugging, rather than for display to 180 the end user. For example, it may indicate the name of an 181 external information source, such as a list of known emergency 182 alerters. 184 source The source parameter identifies the entity, by host name, 185 domain or IP address, that inserted the parameters above. It uses 186 the "host" ABNF syntax. 188 5. Call Types 190 The following initial set of types are defined. The call types are 191 generally based on the caller's telephone number or possibly an 192 assertion by a trusted caller, as the content cannot be not known. 194 Each call is tagged with at most one type label, i.e., the labels are 195 meant to be mutually exclusive. The definitions are meant to be 196 informal and reflect the common understanding of subscribers who are 197 not lawyers. By their very nature, this classification may sometimes 198 be erroneous, e.g., if a number has been re-assigned to another 199 entity or if crowd-sourced information is wrong, and thus should be 200 treated as a hint or estimate. Each entity inserting type 201 information will need to define its own policy as to the level of 202 certainty it requires before it inserts type information. 204 Other strings may be used; there does not appear to be a need for 205 defining vendor-defined strings as the likelihood of confusion 206 between a service-provider-specific usage and a later extension to 207 the list appears low. Additional labels are registered with IANA. 209 business Calls placed by businesses, i.e., an entity or enterprise 210 entered into for profit. This type is used if no other, more 211 precise, category fits. 213 debt-collection Calls related to collecting of debt owed or alleged 214 to be owed by the called party. 216 emergency-alert Calls that provide the recipient warnings and alerts 217 regarding a pending or on-going emergency. (This call type is 218 unrelated to emergency calls placed by individuals using emergency 219 numbers such as 9-1-1 or 1-1-2.) 221 fraud The call is considered to be fraudulent. 223 government A call placed by a government entity, if no more specific 224 label such as "health" or "debt-collection" is known or applies. 226 health Informational calls by health plans, health care 227 clearinghouses or health care provider, where health care means 228 care, services, or supplies related to the health of an 229 individual. 231 informational Calls intended to convey information to the called 232 party about a transaction such as package delivery, appointment 233 reminder, order confirmation. This call type is only used if the 234 calling party believes to have an established business 235 relationship with the called party. 237 not-for-profit A call placed by a not-for-profit organization, 238 including for soliciting donations or providing information. 240 personal A non-business, person-to-person, call, e.g., from a 241 residential line or personal mobile number. 243 political Calls related to elections or other political purposes. 245 public-service Calls that provide the recipient information 246 regarding public services, e.g., school closings. 248 prison Calls from jails, prisons and other correctional facilities. 250 spam A call that is likely unwanted, if not otherwise classified. 252 spoofed The calling number for this call has been spoofed. 254 survey A call that solicits the opinions or data of the called 255 party. 257 telemarketing Calls placed in order to induce the purchase of a 258 product or service to the called party. 260 trusted The call is being placed by a trusted entity and falls 261 outside the other categories listed. This may include call backs, 262 e.g., from a conferencing service, or messages from 263 telecommunication carriers and utilities. 265 6. Examples 267 6.1. REGISTER Response 269 The example below shows a partial REGISTER response showing that the 270 registrar and proxy will remove any untrusted Call-Info header 271 elements. 273 SIP/2.0 200 OK 274 ... 275 From: Bob ;tag=a73kszlfl 276 To: Bob ;tag=34095828jh 277 ... 278 Feature-Caps: *sip.call-info.spam 280 6.2. INVITE Request 282 Call-Info: ;source=carrier.example.com 284 ;purpose=info ;confidence=85 ;type=fraud ;reason="FTC list" 286 7. ABNF 288 label-info-params = [ci-confidence] / [ci-type] / [ci-source] / [ci-reason] 289 ci-confidence = "confidence" EQUAL 1*3DIGIT 290 ci-type = "type" EQUAL ("business" / "debt-collection" / "emergency-alert" / "fraud" / 291 "government" / "health" / "informational" / "not-for-profit" / 292 "personal" / "political" / "public-service" / "prison" / "spam" / 293 "spoofed" / "survey" / "telemarketing" / "trusted" / 294 iana-token) 295 ci-source = "source" EQUAL host 296 ci-reason = "reason" EQUAL quoted-string 298 8. IANA Considerations 300 8.1. SIP Call-Info Header Field Parameters 302 This document defines the 'confidence', 'type', 'reason' and 'source' 303 parameters in the Call-Info header in the "Header Field Parameters 304 and Parameter Values" registry defined by [RFC3968]. 306 +--------------+----------------+-------------------+------------+ 307 | Header Field | Parameter Name | Predefined Values | Reference | 308 +--------------+----------------+-------------------+------------+ 309 | Call-Info | reason | No | [this RFC] | 310 | Call-Info | source | No | [this RFC] | 311 | Call-Info | confidence | No | [this RFC] | 312 | Call-Info | type | Yes | [this RFC] | 313 +--------------+----------------+-------------------+------------+ 315 8.2. SIP Global Feature-Capability Indicator 317 This document defines the feature capability sip.call-info.spam in 318 the "SIP Feature-Capability Indicator Registration Tree" registry 319 defined in [RFC6809]. 321 Name sip.call-info.spam 323 Description This feature-capability indicator when used in a 324 REGISTER response indicates that the server will add, inspect, 325 alter and possibly remove the Call-Info header field parameters 326 defined in the reference. 328 Reference [this RFC] 330 8.3. SIP Call-Info Type Parameter 332 This specification establishes the "Call-Info Type" sub-registry 333 under http://www.iana.org/assignments/sip-parameters. Call-Info 334 "type" parameters are used in the "type" parameter in the SIP Call- 335 Info header field. The initial values are listed in Section 5. 336 Additional values are allocated by expert review [RFC5226]; only the 337 token value, using the ABNF iana-token, and a brief description, 338 typically no more than a few sentences, is required. The ABNF for 339 iana-token is defined in [RFC3261]. A specification is not required. 341 9. Security Considerations 343 The security considerations in [RFC3261] (Section 20.9) apply. A 344 user agent MUST ignore the parameters defined in this document unless 345 the SIP REGISTER response contained the sip.call-info.spam feature 346 capability. B2BUAs or proxies that maintain user registrations MUST 347 remove any parameters defined in this document that were provided by 348 untrusted third parties. 350 The protection offered against rogue SIP entities by the feature 351 capability relies on protecting the REGISTER response against man-in- 352 the-middle attacks that maliciously add the capability indicator. 354 10. Acknowledgements 356 Jim Calme and other members of the Robocall Strikeforce helped draft 357 the initial list of call types. Tolga Asveren, Keith Drage, Christer 358 Holmberg and Paul Kyzivat provided helpful comments on the document. 360 11. References 362 11.1. Normative References 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 370 DOI 10.17487/RFC2397, August 1998, 371 . 373 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 374 A., Peterson, J., Sparks, R., Handley, M., and E. 375 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 376 DOI 10.17487/RFC3261, June 2002, 377 . 379 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 380 (IANA) Header Field Parameter Registry for the Session 381 Initiation Protocol (SIP)", BCP 98, RFC 3968, 382 DOI 10.17487/RFC3968, December 2004, 383 . 385 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 386 IANA Considerations Section in RFCs", RFC 5226, 387 DOI 10.17487/RFC5226, May 2008, 388 . 390 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 391 Indicate Support of Features and Capabilities in the 392 Session Initiation Protocol (SIP)", RFC 6809, 393 DOI 10.17487/RFC6809, November 2012, 394 . 396 11.2. Informative References 398 [I-D.ietf-stir-rfc4474bis] 399 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 400 "Authenticated Identity Management in the Session 401 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 402 (work in progress), February 2017. 404 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 405 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 406 January 2008, . 408 Author's Address 410 Henning Schulzrinne 411 Columbia University 412 450 Computer Science Bldg. 413 New York, NY 10027 414 US 416 Email: hgs@cs.columbia.edu