draft-ietf-sipcore-rejected-03.txt   draft-ietf-sipcore-rejected-04.txt 
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft Georgetown University Internet-Draft Georgetown University
Intended status: Standards Track B. Nagda Intended status: Standards Track B. Nagda
Expires: August 7, 2019 Massachusetts Institute of Technology Expires: September 28, 2019 Massachusetts Institute of Technology
February 3, 2019 March 27, 2019
A Session Initiation Protocol (SIP) Response Code for Rejected Calls A Session Initiation Protocol (SIP) Response Code for Rejected Calls
draft-ietf-sipcore-rejected-03 draft-ietf-sipcore-rejected-04
Abstract Abstract
This document defines the 608 (Rejected) SIP response code. This This document defines the 608 (Rejected) SIP response code. This
response code enables calling parties to learn that an intermediary response code enables calling parties to learn that an intermediary
rejected their call attempt. The call will not be answered. As a rejected their call attempt. The call will not be answered. As a
6xx code, the caller will be aware that future attempts to contact 6xx code, the caller will be aware that future attempts to contact
the same UAS will likely fail. The present use case driving the need the same UAS will likely fail. The present use case driving the need
for the 608 response code is when the intermediary is an analytics for the 608 response code is when the intermediary is an analytics
engine. In this case, the rejection is by a machine or other engine. In this case, the rejection is by a machine or other
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 7, 2019. This Internet-Draft will expire on September 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8
3.2. jCard Construction . . . . . . . . . . . . . . . . . . . 8 3.2. jCard Construction . . . . . . . . . . . . . . . . . . . 8
3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9 3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9
3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9 3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 9 3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 9
3.5. Announcement Requirements . . . . . . . . . . . . . . . . 10 3.5. Announcement Requirements . . . . . . . . . . . . . . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 15 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 14
4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 15 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 15
4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 17 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 17
5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 17 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 17
5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 18 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 17
5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 18 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The IETF has been addressing numerous issues surrounding how to The IETF has been addressing numerous issues surrounding how to
handle unwanted and, depending on the jurisdiction, illegal calls handle unwanted and, depending on the jurisdiction, illegal calls
[RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN]
skipping to change at page 7, line 22 skipping to change at page 7, line 22
undecipherable, either (1) a malicious agent is lying about the jCard undecipherable, either (1) a malicious agent is lying about the jCard
or (2) the redress mechanism is misconfigured. or (2) the redress mechanism is misconfigured.
2. Terminology 2. Terminology
This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only
when, they appear in all capitals, as shown here. when, they appear in all capitals, as shown here.
As a matter of principle, this document uses the term "UNLESS" to
distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD"
means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a.
Burger's Law of Protocol Meaningless Terms.
3. Protocol Operation 3. Protocol Operation
For clarity, this section uses the term 'intermediary' as the entity For clarity, this section uses the term 'intermediary' as the entity
that acts as a SIP User Agent Server (UAS) on behalf of the user in that acts as a SIP User Agent Server (UAS) on behalf of the user in
the network, as opposed to the user's UAS (colloquially, but not the network, as opposed to the user's UAS (colloquially, but not
necessarily, their phone). The intermediary could be a back-to-back necessarily, their phone). The intermediary could be a back-to-back
user agent (B2BUA) or a SIP Proxy. user agent (B2BUA) or a SIP Proxy.
Figure 4 shows an overview of the call flow for a rejected call. Figure 4 shows an overview of the call flow for a rejected call.
skipping to change at page 8, line 30 skipping to change at page 8, line 14
3.1. Intermediary Operation 3.1. Intermediary Operation
An intermediary MAY issue the 608 response code in a failure response An intermediary MAY issue the 608 response code in a failure response
for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP
[RFC3261] request to indicate that an intermediary rejected the [RFC3261] request to indicate that an intermediary rejected the
offered communication as unwanted by the user. An intermediary MAY offered communication as unwanted by the user. An intermediary MAY
issue the 608 as the value of the "cause" parameter of a SIP reason- issue the 608 as the value of the "cause" parameter of a SIP reason-
value in a Reason header field [RFC3326]. value in a Reason header field [RFC3326].
If an intermediary issues a 608 code, the intermediary SHOULD include If an intermediary issues a 608 code and there are not indicators the
a Call-Info header in the response, UNLESS there are indicators the
calling party will use the contents of the Call-Info header for calling party will use the contents of the Call-Info header for
malicious purposes (see Section 6). malicious purposes (see Section 6), the intermediary MUST include a
Call-Info header in the response.
If there is a Call-Info header, it MUST have the 'purpose' parameter If there is a Call-Info header, it MUST have the 'purpose' parameter
of 'jwscard'. The value of the Call-Info header MUST refer to a of 'jwscard'. The value of the Call-Info header MUST refer to a
valid JWS [RFC7515] encoding of a jCard [RFC7095] object. valid JWS [RFC7515] encoding of a jCard [RFC7095] object.
Proxies need to be mindful that a downstream intermediary may reject Proxies need to be mindful that a downstream intermediary may reject
the attempt with a 608 while other paths may still be in progress. the attempt with a 608 while other paths may still be in progress.
In this situation, the requirements stated in Section 16.7 of RFC3261 In this situation, the requirements stated in Section 16.7 of RFC3261
[RFC3261] apply. Specifically, the proxy should cancel pending [RFC3261] apply. Specifically, the proxy should cancel pending
transactions and must not create any new branches. Note this is not transactions and must not create any new branches. Note this is not
skipping to change at page 10, line 19 skipping to change at page 9, line 50
the intermediary that rejected the call attempt. the intermediary that rejected the call attempt.
The degenerate case is the intermediary is the only element that The degenerate case is the intermediary is the only element that
understands the semantics of the 608 response code. Obviously, any understands the semantics of the 608 response code. Obviously, any
SIP device will understand that a 608 response code is a 6xx error. SIP device will understand that a 608 response code is a 6xx error.
However, there are no other elements in the call path that understand However, there are no other elements in the call path that understand
the meaning of the value of the Call-Info header. The intermediary the meaning of the value of the Call-Info header. The intermediary
knows this is the case as the INVITE request will not have the knows this is the case as the INVITE request will not have the
sip.608 feature capability. In this case, one can consider the sip.608 feature capability. In this case, one can consider the
intermediary to be the element 'inserting' a virtual sip.608 feature intermediary to be the element 'inserting' a virtual sip.608 feature
capability. As such, the intermediary SHOULD play the announcement, capability. If the caveats described in Section 3.5 and Section 6 do
UNLESS the caveats described in Section 3.5 and Section 6 hold. not hold, the intermediary MUST play the announcement.
Now we take the case where a network element that understands the 608 Now we take the case where a network element that understands the 608
response code receives an INVITE for further processing. A network response code receives an INVITE for further processing. A network
element conforming with this specification MUST insert the sip.608 element conforming with this specification MUST insert the sip.608
feature capability, per the behaviors described in Section 4.2 of feature capability, per the behaviors described in Section 4.2 of
[RFC6809]. [RFC6809].
Do note that even if a network element plays an announcement Do note that even if a network element plays an announcement
describing the contents of the 608 response message, the network describing the contents of the 608 response message, the network
element MUST forward the 608 response code message as the final element MUST forward the 608 response code message as the final
skipping to change at page 11, line 13 skipping to change at page 10, line 42
information. information.
Let us take the case where a telecommunications service provider Let us take the case where a telecommunications service provider
controls the element inserting the sip.608 feature capability. It controls the element inserting the sip.608 feature capability. It
would be reasonable to expect the service provider would play an would be reasonable to expect the service provider would play an
announcement in the media path towards the UAC (caller). It is announcement in the media path towards the UAC (caller). It is
important to note the network element should be mindful of the media important to note the network element should be mindful of the media
type requested by the UAC as it formulates the announcement. For type requested by the UAC as it formulates the announcement. For
example, it would make sense for an INVITE that only indicated audio example, it would make sense for an INVITE that only indicated audio
codecs in the SDP [RFC4566] to result in an audio announcement. codecs in the SDP [RFC4566] to result in an audio announcement.
However, if the INVITE only indicated a real-time text codec, the However, if the INVITE only indicated a real-time text codec and the
network element SHOULD send the information in a text format, not an network element is able to render the information in the requested
audio format, unless the network element is unable to render the media format, the network element MUST send the information in a text
information in the requested media format. format, not an audio format.
It is also possible for the network element inserting the sip.608 It is also possible for the network element inserting the sip.608
feature capability to be under the control of the same entity that feature capability to be under the control of the same entity that
controls the UAC. For example, a large call center might have legacy controls the UAC. For example, a large call center might have legacy
UACs, but have a modern outbound calling proxy that understands the UACs, but have a modern outbound calling proxy that understands the
full semantics of the 608 response code. In this case, it is enough full semantics of the 608 response code. In this case, it is enough
for the outbound calling proxy to digest the Call-Info information for the outbound calling proxy to digest the Call-Info information
and handle the information digitally, rather than 'transcoding' the and handle the information digitally, rather than 'transcoding' the
Call-Info information for presentation to the caller. Call-Info information for presentation to the caller.
 End of changes. 13 change blocks. 
24 lines changed or deleted 19 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/