rfc-xmldiff draft-ietf-sipcore-rejected-09-LB.v2v3.original.xml draft-ietf-sipcore-rejected-09-LB.v2v3.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3262 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3262.xml">
<!ENTITY RFC3326 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml">
<!ENTITY RFC4103 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4103.xml">
<!ENTITY RFC4240 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4240.xml">
<!ENTITY RFC4566 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC5039 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5039.xml">
<!ENTITY RFC6350 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml">
<!ENTITY RFC6809 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6809.xml">
<!ENTITY RFC7092 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
<!ENTITY RFC7095 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml">
<!ENTITY RFC7340 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml">
<!ENTITY RFC7515 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
<!ENTITY RFC7518 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
<!ENTITY RFC7519 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8197 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8197.xml">
<!ENTITY RFC8224 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml">
<!ENTITY RFC8259 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
<!ENTITY RFC8445 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-sipcore-rejected-09" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.23.1 -->
  <front>
    <title abbrev="SIP Response Code for Rejected Calls">A Session Initiation
    Protocol (SIP) Response Code for Rejected Calls</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-sipcore-rejected-09"/>
    <author fullname="Eric W. Burger" initials="E.W." surname="Burger">
      <organization>Georgetown University</organization>
      <address>
        <postal>
          <street>37th &amp; O St, NW</street>
          <city>Washington</city>
          <region>DC</region>
          <code>20057</code>
          <country>USA</country>
        </postal>
        <email>eburger@standardstrack.com</email>
      </address>
    </author>
    <author fullname="Bhavik Nagda" initials="B." surname="Nagda">
      <organization>Massachusetts Institute of Technology</organization>
      <address>
        <postal>
          <street>77 Massachusetts Avenue</street>
          <city>Cambridge</city>
          <region>MA</region>
          <code>02139</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>nagdab@gmail.com</email>
        <uri/>
      </address>
    </author>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->
    <date day="28" month="June" year="2019"/>
    <!-- Meta-data Declarations -->
    <area>RAI</area>
    <workgroup>SIPCORE</workgroup>
    <keyword>STIR</keyword>
    <keyword>SIPCORE</keyword>
    <keyword>IANA</keyword>
    <abstract>
      <t>This document defines the 608 (Rejected) SIP response code. This
      response code enables calling parties to learn that an intermediary
      rejected their call attempt. No one will deliver, and thus no one will
      answer, the call. As a 6xx code, the caller will be aware that future
      attempts to contact the same User Agent Server will likely fail. The
      initial use case driving the need for the 608 response code is when the
      intermediary is an analytics engine. In this case, the rejection is by a
      machine or other process. This contrasts with the 607 (Unwanted) SIP
      response code, which a human at the target User Agent Server indicated
      the user did not want the call. In some jurisdictions this distinction
      is important. This document also defines the use of the Call-Info header
      field in 608 responses to enable rejected callers to contact entities
      that blocked their calls in error. This provides a remediation mechanism
      for legal callers that find their calls blocked.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>The IETF has been addressing numerous issues surrounding how to
      handle unwanted and, depending on the jurisdiction, illegal calls <xref target="RFC5039" format="default"/>. <xref target="RFC7340" format="default">STIR</xref> and <xref target="SHAKEN" format="default">SHAKEN</xref> address the cryptographic signing and
      attestation, respectively, of signaling to ensure the integrity and
      authenticity of the asserted caller identity.</t>
      <t>This document describes a new <xref target="RFC3261" format="default">Session
      Initiation Protocol (SIP)</xref> response code, 608, which allows
      calling parties to learn that an intermediary rejected their call. As
      described below, we need a distinct indicator to differentiate between a
      user rejection and an intermediary's rejection of a call. In some
      jurisdictions, service providers may not be permitted to block calls,
      even if unwanted by the user, unless there is an explicit user request.
      Moreover, users may misidentify the nature of a caller.</t>
      <t>For example, a legitimate caller may call a user who finds the call
      to be unwanted. However, instead of marking the call as unwanted, the
      user may mark the call as illegal. With that information, an analytics
      engine may determine to block all calls from that source. However, in
      some jurisdictions blocking calls from that source for other users may
      not be legal. Likewise, one can envision jurisdictions that allow an
      operator to block such calls, but only if there is a remediation
      mechanism in place to address false positives.</t>
      <t>Some call blocking services may return responses such as 604 (Does
      Not Exist Anywhere). This might be a strategy to try to get a
      destination's address removed from a calling database. However, other
      network elements might also interpret this to mean the user truly does
      not exist, which might result in the user not being able to receive
      calls from anyone, even if they wanted to receive the calls. In many
      jurisdictions, providing such false signaling is also illegal.</t>
      <t>The 608 response code addresses this need of remediating falsely
      blocked calls. Specifically, this code informs the SIP User Agent Client
      (UAC) that an intermediary blocked the call and provides a redress
      mechanism that allows callers to contact the operator of the
      intermediary.</t>
      <t>In the current call handling ecosystem, users can explicitly reject a
      call or later mark a call as being unwanted by issuing a <xref target="RFC8197" format="default">607 SIP response code (Unwanted)</xref>. <xref target="uas_reject" format="default"/> and <xref target="reject_ladder" format="default"/> show the
      operation of the 607 SIP response code. The User Agent Server (UAS)
      indicates the call was unwanted. As <xref target="RFC8197" format="default"/> explains,
      not only does the called party desire to reject that call, they can let
      their proxy know that they consider future calls from that source
      unwanted. Upon receipt of the 607 response from the UAS, the proxy 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 <xref target="RFC8197" format="default"/>, if a network
      operator receives multiple reports of unwanted calls, that may indicate
      that the entity placing the calls is likely to be a source of unwanted
      calls for many people. As such, other customers of the service provider
      may want the service provider to automatically reject calls on their
      behalf.</t>
      <t>There is another value of the 607 rejection code. Presuming the proxy
      forwards the response code to the User Agent Client (UAC), the calling
      UAC or intervening proxies will also learn the user is not interested in
      receiving calls from that sender.</t>
      <figure anchor="uas_reject">
        <name>Unwanted (607) Call Flow</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                      +-----------+
                      |   Call    |
                      | Analytics |
                      |  Engine   |
                      +-----------+
                         ^     | (likely not SIP)
                         |     v
                      +-----------+
   +-----+    607     |  Called   |    607    +-----+
   | UAC | <--------- |  Party    | <-------- | UAS |
   +-----+            |  Proxy    |           +-----+
                      +-----------+

       ]]></artwork>
      </figure>
      <t>For calls rejected with a 607 from a legitimate caller, receiving a
      607 response code can inform the caller to stop attempting to call the
      user. Moreover, if a legitimate caller believes the user is rejecting
      their calls in error, they can use other channels to contact the user.
      For example, if a pharmacy calls a user to let them know their
      prescription is available for pickup and the user mistakenly thinks the
      call is unwanted and issues a 607 response code, the pharmacy, having an
      existing relationship with the customer, can send the user an email or
      push a note to the pharmacist to ask the customer to consider not
      rejecting their calls in the future.</t>
      <t>Many systems that allow the user to mark the call unwanted (e.g.,
      with the 607 response code) also allow the user to change their mind and
      unmark such calls. This mechanism is relatively easy to implement as the
      user usually has a direct relationship with the service provider that is
      blocking calls.</t>
      <t>However, things become more complicated if an intermediary, such as a
      third-party provider of call management services that classifies calls
      based on the relative likelihood that the call is unwanted,
      misidentifies the call as unwanted. <xref target="cae_reject" format="default"/> 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 beneficial for the caller to learn who rejected
      the call, so they can correct the misidentification.</t>
      <figure anchor="reject_ladder">
        <name>Unwanted (607) Ladder Diagram</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                    +--------+         +-----------+
                    | Called |         |   Call    |
   +-----+          | Party  |         | Analytics |   +-----+
   | UAC |          | Proxy  |         |  Engine   |   | UAS |
   +-----+          +--------+         +-----------+   +-----+
      |  INVITE         |                    |            |
      | --------------> |  Is call OK?       |            |
      |                 |------------------->|            |
      |                 |                    |            |
      |                 |               Yes  |            |
      |                 |<-------------------|            |
      |                 |                    |            |
      |                 | INVITE             |            |
      |                 | ------------------------------> |
      |                 |                    |            |
      |                 |                    |       607  |
      |                 | <------------------------------ |
      |                 |                    |            |
      |                 |  Unwanted call     |            |
      |            607  | -----------------> |            |
      | <-------------- |  indicators        |            |
      |                 |                    |            |


]]></artwork>
      </figure>
      <figure anchor="cae_reject">
        <name>Rejected (608) Call Flow</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                      +-----------+
                      |   Call    |
                      | Analytics |
                      |  Engine   |
                      +-----------+
                         ^     | (likely not SIP)
                         |     v
                      +-----------+
   +-----+    608     |  Called   |           +-----+
   | UAC | <--------- |  Party    |           | UAS |
   +-----+            |  Proxy    |           +-----+
                      +-----------+

       ]]></artwork>
      </figure>
      <t>In this situation, one might consider to have the intermediary use
      the 607 response code. 607 indicates to the caller the subscriber does
      not want the call. However, <xref target="RFC8197" format="default"/> specifies that one
      of the uses of 607 is to inform analytics engines that a user (human)
      has rejected a call. The problem here is that network elements
      downstream from the intermediary might interpret the 607 as coming from
      a user (human) who has marked the call as unwanted, as opposed to coming
      from an algorithm using statistics or machine learning to reject the
      call. An algorithm can be vulnerable to the <xref target="BaseRate" format="default">base
      rate fallacy</xref> rejecting the call. In other words, those downstream
      entities should not rely on another entity 'deciding' the call is
      unwanted. By distinguishing between a (human) user rejection and 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, versus deciding whether to consider a 608 at all,
      and if so, weighing it appropriately.</t>
      <t>It is useful for blocked callers to have a redress mechanism. One can
      imagine that some jurisdictions will require it. However, we must be
      mindful that most of the calls that intermediaries block will, in fact,
      be illegal and eligible for blocking. Thus, providing alternate contact
      information for a user would be counterproductive to protecting that
      user from illegal communications. This is another reason we do not
      propose to simply allow alternate contact information in a 607 response
      message.</t>
      <t>Why do we not use the same mechanism an analytics service provider
      offers their customers? Specifically, why not have the analytics service
      provider allow the called party to correct a call blocked in error? The
      reason is while there is an existing relationship between the customer
      (called party) and the analytics service provider, it is unlikely there
      is a relationship between the caller and the analytics service provider.
      Moreover, there are numerous call blocking providers in the ecosystem.
      Therefore, we need a mechanism for indicating an intermediary rejected a
      call that also provides contact information for the operator of that
      intermediary, without exposing the target user's contact
      information.</t>
      <t>The protocol described in this document uses existing SIP protocol
      mechanisms for specifying the redress mechanism. In the Call-Info header
      passed back to the UAC, we send additional information specifying a
      redress address. We choose to encode the redress address using <xref target="RFC7095" format="default">jCard</xref>. As we will see later in this document,
      this information needs to have its own, application-layer integrity
      protection. Thus, we use jCard rather than <xref target="RFC6350" format="default">vCard</xref> as we have a marshaling mechanism for
      creating a JavaScript Object Notation <xref target="RFC8259" format="default">(JSON)</xref> object, such as a jCard, and a standard
      integrity format for such an object, namely JSON Web Signature <xref target="RFC7515" format="default">(JWS)</xref>. The SIP community is familiar with this
      concept as it is the mechanism used by <xref target="RFC8224" format="default">STIR</xref>.</t>
      <t>Integrity protecting the jCard with a cryptographic signature might
      seem unnecessary at first, but it is essential to preventing potential
      network attacks. <xref target="Security" format="default"/> describes the attack and why
      we sign the jCard in more detail.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Terminology</name>
      <t>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
      <xref target="RFC2119" format="default"/><xref target="RFC8174" format="default"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Protocol Operation</name>
      <t>This section uses the term 'intermediary' to mean the entity that
      acts as a SIP User Agent Server (UAS) on behalf of the user in the
      network, as opposed to the user's UAS (usually, but not necessarily,
      their phone). The intermediary could be a back-to-back user agent
      (B2BUA) or a SIP Proxy.</t>
      <t><xref target="cae_ladder" format="default"/> shows an overview of the call flow for a
      rejected call.</t>
      <figure anchor="cae_ladder">
        <name>Rejected (608) Ladder Diagram</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                    +--------+         +-----------+
                    | Called |         |   Call    |
   +-----+          | Party  |         | Analytics |   +-----+
   | UAC |          | Proxy  |         |  Engine   |   | UAS |
   +-----+          +--------+         +-----------+   +-----+
      |  INVITE         |                    |            |
      | --------------> |  Information from  |            |
      |                 | -----------------> |            |
      |                 |  INVITE            |            |
      |                 |            Reject  |            |
      |            608  | <----------------- |            |
      | <-------------- |            call    |            |
      |                 |                    |            |

       ]]></artwork>
      </figure>
      <section numbered="true" toc="default">
        <name>Intermediary Operation</name>
        <t>An intermediary MAY issue the 608 response code in a failure
        response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog
        <xref target="RFC3261" format="default">SIP</xref> request to indicate that an
        intermediary rejected the offered communication as unwanted by the
        user. An intermediary MAY issue the 608 as the value of the "cause"
        parameter of a SIP reason-value in a Reason header field <xref target="RFC3326" format="default"/>.</t>
        <t>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 <xref target="Security" format="default"/>), the
        intermediary MUST include a Call-Info header field in the
        response.</t>
        <t>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 (<xref target="RFC7515" format="default">JWS</xref>) encoding of a <xref target="RFC7095" format="default">jCard</xref> object. The following section describes
        the construction of the JWS.</t>
        <t>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 <xref target="RFC3261" format="default"/> 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.</t>
      </section>
      <section numbered="true" toc="default">
        <name>JWS Construction</name>
        <t>The intermediary constructs the JWS of the jCard as follows.</t>
        <section numbered="true" toc="default">
          <name>JOSE Header</name>
          <t>The Javascript Object Signing and Encryption (JOSE) header MUST
          include the typ, alg, and x5u parameters from <xref target="RFC7515" format="default">JWS</xref>. The typ parameter MUST have the value
          "vcard+json". Implementations MUST support ES256 as JSON Web
          Algorithms (<xref target="RFC7518" format="default">JWA</xref>) 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.</t>
        </section>
        <section anchor="JWT" numbered="true" toc="default">
          <name>JWT Payload</name>
          <t>The payload contains two JSON values. The first JSON Web Token
          (JWT) claim that MUST be present is the <xref target="RFC7519" format="default">iat
          (issued at) claim</xref>. 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.</t>
          <t>The second JWT claim that MUST be present is the "jcard" claim.
          The value of the <xref target="RFC7095" format="default">jcard</xref> claim is a JSON
          array conforming to the JSON jCard data format defined in RFC7095
          <xref target="JWT-IANA" format="default"/> 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.</t>
        </section>
        <section anchor="s.JWS" numbered="true" toc="default">
          <name>JWS Signature</name>
          <t><xref target="RFC7515" format="default">JWS</xref> specifies the procedure for
          calculating the signature over the jCard JWT. <xref target="EXAMPLES" format="default"/> of this document has a detailed example on
          constructing the JWS, including the signature.</t>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>UAC Operation</name>
        <t>A UAC conforming to this specification MUST include the sip.608
        feature capability indicator in the Feature-Caps header field of the
        INVITE request.</t>
        <t>Upon receiving a 608 response, UACs perform normal SIP processing
        for 6xx responses.</t>
        <t>As for the disposition of the jCard itself, the UAC MUST check the
        "iat" claim in the JWT. As noted in <xref target="s.JWS" format="default"/>, 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.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Legacy Interoperation</name>
        <t>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?</t>
        <t>We address this situation by having the first network element that
        conforms with this specification play an announcement in the media.
        See <xref target="announcement" format="default"/> 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.</t>
        <t>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 <xref target="announcement" format="default"/> and <xref target="Security" format="default"/> do not hold, the
        intermediary MUST play the announcement.</t>
        <t>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
        <xref target="RFC6809" format="default"/>.</t>
        <t>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.</t>
        <t>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 (<xref target="RFC7092" format="default">SBC</xref>), or proxy) need to understand the sip.608
        feature capability. If the other network elements conform to Section
        16.6 of <xref target="RFC3261" format="default"/>, they will pass header fields such as
        "Feature-Caps: *;+sip.608" unmodified and without need for
        upgrade.</t>
        <t>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 <xref target="RFC3262" format="default">100Rel</xref> in its INVITE and the
        network element conveying the announcement MUST Require 100Rel in the
        183 and the UAC MUST issue a PRACK to which the network element MUST
        respond 200 OK PRACK.</t>
      </section>
      <section anchor="announcement" numbered="true" toc="default">
        <name>Announcement Requirements</name>
        <t>There are a few requirements on the element that handles the
        announcement for legacy interoperation.</t>
        <t>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.</t>
        <t>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 <xref target="RFC4566" format="default">(SDP)</xref> to result in an audio announcement.
        Likewise, if the INVITE only indicated a <xref target="RFC4103" format="default">real-time text codec</xref> and the network element
        can render the information in the requested media format, the network
        element should send the information in a text format.</t>
        <t>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.</t>
      </section>
    </section>
    <section anchor="EXAMPLES" numbered="true" toc="default">
      <name>Examples</name>
      <t>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.</t>
      <section numbered="true" toc="default">
        <name>Full Exchange</name>
        <t>Given an INVITE, shamelessly taken from <xref target="SHAKEN" format="default"/>,
        with the line breaks in the Identity header field for display purposes
        only:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
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: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
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
       ]]></artwork>
        <t>An intermediary could reply:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
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
      ]]></artwork>
        <t>The location https://block.example.net/complaint-jws resolves to a
        JWS. One would construct the JWS as follows.</t>
        <t>The JWS header of this example jCard could be:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[{ "alg":"ES256",
  "typ":"vcard+json",
  "x5u":"https://certs.example.net/reject_key.cer"
}

]]></artwork>
        <t>Now, let us construct a minimal jCard. For this example, the jCard
        refers the caller to an email address,
        remediation@blocker.example.net:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["email", {"type":"work"}, 
              "text", "remediation@blocker.example.net"]
  ]
]

]]></artwork>
        <t>With this jCard, we can now construct the JWT:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[{
  "iat":1546008698,
  "jcard":["vcard",
    [
      ["version", {}, "text", "4.0"],
      ["fn", {}, "text", "Robocall Adjudication"],
      ["email", {"type":"work"}, 
                "text", "remediation@blocker.example.net"]
    ]
  ]
}

]]></artwork>
        <t>To calculate the signature, we need to encode the JSON Object
        Signing and Encryption (JOSE) header and JWT into base64url. As an
        implementation note, one 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 for ease of publication 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 SIP
        header.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[base64url of JOSE header:
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=

base64url of JWT:
eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19

]]></artwork>
        <t>In this case, the object to sign (remembering this is just a
        single, long line; the line breaks are for ease of review but do not
        appear in the actual object) is as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19

]]></artwork>
        <t>We use the following X.509 PKCS #8-encoded ECDSA key, also
        shamelessly taken from <xref target="SHAKEN" format="default"/>), 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.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----

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

]]></artwork>
        <t>The resulting JWS, using the above key on the above object, renders
        the following ECDSA P-256 SHA-256 digital signature.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag

]]></artwork>
        <t>Thus, the JWS stored at https://blocker.example.net/complaints-jws,
        would contain:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag

]]></artwork>
      </section>
      <section numbered="true" toc="default">
        <name>Web Site jCard</name>
        <t>For an intermediary that provides a Web site for adjudication, the
        jCard could contain the following. Note 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.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["url", {"type":"work"}, 
            "text", "https://blocker.example.net/adjudication-form"]
  ]
]     ]]></artwork>
      </section>
      <section numbered="true" toc="default">
        <name>Multi-modal jCard</name>
        <t>For an intermediary that provides a telephone number and a postal
        address, the jCard could contain the following. Note 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.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[["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"]
  ]
]     ]]></artwork>
        <t>Note that it is up to the UAC to decide which jCard contact
        modality, if any, it will use.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Legacy Interoperability</name>
        <t><xref target="legacy_ladder" format="default"/> depicts a call flow illustrating
        legacy interoperability. 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 608. Per <xref target="RFC6809" format="default"/>, the SBC can
        insert "*;+sip.608" into the Feature-Caps header field for the INVITE.
        When the intermediary, labeled "Called Party Proxy" in the figure,
        rejects the call, it knows it can simply perform the processing
        described in this document. Since the 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 erroneous rejection. For
        illustrative purposes, the figure shows generic SIP Proxies in the
        flow. Their presence or absence or the number of proxies is not
        relevant to the operation of the protocol. They are in the figure to
        show that proxies that do not understand the sip.608 feature
        capability can still participate in a network offering 608
        services.</t>
        <figure anchor="legacy_ladder">
          <name>Legacy Operation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                                                  +---------+
                                                  |  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: <...> |                               |
  |                   |                               |

]]></artwork>
        </figure>
        <t>When the SBC receives the 608 response code, it correlates that
        with the original INVITE from the UAC. The SBC remembers that it
        inserted the sip.608 feature capability, which means it is responsible
        for somehow alerting the UAC the call failed and whom to contact. At
        this point the SBC can play a prompt, either natively or through a
        mechanism such as <xref target="RFC4240" format="default">NETANN</xref>, that sends the
        relevant information in the appropriate media to the UAC. Since this
        is a potentially long transaction and there is a chance the UAC is
        using an unreliable transport protocol, 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 provide the
        PRACK, and the SBC will acknowledge receipt of the PRACK before
        playing the announcement.</t>
        <t>As an example, the SBC could extract the FN and TEL jCard fields
        and play something like a special information tone (see Telcordia
        <xref target="SR-2275" format="default">SR-2275</xref> section 6.21.2.1 or <xref target="ITU.E.180.1998" format="default">ITU-T E.180</xref> section 7), 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.</t>
        <t>Note the SBC also still sends the full 608 response code, including
        the Call-Info header, towards the UAC.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>SIP Response Code</name>
        <t>This document defines a new SIP response code, 608 in the "Response
        Codes" subregistry of the "Session Initiation Protocol (SIP)
        Parameters" registry defined in <xref target="RFC3261" format="default"/>.</t>
        <dl newline="false" spacing="normal">
          <dt>Response code:</dt>
          <dd>608</dd>
          <dt>Description:</dt>
          <dd>Rejected</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX]</dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>SIP Feature-Capability Indicator</name>
        <t>This document defines the feature capability sip.608 in the "SIP
        Feature-Capability Indicator Registration Tree" registry defined in
        <xref target="RFC6809" format="default"/>.</t>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
          <dd>sip.608</dd>
          <dt>Description:</dt>
          <dd>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.</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX]</dd>
        </dl>
      </section>
      <section anchor="JWT-IANA" numbered="true" toc="default">
        <name>JSON Web Token Claim</name>
        <t>This document defines the new JSON Web Token claim in the "JSON Web
        Token Claims" sub-registry created by <xref target="RFC7519" format="default"/>. <xref target="JWT" format="default"/> defines the syntax. The required information is:</t>
        <dl newline="false" spacing="normal">
          <dt>Claim Name:</dt>
          <dd>jcard</dd>
          <dt>Claim Description:</dt>
          <dd>jCard data</dd>
          <dt>Change Controller:</dt>
          <dd>IESG</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX], <xref target="RFC7095" format="default"/></dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>Call-Info Purpose</name>
        <t>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":</t>
        <dl newline="false" spacing="normal">
          <dt>Header Field:</dt>
          <dd>Call-Info</dd>
          <dt>Parameter Name:</dt>
          <dd>purpose</dd>
          <dt>Predefined Values:</dt>
          <dd>Yes</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX]</dd>
        </dl>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Intermediary operators need to be mindful to whom they are sending
      the 608 response. The intermediary could be rejecting a truly malicious
      caller. This raises two issues. The first is the caller, now alerted an
      intermediary is automatically rejecting their call attempts, may change
      their call behavior to defeat call blocking systems. The second, and
      more significant risk, is that by providing a contact in the Call-Info
      header field, the intermediary may be giving the malicious caller a
      vector for attack. In other words, the intermediary will be publishing
      an address that a malicious actor may use to launch an attack on the
      intermediary. 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 and that pass validation by
      <xref target="RFC8224" format="default">STIR</xref>.</t>
      <t>Another risk is as follows. Consider an attacker that floods a proxy
      that supports the sip.608 feature. However, the SDP in the INVITE
      request refers to a victim device. Moreover, the attacker somehow knows
      there is a 608-aware gateway connecting to the victim who is on a
      segment that lacks the sip.608 feature capability. Because the mechanism
      described here can result in sending an audio file to the target of the
      SDP, an attacker could use the mechanism described by this document as
      an amplification attack, given a SIP INVITE can be under 1 kilobyte and
      an audio file can be hundreds of kilobytes. One remediation for this 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. A method for this is to only play media in response to a
      STIR-signed INVITE that passes validation. Beyond requiring a valid STIR
      signature on the INVITE, the intermediary can also use remediation
      procedures such as doing the connectivity checks specified by <xref target="RFC8445" format="default">Interactive Connectivity Establishment</xref>. If the
      target did not request the media, the check will fail.</t>
      <t>Yet another risk is a malicious intermediary that generates a
      malicious 608 response with a jCard referring 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. However, instead of using that
      information to verify the recipient's identity, they are phishing the
      information for nefarious ends. A similar scenario can unfold if the
      malicious agent inserts a URI that points to a phishing or other site.
      As such, we strongly recommend the recipient validates to whom they are
      communicating with if 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 remediation is to require the intermediary to sign the
      jCard. Signing the jCard provides integrity protection. In addition, one
      can imagine mechanisms such as used by <xref target="SHAKEN" format="default">SHAKEN</xref>.</t>
      <t>Similarly, one can imagine an adverse agent that maliciously spoofs a
      608 response with a victim's contact address to many active callers, who
      may then all send redress requests to the specified address (the basis
      for a denial-of-service attack). The process would occur as follows: (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, causing (3) the UACs to all contact the
      redress address at once. The jCard encoding allows the UAC to verify the
      blocking intermediary's identity before contacting the redress address.
      Specifically, because the sender signs the jCard, we can
      cryptographically trace the sender of the jCard. Given the protocol
      machinery of having a signature, one can apply local policy to decide
      whether to believe the sender of the jCard represents the owner of the
      contact information found in the jCard. This guards against a malicious
      agent spoofing 608 responses.</t>
      <t>Specifically, one could use policies around signing certificate
      issuance as a mechanism for traceback to the entity issuing the jCard.
      One check could be verifying the identity of the subject of the
      certificate relates to the To header field of the initial SIP request,
      similar to validating the intermediary was vouching for the From header
      field of a SIP request with that identity. Note that we are only
      protecting against a malicious intermediary and not a hidden
      intermediary attack (formerly known as a "man in the middle attack").
      Thus, we only need to ensure the signature is fresh, which is why we
      include "iat". For most implementations, we assume that the intermediary
      has a single set of contact points and will generate the jCard on
      demand. As such, there is no need to directly correlate HTTPS fetches to
      specific calls. However, since the intermediary is in control of the
      jCard and Call-Info response, an intermediary may choose to encode
      per-call information in the URI returned in a given 608 response.
      However, if the intermediary does go that route, the intermediary MUST
      use a non-deterministic URI reference mechanism and be prepared to
      return dummy responses to URI requests referencing calls that do not
      exist so that attackers attempting to glean call metadata by guessing
      URI's (and thus calls) will not get any actionable information from the
      HTTPS GET.</t>
      <t>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 ascertain whom to contact without including such
      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. Thus, the Call-Info jCard could be
      redundant information. However, the factors going into a particular
      service provider's or jurisdiction's choice of whether to include
      Call-Info is outside the scope of this document.</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>This document liberally lifts from <xref target="RFC8197" format="default"/> in its
      text and structure. However, the mechanism and purpose of 608 is quite
      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
      Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on
      improving the draft. Tolga's suggestion to provide a mechanism for
      legacy interoperability served to expand the draft by 50%. In addition,
      Tolga came up with the jCard attack. Finally, Christer Holmberg as
      always provided a close reading and fixed a SIP feature capability bug
      found by Yehoshua Gev.</t>
      <t>Of course, we appreciated the close read and five pages of comments
      from our estimable Area Director, Adam Roach. In addition, we received
      valuable comments during IETF Last Call and JWT review from Ines Robles,
      Mike Jones, and Brian Campbell and IESG review from Alissa Cooper,
      Eric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and
      with most glee, Warren Kumari.</t>
      <t>Finally, Bhavik Nagda provided clarifying edits as well and more
      especially wrote and tested an implementation of the 608 response code
      in Kamailio. Code is available at <eref target="https://github.com/nagdab/608_Implementation"/>. Grace Chuan
      from MIT regenerated and verified the JWT while working at the FCC.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC3261"/>
            <seriesInfo name="RFC" value="3261"/>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization/>
            </author>
            <author initials="A." surname="Johnston" fullname="A. Johnston">
              <organization/>
            </author>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization/>
            </author>
            <author initials="R." surname="Sparks" fullname="R. Sparks">
              <organization/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization/>
            </author>
            <author initials="E." surname="Schooler" fullname="E. Schooler">
              <organization/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3262" target="https://www.rfc-editor.org/info/rfc3262" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3262.xml">
          <front>
            <title>Reliability of Provisional Responses in Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC3262"/>
            <seriesInfo name="RFC" value="3262"/>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t>This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages.  This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3326" target="https://www.rfc-editor.org/info/rfc3326" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml">
          <front>
            <title>The Reason Header Field for the Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC3326"/>
            <seriesInfo name="RFC" value="3326"/>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <author initials="D." surname="Oran" fullname="D. Oran">
              <organization/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization/>
            </author>
            <date year="2002" month="December"/>
            <abstract>
              <t>The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record.  This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: &lt;sip:alice@pc33.atlanta.com&gt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA).  The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies.  The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use.  This document defines an extension header field, "Path" which provides such a mechanism.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6809" target="https://www.rfc-editor.org/info/rfc6809" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6809.xml">
          <front>
            <title>Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6809"/>
            <seriesInfo name="RFC" value="6809"/>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization/>
            </author>
            <author initials="I." surname="Sedlacek" fullname="I. Sedlacek">
              <organization/>
            </author>
            <author initials="H." surname="Kaplan" fullname="H. Kaplan">
              <organization/>
            </author>
            <date year="2012" month="November"/>
            <abstract>
              <t>This specification defines a new SIP header field, Feature-Caps.  The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.</t>
              <t>SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.</t>
              <t>This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7095" target="https://www.rfc-editor.org/info/rfc7095" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml">
          <front>
            <title>jCard: The JSON Format for vCard</title>
            <seriesInfo name="DOI" value="10.17487/RFC7095"/>
            <seriesInfo name="RFC" value="7095"/>
            <author initials="P." surname="Kewisch" fullname="P. Kewisch">
              <organization/>
            </author>
            <date year="2014" month="January"/>
            <abstract>
              <t>This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses.  JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7515"/>
            <seriesInfo name="RFC" value="7515"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
          <front>
            <title>JSON Web Algorithms (JWA)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7518"/>
            <seriesInfo name="RFC" value="7518"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
          <front>
            <title>JSON Web Token (JWT)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7519"/>
            <seriesInfo name="RFC" value="7519"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC4103" target="https://www.rfc-editor.org/info/rfc4103" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4103.xml">
          <front>
            <title>RTP Payload for Text Conversation</title>
            <seriesInfo name="DOI" value="10.17487/RFC4103"/>
            <seriesInfo name="RFC" value="4103"/>
            <author initials="G." surname="Hellstrom" fullname="G. Hellstrom">
              <organization/>
            </author>
            <author initials="P." surname="Jones" fullname="P. Jones">
              <organization/>
            </author>
            <date year="2005" month="June"/>
            <abstract>
              <t>This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets.  Text conversation session contents are specified in ITU-T Recommendation T.140.</t>
              <t>One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.</t>
              <t>This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4240" target="https://www.rfc-editor.org/info/rfc4240" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4240.xml">
          <front>
            <title>Basic Network Media Services with SIP</title>
            <seriesInfo name="DOI" value="10.17487/RFC4240"/>
            <seriesInfo name="RFC" value="4240"/>
            <author initials="E." surname="Burger" fullname="E. Burger" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Van Dyke" fullname="J. Van Dyke">
              <organization/>
            </author>
            <author initials="A." surname="Spitzer" fullname="A. Spitzer">
              <organization/>
            </author>
            <date year="2005" month="December"/>
            <abstract>
              <t>In SIP-based networks, there is a need to provide basic network media services.  Such services include network announcements, user interaction, and conferencing services.  These services are basic building blocks, from which one can construct interesting applications.  In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.</t>
              <t>This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
          <front>
            <title>SDP: Session Description Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC4566"/>
            <seriesInfo name="RFC" value="4566"/>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5039" target="https://www.rfc-editor.org/info/rfc5039" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5039.xml">
          <front>
            <title>The Session Initiation Protocol (SIP) and Spam</title>
            <seriesInfo name="DOI" value="10.17487/RFC5039"/>
            <seriesInfo name="RFC" value="5039"/>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <author initials="C." surname="Jennings" fullname="C. Jennings">
              <organization/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t>Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email.  Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications.  Therefore, it is susceptible to spam, just as email is.  In this document, we analyze the problem of spam in SIP.  We first identify the ways in which the problem is the same and the ways in which it is different from email.  We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6350" target="https://www.rfc-editor.org/info/rfc6350" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml">
          <front>
            <title>vCard Format Specification</title>
            <seriesInfo name="DOI" value="10.17487/RFC6350"/>
            <seriesInfo name="RFC" value="6350"/>
            <author initials="S." surname="Perreault" fullname="S. Perreault">
              <organization/>
            </author>
            <date year="2011" month="August"/>
            <abstract>
              <t>This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7092" target="https://www.rfc-editor.org/info/rfc7092" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
          <front>
            <title>A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents</title>
            <seriesInfo name="DOI" value="10.17487/RFC7092"/>
            <seriesInfo name="RFC" value="7092"/>
            <author initials="H." surname="Kaplan" fullname="H. Kaplan">
              <organization/>
            </author>
            <author initials="V." surname="Pascual" fullname="V. Pascual">
              <organization/>
            </author>
            <date year="2013" month="December"/>
            <abstract>
              <t>In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs.  The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).</t>
              <t>There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7340" target="https://www.rfc-editor.org/info/rfc7340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml">
          <front>
            <title>Secure Telephone Identity Problem Statement and Requirements</title>
            <seriesInfo name="DOI" value="10.17487/RFC7340"/>
            <seriesInfo name="RFC" value="7340"/>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <date year="2014" month="September"/>
            <abstract>
              <t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8197" target="https://www.rfc-editor.org/info/rfc8197" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8197.xml">
          <front>
            <title>A SIP Response Code for Unwanted Calls</title>
            <seriesInfo name="DOI" value="10.17487/RFC8197"/>
            <seriesInfo name="RFC" value="8197"/>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <date year="2017" month="July"/>
            <abstract>
              <t>This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8224" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml">
          <front>
            <title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8224"/>
            <seriesInfo name="RFC" value="8224"/>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization/>
            </author>
            <author initials="C." surname="Jennings" fullname="C. Jennings">
              <organization/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <author initials="C." surname="Wendt" fullname="C. Wendt">
              <organization/>
            </author>
            <date year="2018" month="February"/>
            <abstract>
              <t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t>
              <t>This document obsoletes RFC 4474.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC8259"/>
            <seriesInfo name="RFC" value="8259"/>
            <seriesInfo name="STD" value="90"/>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
          <front>
            <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
            <seriesInfo name="DOI" value="10.17487/RFC8445"/>
            <seriesInfo name="RFC" value="8445"/>
            <author initials="A." surname="Keranen" fullname="A. Keranen">
              <organization/>
            </author>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization/>
            </author>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <date year="2018" month="July"/>
            <abstract>
              <t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t>
              <t>This document obsoletes RFC 5245.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="SHAKEN" target="https://www.sipforum.org/download/sip-forum-twg-10-signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813">
          <front>
            <title>Signature-based Handling of Asserted information using toKENs
          (SHAKEN)</title>
            <seriesInfo name="ATIS" value="1000074"/>
            <author>
              <organization>Alliance for Telecommunications Industry Solutions
            (ATIS) and the SIP Forum</organization>
            </author>
            <date day="5" month="1" year="2017"/>
          </front>
        </reference>
        <reference anchor="BaseRate" target=" https://apps.dtic.mil/docs/citations/ADA045772">
          <front>
            <title>The Base-Rate Fallacy in Probability Judgements</title>
            <author fullname="Maya Bar-Hillel" initials="M." surname="Bar-Hillel">
              <organization>Hebrew University</organization>
            </author>
            <date month="4" year="1977"/>
          </front>
        </reference>
        <reference anchor="ITU.E.180.1998">
          <front>
            <title>Technical characteristics of tones for the telephone
          service</title>
            <seriesInfo name="ITU" value="Recommendation E.180/Q.35"/>
            <author>
              <organization>International Telecommunications
            Union</organization>
            </author>
            <date month="March" year="1998"/>
          </front>
        </reference>
        <reference anchor="SR-2275">
          <front>
            <title>Bellcore Notes on the Networks</title>
            <seriesInfo name="Telcordia" value="SR-2275"/>
            <author>
              <organization>Telcordia</organization>
            </author>
            <date month="October" year="2000"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
</rfc>

<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<date year="1997" month="March"/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>

<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo"><organization/></author>
<author initials="A." surname="Johnston" fullname="A. Johnston"><organization/></author>
<author initials="J." surname="Peterson" fullname="J. Peterson"><organization/></author>
<author initials="R." surname="Sparks" fullname="R. Sparks"><organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley"><organization/></author>
<author initials="E." surname="Schooler" fullname="E. Schooler"><organization/></author>
<date year="2002" month="June"/>
<abstract><t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>

<reference anchor="RFC3262" target="https://www.rfc-editor.org/info/rfc3262" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3262.xml">
<front>
<title>Reliability of Provisional Responses in Session Initiation Protocol (SIP)</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<date year="2002" month="June"/>
<abstract><t>This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages.  This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="3262"/>
<seriesInfo name="DOI" value="10.17487/RFC3262"/>
</reference>

<reference anchor="RFC3326" target="https://www.rfc-editor.org/info/rfc3326" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml">
<front>
<title>The Reason Header Field for the Session Initiation Protocol (SIP)</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<author initials="D." surname="Oran" fullname="D. Oran"><organization/></author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo"><organization/></author>
<date year="2002" month="December"/>
<abstract><t>The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record.  This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: &lt;sip:alice@pc33.atlanta.com&gt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA).  The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies.  The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use.  This document defines an extension header field, "Path" which provides such a mechanism.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="3326"/>
<seriesInfo name="DOI" value="10.17487/RFC3326"/>
</reference>

<reference anchor="RFC6809" target="https://www.rfc-editor.org/info/rfc6809" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6809.xml">
<front>
<title>Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)</title>
<author initials="C." surname="Holmberg" fullname="C. Holmberg"><organization/></author>
<author initials="I." surname="Sedlacek" fullname="I. Sedlacek"><organization/></author>
<author initials="H." surname="Kaplan" fullname="H. Kaplan"><organization/></author>
<date year="2012" month="November"/>
<abstract><t>This specification defines a new SIP header field, Feature-Caps.  The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.</t><t>SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.</t><t>This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6809"/>
<seriesInfo name="DOI" value="10.17487/RFC6809"/>
</reference>

<reference anchor="RFC7095" target="https://www.rfc-editor.org/info/rfc7095" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml">
<front>
<title>jCard: The JSON Format for vCard</title>
<author initials="P." surname="Kewisch" fullname="P. Kewisch"><organization/></author>
<date year="2014" month="January"/>
<abstract><t>This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses.  JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.</t></abstract>
</front>
<seriesInfo name="RFC" value="7095"/>
<seriesInfo name="DOI" value="10.17487/RFC7095"/>
</reference>

<reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
<front>
<title>JSON Web Signature (JWS)</title>
<author initials="M." surname="Jones" fullname="M. Jones"><organization/></author>
<author initials="J." surname="Bradley" fullname="J. Bradley"><organization/></author>
<author initials="N." surname="Sakimura" fullname="N. Sakimura"><organization/></author>
<date year="2015" month="May"/>
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>

<reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author initials="M." surname="Jones" fullname="M. Jones"><organization/></author>
<date year="2015" month="May"/>
<abstract><t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</t></abstract>
</front>
<seriesInfo name="RFC" value="7518"/>
<seriesInfo name="DOI" value="10.17487/RFC7518"/>
</reference>

<reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
<front>
<title>JSON Web Token (JWT)</title>
<author initials="M." surname="Jones" fullname="M. Jones"><organization/></author>
<author initials="J." surname="Bradley" fullname="J. Bradley"><organization/></author>
<author initials="N." surname="Sakimura" fullname="N. Sakimura"><organization/></author>
<date year="2015" month="May"/>
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>

<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"><organization/></author>
<date year="2017" month="May"/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>

<reference anchor="RFC4103" target="https://www.rfc-editor.org/info/rfc4103" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4103.xml">
<front>
<title>RTP Payload for Text Conversation</title>
<author initials="G." surname="Hellstrom" fullname="G. Hellstrom"><organization/></author>
<author initials="P." surname="Jones" fullname="P. Jones"><organization/></author>
<date year="2005" month="June"/>
<abstract><t>This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets.  Text conversation session contents are specified in ITU-T Recommendation T.140.</t><t>One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.</t><t>This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="4103"/>
<seriesInfo name="DOI" value="10.17487/RFC4103"/>
</reference>

<reference anchor="RFC4240" target="https://www.rfc-editor.org/info/rfc4240" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4240.xml">
<front>
<title>Basic Network Media Services with SIP</title>
<author initials="E." surname="Burger" fullname="E. Burger" role="editor"><organization/></author>
<author initials="J." surname="Van Dyke" fullname="J. Van Dyke"><organization/></author>
<author initials="A." surname="Spitzer" fullname="A. Spitzer"><organization/></author>
<date year="2005" month="December"/>
<abstract><t>In SIP-based networks, there is a need to provide basic network media services.  Such services include network announcements, user interaction, and conferencing services.  These services are basic building blocks, from which one can construct interesting applications.  In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.</t><t>This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name="RFC" value="4240"/>
<seriesInfo name="DOI" value="10.17487/RFC4240"/>
</reference>

<reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
<front>
<title>SDP: Session Description Protocol</title>
<author initials="M." surname="Handley" fullname="M. Handley"><organization/></author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson"><organization/></author>
<author initials="C." surname="Perkins" fullname="C. Perkins"><organization/></author>
<date year="2006" month="July"/>
<abstract><t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="4566"/>
<seriesInfo name="DOI" value="10.17487/RFC4566"/>
</reference>

<reference anchor="RFC5039" target="https://www.rfc-editor.org/info/rfc5039" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5039.xml">
<front>
<title>The Session Initiation Protocol (SIP) and Spam</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<author initials="C." surname="Jennings" fullname="C. Jennings"><organization/></author>
<date year="2008" month="January"/>
<abstract><t>Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email.  Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications.  Therefore, it is susceptible to spam, just as email is.  In this document, we analyze the problem of spam in SIP.  We first identify the ways in which the problem is the same and the ways in which it is different from email.  We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name="RFC" value="5039"/>
<seriesInfo name="DOI" value="10.17487/RFC5039"/>
</reference>

<reference anchor="RFC6350" target="https://www.rfc-editor.org/info/rfc6350" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml">
<front>
<title>vCard Format Specification</title>
<author initials="S." surname="Perreault" fullname="S. Perreault"><organization/></author>
<date year="2011" month="August"/>
<abstract><t>This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6350"/>
<seriesInfo name="DOI" value="10.17487/RFC6350"/>
</reference>

<reference anchor="RFC7092" target="https://www.rfc-editor.org/info/rfc7092" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
<front>
<title>A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents</title>
<author initials="H." surname="Kaplan" fullname="H. Kaplan"><organization/></author>
<author initials="V." surname="Pascual" fullname="V. Pascual"><organization/></author>
<date year="2013" month="December"/>
<abstract><t>In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs.  The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).</t><t>There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.</t></abstract>
</front>
<seriesInfo name="RFC" value="7092"/>
<seriesInfo name="DOI" value="10.17487/RFC7092"/>
</reference>

<reference anchor="RFC7340" target="https://www.rfc-editor.org/info/rfc7340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml">
<front>
<title>Secure Telephone Identity Problem Statement and Requirements</title>
<author initials="J." surname="Peterson" fullname="J. Peterson"><organization/></author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig"><organization/></author>
<date year="2014" month="September"/>
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.</t></abstract>
</front>
<seriesInfo name="RFC" value="7340"/>
<seriesInfo name="DOI" value="10.17487/RFC7340"/>
</reference>

<reference anchor="RFC8197" target="https://www.rfc-editor.org/info/rfc8197" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8197.xml">
<front>
<title>A SIP Response Code for Unwanted Calls</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<date year="2017" month="July"/>
<abstract><t>This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.</t></abstract>
</front>
<seriesInfo name="RFC" value="8197"/>
<seriesInfo name="DOI" value="10.17487/RFC8197"/>
</reference>

<reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8224" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml">
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author initials="J." surname="Peterson" fullname="J. Peterson"><organization/></author>
<author initials="C." surname="Jennings" fullname="C. Jennings"><organization/></author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla"><organization/></author>
<author initials="C." surname="Wendt" fullname="C. Wendt"><organization/></author>
<date year="2018" month="February"/>
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t><t>This document obsoletes RFC 4474.</t></abstract>
</front>
<seriesInfo name="RFC" value="8224"/>
<seriesInfo name="DOI" value="10.17487/RFC8224"/>
</reference>

<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor"><organization/></author>
<date year="2017" month="December"/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference>

<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
<author initials="A." surname="Keranen" fullname="A. Keranen"><organization/></author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg"><organization/></author>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<date year="2018" month="July"/>
<abstract><t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t><t>This document obsoletes RFC 5245.</t></abstract>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc category="std" docName="draft-ietf-sipcore-rejected-09" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" version="3" number="9999" symRefs="true" sortRefs="true">
- <-- xml2rfc v2v3 conversion 2.23.1 -->
- <front>
  - <title abbrev="SIP Response Code for Rejected Calls">
    - A Session Initiation Protocol (SIP) Response Code for Rejected Calls
    - </title>
  - <seriesInfo name="Internet-Draft" "RFC" value="draft-ietf-sipcore-rejected-09" "9999" />
  - <author fullname="Eric W. Burger" initials="E.W." surname="Burger">
    - <organization>
      - Georgetown University
      - </organization>
    - <address>
      - <postal>
        
        <street>
        
        37th & O St, NW
        
        </street>
        
        <city>
        
        Washington
        
        </city>
        
        <region>
        
        DC
        
        </region>
        
        <code>
        
        20057
        
        </code>
        
        <country>
        
        USA
        
        </country>
        
        </postal>
      - <email>
        
        eburger@standardstrack.com
        
        </email>
      - </address>
    - </author>
  - <author fullname="Bhavik Nagda" initials="B." surname="Nagda">
    - <organization>
      - Massachusetts Institute of Technology
      - </organization>
    - <address>
      - <postal>
        
        <street>
        
        77 Massachusetts Avenue
        
        </street>
        
        <city>
        
        Cambridge
        
        </city>
        
        <region>
        
        MA
        
        </region>
        
        <code>
        
        02139
        
        </code>
        
        <country>
        
        USA
        
        </country>
        
        </postal>
      - <phone/>
      - <email>
        
        nagdab@gmail.com
        
        </email>
      - <uri/>
      - </address>
    - </author>
  - <-- If the month and year are both specified and are the current ones, xml2rfc will fill
    in the current day for you. If only the current year is specified, xml2rfc will fill
    in the current day and month for you. If the year is not the current one, it is
    necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
    purpose of calculating the expiry date). With drafts it is normally sufficient to
    specify just the year. -->
  - <date day="28" month="June" "August" year="2019"/>
  - <-- Meta-data Declarations -->
  - <area>
    - RAI
    - </area>
  - <workgroup>
    - SIPCORE
    - </workgroup>
  - <keyword>
    - STIR
    - </keyword>
  - <keyword>
    - SIPCORE
    - </keyword>
  - <keyword>
    - IANA
    - </keyword>
  - <abstract>
    - <t>
      - This document defines the 608 (Rejected) SIP response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus no one will answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code, which a human at the target User Agent Server indicated the user did not want the call. In some jurisdictions this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked.
      - </t>
    - </abstract>
  - </front>
- <middle>
  - <section numbered="true" toc="default">
    - <name>
      - Introduction
      - </name>
    - <t>
      - The IETF has been addressing numerous issues surrounding how to handle unwanted and, depending on the jurisdiction, illegal calls <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5039" format="default"/>. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7340" format="default">STIR</xref> and <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SHAKEN" format="default">SHAKEN</xref> address the cryptographic signing and attestation, respectively, of signaling to ensure the integrity and authenticity of the asserted caller identity.
      - </t>
    - <t>
      - This document describes a new <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3261" format="default">Session Initiation Protocol (SIP)</xref> response code, 608, which allows calling parties to learn that an intermediary rejected their call. As described below, we need a distinct indicator to differentiate between a user rejection and an intermediary's rejection of a call. In some jurisdictions, service providers may not be permitted to block calls, even if unwanted by the user, unless there is an explicit user request. Moreover, users may misidentify the nature of a caller.
      - </t>
    - <t>
      - For example, a legitimate caller may call a user who finds the call to be unwanted. However, instead of marking the call as unwanted, the user may mark the call as illegal. With that information, an analytics engine may determine to block all calls from that source. However, in some jurisdictions blocking calls from that source for other users may not be legal. Likewise, one can envision jurisdictions that allow an operator to block such calls, but only if there is a remediation mechanism in place to address false positives.
      - </t>
    - <t>
      - Some call blocking services may return responses such as 604 (Does Not Exist Anywhere). This might be a strategy to try to get a destination's address removed from a calling database. However, other network elements might also interpret this to mean the user truly does not exist, which might result in the user not being able to receive calls from anyone, even if they wanted to receive the calls. In many jurisdictions, providing such false signaling is also illegal.
      - </t>
    - <t>
      - The 608 response code addresses this need of remediating falsely blocked calls. Specifically, this code informs the SIP User Agent Client (UAC) that an intermediary blocked the call and provides a redress mechanism that allows callers to contact the operator of the intermediary.
      - </t>
    - <t>
      - In the current call handling ecosystem, users can explicitly reject a call or later mark a call as being unwanted by issuing a <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8197" format="default">607 SIP response code (Unwanted)</xref>. Figures <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="uas_reject" format="default"/> "counter"/> and <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="reject_ladder" format="default"/> "counter"/> show the operation of the 607 SIP response code. The User Agent Server (UAS) indicates the call was unwanted. As <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8197" format="default"/> explains, not only does the called party desire to reject that call, they can let their proxy know that they consider future calls from that source unwanted. Upon receipt of the 607 response from the UAS, the proxy 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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8197" format="default"/>, if a network operator receives multiple reports of unwanted calls, that may indicate that the entity placing the calls is likely to be a source of unwanted calls for many people. As such, other customers of the service provider may want the service provider to automatically reject calls on their behalf.
      - </t>
    - <t>
      - There is another value of the 607 rejection code. Presuming the proxy forwards the response code to the User Agent Client (UAC), the calling UAC or intervening proxies will also learn the user is not interested in receiving calls from that sender.
      - </t>
    - <figure anchor="uas_reject">
      - <name>
        
        Unwanted (607) Call Flow
        
        </name>
      - <artwork name="" type="" align="left" alt="">
        
                              +-----------+
                              |   Call    |
                              | Analytics |
                              |  Engine   |
                              +-----------+
                                 ^     | (likely not SIP)
                                 |     v
                              +-----------+
           +-----+    607     |  Called   |    607    +-----+
           | UAC | <--------- |  Party    | <-------- | UAS |
           +-----+            |  Proxy    |           +-----+
                              +-----------+
        
        
        
        </artwork>
      - </figure>
    - <t>
      - For calls rejected with a 607 from a legitimate caller, receiving a 607 response code can inform the caller to stop attempting to call the user. Moreover, if a legitimate caller believes the user is rejecting their calls in error, they can use other channels to contact the user. For example, if a pharmacy calls a user to let them know their prescription is available for pickup and the user mistakenly thinks the call is unwanted and issues a 607 response code, the pharmacy, having an existing relationship with the customer, can send the user an email or push a note to the pharmacist to ask the customer to consider not rejecting their calls in the future.
      - </t>
    - <t>
      - Many systems that allow the user to mark the call unwanted (e.g., with the 607 response code) also allow the user to change their mind and unmark such calls. This mechanism is relatively easy to implement as the user usually has a direct relationship with the service provider that is blocking calls.
      - </t>
    - <t>
      - However, things become more complicated if an intermediary, such as a third-party provider of call management services that classifies calls based on the relative likelihood that the call is unwanted, misidentifies the call as unwanted. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="cae_reject" format="default"/> 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 beneficial for the caller to learn who rejected the call, so they can correct the misidentification.
      - </t>
    - <figure anchor="reject_ladder">
      - <name>
        
        Unwanted (607) Ladder Diagram
        
        </name>
      - <artwork name="" type="" align="left" alt="">
        
                            +--------+         +-----------+
                            | Called |         |   Call    |
           +-----+          | Party  |         | Analytics |   +-----+
           | UAC |          | Proxy  |         |  Engine   |   | UAS |
           +-----+          +--------+         +-----------+   +-----+
              |  INVITE         |                    |            |
              | --------------> |  Is call OK?       |            |
              |                 |------------------->|            |
              |                 |                    |            |
              |                 |               Yes  |            |
              |                 |<-------------------|            |
              |                 |                    |            |
              |                 | INVITE             |            |
              |                 | ------------------------------> |
              |                 |                    |            |
              |                 |                    |       607  |
              |                 | <------------------------------ |
              |                 |                    |            |
              |                 |  Unwanted call     |            |
              |            607  | -----------------> |            |
              | <-------------- |  indicators        |            |
              |                 |                    |            |
        
        </artwork>
      - </figure>
    - <figure anchor="cae_reject">
      - <name>
        
        Rejected (608) Call Flow
        
        </name>
      - <artwork name="" type="" align="left" alt="">
        
                              +-----------+
                              |   Call    |
                              | Analytics |
                              |  Engine   |
                              +-----------+
                                 ^     | (likely not SIP)
                                 |     v
                              +-----------+
           +-----+    608     |  Called   |           +-----+
           | UAC | <--------- |  Party    |           | UAS |
           +-----+            |  Proxy    |           +-----+
                              +-----------+
        
        
        
        </artwork>
      - </figure>
    - <t>
      - In this situation, one might consider to have the intermediary use the 607 response code. 607 indicates to the caller the subscriber does not want the call. However, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8197" format="default"/> specifies that one of the uses of 607 is to inform analytics engines that a user (human) has rejected a call. The problem here is that network elements downstream from the intermediary might interpret the 607 as coming from a user (human) who has marked the call as unwanted, as opposed to coming from an algorithm using statistics or machine learning to reject the call. An algorithm can be vulnerable to the <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="BaseRate" format="default">base rate fallacy</xref> rejecting the call. In other words, those downstream entities should not rely on another entity 'deciding' the call is unwanted. By distinguishing between a (human) user rejection and 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, versus deciding whether to consider a 608 at all, and if so, weighing it appropriately.
      - </t>
    - <t>
      - It is useful for blocked callers to have a redress mechanism. One can imagine that some jurisdictions will require it. However, we must be mindful that most of the calls that intermediaries block will, in fact, be illegal and eligible for blocking. Thus, providing alternate contact information for a user would be counterproductive to protecting that user from illegal communications. This is another reason we do not propose to simply allow alternate contact information in a 607 response message.
      - </t>
    - <t>
      - Why do we not use the same mechanism an analytics service provider offers their customers? Specifically, why not have the analytics service provider allow the called party to correct a call blocked in error? The reason is while there is an existing relationship between the customer (called party) and the analytics service provider, it is unlikely there is a relationship between the caller and the analytics service provider. Moreover, there are numerous call blocking providers in the ecosystem. Therefore, we need a mechanism for indicating an intermediary rejected a call that also provides contact information for the operator of that intermediary, without exposing the target user's contact information.
      - </t>
    - <t>
      - The protocol described in this document uses existing SIP protocol mechanisms for specifying the redress mechanism. In the Call-Info header passed back to the UAC, we send additional information specifying a redress address. We choose to encode the redress address using <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7095" format="default">jCard</xref>. As we will see later in this document, this information needs to have its own, application-layer integrity protection. Thus, we use jCard rather than <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6350" format="default">vCard</xref> as we have a marshaling mechanism for creating a JavaScript Object Notation <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8259" format="default">(JSON)</xref> object, such as a jCard, and a standard integrity format for such an object, namely JSON Web Signature <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7515" format="default">(JWS)</xref>. The SIP community is familiar with this concept as it is the mechanism used by <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8224" format="default">STIR</xref>.
      - </t>
    - <t>
      - Integrity protecting the jCard with a cryptographic signature might seem unnecessary at first, but it is essential to preventing potential network attacks. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Security" format="default"/> describes the attack and why we sign the jCard in more detail.
      - </t>
    - </section>
  - <section numbered="true" toc="default">
    - <name>
      - Terminology
      - </name>
    - <t>
      - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">REQUIRED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">RECOMMENDED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">NOT RECOMMENDED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14>", and "OPTIONAL" "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC2119" format="default"/><xref "RFC2119"/> <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8174" format="default"/> "RFC8174"/> when, and only when, they appear in all capitals, as shown here.
      - </t>
    - </section>
  - <section numbered="true" toc="default">
    - <name>
      - Protocol Operation
      - </name>
    - <t>
      - This section uses the term 'intermediary' to mean the entity that acts as a SIP User Agent Server (UAS) on behalf of the user in the network, as opposed to the user's UAS (usually, but not necessarily, their phone). The intermediary could be a back-to-back user agent (B2BUA) or a SIP Proxy.
      - </t>
    - <t>
      - <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="cae_ladder" format="default"/> shows an overview of the call flow for a rejected call.
      - </t>
    - <figure anchor="cae_ladder">
      - <name>
        
        Rejected (608) Ladder Diagram
        
        </name>
      - <artwork name="" type="" align="left" alt="">
        
                            +--------+         +-----------+
                            | Called |         |   Call    |
           +-----+          | Party  |         | Analytics |   +-----+
           | UAC |          | Proxy  |         |  Engine   |   | UAS |
           +-----+          +--------+         +-----------+   +-----+
              |  INVITE         |                    |            |
              | --------------> |  Information from  |            |
              |                 | -----------------> |            |
              |                 |  INVITE            |            |
              |                 |            Reject  |            |
              |            608  | <----------------- |            |
              | <-------------- |            call    |            |
              |                 |                    |            |
        
        
        
        </artwork>
      - </figure>
    - <section numbered="true" toc="default">
      - <name>
        
        Intermediary Operation
        
        </name>
      - <t>
        
        An intermediary MAY <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> issue the 608 response code in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3261" format="default">SIP</xref> request to indicate that an intermediary rejected the offered communication as unwanted by the user. An intermediary MAY <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> issue the 608 as the value of the "cause" parameter of a SIP reason-value in a Reason header field <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3326" format="default"/>.
        
        </t>
      - <t>
        
        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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Security" format="default"/>), the intermediary MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> include a Call-Info header field in the response.
        
        </t>
      - <t>
        
        If there is a Call-Info header field, it MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> have the 'purpose' parameter of 'jwscard'. The value of the Call-Info header field MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> refer to a valid JSON Web Signature (<xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7515" format="default">JWS</xref>) encoding of a <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7095" format="default">jCard</xref> object. The following section describes the construction of the JWS.
        
        </t>
      - <t>
        
        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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3261" format="default"/> sectionFormat="of" section="16.7"/> 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.
        
        </t>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        JWS Construction
        
        </name>
      - <t>
        
        The intermediary constructs the JWS of the jCard as follows.
        
        </t>
      - <section numbered="true" toc="default">
        
        <name>
        
        JOSE Header
        
        </name>
        
        <t>
        
        The Javascript Object Signing and Encryption (JOSE) header MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> include the typ, alg, and x5u parameters from <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7515" format="default">JWS</xref>. The typ parameter MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> have the value "vcard+json". Implementations MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> support ES256 as JSON Web Algorithms (<xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7518" format="default">JWA</xref>) defines it, and MAY <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> support other registered signature algorithms. Finally, the x5u parameter MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be a URI that resolves to the public key certificate corresponding to the key used to digitally sign the JWS.
        
        </t>
        
        </section>
      - <section anchor="JWT" numbered="true" toc="default">
        
        <name>
        
        JWT Payload
        
        </name>
        
        <t>
        
        The payload contains two JSON values. The first JSON Web Token (JWT) claim that MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be present is the <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7519" format="default">iat (issued at) claim</xref>. The "iat" MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be set to the date and time of the issuance of the 608 response. This mandatory component protects the response from replay attacks.
        
        </t>
        
        <t>
        
        The second JWT claim that MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be present is the "jcard" claim. The value of the <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7095" format="default">jcard</xref> claim is a JSON array conforming to the JSON jCard data format defined in RFC7095 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7095"/>. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="JWT-IANA" format="default"/> of this document describes the registration. In the construction of the jcard claim, the "jcard" MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> include at least one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this specification MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> 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.
        
        </t>
        
        </section>
      - <section anchor="s.JWS" numbered="true" toc="default">
        
        <name>
        
        JWS Signature
        
        </name>
        
        <t>
        
        <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7515" format="default">JWS</xref> specifies the procedure for calculating the signature over the jCard JWT. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="EXAMPLES" format="default"/> of this document has a detailed example on constructing the JWS, including the signature.
        
        </t>
        
        </section>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        UAC Operation
        
        </name>
      - <t>
        
        A UAC conforming to this specification MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> include the sip.608 feature capability indicator in the Feature-Caps header field of the INVITE request.
        
        </t>
      - <t>
        
        Upon receiving a 608 response, UACs perform normal SIP processing for 6xx responses.
        
        </t>
      - <t>
        
        As for the disposition of the jCard itself, the UAC MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> check the "iat" claim in the JWT. As noted in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="s.JWS" format="default"/>, we are concerned about replay attacks. Therefore, the UAC MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> 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.
        
        </t>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        Legacy Interoperation
        
        </name>
      - <t>
        
        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?
        
        </t>
      - <t>
        
        We address this situation by having the first network element that conforms with this specification play an announcement in the media. See <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="announcement" format="default"/> for requirements on the announcement. The simple rule is a network element that inserts the sip.608 feature capability MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be able to convey at a minimum how to contact the operator of the intermediary that rejected the call attempt.
        
        </t>
      - <t>
        
        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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="announcement" format="default"/> "counter"/> and <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Security" format="default"/> "counter"/> do not hold, the intermediary MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> play the announcement.
        
        </t>
      - <t>
        
        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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> insert the sip.608 feature capability, per the behaviors described in Section 4.2 of <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6809" format="default"/>. sectionFormat="of" section="4.2"/>.
        
        </t>
      - <t>
        
        Do note that even if a network element plays an announcement describing the contents of the 608 response message, the network element MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> forward the 608 response code message as the final response to the INVITE.
        
        </t>
      - <t>
        
        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 (<xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7092" format="default">SBC</xref>), or proxy) need to understand the sip.608 feature capability. If the other network elements conform to Section 16.6 of <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3261" format="default"/>, sectionFormat="of" section="16.6"/>, they will pass header fields such as "Feature-Caps: *;+sip.608" unmodified and without need for upgrade.
        
        </t>
      - <t>
        
        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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> include support for <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3262" format="default">100Rel</xref> in its INVITE and the network element conveying the announcement MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> Require 100Rel in the 183 and the UAC MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> issue a PRACK to which the network element MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> respond 200 OK PRACK.
        
        </t>
      - </section>
    - <section anchor="announcement" numbered="true" toc="default">
      - <name>
        
        Announcement Requirements
        
        </name>
      - <t>
        
        There are a few requirements on the element that handles the announcement for legacy interoperation.
        
        </t>
      - <t>
        
        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.
        
        </t>
      - <t>
        
        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 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4566" format="default">(SDP)</xref> to result in an audio announcement. Likewise, if the INVITE only indicated a <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4103" format="default">real-time text codec</xref> and the network element can render the information in the requested media format, the network element should send the information in a text format.
        
        </t>
      - <t>
        
        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.
        
        </t>
      - </section>
    - </section>
  - <section anchor="EXAMPLES" numbered="true" toc="default">
    - <name>
      - Examples
      - </name>
    - <t>
      - 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.
      - </t>
    - <section numbered="true" toc="default">
      - <name>
        
        Full Exchange
        
        </name>
      - <t>
        
        Given an INVITE, shamelessly taken from <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SHAKEN" format="default"/>, with the line breaks in the Identity header field for display purposes only:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        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: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
        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
        
        
        </artwork>
      - <t>
        
        An intermediary could reply:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        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
        
        </artwork>
      - <t>
        
        The location https://block.example.net/complaint-jws resolves to a JWS. One would construct the JWS as follows.
        
        </t>
      - <t>
        
        The JWS header of this example jCard could be:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        <sourcecode name="JWS-header" type="json">
        
        { "alg":"ES256",
        "typ":"vcard+json",
        "x5u":"https://certs.example.net/reject_key.cer" }
        }
        
        </sourcecode>
        
        </artwork>
      - <t>
        
        Now, let us construct a minimal jCard. For this example, the jCard refers the caller to an email address, remediation@blocker.example.net:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        <sourcecode name="jcard-example" type="json">
        
        ["vcard",
           [
              ["version", {}, "text", "4.0"],
            ["fn", {}, "text", "Robocall Adjudication"],
            ["email", {"type":"work"},
                      "text", "remediation@blocker.example.net"]
        ] ]
        ]
        
        </sourcecode>
        
        </artwork>
      - <t>
        
        With this jCard, we can now construct the JWT:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        <sourcecode name="jwt-from-jcard" type="json">
        
        {
           "iat":1546008698,
           "jcard":["vcard",
              [
              ["version", {}, "text", "4.0"],
              ["fn", {}, "text", "Robocall Adjudication"],
              ["email", {"type":"work"},
                        "text", "remediation@blocker.example.net"]
            ]
          ] }
        }
        
        </sourcecode>
        
        </artwork>
      - <t>
        
        To calculate the signature, we need to encode the JSON Object Signing and Encryption (JOSE) header and JWT into base64url. As an implementation note, one can trim whitespace in the JSON objects to save a few bytes. UACs MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> 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 for ease of publication 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST NOT</bcp14> insert line breaks into the base64url encodings of the JOSE header or JWT. This also means UACs MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be prepared to receive arbitrarily long octet streams from the URI referenced by the Call-Info SIP header.
        
        </t>
      - <t>
        
        base64url of JOSE header:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=
        
        </artwork>
      - <t>
        
        base64url of JWT:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        base64url of JOSE header:
        eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
        L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0=
        
        base64url of JWT:
        eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
        fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
        Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
        YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
        
        </artwork>
      - <t>
        
        In this case, the object to sign (remembering this is just a single, long line; the line breaks are for ease of review but do not appear in the actual object) is as follows:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
        K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
        ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
        ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
        bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
        IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19
        
        </artwork>
      - <t>
        
        We use the following X.509 PKCS #8-encoded ECDSA key, also shamelessly taken from <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SHAKEN" format="default"/>), 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.
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        -----BEGIN PRIVATE KEY-----
        MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
        qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
        ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
        -----END PRIVATE KEY-----
        
        -----BEGIN PUBLIC KEY-----
        MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
        78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
        -----END PUBLIC KEY-----
        
        </artwork>
      - <t>
        
        The resulting JWS, using the above key on the above object, renders the following ECDSA P-256 SHA-256 digital signature.
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
        5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
        
        </artwork>
      - <t>
        
        Thus, the JWS stored at https://blocker.example.net/complaints-jws, would contain:
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
        2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
        g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
        dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
        bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
        GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
        g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag
        
        </artwork>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        Web Site jCard
        
        </name>
      - <t>
        
        For an intermediary that provides a Web site for adjudication, the jCard could contain the following. Note 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.
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        <sourcecode name="another-jcard-example" type="json">
        
        ["vcard",
           [
              ["version", {}, "text", "4.0"],
            ["fn", {}, "text", "Robocall Adjudication"],
            ["url", {"type":"work"},
                    "text", "https://blocker.example.net/adjudication-form"]
          ]
        ]
        
        </sourcecode>
        
        </artwork>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        Multi-modal jCard
        
        </name>
      - <t>
        
        For an intermediary that provides a telephone number and a postal address, the jCard could contain the following. Note 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.
        
        </t>
      - <artwork name="" type="" align="left" alt="">
        
        <sourcecode name="multi-modal-jcard" type="json">
        
        ["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"]
          ]
        ]
        
        </sourcecode>
        
        </artwork>
      - <t>
        
        Note that it is up to the UAC to decide which jCard contact modality, if any, it will use.
        
        </t>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        Legacy Interoperability
        
        </name>
      - <t>
        
        <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="legacy_ladder" format="default"/> depicts a call flow illustrating legacy interoperability. 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 608. Per <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6809" format="default"/>, the SBC can insert "*;+sip.608" into the Feature-Caps header field for the INVITE. When the intermediary, labeled "Called Party Proxy" in the figure, rejects the call, it knows it can simply perform the processing described in this document. Since the 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 erroneous rejection. For illustrative purposes, the figure shows generic SIP Proxies in the flow. Their presence or absence or the number of proxies is not relevant to the operation of the protocol. They are in the figure to show that proxies that do not understand the sip.608 feature capability can still participate in a network offering 608 services.
        
        </t>
      - <figure anchor="legacy_ladder">
        
        <name>
        
        Legacy Operation
        
        </name>
        
        <artwork name="" type="" align="left" alt="">
        
                                                          +---------+
                                                          |  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: <...> |                               |
          |                   |                               |
                                                          +---------+
                                                          |  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: <...> |                               |
          |                   |                               |
        
        </artwork>
        
        </figure>
      - <t>
        
        When the SBC receives the 608 response code, it correlates that with the original INVITE from the UAC. The SBC remembers that it inserted the sip.608 feature capability, which means it is responsible for somehow alerting the UAC the call failed and whom to contact. At this point the SBC can play a prompt, either natively or through a mechanism such as <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4240" format="default">NETANN</xref>, that sends the relevant information in the appropriate media to the UAC. Since this is a potentially long transaction and there is a chance the UAC is using an unreliable transport protocol, 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 provide the PRACK, and the SBC will acknowledge receipt of the PRACK before playing the announcement.
        
        </t>
      - <t>
        
        As an example, the SBC could extract the FN and TEL jCard fields and play something like a special information tone (see Telcordia <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-2275" format="default">SR-2275</xref> sectionFormat="comma" section 6.21.2.1 ="6.21.2.1">SR-2275</xref> or <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="ITU.E.180.1998" format="default">ITU-T E.180</xref> sectionFormat="comma" section 7), ="7">ITU-T E.180</xref>), 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.
        
        </t>
      - <t>
        
        Note the SBC also still sends the full 608 response code, including the Call-Info header, towards the UAC.
        
        </t>
      - </section>
    - </section>
  - <section numbered="true" toc="default">
    - <name>
      - IANA Considerations
      - </name>
    - <section numbered="true" toc="default">
      - <name>
        
        SIP Response Code
        
        </name>
      - <t>
        
        This document defines a new SIP response code, 608 in the "Response Codes" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3261" format="default"/>.
        
        </t>
      - <dl newline="false" spacing="normal">
        
        <dt>
        
        Response code:
        
        </dt>
        
        <dd>
        
        608
        
        </dd>
        
        <dt>
        
        Description:
        
        </dt>
        
        <dd>
        
        Rejected
        
        </dd>
        
        <dt>
        
        Reference:
        
        </dt>
        
        <dd>
        
        [RFCXXXX]
        
        </dd>
        
        </dl>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        SIP Feature-Capability Indicator
        
        </name>
      - <t>
        
        This document defines the feature capability sip.608 in the "SIP Feature-Capability Indicator Registration Tree" registry defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6809" format="default"/>.
        
        </t>
      - <dl newline="false" spacing="normal">
        
        <dt>
        
        Name:
        
        </dt>
        
        <dd>
        
        sip.608
        
        </dd>
        
        <dt>
        
        Description:
        
        </dt>
        
        <dd>
        
        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.
        
        </dd>
        
        <dt>
        
        Reference:
        
        </dt>
        
        <dd>
        
        [RFCXXXX]
        
        </dd>
        
        </dl>
      - </section>
    - <section anchor="JWT-IANA" numbered="true" toc="default">
      - <name>
        
        JSON Web Token Claim
        
        </name>
      - <t>
        
        This document defines the new JSON Web Token claim in the "JSON Web Token Claims" sub-registry created by <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7519" format="default"/>. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="JWT" format="default"/> defines the syntax. The required information is:
        
        </t>
      - <dl newline="false" spacing="normal">
        
        <dt>
        
        Claim Name:
        
        </dt>
        
        <dd>
        
        jcard
        
        </dd>
        
        <dt>
        
        Claim Description:
        
        </dt>
        
        <dd>
        
        jCard data
        
        </dd>
        
        <dt>
        
        Change Controller:
        
        </dt>
        
        <dd>
        
        IESG
        
        </dd>
        
        <dt>
        
        Reference:
        
        </dt>
        
        <dd>
        
        [RFCXXXX], <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7095" format="default"/>
        
        </dd>
        
        </dl>
      - </section>
    - <section numbered="true" toc="default">
      - <name>
        
        Call-Info Purpose
        
        </name>
      - <t>
        
        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":
        
        </t>
      - <dl newline="false" spacing="normal">
        
        <dt>
        
        Header Field:
        
        </dt>
        
        <dd>
        
        Call-Info
        
        </dd>
        
        <dt>
        
        Parameter Name:
        
        </dt>
        
        <dd>
        
        purpose
        
        </dd>
        
        <dt>
        
        Predefined Values:
        
        </dt>
        
        <dd>
        
        Yes
        
        </dd>
        
        <dt>
        
        Reference:
        
        </dt>
        
        <dd>
        
        [RFCXXXX]
        
        </dd>
        
        </dl>
      - </section>
    - </section>
  - <section anchor="Security" numbered="true" toc="default">
    - <name>
      - Security Considerations
      - </name>
    - <t>
      - Intermediary operators need to be mindful to whom they are sending the 608 response. The intermediary could be rejecting a truly malicious caller. This raises two issues. The first is the caller, now alerted an intermediary is automatically rejecting their call attempts, may change their call behavior to defeat call blocking systems. The second, and more significant risk, is that by providing a contact in the Call-Info header field, the intermediary may be giving the malicious caller a vector for attack. In other words, the intermediary will be publishing an address that a malicious actor may use to launch an attack on the intermediary. 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 and that pass validation by <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8224" format="default">STIR</xref>.
      - </t>
    - <t>
      - Another risk is as follows. Consider an attacker that floods a proxy that supports the sip.608 feature. However, the SDP in the INVITE request refers to a victim device. Moreover, the attacker somehow knows there is a 608-aware gateway connecting to the victim who is on a segment that lacks the sip.608 feature capability. Because the mechanism described here can result in sending an audio file to the target of the SDP, an attacker could use the mechanism described by this document as an amplification attack, given a SIP INVITE can be under 1 kilobyte and an audio file can be hundreds of kilobytes. One remediation for this 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. A method for this is to only play media in response to a STIR-signed INVITE that passes validation. Beyond requiring a valid STIR signature on the INVITE, the intermediary can also use remediation procedures such as doing the connectivity checks specified by <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8445" format="default">Interactive Connectivity Establishment</xref>. If the target did not request the media, the check will fail.
      - </t>
    - <t>
      - Yet another risk is a malicious intermediary that generates a malicious 608 response with a jCard referring 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. However, instead of using that information to verify the recipient's identity, they are phishing the information for nefarious ends. A similar scenario can unfold if the malicious agent inserts a URI that points to a phishing or other site. As such, we strongly recommend the recipient validates to whom they are communicating with if 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 remediation is to require the intermediary to sign the jCard. Signing the jCard provides integrity protection. In addition, one can imagine mechanisms such as used by <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SHAKEN" format="default">SHAKEN</xref>.
      - </t>
    - <t>
      - Similarly, one can imagine an adverse agent that maliciously spoofs a 608 response with a victim's contact address to many active callers, who may then all send redress requests to the specified address (the basis for a denial-of-service attack). The process would occur as follows: (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, causing (3) the UACs to all contact the redress address at once. The jCard encoding allows the UAC to verify the blocking intermediary's identity before contacting the redress address. Specifically, because the sender signs the jCard, we can cryptographically trace the sender of the jCard. Given the protocol machinery of having a signature, one can apply local policy to decide whether to believe the sender of the jCard represents the owner of the contact information found in the jCard. This guards against a malicious agent spoofing 608 responses.
      - </t>
    - <t>
      - Specifically, one could use policies around signing certificate issuance as a mechanism for traceback to the entity issuing the jCard. One check could be verifying the identity of the subject of the certificate relates to the To header field of the initial SIP request, similar to validating the intermediary was vouching for the From header field of a SIP request with that identity. Note that we are only protecting against a malicious intermediary and not a hidden intermediary attack (formerly known as a "man in the middle attack"). Thus, we only need to ensure the signature is fresh, which is why we include "iat". For most implementations, we assume that the intermediary has a single set of contact points and will generate the jCard on demand. As such, there is no need to directly correlate HTTPS fetches to specific calls. However, since the intermediary is in control of the jCard and Call-Info response, an intermediary may choose to encode per-call information in the URI returned in a given 608 response. However, if the intermediary does go that route, the intermediary MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> use a non-deterministic URI reference mechanism and be prepared to return dummy responses to URI requests referencing calls that do not exist so that attackers attempting to glean call metadata by guessing URI's (and thus calls) will not get any actionable information from the HTTPS GET.
      - </t>
    - <t>
      - 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 ascertain whom to contact without including such 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. Thus, the Call-Info jCard could be redundant information. However, the factors going into a particular service provider's or jurisdiction's choice of whether to include Call-Info is outside the scope of this document.
      - </t>
    - </section>
  - <section anchor="Acknowledgements" numbered="true" toc="default">
    - <name>
      - Acknowledgements
      - </name>
    - <t>
      - This document liberally lifts from <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8197" format="default"/> in its text and structure. However, the mechanism and purpose of 608 is quite 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 Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on improving the draft. Tolga's suggestion to provide a mechanism for legacy interoperability served to expand the draft by 50%. In addition, Tolga came up with the jCard attack. Finally, Christer Holmberg as always provided a close reading and fixed a SIP feature capability bug found by Yehoshua Gev.
      - </t>
    - <t>
      - Of course, we appreciated the close read and five pages of comments from our estimable Area Director, Adam Roach. In addition, we received valuable comments during IETF Last Call and JWT review from Ines Robles, Mike Jones, and Brian Campbell and IESG review from Alissa Cooper, Eric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and with most glee, Warren Kumari.
      - </t>
    - <t>
      - Finally, Bhavik Nagda provided clarifying edits as well and more especially wrote and tested an implementation of the 608 response code in Kamailio. Code is available at <eref xmlns:xi="http://www.w3.org/2001/XInclude" target="https://github.com/nagdab/608_Implementation"/>. Grace Chuan from MIT regenerated and verified the JWT while working at the FCC.
      - </t>
    - </section>
  - </middle>
- <-- *****BACK MATTER ***** -->
- <back>
  - <references>
    - <name>
      - References
      - </name>
    - <references>
      - <name>
        
        Normative References
        
        </name>
      - <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        
        <front>
        
        <title>
        
        Key words for use in RFCs to Indicate Requirement Levels
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        
        <seriesInfo name="RFC" value="2119"/>
        
        <seriesInfo name="BCP" value="14"/>
        
        <author initials="S." surname="Bradner" fullname="S. Bradner">
        
        <organization/>
        
        </author>
        
        <date year="1997" month="March"/>
        
        <abstract>
        
        <t>
        
        In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
        
        <front>
        
        <title>
        
        SIP: Session Initiation Protocol
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC3261"/>
        
        <seriesInfo name="RFC" value="3261"/>
        
        <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
        
        <organization/>
        
        </author>
        
        <author initials="G." surname="Camarillo" fullname="G. Camarillo">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Johnston" fullname="A. Johnston">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Peterson" fullname="J. Peterson">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Sparks" fullname="R. Sparks">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Handley" fullname="M. Handley">
        
        <organization/>
        
        </author>
        
        <author initials="E." surname="Schooler" fullname="E. Schooler">
        
        <organization/>
        
        </author>
        
        <date year="2002" month="June"/>
        
        <abstract>
        
        <t>
        
        This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC3262" target="https://www.rfc-editor.org/info/rfc3262" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3262.xml">
        
        <front>
        
        <title>
        
        Reliability of Provisional Responses in Session Initiation Protocol (SIP)
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC3262"/>
        
        <seriesInfo name="RFC" value="3262"/>
        
        <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
        
        <organization/>
        
        </author>
        
        <date year="2002" month="June"/>
        
        <abstract>
        
        <t>
        
        This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC3326" target="https://www.rfc-editor.org/info/rfc3326" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml">
        
        <front>
        
        <title>
        
        The Reason Header Field for the Session Initiation Protocol (SIP)
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC3326"/>
        
        <seriesInfo name="RFC" value="3326"/>
        
        <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
        
        <organization/>
        
        </author>
        
        <author initials="D." surname="Oran" fullname="D. Oran">
        
        <organization/>
        
        </author>
        
        <author initials="G." surname="Camarillo" fullname="G. Camarillo">
        
        <organization/>
        
        </author>
        
        <date year="2002" month="December"/>
        
        <abstract>
        
        <t>
        
        The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC6809" target="https://www.rfc-editor.org/info/rfc6809" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6809.xml">
        
        <front>
        
        <title>
        
        Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC6809"/>
        
        <seriesInfo name="RFC" value="6809"/>
        
        <author initials="C." surname="Holmberg" fullname="C. Holmberg">
        
        <organization/>
        
        </author>
        
        <author initials="I." surname="Sedlacek" fullname="I. Sedlacek">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Kaplan" fullname="H. Kaplan">
        
        <organization/>
        
        </author>
        
        <date year="2012" month="November"/>
        
        <abstract>
        
        <t>
        
        This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.
        
        </t>
        
        <t>
        
        SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.
        
        </t>
        
        <t>
        
        This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC7095" target="https://www.rfc-editor.org/info/rfc7095" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml">
        
        <front>
        
        <title>
        
        jCard: The JSON Format for vCard
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC7095"/>
        
        <seriesInfo name="RFC" value="7095"/>
        
        <author initials="P." surname="Kewisch" fullname="P. Kewisch">
        
        <organization/>
        
        </author>
        
        <date year="2014" month="January"/>
        
        <abstract>
        
        <t>
        
        This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
        
        <front>
        
        <title>
        
        JSON Web Signature (JWS)
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        
        <seriesInfo name="RFC" value="7515"/>
        
        <author initials="M." surname="Jones" fullname="M. Jones">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Bradley" fullname="J. Bradley">
        
        <organization/>
        
        </author>
        
        <author initials="N." surname="Sakimura" fullname="N. Sakimura">
        
        <organization/>
        
        </author>
        
        <date year="2015" month="May"/>
        
        <abstract>
        
        <t>
        
        JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
        
        <front>
        
        <title>
        
        JSON Web Algorithms (JWA)
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC7518"/>
        
        <seriesInfo name="RFC" value="7518"/>
        
        <author initials="M." surname="Jones" fullname="M. Jones">
        
        <organization/>
        
        </author>
        
        <date year="2015" month="May"/>
        
        <abstract>
        
        <t>
        
        This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
        
        <front>
        
        <title>
        
        JSON Web Token (JWT)
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC7519"/>
        
        <seriesInfo name="RFC" value="7519"/>
        
        <author initials="M." surname="Jones" fullname="M. Jones">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Bradley" fullname="J. Bradley">
        
        <organization/>
        
        </author>
        
        <author initials="N." surname="Sakimura" fullname="N. Sakimura">
        
        <organization/>
        
        </author>
        
        <date year="2015" month="May"/>
        
        <abstract>
        
        <t>
        
        JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        
        <front>
        
        <title>
        
        Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        
        <seriesInfo name="RFC" value="8174"/>
        
        <seriesInfo name="BCP" value="14"/>
        
        <author initials="B." surname="Leiba" fullname="B. Leiba">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="May"/>
        
        <abstract>
        
        <t>
        
        RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - </references>
    - <references>
      - <name>
        
        Informative References
        
        </name>
      - <reference anchor="RFC4103" target="https://www.rfc-editor.org/info/rfc4103" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4103.xml">
        
        <front>
        
        <title>
        
        RTP Payload for Text Conversation
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC4103"/>
        
        <seriesInfo name="RFC" value="4103"/>
        
        <author initials="G." surname="Hellstrom" fullname="G. Hellstrom">
        
        <organization/>
        
        </author>
        
        <author initials="P." surname="Jones" fullname="P. Jones">
        
        <organization/>
        
        </author>
        
        <date year="2005" month="June"/>
        
        <abstract>
        
        <t>
        
        This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.
        
        </t>
        
        <t>
        
        One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.
        
        </t>
        
        <t>
        
        This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC4240" target="https://www.rfc-editor.org/info/rfc4240" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4240.xml">
        
        <front>
        
        <title>
        
        Basic Network Media Services with SIP
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC4240"/>
        
        <seriesInfo name="RFC" value="4240"/>
        
        <author initials="E." surname="Burger" fullname="E. Burger" role="editor">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Van Dyke" fullname="J. Van Dyke">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Spitzer" fullname="A. Spitzer">
        
        <organization/>
        
        </author>
        
        <date year="2005" month="December"/>
        
        <abstract>
        
        <t>
        
        In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
        
        </t>
        
        <t>
        
        This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
        
        <front>
        
        <title>
        
        SDP: Session Description Protocol
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC4566"/>
        
        <seriesInfo name="RFC" value="4566"/>
        
        <author initials="M." surname="Handley" fullname="M. Handley">
        
        <organization/>
        
        </author>
        
        <author initials="V." surname="Jacobson" fullname="V. Jacobson">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Perkins" fullname="C. Perkins">
        
        <organization/>
        
        </author>
        
        <date year="2006" month="July"/>
        
        <abstract>
        
        <t>
        
        This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC5039" target="https://www.rfc-editor.org/info/rfc5039" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5039.xml">
        
        <front>
        
        <title>
        
        The Session Initiation Protocol (SIP) and Spam
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC5039"/>
        
        <seriesInfo name="RFC" value="5039"/>
        
        <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Jennings" fullname="C. Jennings">
        
        <organization/>
        
        </author>
        
        <date year="2008" month="January"/>
        
        <abstract>
        
        <t>
        
        Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. This memo provides information for the Internet community.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC6350" target="https://www.rfc-editor.org/info/rfc6350" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml">
        
        <front>
        
        <title>
        
        vCard Format Specification
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC6350"/>
        
        <seriesInfo name="RFC" value="6350"/>
        
        <author initials="S." surname="Perreault" fullname="S. Perreault">
        
        <organization/>
        
        </author>
        
        <date year="2011" month="August"/>
        
        <abstract>
        
        <t>
        
        This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC7092" target="https://www.rfc-editor.org/info/rfc7092" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
        
        <front>
        
        <title>
        
        A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC7092"/>
        
        <seriesInfo name="RFC" value="7092"/>
        
        <author initials="H." surname="Kaplan" fullname="H. Kaplan">
        
        <organization/>
        
        </author>
        
        <author initials="V." surname="Pascual" fullname="V. Pascual">
        
        <organization/>
        
        </author>
        
        <date year="2013" month="December"/>
        
        <abstract>
        
        <t>
        
        In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).
        
        </t>
        
        <t>
        
        There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC7340" target="https://www.rfc-editor.org/info/rfc7340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml">
        
        <front>
        
        <title>
        
        Secure Telephone Identity Problem Statement and Requirements
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC7340"/>
        
        <seriesInfo name="RFC" value="7340"/>
        
        <author initials="J." surname="Peterson" fullname="J. Peterson">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
        
        <organization/>
        
        </author>
        
        <date year="2014" month="September"/>
        
        <abstract>
        
        <t>
        
        Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC8197" target="https://www.rfc-editor.org/info/rfc8197" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8197.xml">
        
        <front>
        
        <title>
        
        A SIP Response Code for Unwanted Calls
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC8197"/>
        
        <seriesInfo name="RFC" value="8197"/>
        
        <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="July"/>
        
        <abstract>
        
        <t>
        
        This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8224" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml">
        
        <front>
        
        <title>
        
        Authenticated Identity Management in the Session Initiation Protocol (SIP)
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC8224"/>
        
        <seriesInfo name="RFC" value="8224"/>
        
        <author initials="J." surname="Peterson" fullname="J. Peterson">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Jennings" fullname="C. Jennings">
        
        <organization/>
        
        </author>
        
        <author initials="E." surname="Rescorla" fullname="E. Rescorla">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Wendt" fullname="C. Wendt">
        
        <organization/>
        
        </author>
        
        <date year="2018" month="February"/>
        
        <abstract>
        
        <t>
        
        The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.
        
        </t>
        
        <t>
        
        This document obsoletes RFC 4474.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
        
        <front>
        
        <title>
        
        The JavaScript Object Notation (JSON) Data Interchange Format
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        
        <seriesInfo name="RFC" value="8259"/>
        
        <seriesInfo name="STD" value="90"/>
        
        <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="December"/>
        
        <abstract>
        
        <t>
        
        JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
        
        </t>
        
        <t>
        
        This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
        
        <front>
        
        <title>
        
        Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
        
        </title>
        
        <seriesInfo name="DOI" value="10.17487/RFC8445"/>
        
        <seriesInfo name="RFC" value="8445"/>
        
        <author initials="A." surname="Keranen" fullname="A. Keranen">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Holmberg" fullname="C. Holmberg">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
        
        <organization/>
        
        </author>
        
        <date year="2018" month="July"/>
        
        <abstract>
        
        <t>
        
        This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).
        
        </t>
        
        <t>
        
        This document obsoletes RFC 5245.
        
        </t>
        
        </abstract>
        
        </front>
        
        </reference>
      - <reference anchor="SHAKEN" target="https://www.sipforum.org/download/sip-forum-twg-10-signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813">
        
        <front>
        
        <title>
        
        Signature-based Handling of Asserted information using toKENs (SHAKEN)
        
        </title>
        
        <seriesInfo name="ATIS" value="1000074"/>
        
        <author>
        
        <organization>
        
        Alliance for Telecommunications Industry Solutions (ATIS) and the SIP Forum
        
        </organization>
        
        </author>
        
        <date day="5" month="1" year="2017"/>
        
        </front>
        
        </reference>
      - <reference anchor="BaseRate" target=" https://apps.dtic.mil/docs/citations/ADA045772">
        
        <front>
        
        <title>
        
        The Base-Rate Fallacy in Probability Judgements
        
        </title>
        
        <author fullname="Maya Bar-Hillel" initials="M." surname="Bar-Hillel">
        
        <organization>
        
        Hebrew University
        
        </organization>
        
        </author>
        
        <date month="4" year="1977"/>
        
        </front>
        
        </reference>
      - <reference anchor="ITU.E.180.1998">
        
        <front>
        
        <title>
        
        Technical characteristics of tones for the telephone service
        
        </title>
        
        <seriesInfo name="ITU" value="Recommendation E.180/Q.35"/>
        
        <author>
        
        <organization>
        
        International Telecommunications Union
        
        </organization>
        
        </author>
        
        <date month="March" year="1998"/>
        
        </front>
        
        </reference>
      - <reference anchor="SR-2275">
        
        <front>
        
        <title>
        
        Bellcore Notes on the Networks
        
        </title>
        
        <seriesInfo name="Telcordia" value="SR-2275"/>
        
        <author>
        
        <organization>
        
        Telcordia
        
        </organization>
        
        </author>
        
        <date month="October" year="2000"/>
        
        </front>
        
        </reference>
      - </references>
    - </references>
  - </back>
- </rfc>

<?xml version='1.0' encoding='utf-8'?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     number="9999" ipr="trust200902" obsoletes=""
     updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.23.1 -->
  <front>
    <title abbrev="SIP Response Code for Rejected Calls">A Session Initiation
    Protocol (SIP) Response Code for Rejected Calls</title>

    <seriesInfo name="RFC" value="9999"/>

    <author fullname="Eric W. Burger" initials="E.W." surname="Burger">
      <organization>Georgetown University</organization>
      <address>
        <postal>
          <street>37th &amp; O St, NW</street>
          <city>Washington</city>
          <region>DC</region>
          <code>20057</code>
          <country>USA</country>
        </postal>
        <email>eburger@standardstrack.com</email>
      </address>
    </author>
    <author fullname="Bhavik Nagda" initials="B." surname="Nagda">
      <organization>Massachusetts Institute of Technology</organization>
      <address>
        <postal>
          <street>77 Massachusetts Avenue</street>
          <city>Cambridge</city>
          <region>MA</region>
          <code>02139</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>nagdab@gmail.com</email>
        <uri/>
      </address>
    </author>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->
    <date month="August" year="2019"/>
    <!-- Meta-data Declarations -->
    <area>RAI</area>
    <workgroup>SIPCORE</workgroup>
    <keyword>STIR</keyword>
    <keyword>SIPCORE</keyword>
    <keyword>IANA</keyword>
    <abstract>
      <t>This document defines the 608 (Rejected) SIP response code. This
      response code enables calling parties to learn that an intermediary
      rejected their call attempt. No one will deliver, and thus no one will
      answer, the call. As a 6xx code, the caller will be aware that future
      attempts to contact the same User Agent Server will likely fail. The
      initial use case driving the need for the 608 response code is when the
      intermediary is an analytics engine. In this case, the rejection is by a
      machine or other process. This contrasts with the 607 (Unwanted) SIP
      response code, which a human at the target User Agent Server indicated
      the user did not want the call. In some jurisdictions this distinction
      is important. This document also defines the use of the Call-Info header
      field in 608 responses to enable rejected callers to contact entities
      that blocked their calls in error. This provides a remediation mechanism
      for legal callers that find their calls blocked.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>The IETF has been addressing numerous issues surrounding how to
      handle unwanted and, depending on the jurisdiction, illegal calls <xref target="RFC5039" format="default"/>. <xref target="RFC7340" format="default">STIR</xref> and <xref target="SHAKEN" format="default">SHAKEN</xref> address the cryptographic signing and
      attestation, respectively, of signaling to ensure the integrity and
      authenticity of the asserted caller identity.</t>
      <t>This document describes a new <xref target="RFC3261" format="default">Session
      Initiation Protocol (SIP)</xref> response code, 608, which allows
      calling parties to learn that an intermediary rejected their call. As
      described below, we need a distinct indicator to differentiate between a
      user rejection and an intermediary's rejection of a call. In some
      jurisdictions, service providers may not be permitted to block calls,
      even if unwanted by the user, unless there is an explicit user request.
      Moreover, users may misidentify the nature of a caller.</t>
      <t>For example, a legitimate caller may call a user who finds the call
      to be unwanted. However, instead of marking the call as unwanted, the
      user may mark the call as illegal. With that information, an analytics
      engine may determine to block all calls from that source. However, in
      some jurisdictions blocking calls from that source for other users may
      not be legal. Likewise, one can envision jurisdictions that allow an
      operator to block such calls, but only if there is a remediation
      mechanism in place to address false positives.</t>
      <t>Some call blocking services may return responses such as 604 (Does
      Not Exist Anywhere). This might be a strategy to try to get a
      destination's address removed from a calling database. However, other
      network elements might also interpret this to mean the user truly does
      not exist, which might result in the user not being able to receive
      calls from anyone, even if they wanted to receive the calls. In many
      jurisdictions, providing such false signaling is also illegal.</t>
      <t>The 608 response code addresses this need of remediating falsely
      blocked calls. Specifically, this code informs the SIP User Agent Client
      (UAC) that an intermediary blocked the call and provides a redress
      mechanism that allows callers to contact the operator of the
      intermediary.</t>
      <t>In the current call handling ecosystem, users can explicitly reject a
      call or later mark a call as being unwanted by issuing a <xref
      target="RFC8197" format="default">607 SIP response code
      (Unwanted)</xref>. Figures <xref target="uas_reject" format="counter"/>
      and <xref target="reject_ladder" format="counter"/> show the
      operation of the 607 SIP response code. The User Agent Server (UAS)
      indicates the call was unwanted. As <xref target="RFC8197" format="default"/> explains,
      not only does the called party desire to reject that call, they can let
      their proxy know that they consider future calls from that source
      unwanted. Upon receipt of the 607 response from the UAS, the proxy 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 <xref target="RFC8197" format="default"/>, if a network
      operator receives multiple reports of unwanted calls, that may indicate
      that the entity placing the calls is likely to be a source of unwanted
      calls for many people. As such, other customers of the service provider
      may want the service provider to automatically reject calls on their
      behalf.</t>
      <t>There is another value of the 607 rejection code. Presuming the proxy
      forwards the response code to the User Agent Client (UAC), the calling
      UAC or intervening proxies will also learn the user is not interested in
      receiving calls from that sender.</t>
      <figure anchor="uas_reject">
        <name>Unwanted (607) Call Flow</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                      +-----------+
                      |   Call    |
                      | Analytics |
                      |  Engine   |
                      +-----------+
                         ^     | (likely not SIP)
                         |     v
                      +-----------+
   +-----+    607     |  Called   |    607    +-----+
   | UAC | <--------- |  Party    | <-------- | UAS |
   +-----+            |  Proxy    |           +-----+
                      +-----------+  ]]></artwork> </figure>
      <t>For calls rejected with a 607 from a legitimate caller, receiving a
      607 response code can inform the caller to stop attempting to call the
      user. Moreover, if a legitimate caller believes the user is rejecting
      their calls in error, they can use other channels to contact the user.
      For example, if a pharmacy calls a user to let them know their
      prescription is available for pickup and the user mistakenly thinks the
      call is unwanted and issues a 607 response code, the pharmacy, having an
      existing relationship with the customer, can send the user an email or
      push a note to the pharmacist to ask the customer to consider not
      rejecting their calls in the future.</t>
      <t>Many systems that allow the user to mark the call unwanted (e.g.,
      with the 607 response code) also allow the user to change their mind and
      unmark such calls. This mechanism is relatively easy to implement as the
      user usually has a direct relationship with the service provider that is
      blocking calls.</t>
     <t>However, things become more complicated if an intermediary, such as a          
      third-party provider of call management services that classifies calls            
      based on the relative likelihood that the call is unwanted,                       
      misidentifies the call as unwanted. <xref target="cae_reject" format="default"/> 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 beneficial for the caller to learn who rejected            
      the call, so they can correct the misidentification.</t>

      <figure anchor="reject_ladder">
        <name>Unwanted (607) Ladder Diagram</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                    +--------+         +-----------+
                    | Called |         |   Call    |
   +-----+          | Party  |         | Analytics |   +-----+
   | UAC |          | Proxy  |         |  Engine   |   | UAS |
   +-----+          +--------+         +-----------+   +-----+
      |  INVITE         |                    |            |
      | --------------> |  Is call OK?       |            |
      |                 |------------------->|            |
      |                 |                    |            |
      |                 |               Yes  |            |
      |                 |<-------------------|            |
      |                 |                    |            |
      |                 | INVITE             |            |
      |                 | ------------------------------> |
      |                 |                    |            |
      |                 |                    |       607  |
      |                 | <------------------------------ |
      |                 |                    |            |
      |                 |  Unwanted call     |            |
      |            607  | -----------------> |            |
      | <-------------- |  indicators        |            |
      |                 |                    |            | ]]></artwork>
      </figure>

      <figure anchor="cae_reject">
        <name>Rejected (608) Call Flow</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                      +-----------+
                      |   Call    |
                      | Analytics |
                      |  Engine   |
                      +-----------+
                         ^     | (likely not SIP)
                         |     v
                      +-----------+
   +-----+    608     |  Called   |           +-----+
   | UAC | <--------- |  Party    |           | UAS |
   +-----+            |  Proxy    |           +-----+
                      +-----------+   ]]></artwork> </figure>
      <t>In this situation, one might consider to have the intermediary use
      the 607 response code. 607 indicates to the caller the subscriber does
      not want the call. However, <xref target="RFC8197" format="default"/> specifies that one
      of the uses of 607 is to inform analytics engines that a user (human)
      has rejected a call. The problem here is that network elements
      downstream from the intermediary might interpret the 607 as coming from
      a user (human) who has marked the call as unwanted, as opposed to coming
      from an algorithm using statistics or machine learning to reject the
      call. An algorithm can be vulnerable to the <xref target="BaseRate" format="default">base
      rate fallacy</xref> rejecting the call. In other words, those downstream
      entities should not rely on another entity 'deciding' the call is
      unwanted. By distinguishing between a (human) user rejection and 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, versus deciding whether to consider a 608 at all,
      and if so, weighing it appropriately.</t>
      <t>It is useful for blocked callers to have a redress mechanism. One can
      imagine that some jurisdictions will require it. However, we must be
      mindful that most of the calls that intermediaries block will, in fact,
      be illegal and eligible for blocking. Thus, providing alternate contact
      information for a user would be counterproductive to protecting that
      user from illegal communications. This is another reason we do not
      propose to simply allow alternate contact information in a 607 response
      message.</t>
      <t>Why do we not use the same mechanism an analytics service provider
      offers their customers? Specifically, why not have the analytics service
      provider allow the called party to correct a call blocked in error? The
      reason is while there is an existing relationship between the customer
      (called party) and the analytics service provider, it is unlikely there
      is a relationship between the caller and the analytics service provider.
      Moreover, there are numerous call blocking providers in the ecosystem.
      Therefore, we need a mechanism for indicating an intermediary rejected a
      call that also provides contact information for the operator of that
      intermediary, without exposing the target user's contact
      information.</t>
      <t>The protocol described in this document uses existing SIP protocol
      mechanisms for specifying the redress mechanism. In the Call-Info header
      passed back to the UAC, we send additional information specifying a
      redress address. We choose to encode the redress address using <xref target="RFC7095" format="default">jCard</xref>. As we will see later in this document,
      this information needs to have its own, application-layer integrity
      protection. Thus, we use jCard rather than <xref target="RFC6350" format="default">vCard</xref> as we have a marshaling mechanism for
      creating a JavaScript Object Notation <xref target="RFC8259" format="default">(JSON)</xref> object, such as a jCard, and a standard
      integrity format for such an object, namely JSON Web Signature <xref target="RFC7515" format="default">(JWS)</xref>. The SIP community is familiar with this
      concept as it is the mechanism used by <xref target="RFC8224" format="default">STIR</xref>.</t>
      <t>Integrity protecting the jCard with a cryptographic signature might
      seem unnecessary at first, but it is essential to preventing potential
      network attacks. <xref target="Security" format="default"/> describes the attack and why
      we sign the jCard in more detail.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Terminology</name>

    <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
    "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
    "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>

    </section>
    <section numbered="true" toc="default">
      <name>Protocol Operation</name>
      <t>This section uses the term 'intermediary' to mean the entity that
      acts as a SIP User Agent Server (UAS) on behalf of the user in the
      network, as opposed to the user's UAS (usually, but not necessarily,
      their phone). The intermediary could be a back-to-back user agent
      (B2BUA) or a SIP Proxy.</t>
      <t><xref target="cae_ladder" format="default"/> shows an overview of the call flow for a
      rejected call.</t>
      <figure anchor="cae_ladder">
        <name>Rejected (608) Ladder Diagram</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                    +--------+         +-----------+
                    | Called |         |   Call    |
   +-----+          | Party  |         | Analytics |   +-----+
   | UAC |          | Proxy  |         |  Engine   |   | UAS |
   +-----+          +--------+         +-----------+   +-----+
      |  INVITE         |                    |            |
      | --------------> |  Information from  |            |
      |                 | -----------------> |            |
      |                 |  INVITE            |            |
      |                 |            Reject  |            |
      |            608  | <----------------- |            |
      | <-------------- |            call    |            |
      |                 |                    |            | ]]></artwork> </figure>
      <section numbered="true" toc="default">
        <name>Intermediary Operation</name>
        <t>An intermediary <bcp14>MAY</bcp14> issue the 608 response code in a failure
        response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog
        <xref target="RFC3261" format="default">SIP</xref> request to indicate that an
        intermediary rejected the offered communication as unwanted by the
        user. An intermediary <bcp14>MAY</bcp14> issue the 608 as the value of the "cause"
        parameter of a SIP reason-value in a Reason header field <xref target="RFC3326" format="default"/>.</t>
        <t>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 <xref target="Security" format="default"/>), the
        intermediary <bcp14>MUST</bcp14> include a Call-Info header field in the
        response.</t>
        <t>If there is a Call-Info header field, it <bcp14>MUST</bcp14> have the 'purpose'
        parameter of 'jwscard'. The value of the Call-Info header field <bcp14>MUST</bcp14>
        refer to a valid JSON Web Signature (<xref target="RFC7515" format="default">JWS</xref>) encoding of a <xref target="RFC7095" format="default">jCard</xref> object. The following section describes
        the construction of the JWS.</t>
        <t>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
        <xref target="RFC3261" sectionFormat="of" section="16.7"/> 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.</t>
      </section>
      <section numbered="true" toc="default">
        <name>JWS Construction</name>
        <t>The intermediary constructs the JWS of the jCard as follows.</t>
        <section numbered="true" toc="default">
          <name>JOSE Header</name>
          <t>The Javascript Object Signing and Encryption (JOSE) header <bcp14>MUST</bcp14>
          include the typ, alg, and x5u parameters from <xref target="RFC7515" format="default">JWS</xref>. The typ parameter <bcp14>MUST</bcp14> have the value
          "vcard+json". Implementations <bcp14>MUST</bcp14> support ES256 as JSON Web
          Algorithms (<xref target="RFC7518" format="default">JWA</xref>) defines it, and <bcp14>MAY</bcp14>
          support other registered signature algorithms. Finally, the x5u
          parameter <bcp14>MUST</bcp14> be a URI that resolves to the public key certificate
          corresponding to the key used to digitally sign the JWS.</t>
        </section>
        <section anchor="JWT" numbered="true" toc="default">
          <name>JWT Payload</name>
          <t>The payload contains two JSON values. The first JSON Web Token
          (JWT) claim that <bcp14>MUST</bcp14> be present is the <xref target="RFC7519" format="default">iat
          (issued at) claim</xref>. The "iat" <bcp14>MUST</bcp14> be set to the date and time
          of the issuance of the 608 response. This mandatory component
          protects the response from replay attacks.</t>
          <t>The second JWT claim that <bcp14>MUST</bcp14> be present is the "jcard" claim.
          The value of the <xref target="RFC7095" format="default">jcard</xref> claim is a JSON
          array conforming to the JSON jCard data format defined in <xref
	  target="RFC7095"/>.
          <xref target="JWT-IANA" format="default"/> of this document describes the registration. In the
          construction of the jcard claim, the "jcard" <bcp14>MUST</bcp14> include at least
          one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this
          specification <bcp14>MUST</bcp14> 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.</t>
        </section>
        <section anchor="s.JWS" numbered="true" toc="default">
          <name>JWS Signature</name>
          <t><xref target="RFC7515" format="default">JWS</xref> specifies the procedure for
          calculating the signature over the jCard JWT. <xref target="EXAMPLES" format="default"/> of this document has a detailed example on
          constructing the JWS, including the signature.</t>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>UAC Operation</name>
        <t>A UAC conforming to this specification <bcp14>MUST</bcp14> include the sip.608
        feature capability indicator in the Feature-Caps header field of the
        INVITE request.</t>
        <t>Upon receiving a 608 response, UACs perform normal SIP processing
        for 6xx responses.</t>
        <t>As for the disposition of the jCard itself, the UAC <bcp14>MUST</bcp14> check the
        "iat" claim in the JWT. As noted in <xref target="s.JWS" format="default"/>, we are
        concerned about replay attacks. Therefore, the UAC <bcp14>MUST</bcp14> 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.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Legacy Interoperation</name>
        <t>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?</t>
        <t>We address this situation by having the first network element that
        conforms with this specification play an announcement in the media.
        See <xref target="announcement" format="default"/> for requirements on the
        announcement. The simple rule is a network element that inserts the
        sip.608 feature capability <bcp14>MUST</bcp14> be able to convey at a minimum how to
        contact the operator of the intermediary that rejected the call
        attempt.</t>
        <t>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 <xref target="announcement" format="counter"/> and
        <xref target="Security" format="counter"/> do not hold, the
        intermediary <bcp14>MUST</bcp14> play the announcement.</t>
        <t>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 <bcp14>MUST</bcp14> insert the sip.608
        feature capability, per the behaviors described in
        <xref target="RFC6809" sectionFormat="of" section="4.2"/>.</t>
        <t>Do note that even if a network element plays an announcement
        describing the contents of the 608 response message, the network
        element <bcp14>MUST</bcp14> forward the 608 response code message as the final
        response to the INVITE.</t>
        <t>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 (<xref target="RFC7092" format="default">SBC</xref>), or proxy) need to understand the sip.608
        feature capability. If the other network elements conform to
        <xref target="RFC3261" sectionFormat="of" section="16.6"/>, they will pass header fields such as
        "Feature-Caps: *;+sip.608" unmodified and without need for
        upgrade.</t>
        <t>Because the ultimate disposition of the call attempt will be a
        600-class response, the network element conveying the announcement in
        the legacy direction <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> include
        support for <xref target="RFC3262" format="default">100Rel</xref> in its INVITE and the
        network element conveying the announcement <bcp14>MUST</bcp14> Require 100Rel in the
        183 and the UAC <bcp14>MUST</bcp14> issue a PRACK to which the network element <bcp14>MUST</bcp14>
        respond 200 OK PRACK.</t>
      </section>
      <section anchor="announcement" numbered="true" toc="default">
        <name>Announcement Requirements</name>
        <t>There are a few requirements on the element that handles the
        announcement for legacy interoperation.</t>
        <t>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.</t>
        <t>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 <xref target="RFC4566" format="default">(SDP)</xref> to result in an audio announcement.
        Likewise, if the INVITE only indicated a <xref target="RFC4103" format="default">real-time text codec</xref> and the network element
        can render the information in the requested media format, the network
        element should send the information in a text format.</t>
        <t>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.</t>
      </section>
    </section>
    <section anchor="EXAMPLES" numbered="true" toc="default">
      <name>Examples</name>
      <t>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.</t>
      <section numbered="true" toc="default">
        <name>Full Exchange</name>
        <t>Given an INVITE, shamelessly taken from <xref target="SHAKEN" format="default"/>,
        with the line breaks in the Identity header field for display purposes
        only:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
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: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
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 ]]></artwork>

        <t>An intermediary could reply:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
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  ]]></artwork>

        <t>The location https://block.example.net/complaint-jws resolves to a
        JWS. One would construct the JWS as follows.</t>
        <t>The JWS header of this example jCard could be:</t>

        <sourcecode name="JWS-header" type="json"><![CDATA[{ "alg":"ES256",
  "typ":"vcard+json",
  "x5u":"https://certs.example.net/reject_key.cer"
} ]]></sourcecode>

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

        <sourcecode name="jcard-example" type="json"><![CDATA[["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["email", {"type":"work"}, 
              "text", "remediation@blocker.example.net"]
  ]
] ]]></sourcecode>

        <t>With this jCard, we can now construct the JWT:</t>

        <sourcecode name="jwt-from-jcard" type="json"><![CDATA[{
  "iat":1546008698,
  "jcard":["vcard",
    [
      ["version", {}, "text", "4.0"],
      ["fn", {}, "text", "Robocall Adjudication"],
      ["email", {"type":"work"}, 
                "text", "remediation@blocker.example.net"]
    ]
  ]
} ]]></sourcecode>

        <t>To calculate the signature, we need to encode the JSON Object
        Signing and Encryption (JOSE) header and JWT into base64url. As an
        implementation note, one can trim whitespace in the JSON objects to
        save a few bytes. UACs <bcp14>MUST</bcp14> 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 for ease of publication 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
        <bcp14>MUST NOT</bcp14> insert line breaks into the base64url encodings of the JOSE header
        or JWT. This also means UACs <bcp14>MUST</bcp14> be prepared to receive arbitrarily
        long octet streams from the URI referenced by the Call-Info SIP
        header.</t>

<t>base64url of JOSE header:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov
L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0= ]]></artwork>

<t>base64url of JWT:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7
fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp
Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp
YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 ]]></artwork>

        <t>In this case, the object to sign (remembering this is just a
        single, long line; the line breaks are for ease of review but do not
        appear in the actual object) is as follows:</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk
K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r
ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2
ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh
bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0
IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 ]]></artwork>

        <t>We use the following X.509 PKCS #8-encoded ECDSA key, also
        shamelessly taken from <xref target="SHAKEN" format="default"/>), 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.</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY----- ]]></artwork>

        <t>The resulting JWS, using the above key on the above object, renders
        the following ECDSA P-256 SHA-256 digital signature.</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL
5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag ]]></artwork>

        <t>Thus, the JWS stored at https://blocker.example.net/complaints-jws,
        would contain:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL
2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD
g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ
dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp
bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le
GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6
g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag ]]></artwork>

      </section>
      <section numbered="true" toc="default">
        <name>Web Site jCard</name>
        <t>For an intermediary that provides a Web site for adjudication, the
        jCard could contain the following. Note 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.</t>

        <sourcecode name="another-jcard-example" type="json"><![CDATA[["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Robocall Adjudication"],
    ["url", {"type":"work"}, 
            "text", "https://blocker.example.net/adjudication-form"]
  ]
]    ]]></sourcecode>
      </section>
      <section numbered="true" toc="default">
        <name>Multi-modal jCard</name>
        <t>For an intermediary that provides a telephone number and a postal
        address, the jCard could contain the following. Note 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.</t>

        <sourcecode name="multi-modal-jcard" type="json"><![CDATA[["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"]
  ]
]     ]]></sourcecode>

        <t>Note that it is up to the UAC to decide which jCard contact
        modality, if any, it will use.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Legacy Interoperability</name>
        <t><xref target="legacy_ladder" format="default"/> depicts a call flow illustrating
        legacy interoperability. 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 608. Per <xref target="RFC6809" format="default"/>, the SBC can
        insert "*;+sip.608" into the Feature-Caps header field for the INVITE.
        When the intermediary, labeled "Called Party Proxy" in the figure,
        rejects the call, it knows it can simply perform the processing
        described in this document. Since the 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 erroneous rejection. For
        illustrative purposes, the figure shows generic SIP Proxies in the
        flow. Their presence or absence or the number of proxies is not
        relevant to the operation of the protocol. They are in the figure to
        show that proxies that do not understand the sip.608 feature
        capability can still participate in a network offering 608
        services.</t>
        <figure anchor="legacy_ladder">
          <name>Legacy Operation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                                                  +---------+
                                                  |  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: <...> |                               |
  |                   |                               |]]></artwork> </figure>
        <t>When the SBC receives the 608 response code, it correlates that
        with the original INVITE from the UAC. The SBC remembers that it
        inserted the sip.608 feature capability, which means it is responsible
        for somehow alerting the UAC the call failed and whom to contact. At
        this point the SBC can play a prompt, either natively or through a
        mechanism such as <xref target="RFC4240" format="default">NETANN</xref>, that sends the
        relevant information in the appropriate media to the UAC. Since this
        is a potentially long transaction and there is a chance the UAC is
        using an unreliable transport protocol, 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 provide the
        PRACK, and the SBC will acknowledge receipt of the PRACK before
        playing the announcement.</t>
        <t>As an example, the SBC could extract the FN and TEL jCard fields
        and play something like a special information tone (see Telcordia
        <xref target="SR-2275" sectionFormat="comma"
        section="6.21.2.1">SR-2275</xref> or
        <xref target="ITU.E.180.1998" sectionFormat="comma" section="7">ITU-T
	E.180</xref>), 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.</t>
        <t>Note the SBC also still sends the full 608 response code, including
        the Call-Info header, towards the UAC.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>SIP Response Code</name>
        <t>This document defines a new SIP response code, 608 in the "Response
        Codes" subregistry of the "Session Initiation Protocol (SIP)
        Parameters" registry defined in <xref target="RFC3261" format="default"/>.</t>
        <dl newline="false" spacing="normal">
          <dt>Response code:</dt>
          <dd>608</dd>
          <dt>Description:</dt>
          <dd>Rejected</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX]</dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>SIP Feature-Capability Indicator</name>
        <t>This document defines the feature capability sip.608 in the "SIP
        Feature-Capability Indicator Registration Tree" registry defined in
        <xref target="RFC6809" format="default"/>.</t>
        <dl newline="false" spacing="normal">
          <dt>Name:</dt>
          <dd>sip.608</dd>
          <dt>Description:</dt>
          <dd>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.</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX]</dd>
        </dl>
      </section>
      <section anchor="JWT-IANA" numbered="true" toc="default">
        <name>JSON Web Token Claim</name>
        <t>This document defines the new JSON Web Token claim in the "JSON Web
        Token Claims" sub-registry created by <xref target="RFC7519" format="default"/>. <xref target="JWT" format="default"/> defines the syntax. The required information is:</t>
        <dl newline="false" spacing="normal">
          <dt>Claim Name:</dt>
          <dd>jcard</dd>
          <dt>Claim Description:</dt>
          <dd>jCard data</dd>
          <dt>Change Controller:</dt>
          <dd>IESG</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX], <xref target="RFC7095" format="default"/></dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>Call-Info Purpose</name>
        <t>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":</t>
        <dl newline="false" spacing="normal">
          <dt>Header Field:</dt>
          <dd>Call-Info</dd>
          <dt>Parameter Name:</dt>
          <dd>purpose</dd>
          <dt>Predefined Values:</dt>
          <dd>Yes</dd>
          <dt>Reference:</dt>
          <dd>[RFCXXXX]</dd>
        </dl>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Intermediary operators need to be mindful to whom they are sending
      the 608 response. The intermediary could be rejecting a truly malicious
      caller. This raises two issues. The first is the caller, now alerted an
      intermediary is automatically rejecting their call attempts, may change
      their call behavior to defeat call blocking systems. The second, and
      more significant risk, is that by providing a contact in the Call-Info
      header field, the intermediary may be giving the malicious caller a
      vector for attack. In other words, the intermediary will be publishing
      an address that a malicious actor may use to launch an attack on the
      intermediary. 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 and that pass validation by
      <xref target="RFC8224" format="default">STIR</xref>.</t>
      <t>Another risk is as follows. Consider an attacker that floods a proxy
      that supports the sip.608 feature. However, the SDP in the INVITE
      request refers to a victim device. Moreover, the attacker somehow knows
      there is a 608-aware gateway connecting to the victim who is on a
      segment that lacks the sip.608 feature capability. Because the mechanism
      described here can result in sending an audio file to the target of the
      SDP, an attacker could use the mechanism described by this document as
      an amplification attack, given a SIP INVITE can be under 1 kilobyte and
      an audio file can be hundreds of kilobytes. One remediation for this 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. A method for this is to only play media in response to a
      STIR-signed INVITE that passes validation. Beyond requiring a valid STIR
      signature on the INVITE, the intermediary can also use remediation
      procedures such as doing the connectivity checks specified by <xref target="RFC8445" format="default">Interactive Connectivity Establishment</xref>. If the
      target did not request the media, the check will fail.</t>
      <t>Yet another risk is a malicious intermediary that generates a
      malicious 608 response with a jCard referring 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. However, instead of using that
      information to verify the recipient's identity, they are phishing the
      information for nefarious ends. A similar scenario can unfold if the
      malicious agent inserts a URI that points to a phishing or other site.
      As such, we strongly recommend the recipient validates to whom they are
      communicating with if 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 remediation is to require the intermediary to sign the
      jCard. Signing the jCard provides integrity protection. In addition, one
      can imagine mechanisms such as used by <xref target="SHAKEN" format="default">SHAKEN</xref>.</t>
      <t>Similarly, one can imagine an adverse agent that maliciously spoofs a
      608 response with a victim's contact address to many active callers, who
      may then all send redress requests to the specified address (the basis
      for a denial-of-service attack). The process would occur as follows: (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, causing (3) the UACs to all contact the
      redress address at once. The jCard encoding allows the UAC to verify the
      blocking intermediary's identity before contacting the redress address.
      Specifically, because the sender signs the jCard, we can
      cryptographically trace the sender of the jCard. Given the protocol
      machinery of having a signature, one can apply local policy to decide
      whether to believe the sender of the jCard represents the owner of the
      contact information found in the jCard. This guards against a malicious
      agent spoofing 608 responses.</t>
      <t>Specifically, one could use policies around signing certificate
      issuance as a mechanism for traceback to the entity issuing the jCard.
      One check could be verifying the identity of the subject of the
      certificate relates to the To header field of the initial SIP request,
      similar to validating the intermediary was vouching for the From header
      field of a SIP request with that identity. Note that we are only
      protecting against a malicious intermediary and not a hidden
      intermediary attack (formerly known as a "man in the middle attack").
      Thus, we only need to ensure the signature is fresh, which is why we
      include "iat". For most implementations, we assume that the intermediary
      has a single set of contact points and will generate the jCard on
      demand. As such, there is no need to directly correlate HTTPS fetches to
      specific calls. However, since the intermediary is in control of the
      jCard and Call-Info response, an intermediary may choose to encode
      per-call information in the URI returned in a given 608 response.
      However, if the intermediary does go that route, the intermediary <bcp14>MUST</bcp14>
      use a non-deterministic URI reference mechanism and be prepared to
      return dummy responses to URI requests referencing calls that do not
      exist so that attackers attempting to glean call metadata by guessing
      URI's (and thus calls) will not get any actionable information from the
      HTTPS GET.</t>
      <t>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 ascertain whom to contact without including such
      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. Thus, the Call-Info jCard could be
      redundant information. However, the factors going into a particular
      service provider's or jurisdiction's choice of whether to include
      Call-Info is outside the scope of this document.</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>This document liberally lifts from <xref target="RFC8197" format="default"/> in its
      text and structure. However, the mechanism and purpose of 608 is quite
      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
      Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on
      improving the draft. Tolga's suggestion to provide a mechanism for
      legacy interoperability served to expand the draft by 50%. In addition,
      Tolga came up with the jCard attack. Finally, Christer Holmberg as
      always provided a close reading and fixed a SIP feature capability bug
      found by Yehoshua Gev.</t>
      <t>Of course, we appreciated the close read and five pages of comments
      from our estimable Area Director, Adam Roach. In addition, we received
      valuable comments during IETF Last Call and JWT review from Ines Robles,
      Mike Jones, and Brian Campbell and IESG review from Alissa Cooper,
      Eric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and
      with most glee, Warren Kumari.</t>
      <t>Finally, Bhavik Nagda provided clarifying edits as well and more
      especially wrote and tested an implementation of the 608 response code
      in Kamailio. Code is available at <eref target="https://github.com/nagdab/608_Implementation"/>. Grace Chuan
      from MIT regenerated and verified the JWT while working at the FCC.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC3261"/>
            <seriesInfo name="RFC" value="3261"/>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization/>
            </author>
            <author initials="A." surname="Johnston" fullname="A. Johnston">
              <organization/>
            </author>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization/>
            </author>
            <author initials="R." surname="Sparks" fullname="R. Sparks">
              <organization/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization/>
            </author>
            <author initials="E." surname="Schooler" fullname="E. Schooler">
              <organization/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3262" target="https://www.rfc-editor.org/info/rfc3262" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3262.xml">
          <front>
            <title>Reliability of Provisional Responses in Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC3262"/>
            <seriesInfo name="RFC" value="3262"/>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t>This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages.  This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3326" target="https://www.rfc-editor.org/info/rfc3326" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml">
          <front>
            <title>The Reason Header Field for the Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC3326"/>
            <seriesInfo name="RFC" value="3326"/>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <author initials="D." surname="Oran" fullname="D. Oran">
              <organization/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization/>
            </author>
            <date year="2002" month="December"/>
            <abstract>
              <t>The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record.  This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: &lt;sip:alice@pc33.atlanta.com&gt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA).  The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies.  The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use.  This document defines an extension header field, "Path" which provides such a mechanism.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6809" target="https://www.rfc-editor.org/info/rfc6809" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6809.xml">
          <front>
            <title>Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6809"/>
            <seriesInfo name="RFC" value="6809"/>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization/>
            </author>
            <author initials="I." surname="Sedlacek" fullname="I. Sedlacek">
              <organization/>
            </author>
            <author initials="H." surname="Kaplan" fullname="H. Kaplan">
              <organization/>
            </author>
            <date year="2012" month="November"/>
            <abstract>
              <t>This specification defines a new SIP header field, Feature-Caps.  The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.</t>
              <t>SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.</t>
              <t>This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7095" target="https://www.rfc-editor.org/info/rfc7095" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml">
          <front>
            <title>jCard: The JSON Format for vCard</title>
            <seriesInfo name="DOI" value="10.17487/RFC7095"/>
            <seriesInfo name="RFC" value="7095"/>
            <author initials="P." surname="Kewisch" fullname="P. Kewisch">
              <organization/>
            </author>
            <date year="2014" month="January"/>
            <abstract>
              <t>This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses.  JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7515"/>
            <seriesInfo name="RFC" value="7515"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
          <front>
            <title>JSON Web Algorithms (JWA)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7518"/>
            <seriesInfo name="RFC" value="7518"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
          <front>
            <title>JSON Web Token (JWT)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7519"/>
            <seriesInfo name="RFC" value="7519"/>
            <author initials="M." surname="Jones" fullname="M. Jones">
              <organization/>
            </author>
            <author initials="J." surname="Bradley" fullname="J. Bradley">
              <organization/>
            </author>
            <author initials="N." surname="Sakimura" fullname="N. Sakimura">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC4103" target="https://www.rfc-editor.org/info/rfc4103" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4103.xml">
          <front>
            <title>RTP Payload for Text Conversation</title>
            <seriesInfo name="DOI" value="10.17487/RFC4103"/>
            <seriesInfo name="RFC" value="4103"/>
            <author initials="G." surname="Hellstrom" fullname="G. Hellstrom">
              <organization/>
            </author>
            <author initials="P." surname="Jones" fullname="P. Jones">
              <organization/>
            </author>
            <date year="2005" month="June"/>
            <abstract>
              <t>This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets.  Text conversation session contents are specified in ITU-T Recommendation T.140.</t>
              <t>One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.</t>
              <t>This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4240" target="https://www.rfc-editor.org/info/rfc4240" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4240.xml">
          <front>
            <title>Basic Network Media Services with SIP</title>
            <seriesInfo name="DOI" value="10.17487/RFC4240"/>
            <seriesInfo name="RFC" value="4240"/>
            <author initials="E." surname="Burger" fullname="E. Burger" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Van Dyke" fullname="J. Van Dyke">
              <organization/>
            </author>
            <author initials="A." surname="Spitzer" fullname="A. Spitzer">
              <organization/>
            </author>
            <date year="2005" month="December"/>
            <abstract>
              <t>In SIP-based networks, there is a need to provide basic network media services.  Such services include network announcements, user interaction, and conferencing services.  These services are basic building blocks, from which one can construct interesting applications.  In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.</t>
              <t>This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
          <front>
            <title>SDP: Session Description Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC4566"/>
            <seriesInfo name="RFC" value="4566"/>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5039" target="https://www.rfc-editor.org/info/rfc5039" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5039.xml">
          <front>
            <title>The Session Initiation Protocol (SIP) and Spam</title>
            <seriesInfo name="DOI" value="10.17487/RFC5039"/>
            <seriesInfo name="RFC" value="5039"/>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <author initials="C." surname="Jennings" fullname="C. Jennings">
              <organization/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t>Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email.  Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications.  Therefore, it is susceptible to spam, just as email is.  In this document, we analyze the problem of spam in SIP.  We first identify the ways in which the problem is the same and the ways in which it is different from email.  We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6350" target="https://www.rfc-editor.org/info/rfc6350" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml">
          <front>
            <title>vCard Format Specification</title>
            <seriesInfo name="DOI" value="10.17487/RFC6350"/>
            <seriesInfo name="RFC" value="6350"/>
            <author initials="S." surname="Perreault" fullname="S. Perreault">
              <organization/>
            </author>
            <date year="2011" month="August"/>
            <abstract>
              <t>This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7092" target="https://www.rfc-editor.org/info/rfc7092" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
          <front>
            <title>A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents</title>
            <seriesInfo name="DOI" value="10.17487/RFC7092"/>
            <seriesInfo name="RFC" value="7092"/>
            <author initials="H." surname="Kaplan" fullname="H. Kaplan">
              <organization/>
            </author>
            <author initials="V." surname="Pascual" fullname="V. Pascual">
              <organization/>
            </author>
            <date year="2013" month="December"/>
            <abstract>
              <t>In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs.  The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).</t>
              <t>There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7340" target="https://www.rfc-editor.org/info/rfc7340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml">
          <front>
            <title>Secure Telephone Identity Problem Statement and Requirements</title>
            <seriesInfo name="DOI" value="10.17487/RFC7340"/>
            <seriesInfo name="RFC" value="7340"/>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <date year="2014" month="September"/>
            <abstract>
              <t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8197" target="https://www.rfc-editor.org/info/rfc8197" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8197.xml">
          <front>
            <title>A SIP Response Code for Unwanted Calls</title>
            <seriesInfo name="DOI" value="10.17487/RFC8197"/>
            <seriesInfo name="RFC" value="8197"/>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization/>
            </author>
            <date year="2017" month="July"/>
            <abstract>
              <t>This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8224" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml">
          <front>
            <title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8224"/>
            <seriesInfo name="RFC" value="8224"/>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization/>
            </author>
            <author initials="C." surname="Jennings" fullname="C. Jennings">
              <organization/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <author initials="C." surname="Wendt" fullname="C. Wendt">
              <organization/>
            </author>
            <date year="2018" month="February"/>
            <abstract>
              <t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t>
              <t>This document obsoletes RFC 4474.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC8259"/>
            <seriesInfo name="RFC" value="8259"/>
            <seriesInfo name="STD" value="90"/>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
          <front>
            <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
            <seriesInfo name="DOI" value="10.17487/RFC8445"/>
            <seriesInfo name="RFC" value="8445"/>
            <author initials="A." surname="Keranen" fullname="A. Keranen">
              <organization/>
            </author>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization/>
            </author>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <date year="2018" month="July"/>
            <abstract>
              <t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t>
              <t>This document obsoletes RFC 5245.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="SHAKEN" target="https://www.sipforum.org/download/sip-forum-twg-10-signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813">
          <front>
            <title>Signature-based Handling of Asserted information using toKENs
          (SHAKEN)</title>
            <seriesInfo name="ATIS" value="1000074"/>
            <author>
              <organization>Alliance for Telecommunications Industry Solutions
            (ATIS) and the SIP Forum</organization>
            </author>
            <date day="5" month="1" year="2017"/>
          </front>
        </reference>
        <reference anchor="BaseRate" target=" https://apps.dtic.mil/docs/citations/ADA045772">
          <front>
            <title>The Base-Rate Fallacy in Probability Judgements</title>
            <author fullname="Maya Bar-Hillel" initials="M." surname="Bar-Hillel">
              <organization>Hebrew University</organization>
            </author>
            <date month="4" year="1977"/>
          </front>
        </reference>
        <reference anchor="ITU.E.180.1998">
          <front>
            <title>Technical characteristics of tones for the telephone
          service</title>
            <seriesInfo name="ITU" value="Recommendation E.180/Q.35"/>
            <author>
              <organization>International Telecommunications
            Union</organization>
            </author>
            <date month="March" year="1998"/>
          </front>
        </reference>
        <reference anchor="SR-2275">
          <front>
            <title>Bellcore Notes on the Networks</title>
            <seriesInfo name="Telcordia" value="SR-2275"/>
            <author>
              <organization>Telcordia</organization>
            </author>
            <date month="October" year="2000"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
</rfc>

<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<date year="1997" month="March"/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>

<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo"><organization/></author>
<author initials="A." surname="Johnston" fullname="A. Johnston"><organization/></author>
<author initials="J." surname="Peterson" fullname="J. Peterson"><organization/></author>
<author initials="R." surname="Sparks" fullname="R. Sparks"><organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley"><organization/></author>
<author initials="E." surname="Schooler" fullname="E. Schooler"><organization/></author>
<date year="2002" month="June"/>
<abstract><t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>

<reference anchor="RFC3262" target="https://www.rfc-editor.org/info/rfc3262" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3262.xml">
<front>
<title>Reliability of Provisional Responses in Session Initiation Protocol (SIP)</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<date year="2002" month="June"/>
<abstract><t>This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages.  This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="3262"/>
<seriesInfo name="DOI" value="10.17487/RFC3262"/>
</reference>

<reference anchor="RFC3326" target="https://www.rfc-editor.org/info/rfc3326" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml">
<front>
<title>The Reason Header Field for the Session Initiation Protocol (SIP)</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<author initials="D." surname="Oran" fullname="D. Oran"><organization/></author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo"><organization/></author>
<date year="2002" month="December"/>
<abstract><t>The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record.  This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: &lt;sip:alice@pc33.atlanta.com&gt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA).  The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies.  The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use.  This document defines an extension header field, "Path" which provides such a mechanism.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="3326"/>
<seriesInfo name="DOI" value="10.17487/RFC3326"/>
</reference>

<reference anchor="RFC6809" target="https://www.rfc-editor.org/info/rfc6809" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6809.xml">
<front>
<title>Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)</title>
<author initials="C." surname="Holmberg" fullname="C. Holmberg"><organization/></author>
<author initials="I." surname="Sedlacek" fullname="I. Sedlacek"><organization/></author>
<author initials="H." surname="Kaplan" fullname="H. Kaplan"><organization/></author>
<date year="2012" month="November"/>
<abstract><t>This specification defines a new SIP header field, Feature-Caps.  The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.</t><t>SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.</t><t>This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6809"/>
<seriesInfo name="DOI" value="10.17487/RFC6809"/>
</reference>

<reference anchor="RFC7095" target="https://www.rfc-editor.org/info/rfc7095" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml">
<front>
<title>jCard: The JSON Format for vCard</title>
<author initials="P." surname="Kewisch" fullname="P. Kewisch"><organization/></author>
<date year="2014" month="January"/>
<abstract><t>This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses.  JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.</t></abstract>
</front>
<seriesInfo name="RFC" value="7095"/>
<seriesInfo name="DOI" value="10.17487/RFC7095"/>
</reference>

<reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
<front>
<title>JSON Web Signature (JWS)</title>
<author initials="M." surname="Jones" fullname="M. Jones"><organization/></author>
<author initials="J." surname="Bradley" fullname="J. Bradley"><organization/></author>
<author initials="N." surname="Sakimura" fullname="N. Sakimura"><organization/></author>
<date year="2015" month="May"/>
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>

<reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author initials="M." surname="Jones" fullname="M. Jones"><organization/></author>
<date year="2015" month="May"/>
<abstract><t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</t></abstract>
</front>
<seriesInfo name="RFC" value="7518"/>
<seriesInfo name="DOI" value="10.17487/RFC7518"/>
</reference>

<reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml">
<front>
<title>JSON Web Token (JWT)</title>
<author initials="M." surname="Jones" fullname="M. Jones"><organization/></author>
<author initials="J." surname="Bradley" fullname="J. Bradley"><organization/></author>
<author initials="N." surname="Sakimura" fullname="N. Sakimura"><organization/></author>
<date year="2015" month="May"/>
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.  The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>

<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"><organization/></author>
<date year="2017" month="May"/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>

<reference anchor="RFC4103" target="https://www.rfc-editor.org/info/rfc4103" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4103.xml">
<front>
<title>RTP Payload for Text Conversation</title>
<author initials="G." surname="Hellstrom" fullname="G. Hellstrom"><organization/></author>
<author initials="P." surname="Jones" fullname="P. Jones"><organization/></author>
<date year="2005" month="June"/>
<abstract><t>This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets.  Text conversation session contents are specified in ITU-T Recommendation T.140.</t><t>One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.</t><t>This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="4103"/>
<seriesInfo name="DOI" value="10.17487/RFC4103"/>
</reference>

<reference anchor="RFC4240" target="https://www.rfc-editor.org/info/rfc4240" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4240.xml">
<front>
<title>Basic Network Media Services with SIP</title>
<author initials="E." surname="Burger" fullname="E. Burger" role="editor"><organization/></author>
<author initials="J." surname="Van Dyke" fullname="J. Van Dyke"><organization/></author>
<author initials="A." surname="Spitzer" fullname="A. Spitzer"><organization/></author>
<date year="2005" month="December"/>
<abstract><t>In SIP-based networks, there is a need to provide basic network media services.  Such services include network announcements, user interaction, and conferencing services.  These services are basic building blocks, from which one can construct interesting applications.  In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.</t><t>This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name="RFC" value="4240"/>
<seriesInfo name="DOI" value="10.17487/RFC4240"/>
</reference>

<reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
<front>
<title>SDP: Session Description Protocol</title>
<author initials="M." surname="Handley" fullname="M. Handley"><organization/></author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson"><organization/></author>
<author initials="C." surname="Perkins" fullname="C. Perkins"><organization/></author>
<date year="2006" month="July"/>
<abstract><t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="4566"/>
<seriesInfo name="DOI" value="10.17487/RFC4566"/>
</reference>

<reference anchor="RFC5039" target="https://www.rfc-editor.org/info/rfc5039" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5039.xml">
<front>
<title>The Session Initiation Protocol (SIP) and Spam</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<author initials="C." surname="Jennings" fullname="C. Jennings"><organization/></author>
<date year="2008" month="January"/>
<abstract><t>Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email.  Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications.  Therefore, it is susceptible to spam, just as email is.  In this document, we analyze the problem of spam in SIP.  We first identify the ways in which the problem is the same and the ways in which it is different from email.  We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name="RFC" value="5039"/>
<seriesInfo name="DOI" value="10.17487/RFC5039"/>
</reference>

<reference anchor="RFC6350" target="https://www.rfc-editor.org/info/rfc6350" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml">
<front>
<title>vCard Format Specification</title>
<author initials="S." surname="Perreault" fullname="S. Perreault"><organization/></author>
<date year="2011" month="August"/>
<abstract><t>This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6350"/>
<seriesInfo name="DOI" value="10.17487/RFC6350"/>
</reference>

<reference anchor="RFC7092" target="https://www.rfc-editor.org/info/rfc7092" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
<front>
<title>A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents</title>
<author initials="H." surname="Kaplan" fullname="H. Kaplan"><organization/></author>
<author initials="V." surname="Pascual" fullname="V. Pascual"><organization/></author>
<date year="2013" month="December"/>
<abstract><t>In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs.  The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).</t><t>There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.</t></abstract>
</front>
<seriesInfo name="RFC" value="7092"/>
<seriesInfo name="DOI" value="10.17487/RFC7092"/>
</reference>

<reference anchor="RFC7340" target="https://www.rfc-editor.org/info/rfc7340" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml">
<front>
<title>Secure Telephone Identity Problem Statement and Requirements</title>
<author initials="J." surname="Peterson" fullname="J. Peterson"><organization/></author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig"><organization/></author>
<date year="2014" month="September"/>
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments.  Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks.  Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session.  This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions.  It also gives high-level requirements for a solution in this space.</t></abstract>
</front>
<seriesInfo name="RFC" value="7340"/>
<seriesInfo name="DOI" value="10.17487/RFC7340"/>
</reference>

<reference anchor="RFC8197" target="https://www.rfc-editor.org/info/rfc8197" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8197.xml">
<front>
<title>A SIP Response Code for Unwanted Calls</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne"><organization/></author>
<date year="2017" month="July"/>
<abstract><t>This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.</t></abstract>
</front>
<seriesInfo name="RFC" value="8197"/>
<seriesInfo name="DOI" value="10.17487/RFC8197"/>
</reference>

<reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8224" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml">
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author initials="J." surname="Peterson" fullname="J. Peterson"><organization/></author>
<author initials="C." surname="Jennings" fullname="C. Jennings"><organization/></author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla"><organization/></author>
<author initials="C." surname="Wendt" fullname="C. Wendt"><organization/></author>
<date year="2018" month="February"/>
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP requests.  It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t><t>This document obsoletes RFC 4474.</t></abstract>
</front>
<seriesInfo name="RFC" value="8224"/>
<seriesInfo name="DOI" value="10.17487/RFC8224"/>
</reference>

<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor"><organization/></author>
<date year="2017" month="December"/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference>

<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
<author initials="A." surname="Keranen" fullname="A. Keranen"><organization/></author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg"><organization/></author>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg"><organization/></author>
<date year="2018" month="July"/>
<abstract><t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t><t>This document obsoletes RFC 5245.</t></abstract>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>