RFC 8688

A Session Initiation Protocol (SIP) Response Code for Rejected Calls

📅 published December 2019, from ietf

RFC 8688: A Session Initiation Protocol (SIP) Response Code for Rejected Calls 💖

Okay bestie, this is RFC 8688 🎀 It's a Standards Track document from the IETF, and it's a total slay. E.W. Burger (Georgetown University) and B. Nagda (Massachusetts Institute of Technology) wrote it, and it was published in December 2019. Here's the quick rundown:

  • Category: Standards Track
  • Date: December 2019
  • ISSN: 2070-1721
  • Authors: E.W. Burger (Georgetown University) and B. Nagda (Massachusetts Institute of Technology)
  • Obsoletes / Updates: The title block doesn't say this one obsoletes or updates anything 🙈

Abstract ✨

Okay so the big idea is that this doc defines the 608 (Rejected) SIP response code 🦋 It lets the calling party find out that an intermediary rejected their call attempt, which means nobody gets to deliver the call or answer it. Lowkey devastating, but also super useful.

Since it's a 6xx code, the caller also knows that trying to reach the same User Agent Server again will probably fail. 💀

The first use case is when the intermediary is an analytics engine. In that case the rejection comes from a machine or some other process, not a person. This is different from the 607 (Unwanted) SIP response code, where a human at the target User Agent Server is the one saying the user didn't want the call. In some jurisdictions, that difference really matters 👑

The doc also defines how to use the Call-Info header field in 608 responses. That way, callers who got rejected can reach the entities that blocked their calls by mistake. It's basically a fix-it button for legit callers whose calls got blocked 🫶

Status of This Memo 🌸

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚

You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8688 💜

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document.

If you pull Code Components out of this document, they have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come without warranty, as described in the Simplified BSD License 🍓

Table of Contents 📑

   1.  Introduction
   2.  Terminology
   3.  Protocol Operation
     3.1.  Intermediary Operation
     3.2.  JWS Construction
       3.2.1.  JOSE Header
       3.2.2.  JWT Payload
       3.2.3.  JWS Signature
     3.3.  UAC Operation
     3.4.  Legacy Interoperation
     3.5.  Announcement Requirements
   4.  Examples
     4.1.  Full Exchange
     4.2.  Web Site jCard
     4.3.  Multi-modal jCard
     4.4.  Legacy Interoperability
   5.  IANA Considerations
     5.1.  SIP Response Code
     5.2.  SIP Feature-Capability Indicator
     5.3.  JSON Web Token Claim
     5.4.  Call-Info Purpose
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

okay so the IETF has been dealing with a LOT when it comes to unwanted and, depending on where you live, illegal calls 📞 [RFC5039]. Secure Telephone Identity Revisited (STIR) [RFC7340] and Signature-based Handling of Asserted information using toKENs (SHAKEN) [SHAKEN] handle the cryptographic signing and attestation, respectively, of signaling. That's how they keep the integrity and authenticity of the asserted caller identity locked in 🔐

This doc describes a new Session Initiation Protocol (SIP) [RFC3261] response code, 608, which lets calling parties learn that an intermediary rejected their call. We need a separate indicator to tell apart a user rejection and an intermediary's rejection of a call, and it's giving very important energy 💅 In some jurisdictions, service providers may not be permitted to block calls, even if the user doesn't want them, unless there is an explicit user request. Plus, users may misidentify the nature of a caller 🙈

Picture this: a legit caller phones a user who finds the call unwanted. Instead of marking it as unwanted, though, the user marks it as illegal. Now an analytics engine might decide to block all calls from that source. But in some jurisdictions, blocking calls from that source for other users may not be legal 😬 Likewise, one can imagine jurisdictions that let an operator block such calls, but only if there is a remediation mechanism in place to address false positives 🫶

Some call-blocking services may return responses such as 604 (Does Not Exist Anywhere). The idea might be to get a destination's address removed from a calling database. The problem is that other network elements might also read this to mean the user truly does not exist, which could mean the user can't receive calls from anyone, even the people they actually want to hear from 💀 In many jurisdictions, providing this kind of false signaling is also illegal.

The 608 response code is built to fix this exact problem of remediating falsely blocked calls 🎀 Specifically, this code tells the SIP User Agent Client (UAC) that an intermediary blocked the call, and it provides a redress mechanism that lets callers contact the operator of the intermediary. Main character energy for the caller who got wrongly blocked 👑

In the current call handling ecosystem, users can explicitly reject a call or later mark a call as unwanted by sending a 607 SIP response code (Unwanted) [RFC8197]. Figures 1 and 2 show how the 607 response code works. The User Agent Server (UAS) indicates the call was unwanted. As [RFC8197] explains, the called party doesn't just want to reject that one call. They can also let their proxy know that they consider future calls from that source unwanted 📵 Once the proxy gets the 607 response from the UAS, it may send unwanted call indicators, such as the value of the From header field and other information elements, to a call analytics engine. For various reasons described in [RFC8197], if a network operator gets multiple reports of unwanted calls, that may mean the entity placing the calls is likely a source of unwanted calls for many people. So other customers of the service provider may want the service provider to automatically reject calls on their behalf 🙅‍♀️

The 607 rejection code has another perk too ✨ Presuming the proxy forwards the response code to the UAC, the calling UAC or any intervening proxies will also learn that the user is not interested in receiving calls from that sender.

                               +-----------+
                               |   Call    |
                               | Analytics |
                               |  Engine   |
                               +-----------+
                                  ^     | (likely not SIP)
                                  |     v
                               +-----------+
            +-----+    607     |  Called   |    607    +-----+
            | UAC | <--------- |  Party    | <-------- | UAS |
            +-----+            |  Proxy    |           +-----+
                               +-----------+

                     Figure 1: Unwanted (607) Call Flow

For calls rejected with a 607 from a legit caller, getting a 607 response code can tell the caller to stop trying to call the user 🛑 And if a legit caller thinks the user is rejecting their calls by mistake, they can use other channels to reach the user. For example, say a pharmacy calls to let a user know their prescription is ready for pickup, and the user accidentally thinks the call is unwanted and sends a 607 response code. The pharmacy already has a relationship with the customer, so it can send the user an email or push a note to the pharmacist asking the customer to consider not rejecting their calls in the future 💊

A lot of systems that let the user mark a call unwanted (e.g., with the 607 response code) also let the user change their mind and unmark those calls 🔄 This mechanism is relatively easy to implement because the user usually has a direct relationship with the service provider that is doing the blocking.

BUT things get messier if an intermediary is involved, like a third-party provider of call management services that classifies calls based on the relative likelihood that the call is unwanted and misidentifies a call as unwanted 😭 Figure 3 shows this case. Note that the UAS typically does not receive an INVITE, since the called party proxy rejects the call on behalf of the user. In this situation, it would be really helpful for the caller to learn who rejected the call so they can correct the misidentification 🙏

                         +--------+         +-----------+
                         | Called |         |   Call    |
        +-----+          | Party  |         | Analytics |   +-----+
        | UAC |          | Proxy  |         |  Engine   |   | UAS |
        +-----+          +--------+         +-----------+   +-----+
           |  INVITE         |                    |            |
           | --------------> |  Is call OK?       |            |
           |                 |------------------->|            |
           |                 |                    |            |
           |                 |               Yes  |            |
           |                 |<-------------------|            |
           |                 |                    |            |
           |                 | INVITE             |            |
           |                 | ------------------------------> |
           |                 |                    |            |
           |                 |                    |       607  |
           |                 | <------------------------------ |
           |                 |                    |            |
           |                 |  Unwanted call     |            |
           |            607  | -----------------> |            |
           | <-------------- |  indicators        |            |
           |                 |                    |            |

                  Figure 2: Unwanted (607) Ladder Diagram
                                 +-----------+
                                 |   Call    |
                                 | Analytics |
                                 |  Engine   |
                                 +-----------+
                                    ^     | (likely not SIP)
                                    |     v
                                 +-----------+
              +-----+    608     |  Called   |           +-----+
              | UAC | <--------- |  Party    |           | UAS |
              +-----+            |  Proxy    |           +-----+
                                 +-----------+

                     Figure 3: Rejected (608) Call Flow

So in this situation, someone might think about having the intermediary use the 607 response code. But 607 tells the caller that the subscriber does not want the call, and [RFC8197] specifies that one of the uses of 607 is to inform analytics engines that a user (human) has rejected a call 🤔 The problem is that network elements downstream from the intermediary might read the 607 as coming from a human who marked the call as unwanted, when it actually came from an algorithm using statistics or machine learning to reject the call. An algorithm can be vulnerable to the base-rate fallacy [BaseRate] when rejecting the call. In other words, those downstream entities should not rely on another entity "deciding" the call is unwanted 🧠 By telling apart a (human) user rejection from an intermediary engine's statistical rejection, a downstream network element that sees a 607 response code can weigh it as a human rejection in its call analytics. Otherwise, it can decide whether to consider a 608 at all and, if so, weigh it appropriately ⚖️

Having a redress mechanism is really useful for blocked callers 💖 One can imagine that some jurisdictions will require it. However, we have to keep in mind that most of the calls intermediaries block will, in fact, be illegal and eligible for blocking. So providing alternate contact information for a user would be counterproductive to protecting that user from illegal communications 🚫 This is another reason we don't propose simply allowing alternate contact information in a 607 response message.

Why don't we just use the same mechanism an analytics service provider offers its customers? Like, why not have the analytics service provider let the called party correct a call blocked in error? The reason is that while there is an existing relationship between the customer (called party) and the analytics service provider, it's unlikely there is a relationship between the caller and the analytics service provider. Plus, there are numerous call blocking providers in the ecosystem 🌈 So we need a mechanism for indicating that an intermediary rejected a call that also provides contact information for the operator of that intermediary, without exposing the target user's contact information.

The protocol in this document uses existing SIP protocol mechanisms for specifying the redress mechanism. In the Call-Info header field passed back to the UAC, we send additional information specifying a redress address 📬 We choose to encode the redress address using jCard [RFC7095]. As we'll see later in this document, this information needs its own application-layer integrity protection. That's why we use jCard rather than vCard [RFC6350]. We have a marshaling mechanism for creating a JavaScript Object Notation (JSON) [RFC8259] object, such as a jCard, and a standard integrity format for such an object, namely, JSON Web Signature (JWS) [RFC7515]. The SIP community is already familiar with this concept, since it's the mechanism used by STIR [RFC8224] 🦋

Integrity protecting the jCard with a cryptographic signature might seem unnecessary at first, but it is essential to preventing potential network attacks 🚨 Section 6 describes the attack and why we sign the jCard in more detail.

2. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖✨

3. Protocol Operation ✨

okay so bestie, in this section "intermediary" means the entity that acts as a SIP UAS for the user, sitting in the network instead of on the user's own UAS (usually their phone, but not always 📱). It could be a back-to-back user agent (B2BUA) or a SIP Proxy. 💅

Figure 4 shows the call flow for a rejected call 🦋

                     +--------+         +-----------+
                     | Called |         |   Call    |
    +-----+          | Party  |         | Analytics |   +-----+
    | UAC |          | Proxy  |         |  Engine   |   | UAS |
    +-----+          +--------+         +-----------+   +-----+
       |  INVITE         |                    |            |
       | --------------> |  Is call OK?       |            |
       |                 |------------------->|            |
       |                 |                    |            |
       |                 |               Yes  |            |
       |                 |<-------------------|            |
       |                 |                    |            |
       |                 | INVITE             |            |
       |                 | ------------------------------> |
       |                 |                    |            |
       |                 |                    |       607  |
       |                 | <------------------------------ |
       |                 |                    |            |
       |                 |  Unwanted call     |            |
       |            607  | -----------------> |            |
       | <-------------- |  indicators        |            |
       |                 |                    |            |

Figure 4: Rejected (608) Ladder Diagram

3.1. Intermediary Operation

an intermediary MAY issue the 608 response code in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP [RFC3261] request, basically saying the user didn't want this communication. 🙅‍♀️ An intermediary MAY also issue the 608 as the value of the cause parameter of a SIP reason-value in a Reason header field [RFC3326].

Wait, I need to keep the MAY in caps exactly where it applies, so I'll rewrite that line with the key words in caps:

An intermediary MAY issue the 608 response code in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP [RFC3261] request, basically saying the user didn't want this communication. 🙅‍♀️ An intermediary MAY also issue the 608 as the value of the cause parameter of a SIP reason-value in a Reason header field [RFC3326].

If an intermediary issues a 608 code and there are no indicators the calling party will use the contents of the Call-Info header field for malicious purposes (see Section 6), the intermediary MUST include a Call-Info header field in the response. 🫶

If there is a Call-Info header field, it MUST have the "purpose" parameter of "jwscard". The value of the Call-Info header field MUST refer to a valid JSON Web Signature (JWS) [RFC7515] encoding of a jCard [RFC7095] object. The next section explains how the JWS gets built. 🧚

Proxies need to be mindful that a downstream intermediary may reject 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] apply. Specifically, the proxy should cancel pending transactions and must not create any new branches. Note this is not a new requirement but simply pointing out the existing 6xx protocol mechanism in SIP. 🌸

3.2. JWS Construction

The intermediary builds the JWS of the jCard like this. 🎀

3.2.1. JOSE Header

The Javascript Object Signing and Encryption (JOSE) header MUST include the typ, alg, and x5u parameters from JWS [RFC7515]. The typ parameter MUST have the value "vcard+json". Implementations MUST support ES256 as JSON Web Algorithms (JWA) [RFC7518] defines it and MAY support other registered signature algorithms. Finally, the x5u parameter MUST be a URI that resolves to the public key certificate corresponding to the key used to digitally sign the JWS. 🔑

3.2.2. JWT Payload

The payload contains two JSON values. The first JSON Web Token (JWT) claim that MUST be present is the "iat" (issued at) claim [RFC7519]. The "iat" MUST be set to the date and time of the issuance of the 608 response. This mandatory component protects the response from replay attacks. 🛡️

The second JWT claim that MUST be present is the "jcard" claim. The value of the jcard [RFC7095] claim is a JSON array conforming to the JSON jCard data format defined in [RFC7095]. Section 5.3 describes the registration. In the construction of the jcard claim, the "jcard" MUST include at least one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this specification MUST be prepared to receive a full jCard. Call originators (at the UAC) can use the information returned by the jCard to contact the intermediary that rejected the call to appeal the intermediary's blocking of the call attempt. What the intermediary does if the blocked caller contacts the intermediary is outside the scope of this document. 📞

3.2.3. JWS Signature

JWS [RFC7515] specifies the procedure for calculating the signature over the jCard JWT. Section 4 of this document has a detailed example on constructing the JWS, including the signature. ✍️

3.3. UAC Operation

A UAC conforming to this specification MUST include the sip.608 feature-capability indicator in the Feature-Caps header field of the INVITE request. 💖

Upon receiving a 608 response, UACs perform normal SIP processing for 6xx responses. 👀

As for the disposition of the jCard itself, the UAC MUST check the "iat" claim in the JWT. As noted in Section 3.2.2, we are concerned about replay attacks. Therefore, the UAC MUST reject jCards that come with an expired "iat". The definition of "expired" is a matter of local policy. A reasonable value would be on the order of a minute due to clock drift and the possibility of the playing of an audio announcement before the delivery of the 608 response. ⏰

3.4. Legacy Interoperation

If the UAC indicates support for 608 and the intermediary issues a 608, life is good, as the UAC will receive all the information it needs to remediate an erroneous block by an intermediary. ✨ However, what if the UAC does not understand 608? For example, how can we support callers from a legacy, non-SIP, public-switched network connecting to the SIP network via a media gateway? 🤔

We address this situation by having the first network element that conforms with this specification play an announcement. See Section 3.5 for requirements on the announcement. The simple rule is a network element that inserts the sip.608 feature capability MUST be able to convey at a minimum how to contact the operator of the intermediary that rejected the call attempt. 📣

The degenerate case is the intermediary is the only element that understands the semantics of the 608 response code. Obviously, any 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 the meaning of the value of the Call-Info header field. The intermediary knows this is the case as the INVITE request will not have the sip.608 feature capability. In this case, one can consider the intermediary to be the element "inserting" a virtual sip.608 feature capability. If the caveats described in Sections 3.5 and 6 do not hold, the intermediary MUST play the announcement. 🎭

Now we take the case where a network element that understands the 608 response code receives an INVITE for further processing. A network element conforming with this specification MUST insert the sip.608 feature capability per the behaviors described in Section 4.2 of [RFC6809]. 🌈

Do note that even if a network element plays an announcement describing the contents of the 608 response message, the network element MUST forward the 608 response code message as the final response to the INVITE. 🙌

One aspect of using a feature capability is that only the network elements that will either consume (UAC) or play an announcement (media gateway, session border controller (SBC) [RFC7092], or proxy) need to understand the sip.608 feature capability. If the other network elements conform to Section 16.6 of [RFC3261], they will pass header fields such as Feature-Caps: *;+sip.608 unmodified and without need for upgrade. 🔁

Because the ultimate disposition of the call attempt will be a 600-class response, the network element conveying the announcement in the legacy direction MUST use the 183 Session Progress response to establish the media session. Because of the small chance the UAC is an extremely old legacy device and is using UDP, the UAC MUST include support for 100rel [RFC3262] in its INVITE, the network element conveying the announcement MUST Require 100rel in the 183, and the UAC MUST issue a Provisional Response ACKnowledgement (PRACK) to which the network element MUST respond 200 OK PRACK. 🥹

3.5. Announcement Requirements

There are a few requirements on the element that handles the announcement for legacy interoperation. 📋

As noted above, the element that inserts the sip.608 feature capability is responsible for conveying the information referenced by the Call-Info header field in the 608 response message. However, this specification does not mandate how to convey that information. 🤷‍♀️

Let us take the case where a telecommunications service provider controls the element inserting the sip.608 feature capability. It would be reasonable to expect the service provider would play an announcement in the media path towards the UAC (caller). It is important to note the network element should be mindful of the media type requested by the UAC as it formulates the announcement. For example, it would make sense for an INVITE that only indicated audio codecs in the Session Description Protocol (SDP) [RFC4566] to result in an audio announcement. Likewise, if the INVITE only indicated real-time text [RFC4103] and the network element can render the information in the requested media format, the network element should send the information in a text format. 🔊

It is also possible for the network element inserting the sip.608 feature capability to be under the control of the same entity that controls the UAC. For example, a large call center might have legacy UACs, but have a modern outbound calling proxy that understands the full semantics of the 608 response code. In this case, it is enough for the outbound calling proxy to digest the Call-Info information and handle the information digitally rather than "transcoding" the Call-Info information for presentation to the caller. 🏢

4. Examples 🍓

These examples are not normative, do not include all protocol elements, and may have errors. Review the protocol documents for actual syntax and semantics of the protocol elements. 📖

4.1. Full Exchange 💖

okay bestie, let's do the full exchange 💅 Here's an INVITE, shamelessly borrowed from [SHAKEN] (the line breaks in the Identity header field are just there so it's easier to read) ✨

INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69
Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f3>
To: <sip:+12155550113@tel.one.example.net>
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>,
    <tel:+12155550112>
CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
    MESSAGE, OPTIONS
Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: *;+sip.608
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0Ijoic2hha2V
uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ
hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx
Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN
DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU
tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info=
<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153

v=0
o=- 13103070023943130 1 IN IP6 2001:db8::177
c=IN IP6 2001:db8::177
t=0 0
m=audio 54242 RTP/AVP 0
a=sendrecv

Now an intermediary could reply like this 🦋

SIP/2.0 608 Rejected
Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
To: <sip:+12155550113@tel.one.example.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE
Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard

The location https://block.example.net/complaint-jws resolves to a JWS. One would construct the JWS as follows 🌸

The JWS header of this example jCard could be:

{ "alg":"ES256",
  "typ":"vcard+json",
  "x5u":"https://certs.example.net/reject_key.cer"
}

Now, let us construct a minimal jCard 🎀 For this example, the jCard refers the caller to an email address, remediation@blocker.example.net:

["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["email", {"type":"work"}, "text",
     "remediation@blocker.example.net"]
  ]
]

With this jCard, we can now construct the JWT 🧚

{
  "iat":1546008698,
  "jcard":["vcard",
    [
      ["version", {}, "text", "4.0"],
      ["fn", {}, "text", "Robocall Adjudication"],
      ["email", {"type":"work"},
       "text", "remediation@blocker.example.net"]
    ]
  ]
}

Okay, this is the part where it gets important 😭 To calculate the signature, we need to encode the JSON Object Signing and Encryption (JOSE) header and JWT into base64url. As an implementation note, you can trim whitespace in the JSON objects to save a few bytes. UACs MUST be prepared to receive pretty-printed, compact, or bizarrely formatted JSON. For the purposes of this example, we leave the objects with pretty whitespace. Speaking of pretty vs. machine formatting, these examples have line breaks in the base64url encodings so they're easy to publish in the RFC format. The specification of base64url allows for these line breaks, and the decoded text works just fine. However, those extra line-break octets would affect the calculation of the signature. Implementations MUST NOT insert line breaks into the base64url encodings of the JOSE header or JWT. This also means UACs MUST be prepared to receive arbitrarily long octet streams from the URI referenced by the Call-Info header field. 🫶

base64url of JOSE header:

eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=

base64url of JWT:

eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19

In this case, the object to sign (remember this is just a single long line; the line breaks are for ease of review and do not appear in the actual object) is as follows 🍓

eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19

We use the following X.509 PKCS #8-encoded Elliptic Curve Digital Signature Algorithm (ECDSA) key, also shamelessly taken from [SHAKEN], as an example key for signing the hash of the above text. Do not use this key in real life! 🙈 It is for example purposes only. At the very least, we would strongly recommend encrypting the key at rest.

-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY-----

The resulting JWS, using the above key on the above object, renders the following ECDSA P-256 SHA-256 digital signature ✨

7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag

Thus, the JWS stored at https://blocker.example.net/complaints-jws would contain:

eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag

4.2. Web Site jCard 🌈

For an intermediary that provides a Web site for adjudication, the jCard could contain the following. Note that we do not show the calculation of the JWS; the URI reference in the Call-Info header field would be to the JWS of the signed jCard 💜

["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["url", {"type":"work"},
     "text", "https://blocker.example.net/adjudication-form"]
  ]
]

4.3. Multi-modal jCard ⭐

For an intermediary that provides a telephone number and a postal address, the jCard could contain the following. Note that we do not show the calculation of the JWS; the URI reference in the Call-Info header field would be to the JWS of the signed jCard 🦋

["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["adr", {"type":"work"}, "text",
      ["Argument Clinic",
       "12 Main St","Anytown","AP","000000","Somecountry"]
    ]
    ["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"]
  ]
]

Note that it is up to the UAC to decide which jCard contact modality, if any, it will use 🎀

4.4. Legacy Interoperability 🎀

Okay so, bestie, Figure 5 shows a call flow for legacy interop 🦋. This one is non-normative, so it's more of a vibe check than a rule. We've got a UAC that doesn't fully get the 608 semantics, BUT there's an SBC that does 👑. Per [RFC6809], the SBC can slap "*;+sip.608" into the Feature-Caps header field of the INVITE. Then when the intermediary (the "Called Party Proxy" in the figure) rejects the call, it knows it can just do the processing this document describes ✨. Since it saw the sip.608 feature capability, it knows it doesn't have to send any media saying who to contact in case of an erroneous rejection. Iconic restraint 💅.

The generic SIP Proxies in the figure are just there for illustration. Whether they're present, absent, or how many there are doesn't change how the protocol works 🧚. They're in the picture to show that proxies who don't understand the sip.608 feature capability can still be part of a network that offers 608 services 🌸.

                                                           +---------+
                                                           |  Call   |
                                                           |Analytics|
                                                           | Engine  |
                                                           +--+--+---+
                                                              ^  |
                                                              |  |
                                                              |  v
                                                            +-+--+-+
         +---+    +-----+    +---+    +-----+    +-----+    |Called|
         |UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party |
         +---+    +-----+    +---+    +-----+    +-----+    |Proxy |
           |                   |                            +------+
           | INVITE            |                               |
           |------------------>|                               |
           |                   | INVITE                        |
           |                   |------------------------------>|
           |                   | Feature-Caps: *;+sip.608      |
           |                   |                               |
           |                   |                  608 Rejected |
           |                   |<------------------------------|
           |               183 |              Call-Info: <...> |
           |<------------------|    [path for Call-Info elided |
           |     SDP for media |     for illustration purposes]|
           |                   |                               |
           | PRACK             |                               |
           |------------------>|                               |
           |                   |                               |
           |      200 OK PRACK |                               |
           |<------------------|                               |
           |                   |                               |
           |<== Announcement ==|                               |
           |                   |                               |
           |      608 Rejected |                               |
           |<------------------|                               |
           |  Call-Info: <...> |                               |
           |                   |                               |

                         Figure 5: Legacy Operation

Okay, plot twist 😭. When the SBC gets the 608 response code, it matches it up with the original INVITE from the UAC. The SBC remembers that it was the one who inserted the sip.608 feature capability, which means it's on the hook for somehow alerting the UAC that the call failed and sharing whom to contact 💀. At this point the SBC can play a prompt, either natively or through a mechanism like NETANN [RFC4240], that sends the relevant info in the right media to the UAC 🎧. This could be a long transaction, and the UAC might be using an unreliable transport protocol, so the UAC will have indicated support for provisional responses, the SBC will indicate it requires a PRACK from the UAC in the 183 response, the UAC will send the PRACK, and the SBC will acknowledge the PRACK before playing the announcement 🫶.

As an example, the SBC could pull the FN and TEL jCard fields and play something like a special information tone (see Section 6.21.2.1 of Telcordia [SR-2275] or Section 7 of ITU-T E.180 [ITU.E.180.1998]), followed by "Your call has been rejected by...", followed by a text-to-speech translation of the FN text, followed by "You can reach them on...", followed by a text-to-speech translation of the telephone number in the TEL field 📞✨.

Note that the SBC still sends the full 608 response code, including the Call-Info header field, towards the UAC. Nothing gets dropped, it's giving thorough 🙈.

5. IANA Considerations 🌈

5.1. SIP Response Code 💖

This document defines a new SIP response code, 608, in the "Response Codes" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry defined in [RFC3261].

   Response code:    608
   Description:      Rejected
   Reference:        RFC 8688

5.2. SIP Feature-Capability Indicator 🦋

This document defines the feature capability, sip.608, in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809].

   Name:         sip.608
   Description:  This feature-capability indicator, when included in a
                 Feature-Caps header field of an INVITE request,
                 indicates that the entity associated with the indicator
                 will be responsible for indicating to the caller any
                 information contained in the 608 SIP response code,
                 specifically, the value referenced by the Call-Info
                 header field.
   Reference:    RFC 8688

5.3. JSON Web Token Claim 🧚

This document defines the new JSON Web Token claim in the "JSON Web Token Claims" subregistry created by [RFC7519]. Section 3.2.2 defines the syntax. The required information is:

   Claim Name:         jcard
   Claim Description:  jCard data
   Change Controller:  IESG
   Reference:          RFC 8688, [RFC7095]

5.4. Call-Info Purpose 🍓

This document defines the new predefined value "jwscard" for the "purpose" header field parameter of the Call-Info header field. This modifies the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry by adding this RFC as a reference to the line for the header field "Call-Info" and parameter name "purpose":

   Header Field:       Call-Info
   Parameter Name:     purpose
   Predefined Values:  Yes
   Reference:          RFC 8688

6. Security Considerations 🔐

okay bestie, this is the serious section, so put the iced coffee down 💀. Intermediary operators have to be super mindful about who they're sending the 608 response to 🫶. The intermediary could be rejecting a truly malicious caller, and that creates two issues. The first is that the caller, now alerted that an intermediary is automatically rejecting their call attempts, may change how they call to defeat call-blocking systems 🙈. The second, and way more significant, risk is that by putting a contact in the Call-Info header field, the intermediary may be handing the malicious caller an attack vector 😭. In other words, the intermediary would be publishing an address that a malicious actor could use to launch an attack on the intermediary itself. Because of this, intermediary operators may wish to configure their response to only include a Call-Info header field for INVITE, or other signed initiating methods, that pass validation by STIR [RFC8224] 🦋.

Another risk is giving an attacker the keys to the amplification party 🎀. Picture an attacker flooding a proxy that supports the sip.608 feature. The SDP in the INVITE request refers to a victim device. The attacker also somehow knows there's a 608-aware gateway connecting to the victim, sitting on a segment that lacks the sip.608 feature capability. Because the mechanism described here can end up sending an audio file to the target of the SDP, an attacker could use it as an amplification attack, since a SIP INVITE can be under 1 kilobyte and an audio file can be hundreds of kilobytes 💀. One remediation is for devices that insert a sip.608 feature capability to only transmit media to what is highly likely to be the actual source of the call attempt ✨. One way to do that is to only play media in response to a STIR-signed INVITE that passes validation. On top of requiring a valid STIR signature on the INVITE, the intermediary can also use remediation procedures like the connectivity checks specified by Interactive Connectivity Establishment [RFC8445]. If the target didn't request the media, the check will fail 🙅‍♀️.

Yet another risk is a malicious intermediary generating a malicious 608 response with a jCard that refers to a malicious agent 😈. For example, the recipient of a 608 may receive a TEL URI in the vCard. When the recipient calls that address, the malicious agent could ask for personally identifying information. Instead of using that info to verify the recipient's identity, they're phishing it for nefarious ends 🚩. A similar scenario can unfold if the malicious agent inserts a URI that points to a phishing or other site. So we strongly recommend that the recipient validates who they're communicating with if they're asking to adjudicate an erroneously rejected call attempt 🫡. Since we may also be concerned about intermediate nodes modifying contact information, we can address both issues with a single solution: the intermediary is required to sign the jCard 💜. Signing the jCard provides integrity protection. Beyond that, one can imagine mechanisms like the ones used by [SHAKEN] 🔏.

Similarly, one can imagine an adverse agent that maliciously spoofs a 608 response with a victim's contact address, sending it to many active callers, who then all send redress requests to that address. That's the basis for a denial-of-service attack 😵. The process would go like this: (1) a malicious agent senses INVITE requests from a variety of UACs, and (2) spoofs 608 responses with an unsigned redress address before the intended receivers can respond, which causes (3) the UACs to all contact the redress address at once. The jCard encoding lets the UAC verify the blocking intermediary's identity before contacting the redress address 🌸. Specifically, because the sender signs the jCard, we can cryptographically trace who the sender is. With the protocol machinery of having a signature, one can apply local policy to decide whether to believe that the sender of the jCard represents the owner of the contact information in it. This guards against a malicious agent spoofing 608 responses 👑.

Specifically, one could use policies around signing certificate issuance as a mechanism for traceback to the entity that issued the jCard 🕵️‍♀️. One check could be verifying that the identity of the subject of the certificate relates to the To header field of the initial SIP request, similar to validating that the intermediary was vouching for the From header field of a SIP request with that identity. Note that we're only protecting against a malicious intermediary, not a hidden intermediary attack (formerly known as a "man-in-the-middle attack") 🧚. So we only need to make sure the signature is fresh, which is exactly why we include iat ⏰. For most implementations, we assume the intermediary has a single set of contact points and generates the jCard on demand. As such, there's no need to directly correlate HTTPS fetches to specific calls. However, since the intermediary is in control of the jCard and the Call-Info response, an intermediary may choose to encode per-call information in the URI returned in a given 608 response. If the intermediary does go that route, though, it MUST use a non-deterministic URI reference mechanism 🔒. It also has to be prepared to return dummy responses to URI requests that reference calls that don't exist, so attackers trying to glean call metadata by guessing URIs (and thus calls) won't get any actionable information from the HTTPS GET 🙃.

Since the decision of whether to include Call-Info in the 608 response is a matter of policy, one thing to consider is whether a legitimate caller can figure out whom to contact without that information in the 608 🧐. For example, in some jurisdictions, if only the terminating service provider can be the intermediary, the caller can look up who the terminating service provider is based on the routing information for the dialed number. So the Call-Info jCard could be redundant info 🤷‍♀️. However, the factors that go into a particular service provider's or jurisdiction's choice of whether to include Call-Info are outside the scope of this document 💅.

7. References 📚

7.1. Normative References

7.2. Informative References 📚

okay bestie, these are the "for more context" sources, the ones that aren't required reading but explain where the ideas came from 🧠✨

Acknowledgements 🫶

this doc totally borrows from [RFC8197] in its wording and structure, no shame 💅 but the mechanism and purpose of 608 is actually super different from 607, so any mistakes are the current editor's and NOT the editor of RFC 8197 🙈 huge thanks to Ken Carlberg of the FCC, Russ Housley, Paul Kyzivat, and Tolga Asveren for their suggestions 💖 Tolga's idea for a legacy interoperability mechanism literally grew the document by 50%, and he also came up with the jCard attack 😭🔥 Christer Holmberg, as always, did a close read and fixed a SIP feature-capability bug that Yehoshua Gev found 👑

we also have to shout out our iconic Area Director, Adam Roach, who sent five pages of comments 💀🫶 and we got great feedback during IETF Last Call and JWT review from Ines Robles, Mike Jones, and Brian Campbell 🦋 plus IESG review from Alissa Cooper, Eric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and, with the most glee, Warren Kumari 🌈

last but not least, Bhavik Nagda did clarifying edits and, more importantly, wrote and tested an implementation of the 608 response code in Kamailio 🧚 the code lives at https://github.com/nagdab/608_Implementation ✨ and Grace Chuan from MIT regenerated and verified the JWT while working at the FCC 🎀

Authors' Addresses 🌸

Eric W. Burger
Georgetown University
37th & O St, NW
Washington, DC 20057
United States of America

Email: eburger@standardstrack.com


Bhavik Nagda
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139
United States of America

Email: nagdab@gmail.com
📦 where this page comes from