draft-ietf-sipcore-status-unwanted-03.txt   draft-ietf-sipcore-status-unwanted-04.txt 
SIPCORE H. Schulzrinne SIPCORE H. Schulzrinne
Internet-Draft FCC Internet-Draft FCC
Intended status: Standards Track February 15, 2017 Intended status: Standards Track March 2, 2017
Expires: August 19, 2017 Expires: September 3, 2017
A SIP Response Code for Unwanted Calls A SIP Response Code for Unwanted Calls
draft-ietf-sipcore-status-unwanted-03 draft-ietf-sipcore-status-unwanted-04
Abstract Abstract
This document defines the 666 (Unwanted) SIP response code, allowing This document defines the 666 (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 August 19, 2017. This Internet-Draft will expire on September 3, 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 3, line 39 skipping to change at page 3, line 39
4. Behavior of SIP Entities 4. Behavior of SIP Entities
The response code 666 MAY be used in a failure response for an The response code 666 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
UAS issues a BYE request terminating an incoming call or the UAC UAS issues a BYE request terminating an incoming call or the UAC
issues a CANCEL request when forking a call. (Including a Reason issues a CANCEL request when forking a call. (Including a Reason
header field with the 666 status code allows the UAS that receive a header field with the 666 status code allows the UAS that receives a
CANCEL request to make an informed choice whether and how to include CANCEL request to make an informed choice whether and how to include
such calls in their missed-call list.) such calls in their missed-call list.)
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 666 response destroys the transaction. The service [RFC5057], the 666 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, for example, MAY add the calling party to a personal response, for example, MAY add the calling party to a personal
blacklist specific to the called party, MAY use the information as blacklist specific to the called party, MAY use the information as
skipping to change at page 4, line 47 skipping to change at page 4, line 47
Info, and may also be affected by diverting services. Info, and may also be affected by diverting services.
This document defines a SIP feature-capability [RFC6809], sip.666, This document defines a SIP feature-capability [RFC6809], sip.666,
that allows the registrar to indicate that the corresponding proxy that allows the registrar to indicate that the corresponding proxy
supports this particular response code. This allows the UA, for supports this particular response code. This allows the UA, for
example, to provide a suitable user interface element, such as a example, to provide a suitable user interface element, such as a
"spam" button, only if its service provider actually supports the "spam" button, only if its service provider actually supports the
feature. The presence of the feature capability does not imply that feature. The presence of the feature capability does not imply that
the provider will take any particular action, such as blocking future the provider will take any particular action, such as blocking future
calls. A UA may still decide to render a "spam" button even without calls. A UA may still decide to render a "spam" button even without
such as a capability if, for example, it maintains a device-local such a capability if, for example, it maintains a device-local
blacklist or reports unwanted calls to a third party. blacklist or reports unwanted calls to a third party.
5. IANA Considerations 5. IANA Considerations
5.1. SIP Response Code 5.1. SIP Response Code
This document registers a new SIP response code. This response code This document registers a new SIP response code. This response code
is defined by the following information, which is to be added to the is defined by the following information, which is to be added to the
"Response Codes" sub-registry under http://www.iana.org/assignments/ "Response Codes" sub-registry under http://www.iana.org/assignments/
sip-parameters. sip-parameters.
skipping to change at page 6, line 19 skipping to change at page 6, line 19
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.
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. rating.
Some call services such as 3PCC [RFC3725] and call transfer increase Some call services such as 3PCC [RFC3725] and call transfer increase
the complexity of identifying who (if anyone) should be impacted by the complexity of identifying who (if anyone) should be impacted by
the receipt of 666 within BYE. Such services might causes the wrong the receipt of 666 within BYE. Such services might cause the wrong
party to be flagged or prevent flagging the desired party. 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 666 may want to distinguish responses recipients of response code 666 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
skipping to change at page 7, line 10 skipping to change at page 7, line 10
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,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, DOI 10.17487/RFC3326, December 2002, RFC 3326, DOI 10.17487/RFC3326, December 2002,
<http://www.rfc-editor.org/info/rfc3326>. <http://www.rfc-editor.org/info/rfc3326>.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057,
November 2007, <http://www.rfc-editor.org/info/rfc5057>.
[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,
<http://www.rfc-editor.org/info/rfc6809>. <http://www.rfc-editor.org/info/rfc6809>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
skipping to change at page 7, line 47 skipping to change at page 7, line 43
<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
Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057,
November 2007, <http://www.rfc-editor.org/info/rfc5057>.
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. 8 change blocks. 
11 lines changed or deleted 11 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/