draft-ietf-sipcore-rejected-04.txt   draft-ietf-sipcore-rejected-05.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: September 28, 2019 Massachusetts Institute of Technology Expires: October 2, 2019 Massachusetts Institute of Technology
March 27, 2019 March 31, 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-04 draft-ietf-sipcore-rejected-05
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 September 28, 2019. This Internet-Draft will expire on October 2, 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 11, line 30 skipping to change at page 11, line 30
To: <sip:+12155551213@tel.example1.net> To: <sip:+12155551213@tel.example1.net>
From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40 From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155551212@tel.example2.net>, P-Asserted-Identity: "Alice"<sip:+12155551212@tel.example2.net>,
<tel:+12155551212> <tel:+12155551212>
CSeq: 2 INVITE CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
MESSAGE, OPTIONS MESSAGE, OPTIONS
Content-Type: application/sdp Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: sip.608 Feature-Caps: *;+sip.608
Identity: Identity:
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I
joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC
J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI
xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6
IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n
Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC
A;info=<http://cert.example2.net/example.cert>;alg=ES256 A;info=<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153 Content-Length: 153
skipping to change at page 15, line 32 skipping to change at page 15, line 32
] ]
Note that it is up to the UAC to decide which jCard contact modality, Note that it is up to the UAC to decide which jCard contact modality,
if any, it will use. if any, it will use.
4.4. Legacy Interoperability 4.4. Legacy Interoperability
Figure 5 depicts a call flow illustrating legacy interoperability. Figure 5 depicts a call flow illustrating legacy interoperability.
In this non-normative example, we see a UAC that does not support the In this non-normative example, we see a UAC that does not support the
full semantics for 608. However, there is an SBC that does support full semantics for 608. However, there is an SBC that does support
608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the 608. Per RFC6809 [RFC6809], the SBC can insert "*;+sip.608" into the
Feature-Caps header for the INVITE. When the intermediary, labeled Feature-Caps header for the INVITE. When the intermediary, labeled
"Called Party Proxy" in the figure, rejects the call, it knows it can "Called Party Proxy" in the figure, rejects the call, it knows it can
simply perform the processing described in this document. Since the simply perform the processing described in this document. Since the
intermediary saw the sip.608 feature capability, it knows it does not intermediary saw the sip.608 feature capability, it knows it does not
need to send any media describing whom to contact in the event of an need to send any media describing whom to contact in the event of an
erroneous rejection. erroneous rejection.
+---------+ +---------+
| Call | | Call |
|Analytics| |Analytics|
skipping to change at page 16, line 20 skipping to change at page 16, line 20
^ | ^ |
| v | v
+---------+ +---------+
| Called | +-----+ +-----+ +---+ +-----+ +---+ | Called | +-----+ +-----+ +---+ +-----+ +---+
| Party | <---|Proxy| <---|Proxy| <---|SBC| <---|Proxy| <---|UAC| | Party | <---|Proxy| <---|Proxy| <---|SBC| <---|Proxy| <---|UAC|
| Proxy | +-----+ +-----+ +---+ +-----+ +---+ | Proxy | +-----+ +-----+ +---+ +-----+ +---+
+---------+ | | +---------+ | |
| | INVITE | | | INVITE |
| INVITE |<--------------------| | INVITE |<--------------------|
|<-----------------------------------| | |<-----------------------------------| |
| Feature-Caps: sip.608 | | | Feature-Caps: *;+sip.608 | |
| | | | | |
| 608 Rejected | | | 608 Rejected | |
|----------------------------------->| 183 | |----------------------------------->| 183 |
| Call-Info: <...> |-------------------->| | Call-Info: <...> |-------------------->|
| [path for Call-Info elided | SDP for media | | [path for Call-Info elided | SDP for media |
| for illustration purposes] | | | for illustration purposes] | |
| |=== Announcement ===>| | |=== Announcement ===>|
| | | | | |
| | 608 | | | 608 |
| |-------------------->| | |-------------------->|
skipping to change at page 17, line 32 skipping to change at page 17, line 32
5.2. SIP Feature-Capability Indicator 5.2. SIP Feature-Capability Indicator
This document defines the feature capability sip.608 in the "SIP This document defines the feature capability sip.608 in the "SIP
Feature-Capability Indicator Registration Tree" registry defined in Feature-Capability Indicator Registration Tree" registry defined in
[RFC6809]. [RFC6809].
Name: sip.608 Name: sip.608
Description: This feature capability indicator, when included in a Description: This feature capability indicator, when included in a
Feature-Caps header field of an INVITE request, indicates that the Feature-Caps header field of an INVITE request, indicates that the
entity that inserted the sip.608 Feature-Caps value will be entity associated with the indicator will be responsible for
responsible for indicating to the caller any information contained indicating to the caller any information contained in the 608 SIP
in the 608 SIP response code, specifically the value referenced by response code, specifically the value referenced by the Call-Info
the Call-Info header header.
Reference: [RFCXXXX] Reference: [RFCXXXX]
5.3. JSON Web Token Claim 5.3. JSON Web Token Claim
This document defines the new JSON Web Token claim in the "JSON Web This document defines the new JSON Web Token claim in the "JSON Web
Token Claims" sub-registry created by [RFC7519]. Section 3.2.2 Token Claims" sub-registry created by [RFC7519]. Section 3.2.2
defines the syntax. The required information is: defines the syntax. The required information is:
Claim Name: jcard Claim Name: jcard
skipping to change at page 19, line 43 skipping to change at page 19, line 43
7. Acknowledgements 7. Acknowledgements
This document liberally lifts from [RFC8197] in its text and This document liberally lifts from [RFC8197] in its text and
structure. However, the mechanism and purpose of 608 is quite structure. However, the mechanism and purpose of 608 is quite
different than 607. Any errors are the current editor's and not the different than 607. Any errors are the current editor's and not the
editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ
Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on
improving the draft. Tolga's suggestion to provide a mechanism for improving the draft. Tolga's suggestion to provide a mechanism for
legacy interoperability served to expand the draft by 50%. In legacy interoperability served to expand the draft by 50%. In
addition, Tolga came up with the jCard attack. addition, Tolga came up with the jCard attack. Finally, Christer
Holmberg as always provided a close reading and caught a SIP feature
capability bug.
Finally, Bhavik Nagda provided clarifying edits as well and more Finally, Bhavik Nagda provided clarifying edits as well and more
especially wrote and tested an implementation of the 608 response especially wrote and tested an implementation of the 608 response
code in Kamailio. Code is available at <https://github.com/ code in Kamailio. Code is available at <https://github.com/
nagdab/608_Implementation> . nagdab/608_Implementation> .
8. References 8. References
8.1. Normative References 8.1. Normative References
 End of changes. 8 change blocks. 
12 lines changed or deleted 14 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/