draft-ietf-sipcore-status-unwanted-06.txt   rfc8197.txt 
SIPCORE H. Schulzrinne Internet Engineering Task Force (IETF) H. Schulzrinne
Internet-Draft FCC Request for Comments: 8197 FCC
Intended status: Standards Track May 8, 2017 Category: Standards Track July 2017
Expires: November 9, 2017 ISSN: 2070-1721
A SIP Response Code for Unwanted Calls A SIP Response Code for Unwanted Calls
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
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 9, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8197.
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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
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 or illegal telemarketing or maybe
receiving party does not want to be disturbed by, say, surveys or the 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
variety of global or user-specific filtering algorithms. One input variety of global or user-specific filtering algorithms. One input
into such algorithms is user feedback. User feedback may be offered into such algorithms is user feedback. User feedback may be offered
through smartphone apps, APIs or within the context of a SIP- through smartphone apps, APIs or within the context of a SIP-
initiated call. This document addresses feedback within the SIP initiated call. This document addresses feedback within the SIP
call. Here, the called party either rejects the SIP [RFC3261] call. Here, the called party either rejects the SIP [RFC3261]
request as unwanted or terminates the session with a BYE request request as unwanted or terminates the session with a BYE request
after answering the call. INVITE and MESSAGE requests are most after answering the call. INVITE and MESSAGE requests are most
likely to trigger such a response. likely to trigger such a response.
To allow the called party to express that the call was unwanted, this To allow the called party to express that the call was unwanted, this
document defines the 607 (Unwanted) response code. The user agent of document defines the 607 (Unwanted) response code. The user agent
the called party, based on input from the called party or some UA- (UA) of the called party, based on input from the called party or
internal logic, uses this to indicate that this call is unwanted and some UA-internal logic, uses this to indicate that this call is
that future attempts are likely to be similarly rejected. While unwanted and that future attempts are likely to be similarly
factors such as identity spoofing and call forwarding may make rejected. While factors such as identity spoofing and call
authoritative identification of the calling party difficult or forwarding may make authoritative identification of the calling party
impossible, the network can use such a rejection -- possibly combined difficult or impossible, the network can use such a rejection --
with a pattern of rejections by other callees and/or other possibly combined with a pattern of rejections by other callees and/
information -- as input to a heuristic algorithm for determining or other information -- as input to a heuristic algorithm for
future call treatment. The heuristic processing and possible determining future call treatment. The heuristic processing and
treatment of persistently unwanted calls are outside the scope of possible treatment of persistently unwanted calls are outside the
this document. scope of this document.
As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity" When this document refers to "caller identity", it uses "identity" in
or "calling party identity" in this document to mean either a the same sense as [SIP-IDENTITY], i.e., to mean either a canonical
canonical address-of-record (AoR) SIP URI employed to reach a user address-of-record (AOR) SIP URI employed to reach a user (such as
(such as 'sip:alice@atlanta.example.com'), or a telephone number, 'sip:alice@atlanta.example.com'), or a telephone number, which
which commonly appears in either a tel URI [RFC3966] or as the user commonly appears in either a tel URI [RFC3966] or as the user portion
portion of a SIP URI. of a SIP URI.
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
[RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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
SIP request is unwanted by the called party. For example, 603 this 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) status. 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. causing the call to be rejected.
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
response from one of the branches. (Including a Reason header field response from one of the branches. (Including a Reason header field
with the 607 status code allows the called party user agent that with the 607 status code allows the called party user agent that
receives a CANCEL request to make an informed choice whether and how receives a CANCEL request to make an informed choice whether and how
to include such calls in their missed-call list or whether to show an to include such calls in their missed-call list or whether to show an
appropriate indication to the user.) appropriate indication to the user.)
skipping to change at page 3, line 44 skipping to change at page 4, line 4
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
response from one of the branches. (Including a Reason header field response from one of the branches. (Including a Reason header field
with the 607 status code allows the called party user agent that with the 607 status code allows the called party user agent that
receives a CANCEL request to make an informed choice whether and how receives a CANCEL request to make an informed choice whether and how
to include such calls in their missed-call list or whether to show an to include such calls in their missed-call list or whether to show an
appropriate indication to the user.) appropriate indication to the user.)
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's identity to consumer
complaint databases. As discussed in Section Section 6, reversing complaint databases. As discussed in Section 6, reversing the
the 'unwanted' labeling is beyond the scope of this mechanism, as it 'unwanted' labeling is beyond the scope of this mechanism, as it will
will likely require a mechanism other than call signaling. 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.
The mechanism described here is only one of many inputs likely to be The mechanism described here is only one of many inputs likely to be
used by call filtering algorithms operated by service providers, used by call-filtering algorithms operated by service providers,
using data on calls from a particular identifier such as a telephone using data on calls from a particular identifier such as a telephone
number to establish handling for future calls from the same number to establish handling for future calls from the same
identifier. Call handling for unwanted calls is likely to involve a identifier. Call handling for unwanted calls is likely to involve a
combination of heuristics, analytics, and machine learning. These combination of heuristics, analytics, and machine learning. These
may use call characteristics such as call duration and call volumes may use call characteristics such as call duration and call volumes
for a particular caller, including changes in those metrics over for a particular caller, including changes in those metrics over
time, as well as user feedback via non-SIP approaches and the time, as well as user feedback via non-SIP approaches and the
mechanism described here. Implementations will have to make mechanism described here. Implementations will have to make
appropriate trade-offs between falsely labeling a caller as unwanted appropriate trade-offs between falsely labeling a caller as unwanted
and delivering unwanted calls. and delivering unwanted calls.
skipping to change at page 4, line 40 skipping to change at page 4, line 47
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
tone. tone.
The actions described here do not depend on the nature of the SIP The actions described here do not depend on the nature of the SIP
URI, e.g., whether it describes a telephone number or not; however, URI, e.g., whether or not it describes a telephone number; however,
the same anonymous SIP URI [RFC3323] may be used by multiple callers the same anonymous SIP URI [RFC3323] may be used by multiple callers;
and thus such URIs are unlikely to be appropriate for URI-specific thus, such URIs are unlikely to be appropriate for URI-specific call
call treatment. SIP entities tallying responses for particular treatment. SIP entities tallying responses for particular callers
callers may need to consider canonicalzing SIP URIs, including may need to consider canonicalzing SIP URIs, including telephone
telephone numbers, as described in [I-D.ietf-stir-rfc4474bis]. The numbers, as described in [SIP-IDENTITY]. The calling party may be
calling party may be identified in different locations in the SIP identified in different locations in the SIP header, e.g., the From
header, e.g., the From header field, P-Asserted-Identity or History- header field, P-Asserted-Identity or History-Info, and may also be
Info, and may also be affected by diverting services. affected by diverting services.
This document defines a SIP feature-capability [RFC6809], sip.607, This document defines a SIP feature-capability [RFC6809], sip.607,
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 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 has been added to the
"Response Codes" sub-registry under http://www.iana.org/assignments/ "Response Codes" subregistry under the "Session Initiation Protocol
sip-parameters. (SIP) Parameters" registry <http://www.iana.org/assignments/sip-
parameters>.
Response Code Number 607 Response Code: 607
Default Reason Phrase Unwanted Description: Unwanted
Reference [this RFC] Reference: [RFC8197]
5.2. SIP Global Feature-Capability Indicator 5.2. SIP Global Feature-Capability Indicator
This document defines the feature capability sip.607 in the "SIP This document defines the feature capability sip.607 in the "SIP
Feature-Capability Indicator Registration Tree" registry defined in Feature-Capability Indicator Registration Tree" registry defined in
[RFC6809]. [RFC6809].
Name sip.607 Name: sip.607
Description This feature-capability indicator, when included in a Description: This feature-capability indicator, when included in a
Feature-Caps header field of a REGISTER response, indicates that Feature-Caps header field of a REGISTER response, indicates that
the server supports, and will process, the 607 (Unwanted) response the server supports, and will process, the 607 (Unwanted) response
code. code.
Reference [this RFC] Reference: [RFC8197]
6. Security Considerations 6. Security Considerations
If the calling party address is spoofed, users may report the caller If the calling party address is spoofed, users may report the caller
identity as placing unwanted calls, possibly leading to the blocking identity as placing unwanted calls, possibly leading to the blocking
of calls from the legitimate user of the caller identity in addition of calls from the legitimate user of the caller identity in addition
to the unwanted caller, i.e., creating a form of denial-of-service to the unwanted caller, i.e., creating a form of denial-of-service
attack. Thus, the response code SHOULD NOT be used for creating attack. Thus, the response code SHOULD NOT be used for creating
global call filters unless the calling party identity has been global call filters unless the calling party identity has been
authenticated using [I-D.ietf-stir-rfc4474bis] as being assigned to authenticated using [SIP-IDENTITY] as being assigned to the caller
the caller placing the unwanted call. (The creation of call filters placing the unwanted call. (The creation of call filters local to a
local to a user agent is beyond the scope of this document.) user agent is beyond the scope of this document.)
Even if the identity is not spoofed, a call or message recipient Even if the identity is not spoofed, a call or message recipient
might flag legitimate caller identities, e.g., to exact vengeance on might flag legitimate caller identities, e.g., to exact vengeance on
a person or business, or simply by mistake. To correct errors, any a person or business, or simply by mistake. To correct errors, any
additions to a personal list of blocked caller identities should be additions to a personal list of blocked caller identities should be
observable and reversible by the party being protected by the observable and reversible by the party being protected by the
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 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 significant number of call recipients, it may be able to convince the
call filtering algorithm to block legitimate calls. Use of TLS to call-filtering algorithm to block legitimate calls. Use of TLS to
protect signaling mitigates against this risk. protect signaling mitigates against this risk.
Since caller identities are routinely re-assigned to new subscribers, Since caller identities are routinely reassigned 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 reassigned 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 reassigned
to a new subscriber.) to a new subscriber.)
Some call services such as 3PCC [RFC3725] and call transfer [RFC5359] Some call services, such as 3PCC [RFC3725] and call transfer
increase the complexity of identifying who (if anyone) should be [RFC5359], increase the complexity of identifying who (if anyone)
impacted by the receipt of 607 within BYE. Such services might cause should be impacted by the receipt of 607 within BYE. Such services
the wrong party to be flagged or prevent flagging the desired party. might cause 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. References
Tolga Asveren, Ben Campbell, Peter Dawes, Spencer Dawkins, Martin
Dolly, Keith Drage, Vijay Gurbani, Christer Holmberg, Olle Johansson,
Paul Kyzivat, Jean Mahoney, Marianne Mohali, Adam Montville, Al
Morton, Denis Ovsienko, Brian Rosen, Brett Tate, Chris Wendt, Dale
Worley and Peter Yee (Gen-ART reviewer) provided helpful comments.
8. References
8.1. Normative References 7.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>.
[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,
skipping to change at page 7, line 31 skipping to change at page 7, line 37
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>.
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-stir-rfc4474bis] 7.2. Informative References
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(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>.
[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,
skipping to change at page 8, line 18 skipping to change at page 8, line 22
[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, [RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan,
S., and K. Summers, "Session Initiation Protocol Service S., and K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359,
October 2008, <http://www.rfc-editor.org/info/rfc5359>. October 2008, <http://www.rfc-editor.org/info/rfc5359>.
[SIP-IDENTITY]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", Work in Progress,
draft-ietf-stir-rfc4474bis-16, February 2017.
Acknowledgements
Tolga Asveren, Ben Campbell, Peter Dawes, Spencer Dawkins, Martin
Dolly, Keith Drage, Vijay Gurbani, Christer Holmberg, Olle Johansson,
Paul Kyzivat, Jean Mahoney, Marianne Mohali, Adam Montville, Al
Morton, Denis Ovsienko, Brian Rosen, Brett Tate, Chris Wendt, Dale
Worley, and Peter Yee (Gen-ART reviewer) provided helpful comments.
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 United States of America
Email: henning.schulzrinne@fcc.gov Email: henning.schulzrinne@fcc.gov
 End of changes. 38 change blocks. 
103 lines changed or deleted 105 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/