RFC 9796

SIP Call-Info Parameters for Rich Call Data

📅 published July 2025, from ietf

RFC 9796: SIP Call-Info Parameters for Rich Call Data 📇✨

okay bestie, this is RFC 9796 🎀 It's an IETF doc from July 2025, and it's on the Standards Track 👑 (so it's a real spec, not just vibes). The authors are C. Wendt from Somos and J. Peterson from TransUnion 🫶. It's ISSN 2070-1721, and the title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈

Abstract

okay so the abstract is basically: this doc defines how to use the SIP Call-Info header field to carry Rich Call Data (RCD) about whoever is calling 📞 The point is to give the called person a description of the caller, including the reason for the call, so they can decide what to do with the call 💖 RCD is more than just a phone number. It can include a calling name, a logo, a photo, or a jCard object that represents the caller 🌸 All of that can help the person answer, ignore, or handle the call differently 🔥

The doc defines three new parameters for Call-Info: call-reason, verified, and integrity ✨ It also adds a new token, "jcard", for the purpose parameter 🦋 And it gives guidance on how to use the existing purpose token "icon" 💅

Status of This Memo

this is an Internet Standards Track document 👑

It's a product of the Internet Engineering Task Force (IETF), so it represents consensus from the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more on Internet Standards, check Section 2 of RFC 7841 📚

For current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9796 🌈

Copyright Notice

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they were in effect on the publication date 📜 Please actually read those, because they explain what rights and restrictions you have with this doc 🙈

Code Components pulled out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions 💜 They're provided without warranty, as described in the Revised BSD License ⚠️

   1.  Introduction
   2.  Terminology
   3.  Overview
   4.  A Call-Info Framework for Carrying Rich Call Data
   5.  "jcard" Call-Info 'purpose' Token
   6.  'call-reason' Call-Info Parameter
   7.  'verified' Call-Info Parameter
   8.  'integrity' Call-Info Parameter
   9.  Usage and an Example of Call-Info for RCD
   10. Usage of jCard and Property-Specific Usage
     10.1.  Usage of URIs in jCard
     10.2.  Usage of Multimedia Data in jCard or with the "icon"
            Call-Info 'purpose' Token
     10.3.  Cardinality
     10.4.  Identification Properties
       10.4.1.  "fn" Property
       10.4.2.  "n" Property
       10.4.3.  "nickname" Property
       10.4.4.  "photo" Property
     10.5.  Delivery Addressing Properties
       10.5.1.  "adr" Property
     10.6.  Communications Properties
       10.6.1.  "tel" Property
       10.6.2.  "email" Property
       10.6.3.  "lang" Property
     10.7.  Geographical Properties
       10.7.1.  "tz" Property
       10.7.2.  "geo" Property
     10.8.  Organizational Properties
       10.8.1.  "title" Property
       10.8.2.  "role" Property
       10.8.3.  "logo" Property
       10.8.4.  "org" Property
     10.9.  Explanatory Properties
       10.9.1.  "categories" Property
       10.9.2.  "note" Property
       10.9.3.  "sound" Property
       10.9.4.  "uid" Property
       10.9.5.  "url" Property
       10.9.6.  "version" Property
   11. Extension of jCard
   12. IANA Considerations
     12.1.  "jcard" Purpose Parameter Value
     12.2.  SIP Call-Info Header Field 'call-reason' Parameter
     12.3.  SIP Call-Info Header Field 'verified' Parameter
     12.4.  SIP Call-Info Header Field 'integrity' Parameter
   13. Security Considerations
   14. References
     14.1.  Normative References
     14.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

okay so phone networks have supported a 'calling name' going from the originating side to the terminating side for a long time 📞 In practice though, the terminating side often has to figure out a name by itself, either by checking a local address book or an external database 🙈

SIP [RFC3261] can also carry a 'display-name' in the From header field value from originating to terminating side. But it's not commonly trusted, and it's often replaced or ignored 💀 The same is true for info in the Call-Info header field in SIP 💅

This doc defines usage of the SIP Call-Info header field [RFC3261] so called parties can get a more comprehensive and extensible set of Rich Call Data (RCD) for incoming calls 🌈 It defines specific usage of Call-Info, a new parameter ('call-reason'), and a new token ("jcard") for the 'purpose' parameter of Call-Info 🎀 Depending on the policies of the communications system, the calling party could be an end user device (like a SIP user agent (UA)) or a network service run by a telephone service provider 🧚 Similarly, the called party could be an end user device, or the network telephone service provider acting on behalf of the call recipient 💜

Next, to properly protect and communicate some of the authenticated and trusted properties of "rcd" claims defined in [RFC9795], this doc defines two more new parameters: 'verified' and 'integrity' 🦋 These help protect RCD info that was sent through a SIP network to, for example, a SIP entity on the edge of the Network-Network Interface (NNI). That entity has a verification service as defined in [RFC8224], and further defined for RCD info in [RFC9795] 🔥 The verification procedures include successful verification of the "rcd" claims, and they can be represented in the Call-Info header field through these new parameters ✨

Used on its own, this spec assumes the called party UA can trust the SIP network to assign, deliver, and protect the correct RCD info as an end-to-end security policy 🫣 But like in many interconnected communications services, that end-to-end trust can't be guaranteed 😭 So the recommended approach is that the entity inserting the Call-Info header field should also sign the caller info. It does this with protocol tools from Secure Telephone Identity Revisited (STIR) [RFC7340] for SIP [RFC8224], specifically through RCD or the "rcd" PASSporT defined in [RFC9795] 🔒

Alternatively, this spec can be used together with the protocols in [RFC9795] as part of the signaling path. That's specifically the trusted User-Network Interface (UNI) device interface on the terminating side, as part of authenticated, network-to-device, trusted signaling 🫶 In that setup, a device may not be able to verify the "rcd" PASSporT, but it can still receive the RCD info from the Call-Info header field, as defined here 💖

This spec also provides a way to deliver jCard data using the same mechanism as [RFC7852] 💅 RFC 7852 defined a way to carry extra data about callers for emergency services, especially Section 4.4 (Owner/Subscriber Information) of [RFC7852] 🚨 This doc defines a 'purpose' parameter value "jcard" for the more generic delivery of info via jCard [RFC7095] 🌸 It also borrows the ability to carry a data structure as a body from [RFC7852], using the "cid" URI scheme [RFC2392] 🍓

2. Terminology 📖

okay this section is the important one for the key words 🙈 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀 So lowercase versions are just regular words, but the ALL CAPS ones are the real rules 👑

3. Overview 🦋

this doc gives a framework for using the Call-Info header field to carry RCD in SIP [RFC3261] ✨ Call-Info (defined in [RFC3261], Section 20.9) already has a 'purpose' parameter 💅 On top of guidance about calling name practices and the existing 'purpose' token "icon", this doc expands on other types of RCD 🔥 It does that by defining a new 'purpose' token, "jcard", and three new parameters for Call-Info: 'call-reason', 'verified', and 'integrity' 🌈 These are meant to line up with RCD as defined in the STIR framework [RFC8224] and with "rcd" PASSporTs defined in [RFC9795] 🫶

The 'purpose' token "jcard" is used to link RCD about the calling party's identity to a jCard [RFC7095] 💜 There is already a "card" token defined in [RFC3261] that could look like it does the same job 🙈 But "jcard" is meant to mark the jCard profile defined in this doc, for use in Call-Info for RCD 🎀 The choice of jCard here came down to two things 🧚 First, jCard is an extensible way to give info about a person or business connected to a call. Second, it has been defined in [RFC9795], and PASSporT [RFC8225] adopted it because it uses JSON Web Tokens (JWT) [RFC7519] 🦋

The new Call-Info parameter 'call-reason' carries the caller's intent, or why they're calling 🌸 That helps the called party understand the context and intent of the call, and figure out why they might want to pick up 💖

The new Call-Info parameter 'verified' shows, with the value "true", the results of the verification procedures done by the sender of the Call-Info header field ✨ And the new Call-Info parameter 'integrity' lets you attach an integrity hash string, as defined in Section 8.2 of [RFC9795], to the content of the resource at the URI in the Call-Info header field 🔒

4. A Call-Info Framework for Carrying Rich Call Data ✨

okay so this spec levels up the Call-Info header field so it plays nicely with the RCD framework from [RFC9795] 💅. SIP calls usually bounce through a bunch of hops across trusted and untrusted networks, and the STIR framework [RFC7340] is what protects call info and identities when they travel over the untrusted ones. The core SIP specs never really handled that part 😭. [RFC3261], Section 20.9 says Call-Info is the way to carry call- and caller-related info, and it also explains how to define new 'purpose' parameter tokens. This doc uses some existing tokens and adds a brand new 'purpose' token, "jcard"? no wait, the new one is for the RCD framework 🎀.

There are a few RCD info types that can ride along in the Call-Info header field of a SIP request. The STIR RCD spec [RFC9795] names the main ones: a calling name, a logo or icon for the caller, and a call reason string. It also mentions an extensible way to carry caller info using jCard [RFC7095] 🌸.

The RCD framework here and in [RFC9795] is all about call-specific info, and the vibe is "one and done." The receiving party should not be required to make any call-specific decisions based on redundant, duplicate, or conflicting RCD, so it's supposed to be singular 🙈. The RCD info is either added by a party that's the authority on it, or translated from a verified STIR RCD PASSporT and left unmodified once it's inside a trusted domain ✨. Any additional parties in the call path MUST NOT modify the Call-Info header field or add extra Call-Info header fields related to RCD. Bestie, that's a hard rule 🚫. The trusted and verified caller RCD info in the RCD Call-Info header field MUST NOT be modified or altered. The user should be able to trust that the RCD info accurately represents the verified info 🫶. This spec admits that without STIR or other mechanisms, there's no way to detect changes, so guidance for using it in a trusted UNI part of the network matters a lot 😬.

As [RFC9795] explains, the calling name uses the display-name value of the From header field [RFC3261] of the request. For some calls, the calling name can instead come from the P-Asserted-ID header field [RFC3325]. Representing that display-name value in Call-Info is out of scope, but this doc does cover how to show that the value was verified using the 'verified' parameter 🔍.

For logos or icons that can represent the calling party, the 'purpose' token "icon" [RFC3261] points to a URI for an image resource that can be shown to the user getting the SIP request 🖼️. For this doc and for sending RCD, the "icon" 'purpose' token should be used as defined. Section 8.2 of [RFC9795] has the high-level guidance on image formatting and related stuff 💖.

This doc defines 'call-reason' as a brand new parameter for the Call-Info header field. It carries a string saying why the call is happening 💬.

jCard is the comprehensive, extensible mechanism that the STIR RCD framework uses. [RFC3261] already has a "card" 'purpose' token, but the point of a new "jcard" 'purpose' token is to use the JSON jCard format [RFC7095]. It also gives guidance on when to use and not use jCard attributes to describe the calling party in a session, plus some security considerations for that info. Those topics get covered in the next sections 🦋.

5. "jcard" Call-Info 'purpose' Token 🎀

The Call-Info 'purpose' token "jcard" says that RCD about the calling party's identity in a SIP call is supported [RFC3261], Section 20.9. Here's what a Call-Info header field looks like when it uses the "jcard" token 💜.

The Call-Info header field is defined to include a URI that points to a resource that is a jCard JSON object [RFC7095]. The media type for the JSON text MUST be set as application/json with a UTF-8 encoding [RFC8259]. That jCard MAY be carried directly in the Call-Info header field URI using the "data" URI scheme. A jCard also MAY be carried in the body of the SIP request that has this Call-Info header field, using the "cid" URI scheme [RFC2392]. Otherwise, the Call-Info header field URI MUST use a transport that can validate the integrity of the source of the resource (for example, HTTPS tied to a specific validated domain) 🔐. If, in the specific SIP deployment, the source or integrity of the RCD info can't be trusted, then the STIR RCD framework from [RFC9795] should be considered 🛡️.

Since this spec is all about giving one clean presentation of RCD info, a call and its matching single RCD-related Call-Info header field MUST only contain a single jCard object. That object is an array with two elements. The array MUST only include a single first element with the string "vcard", and the second element is an array of jCard properties for that single entity jCard object 🌈.

jCard has lots of fields that can say similar things. For example, "fn", "n", and "nickname" are strings that represent names in different ways, and "photo" or "logo" represent a picture 📸. Anyone using this spec should make sure the calling name string matches the single name in the SIP From or P-Asserted-ID header field, and that a "logo" or "photo" corresponds to the RCD "icon" from the previous section ✨. As described in [RFC8224] and the [RFC9795] verification procedures, the values represented in the RCD MUST match the matching info in the SIP message, so that calling name or icon verification works consistently 🔎.

Here's an example Call-Info header field:

Call-Info: <https://example.com/qbranch.json>;purpose=jcard

And here's what the URL-linked jCard JSON file can look like:

["vcard",
  [
    ["version",{},"text","4.0"],
    ["fn",{},"text","Q Branch"],
    ["org",{},"text","MI6;Q Branch Spy Gadgets"],
    ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
    ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
    ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
  ]
]

Next up is a SIP INVITE using the "data" URI scheme 🧚:

   INVITE sip:alice@example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
   To: Alice <sip:alice@example.com>
   From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
   Call-ID: a84b4c76e66710
   Call-Info: <data:application/json,["vcard",[["version",{},"text",
    "4.0"],["fn",{},"text","Q Branch"],["org",{},"text","MI6;Q Branch
    Spy Gadgets"],["photo",{},"uri","https://example.com/photos/quart
    ermaster-256x256.png"],["logo",{},"uri","https://example.com/log
    os/mi6-256x256.jpg"],["logo",{},"uri","https://example.com/logos/
    mi6-64x64.jpg"]]]\>;purpose=jcard;call-reason="Rendezvous for
    Little Nellie"
   CSeq: 314159 INVITE
   Max-Forwards: 70
   Date: Fri, 25 Sep 2025 19:12:25 GMT
   Contact: <sip:12155551000@gateway.example.com>
   Content-Type: application/sdp

   v=0
   o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
   s=Session SDP
   c=IN IP4 pc33.atlanta.example.com
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

And a SIP INVITE using the "cid" URI scheme 🌸:

   INVITE sip:alice@example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
   To: Alice <sip:alice@example.com>
   From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
   Call-ID: a84b4c76e66710
   Call-Info: <cid:12155551000@example.com>;purpose=jcard;
    call-reason="Rendezvous for Little Nellie"
   CSeq: 314159 INVITE
   Max-Forwards: 70
   Date: Fri, 25 Sep 2025 19:12:25 GMT
   Contact: <sip:12155551000@gateway.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   v=0
   o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
   s=Session SDP
   c=IN IP4 pc33.atlanta.example.com
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   --boundary1

   Content-Type: application/json
   Content-ID: <12155551000@example.com>

   ["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],
    ["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","
    https://example.com/photos/quartermaster-256x256.png"],["logo",
    {},"uri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},
    "uri","https://example.com/logos/mi6-64x64.jpg"]]]

6. 'call-reason' Call-Info Parameter 💌

This parameter is meant to be separate and distinct from the other URI and 'purpose' tokens that might come before it 🧁.

This new Call-Info parameter is called 'call-reason'. It's meant to carry a short text message that's suitable for showing the end user while the call is alerting 🔔. As a general guideline, this message SHOULD be no longer than 64 characters. Displays that support this spec may be forced to cut off messages that don't fit on the screen ✂️. The message tells the callee the caller's intention for reaching out 💭. It's an optional parameter, and the sender of a SIP request can't guarantee that the terminating endpoint will support displaying it 🤷‍♀️. How the caller sets this reason is outside the scope of this spec. In general, strings that could be forms of URIs, or other strings that could be used or interpreted as a 'clickable' action, are discouraged 🚫🔗.

The alternative would have been to use the Subject header field [RFC3261] to convey the reason for the call. But the Subject header field has seen little historical use in SIP implementations, and its spec describes using it for filtering. So it seemed smarter to define a new way to carry the call-reason 🧠.

Here's an example Call-Info header field value with the "call-reason" parameter:

   Call-Info: <https://example.com/jbond.json>;purpose=jcard;
    call-reason="For your ears only"

For 'call-reason' or 'verified' parameters defined in this document that don't need an associated URI, or for future parameters that don't need one either, the Call-Info header field URI should be set to the null data URI, "data:". The "jcard" purpose parameter defined in this document is used to avoid conflicts or confusion with existing implementations and previously defined purpose parameters 🌷. For example:

   Call-Info: <data:>;purpose=jcard;
    call-reason="For your ears only"

7. 'verified' Call-Info Parameter ✨

okay so the 'verified' parameter is the bestie that backs up the RCD info 💅 It extends and complements what the RCD-related Call-Info header field already says. It tells the recipient that the info in that Call-Info header field was checked by the verification procedures for claims defined in Section 8 of [RFC9795]. Having a 'verified' parameter on a Call-Info header field only counts for the info in that one header field 🦋 If there's a Call-Info header field for something this spec defines that doesn't have a 'verified' parameter, the recipient should assume that info was not received and verified against the Section 8 procedures in [RFC9795]. ngl that's a major vibe check 😭

There's only one valid value for 'verified', and that's 'true'. It means the party that put the header field in did a successful verification of the info it represents. As a general rule, the recipient's ability to trust 'verified' comes down to the trusted relationship with the party sending them the SIP request 🫶

Here's an example where verified="true" shows that a verification procedure ran inside a trusted domain and the "icon" URL passed ✨

Call-Info: <https://example.com/jbond.png>;purpose=icon;
 verified="true"

Besides showing that RCD info passed verification, a major use of 'verified' is to show that display-name info has been verified. This is sometimes called calling name or CNAM 🎀

Here's a fun one. A call came in via an NNI to a terminating provider with this STIR RCD PASSporT 🕵️

Protected Header
{
  "alg":"ES256",
  "typ":"passport",
  "ppt":"rcd",
  "x5u":"https://cert.example.org/passport.pem"
}
Payload
{
  "dest":{"tn":["12025551001"]},
  "iat":1443208345,
  "orig":{"tn":"12025551000"},
  "rcd":{"nam":"James Bond","icn":"https://example.com/jbond.png"}
}

The terminating provider gets a SIP INVITE with an identity header carrying that STIR RCD PASSporT, and a verification service checks it. The provider then wants to deliver the call to an end device in the trusted and authenticated UNI network 📞 It uses local policies to decide what info to show the end device. The SIP INVITE below could represent the RCD info using two Call-Info header fields. Because both the icon and the calling name passed verification, a Call-Info header for the "icon" gets added with verified="true", and a Call-Info with a null data URI gets used too, as discussed in the "call-reason" section above. This document defines that the display-name info in either the From and/or P-Asserted-ID header field has been verified via RCD PASSporT verification procedures when all of this is present: a 'purpose' parameter token of "jcard", a Call-Info header field with a null data URI "data:", and a verified parameter equal to "true" 💖

Example SIP INVITE described above:

INVITE sip:qbranch@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: "QBranch" <sip:qbranch@example.com>
From: "James Bond" <sip:12155551000@example.com;user=phone>;
 tag=1928>
Call-ID: a84b4c76e66710
Call-Info: <https://example.com/jbond.png>;purpose=icon;
 verified="true"
Call-Info: <data:>;purpose=jcard;verified="true"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2025 19:12:25 GMT
Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp

v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

8. 'integrity' Call-Info Parameter 🔐

the 'integrity' parameter extends and complements the integrity info that the "rcdi" claim carries in the RCD-related Call-Info header field 💜 It's used to show that, for a URI in the Call-Info header field, the resource behind that URI has an associated integrity hash value. This is conceptually based on [W3C-SRI]. Section 6 of [RFC9795] covers how to create the digest value, including the hash algorithm indicator, a '-' separator, and the hash value as a string. The JSON pointer object container that holds the 'rcdi' hashes isn't needed here, because each hash value should only correspond to a single URI.

Following the guidance in Section 6 of [RFC9795], implementations of this specification MUST support the hash algorithms SHA-256, SHA-384, and SHA-512 🌈 These are identified by "sha256", "sha384", and "sha512", respectively.

If the URI and the resource it points to don't change between the STIR RCD PASSporT and the Call-Info URI value, the integrity value can usually be used as the same string in both the "rcdi" claim and the 'integrity' parameter ✨

Note: When the 'rcdi' claim is part of the successfully verified RCD PASSporT, the Call-Info Header Field should include both the 'verified' and 'integrity' parameters. Creation of a Call-Info header field based on an identity header field that carries RCD claims that does not pass verification procedures is not suggested (i.e., the inclusion of an 'integrity' parameter without a properly included 'verified' parameter).

Here's an example STIR RCD PASSporT 🍓

Protected Header
{
  "alg":"ES256",
  "typ":"passport",
  "ppt":"rcd",
  "x5u":"https://cert.example.org/passport.pem"
}
Payload
{
  "crn": "Rendezvous for Little Nellie",
  "dest": {"tn": ["12155551001"]},
  "iat": 1443208345,
  "orig": {"tn": "12025551000"},
  "rcd": {
    "nam": "Q Branch Spy Gadgets",
    "icn": "https://example.com/photos/q-256x256.png"
  },
  "rcdi": {
    "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
  }
}

Here's the matching SIP INVITE, with Call-Info info derived from the RCD info above 🧚

INVITE sip:qbranch@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: "James Bond" <sip:12155551001@example.com;user=phone>
From: "Q Branch Spy Gadgets" <sip:12025551000@example.com;
 user=phone>;tag=1928>
Call-ID: a84b4c76e66710
Call-Info: <https://example.com/photos/q-256x256.png>;purpose=
 icon;verified="true";integrity="sha256-RojgWwU6xUtI4q82+kHPyHm
 1JKbm7+663bMvzymhkl4"
Call-Info: <data:>;purpose=jcard;call-reason="Rendezvous for
 Little Nellie";verified="true"
Call-Info: <data:>;purpose=jcard;verified="true"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2025 19:12:25 GMT
Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp

v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

9. Usage and an Example of Call-Info for RCD 📇

the procedures for using URIs and 'purpose' parameter tokens should follow the ones defined in [RFC3261] 💅 Managing and provisioning RCD for an initiating party takes a lot of validation of info about that specific party, and that's out of scope for this document. The 'rcd' Call-Info header field is verified while the call moves from the Network-to-Network Interface (NNI) to the User-to-Network Interface (UNI). So a common approach is to pull the verified info out of a received STIR 'rcd' PASSporT and translate it into this header field. That lets the RCD get delivered to the end user device through the UNI 🌸

The next example shows both the STIR RCD PASSporT and the matching set of Call-Info header fields. It uses multiple Call-Info 'purpose' tokens to indicate "jCard" and "icon", plus a 'call-reason' Call-Info parameter 🦋

Example STIR RCD PASSporT:

Protected Header
{
   "alg":"ES256",
   "typ":"passport",
   "ppt":"rcd",
   "x5u":"https://cert.example.org/passport.pem"
}
Payload
{
   "crn":"For your ears only",
   "dest":{"tn":["12025551001"]},
   "iat":1443208345,
   "orig":{"tn":"12025551000"},
   "rcd":{
     "jcl":"https://example.com/qbranch.json",
     "icn":"https://example.com/jbond.png"
   },
   "rcdi": {
     "/jcl": "sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82+kHP"
     "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
   }
}

Example Call-Info header fields:

Call-Info: <data:>;purpose=jcard;verified="true"
Call-Info: <https://example.com/jbond.json>;purpose=jcard;verified
 =true;integrity="sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82
 +kHP"
Call-Info: <https://example.com/jbond.png>;purpose=icon;
 call-reason="For your ears only";verified=true;integrity=
 "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"

10. Usage of jCard and Property-Specific Usage 🎀

beyond the specific properties or JSON arrays tied to each property, this spec adds a few rules on top of the ones in [RFC7095] that are specific to using jCard for Call-Info and RCD 💖 The goal is a minimum level of supported properties that every implementation of this spec should stick to. That covers interpreting the value of these properties, and being able to render them in a suitable form on the display capabilities of common telephone devices and applications. It also covers requirements for text-based and graphics-capable displays ✨

10.1. Usage of URIs in jCard 🔗

when one or more URIs are used in a jCard, it's important to know that any URI-referenced data MUST NOT contain any URI references. The one exception is the top-level usage of "jcl" as a URI to the jCard itself. So the jCard can have URI references as defined in the jCard specification and this document, but the content referenced by those URIs MUST NOT have any URIs. The client MUST ensure that those URI references are not followed, and any URIs in that linked content are not rendered 🙈 This is about security, and specifically about lining up with the content-integrity mechanism defined in [RFC9795]. Deeper URI references aren't expected to be needed, or even supported, by typical use of current jCard properties. But jCard is extensible, so this rule keeps further extensions from going ahead without proper thought about the security and integrity properties of both Call-Info usage and the RCD and STIR signing of the data [RFC9795] [RFC8224] 😭

10.2. Usage of Multimedia Data in jCard or with the "icon" Call-Info 'purpose' Token 🎀

okay bestie, this part is all about pictures and sounds 🖼️🔊. If you're using the "icon" 'purpose' token, or your jCard either points at URIs or stuffs images and sounds straight in with Base64 encoding (Section 4 of [RFC4648]), this doc gives some guidance (as of writing!) to help those images and media formats decode and render smoothly ✨. Media formats are probably something each implementer needs to think about for their own app, ngl 💅.

For images, like the "photo" and "logo" properties, the default image formats SHOULD be PNG [ISOPNG] or JPEG [ITUJPEG], because these are the go-to files for 24-bit RGB images 🌈. Supporting older telephones that only handle bitmap (BMP) images [RFC7903] with a lower bit range (like 16-bit, 8-bit, or 1-bit), or grayscale, or 1-bit black and white color displays, should be considered optional or even not recommended. Those are getting rarer every year 🥹. Basically, devices either have color or color-aware screens that support PNG or JPEG, or they're exclusively textual displays 💀.

Vector images are increasingly popular for icons because they stay scalable without you having to send multiple resolutions 🦋. SVG has gained wide support as a common vector format as of this writing. At a minimum, the SVG Tiny 1.2 specification [W3C-SVGTiny1.2] SHOULD be supported as an additional default format for devices 💜.

For cases where image files are referenced by URIs as file resources, this document defines a character string that SHOULD be concatenated onto the end of a file name, but before the file extension. It signals the height and width of the image to the end device, so it can figure out which resolution to grab without retrieving all the image files 📐. It is also recommended that images have a square aspect ratio, with equal height and width and a power-of-two value for the number of pixels (e.g., 32x32, 128x128, 512x512) 🌸. The format of the string should be "filename-HxW", where "filename" is a unique string representing the file, "H" represents the height in pixels, and "W" represents the width in pixels.

It's appropriate and useful to include multiple versions of images or sounds so that endpoints that can't support every format or resolution can pick the one they do support 🧚. The RECOMMENDED convention is for files that refer to the same content to use the same filename portion. If the image format has a specific resolution, the HxW portion of the filename should correspond to the pixel resolution. The file extension should reference the file type, like filename.png, filename.svg, or filename.jpg, or like filename-32x32.png, filename-64x64.png, filename.svg, filename-32x32.jpg, or filename-64x64.jpg 🍓.

This is a complex and often debated topic that has evolved over the years of advances in image coding and display technologies, so this specification suggests relying on either future specifications or industry forum specifications that might correspond to supporting particular classes of devices. Those can further define how URIs reference appropriate image formats and files 🤓.

For audio files, the recommendation is to provide mp3, m4a or mp4, or wav files [RFC2361]. The usage of sound (for example, a special ring tone for a particular caller) is not well defined in this specification though 🎶. Future documents should consider both usage and potential security risks of playing sounds that are not specifically authorized by a device user. Seriously, this one matters 🚨.

10.3. Cardinality 🔢

Property cardinalities are indicated, for convenience, using the following notation. They follow the guidance of jCard [RFC7095] and vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6) ✨:

+=============+==================================================+
| Cardinality | Meaning                                          |
+=============+==================================================+
| 1           | Exactly one instance per jCard MUST be present.  |
+-------------+--------------------------------------------------+
| *1          | Exactly one instance per jCard MAY be present.   |
+-------------+--------------------------------------------------+
| 1*          | One or more instances per jCard MUST be present. |
+-------------+--------------------------------------------------+
| *           | One or more instances per jCard MAY be present.  |
+-------------+--------------------------------------------------+

Table 1

10.4. Identification Properties 🪪

The following properties, initially defined in [RFC6350], hold the identity information of the entity associated with the jCard. This subset was selected for this document because it's relevant to telephone and messaging applications 📞.

10.4.1. "fn" Property 💖

The "fn" property provides formatted text corresponding to the name of the object the jCard represents. Reference: [RFC6350], Section 6.2.1.

Value type: A single text value. Cardinality: 1*

Example:

  ["fn", {}, "text", "Mr. John Q. Public\, Esq."]

10.4.2. "n" Property 🌷

The "n" property provides the components of the name of the object the jCard represents. Reference: [RFC6350], Section 6.2.2.

Value type: A single structured text value. Each component can have multiple values. Cardinality: *1

Example:

  ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]
  ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]

10.4.3. "nickname" Property 🧸

The "nickname" property provides the text corresponding to the nickname of the object the jCard represents. Reference: [RFC6350], Section 6.2.3.

Value type: One or more text values separated by a COMMA character (U+002C). Cardinality: *

Example:

  ["nickname", {}, "text", "Robbie"]
  ["nickname", {}, "text", "Jim,Jimmie"]
  ["nickname", {}, "text", "TYPE=work:Boss"]

10.4.4. "photo" Property 📸

The "photo" property provides image or photograph information that annotates some aspect of the object the jCard represents. Reference: [RFC6350], Section 6.2.4.

In addition to the definition of jCard, and to promote interoperability and proper formatting and rendering of images, the photo SHOULD correspond to a square image with the size of 128x128, 256x256, 512x512, or 1024x1024 pixels 🖼️.

Value type: A single URI. Cardinality: *

Example:

  ["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"]

10.5. Delivery Addressing Properties 📬

This property is concerned with information related to the delivery address of the jCard object.

10.5.1. "adr" Property 🏠

The "adr" property provides the delivery address of the object the jCard represents. Reference: [RFC6350], Section 6.3.1.

Value type: A single structured text value separated by the SEMICOLON character (U+003B). Cardinality: *

Example:

  ["adr", {"type":"work"}, "text",
    ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
      "20008", "U.S.A."]
  ]

"adr" also allows a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. The following example shows alternate values for the address string 🎀.

Example:

  ["adr", {"type":"work"}, "text",
    ["", "", ["3100 Massachusetts Avenue NW","Embassy of the
      United Kingdom"], "Washington", "DC", "20008", "U.S.A."]
  ]

10.6. Communications Properties 💬

These properties describe how to communicate with the object the jCard represents.

10.6.1. "tel" Property ☎️

The "tel" property provides the telephone number for the object the jCard represents. Reference: [RFC6350], Section 6.4.1.

Relative to the SIP From header field value, this information may provide an alternate telephone number or other related telephone numbers for other uses.

It is important to note that any of the instances of the "tel" property should not be considered part of the authentication or verification part of STIR [RFC8224] or required to match the "orig" claim in the PASSporT [RFC8225]. These telephone numbers can be for contact, fax, or other purposes aligned with the general usage of jCard and vCard. But the potential confusion of the callee when provided with multiple telephone numbers instead of the actual, verified telephone number should be considered from a general policy point of view 🚦.

Value type: By default, it is a single free-form text value (for backward compatibility with vCard 3), but it SHOULD be reset to a URI value. It is expected that the URI scheme will be "tel", as specified in [RFC3966], but other schemes MAY be used. Cardinality: *

Example:

  ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
   "tel:+1-202-555-1000"]
  ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]

10.6.2. "email" Property 📧

The "email" property provides the electronic mail address of the object the jCard represents. Reference: [RFC6350], Section 6.4.2.

Value type: A single text value. Cardinality: *

Example:

  ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]
  ["email", {"pref":"1"}, "text", "jane_doe@example.com"]

10.6.3. "lang" Property 🌍

The "lang" property indicates the language(s) that may be used for communicating with the object the jCard represents. Reference: [RFC6350], Section 6.4.4.

Value type: A single language-tag value. Cardinality: *

Example:

  ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]
  ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]
  ["lang", {"type":"home"}, "language-tag", "fr"]

10.7. Geographical Properties 🗺️

These properties provide geographical information associated with the object the jCard represents.

10.7.1. "tz" Property ⏰

The "tz" property provides the time zone of the object the jCard represents. Reference: [RFC6350], Section 6.5.1.

Note: The reference for time-zone names is
`<https://www.iana.org/time-zones>`.

Value type: The default is a single text value. It can also be reset to a single URI or a UTC-offset value. Cardinality: *

Example:

  ["tz", {}, "text", "America/New_York"]

10.7.2. "geo" Property 🌏

The "geo" property provides the global positioning of the object the jCard represents. Reference: [RFC6350], Section 6.5.2.

Value type: A single URI. Cardinality: *

Example:

  ["geo", {}, "uri", "geo:37.386013,-122.082932"]

10.8. Organizational Properties 🏢

These properties are concerned with information associated with characteristics of the organization or organizational units of the object that the jCard represents.

10.8.1. "title" Property 👑

The "title" property provides the position or job of the object the jCard represents. Reference [RFC6350], Section 6.6.1.

Value type: A single text value. Cardinality: *

Example:

  ["title", {}, "text", "Research Scientist"]

10.8.2. "role" Property 🎯

The "role" property provides the position or job of the object the jCard represents. Reference [RFC6350], Section 6.6.2.

Value type: A single text value. Cardinality: *

Example:

  ["role", {}, "text", "Project Leader"]

10.8.3. "logo" Property 🎨

okay bestie, the "logo" property is how you attach a graphic of the logo for the object the jCard represents 💖 it's defined in Reference [RFC6350], Section 6.6.3. ✨

Value type: a single URI. Cardinality: *

["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"]

["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC
 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
 <...the remainder of base64-encoded data...>"]

10.8.4. "org" Property 🏢

the "org" property is the organization's name and units for the object the jCard represents 💼 it's Reference [RFC6350], Section 6.6.4. 🌸

Value type: a single structured text value made of components separated by the SEMICOLON character (U+003B). Cardinality: *

["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]

10.9. Explanatory Properties 📝

these properties add extra info like notes or revisions specific to the jCard, the little extras that make it iconic 🦋

10.9.1. "categories" Property 🏷️

the "categories" property tells you the application category info about the object the jCard represents. Reference: [RFC6350], Section 6.7.1. 🎀

Value type: one or more text values separated by a COMMA character (U+002C). Cardinality: *

["categories", {}, "text", "TRAVEL AGENT"]

["categories", {}, "text", "INTERNET,IETF,INDUSTRY"]

10.9.2. "note" Property 🗒️

the "note" property is supplemental info or a comment about the object the jCard represents, basically the bestie gossip section 🙈 Reference: [RFC6350], Section 6.7.2.

Value type: a single text value. Cardinality: *

["note", {}, "text", "This fax number is operational 0800 to 1715
 EST\, Mon-Fri."]

10.9.3. "sound" Property 🔊

the "sound" property is digital sound content that annotates some part of the object the jCard represents 🎧 it's often used for the proper pronunciation of the name property value, so you never mispronounce your bestie's name again 💅 Reference: [RFC6350], Section 6.7.5.

Value type: a single URI. Cardinality: *

["sound", {}, "uri", "https://www.example.com/pub/logos
 /abccorp.mp3"]

["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBA
 gICBEAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvb
 W11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiB
 <...the remainder of base64-encoded data...>"]

10.9.4. "uid" Property 🆔

the "uid" property is a globally unique identifier for the object the jCard represents, like a forever ID card 🪪 Reference: [RFC6350], Section 6.7.6.

Value type: a single URI value. It MAY also be reset to free-form text. Cardinality: *1

["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]

10.9.5. "url" Property 🔗

the "url" property is a uniform resource locator associated with the object the jCard represents. Reference: [RFC6350], Section 6.7.8. 💌

⚠️ there are potential security and privacy implications of providing URLs with telephone calls, so be careful, bestie 🥺

The end client receiving a jCard with a "url" property MUST only display the URL and not automatically follow the URL or provide an automatic preview of the URL. ✨ On top of that, it MUST generally adhere to good practice and make it clear to the user that it is their choice whether to follow the URL in a browser context, consistent with all of the common browser security and privacy practices available on most consumer OS environments. 🛡️

Value type: a single uri value. Cardinality: *

["url", {}, "uri", "https://example.org/french-rest/chezchic.html"]

10.9.6. "version" Property 🔖

the "version" property MUST be included, and it's there to specify the version of the vCard specification used to format this vCard. Reference: [RFC6350], Section 6.7.9. 👑

Value type: a single text value. Cardinality: 1

["version", {}, "text", "4.0"]

11. Extension of jCard 🧚

part of the whole point of jCard is that it's extensible, so you can define brand new properties to relay new info related to a caller 🌈 that capability is inherently supported as part of standard extensibility. however, usage of those new properties should be published and registered following [RFC7095], Section 3.6 or as defined in future specifications. 💜

12. IANA Considerations 📋

12.1. "jcard" Purpose Parameter Value 💕

this document defines the "jcard" value for the 'purpose' parameter of the Call-Info header field [RFC3261]. IANA has added this document to the list of references for the 'purpose' value of Call-Info in the "Header Field Parameters and Parameter Values" registry within the "Session Initiation Protocol (SIP) Parameters" registry group. 📚

12.2. SIP Call-Info Header Field 'call-reason' Parameter 📞

this document defines the 'call-reason' generic parameter for use in the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. the parameter's token is "call-reason", and it takes the value of a quoted string. 🍓

+==============+================+===================+===========+
| Header Field | Parameter Name | Predefined Values | Reference |
+==============+================+===================+===========+
| Call-Info    | call-reason    | No                | RFC 9796  |
+--------------+----------------+-------------------+-----------+

                             Table 2

12.3. SIP Call-Info Header Field 'verified' Parameter ✅

this document defines the 'verified' generic parameter for use in the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. the parameter's token is "verified", and it takes the value of a quoted string that can only be "true". 🫶

+==============+================+===================+===========+
| Header Field | Parameter Name | Predefined Values | Reference |
+==============+================+===================+===========+
| Call-Info    | verified       | Yes               | RFC 9796  |
+--------------+----------------+-------------------+-----------+

                             Table 3

12.4. SIP Call-Info Header Field 'integrity' Parameter 🔐

this document defines the 'integrity' generic parameter for use as a new parameter in the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968]. the parameter's token is "integrity", and it takes the value of a quoted string. 💖

+==============+================+===================+===========+
| Header Field | Parameter Name | Predefined Values | Reference |
+==============+================+===================+===========+
| Call-Info    | integrity      | No                | RFC 9796  |
+--------------+----------------+-------------------+-----------+

                             Table 4

13. Security Considerations 🚨

okay this section is SERIOUS bestie, so read it all 😭 revealing info like someone's name, location, and affiliation necessarily comes with certain privacy risks. the SIP Call-Info header field has no particular confidentiality requirement, since the info sent in SIP is in the clear anyway. transport-level security can be used to hide info from eavesdroppers, and the same confidentiality mechanisms would protect any Call-Info or jCard information carried or referred to in SIP. 🔒

the use of the Call-Info header for transporting RCD ('rcd') is intended primarily for providing verified info at the termination of a call, where a verification service has a trusted UNI relationship with the user agent. 🦋 to make sure the integrity and authenticity of this data holds up, the security framework established by STIR should be followed, including the use of the 'rcd'PASSporT as defined in [RFC9795]. this framework enables digital signatures to verify the issuer of assertions related to the calling party's identity, and it distinguishes persistent identity attributes from transient, per-call details. implementers should also consider certificate-based constraints to ensure proper binding between caller identity assertions and call-specific metadata, while keeping the integrity of the info intact throughout transmission. since Call-Info is a means to convey verified caller info to the end user, mechanisms should be in place to validate the authenticity of the assertion, enforce appropriate certificate associations, and preserve the trustworthiness of RCD from origination to termination. 👑

the SIP framework, defined in [RFC3261] and the various extensions to SIP (which include STIR [RFC8224] and RCD [RFC9795]), has always provided mechanisms to assert info about the person or entity behind the call. that can be a real benefit to the SIP network, since it lets users help identify the calling party behind an abstract telephone number 📞 but it can also let actors impersonate a calling party they are not authorized to represent 💀 the core security consideration that has been acknowledged, either explicitly or implicitly, across the SIP and STIR specifications is that there be a management and policy layer that validates the participants in the ecosystem and their use of a SIP network with telephone number identifiers and identity-related info. users should assess this risk and make the appropriate adjustments to validate proper participation, while following these tools with these larger security, impersonation prevention, and privacy considerations. 🛡️

the use of this specification with the insertion of metadata related to a caller or the purpose of the call should recognize the risk that this info can be viewed by those network elements and participants involved in delivering the SIP call 👀 the insertion of media, directly or via Base64 encoding or using a remote URI that queries network resources, should be considered a potential threat vector to the user or user agent, since it could allow parsing of documents crafted to trigger a bug or install a virus 😱 remote access to URI content should additionally be considered as potentially exposing info about that user or user agent. some sensitive users may want the ability to control or disable these mechanisms entirely, and methods to restrict or disable the potential exposure should be considered to mitigate these concerns. largely, any info included in RCD should be considered public, and this specification does not define any mechanism to protect this info beyond the security and privacy associated with the SIP signaling itself. this is consistent with SIP more generally, and this specification follows a similar pattern for its use. 🌸

this specification contains the ability to include media resources, and URI and URL resource references to media resources, that could pose a threat when referencing or decoding the content of those media resources. that's similar to the threats that web browsers and other media decoding applications must be concerned about 🫣 network administrators should consider a network-specific set of policies or best practices for the use and hosting of media content that is agreed to contain validated media resources, evaluated to not pose a security threat to the participants or the devices supported in the ecosystem. 🧚

14. References 📚

14.1. Normative References 📚

Okay, bestie, these are the must-read sources the spec leans on, so they're basically the homework that comes first 🤓

[ISOPNG] ISO/IEC, "Information technology -- Computer graphics and image processing -- Portable Network Graphics (PNG), Functional specification", ISO/IEC 15948:2004, March 2004, <https://www.iso.org/standard/29581.html>.

[ITUJPEG] ITU-T, "Information technology - Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF)", ITU-T Recommendation T.871, ISO/IEC 10918-5, May 2013, <https://www.itu.int/rec/T-REC-T.871-201105-I/en>. 🖼️

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. 💅 The OG key words doc, obviously iconic.

[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>. 🦋

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. 📞 SIP, the whole vibe.

[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>. ☎️

[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <https://www.rfc-editor.org/info/rfc3968>. 🗂️

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. 🔤

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. ✍️ ABNF is the grammar language we've been reading all along.

[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/info/rfc6350>. 👩‍💼

[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, <https://www.rfc-editor.org/info/rfc7095>. 🧾

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>. 🔑

[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, <https://www.rfc-editor.org/info/rfc7852>. 🚨 Serious business, handle with care.

[RFC7903] Leonard, S., "Windows Image Media Types", RFC 7903, DOI 10.17487/RFC7903, September 2016, <https://www.rfc-editor.org/info/rfc7903>. 🪟

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 🔠 This one's the reason the capital letters matter!!

[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>. 🪪

[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>. 🎟️

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>. 🧃

[RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT) Extension for Rich Call Data", RFC 9795, DOI 10.17487/RFC9795, July 2025, <https://www.rfc-editor.org/info/rfc9795>. ✨ The newest one on the list!

[W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J. Weinberger, Ed., "Subresource Integrity", W3C Recommendation, 23 June 2016, <https://www.w3.org/TR/2016/REC-SRI-20160623/>. 🌐

[W3C-SVGTiny1.2] Anderssone, O., Ed., Berjon, R., Ed., Dahlström, E., Ed., Emmons, A., Ed., Ferraiolo, J., Ed., Grasso, A., Ed., Hardy, V., Ed., Hayman, S., Ed., Jackson, D., Ed., Lilley, C., Ed., McCormack, C., Ed., Neumann, A., Ed., Northway, C., Ed., Quint, A., Ed., Ramani, N., Ed., Schepers, D., Ed., and A. Shellshear, Ed., "Scalable Vector Graphics (SVG) Tiny 1.2 Specification", W3C Recommendation, 22 December 2008, <https://www.w3.org/TR/2008/REC-SVGTiny12-20081222/>. 🎨 That's a LOT of editors, it's giving group project energy 😭

14.2. Informative References 🌷

These ones are more like the bonus reading. Helpful, not required, but you'll look so smart if you check them out 🧠

[RFC2361] Fleischman, E., "WAVE and AVI Codec Registries", RFC 2361, DOI 10.17487/RFC2361, June 1998, <https://www.rfc-editor.org/info/rfc2361>. 🎬

[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>. 🤝

[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, <https://www.rfc-editor.org/info/rfc7340>. 🕵️‍♀️ The problem statement that started the whole secure-caller-ID plot arc.

Acknowledgements 🫶

Huge thank-yous to David Hancock, Alec Fenichel, Paul Kyzivat, Yi Jing, and everyone else in the SIPCORE and STIR working groups, plus ATIS/SIP Forum IPNNI. They gave super helpful suggestions and comments while this document was being made, and we are SO grateful 💖✨

Authors' Addresses 🖋️

Chris Wendt
Somos
United States of America
Email: chris@appliedbits.com


Jon Peterson
TransUnion
United States of America
Email: jon.peterson@transunion.com

📦 where this page comes from

ietf: rfc9796 2025-07
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms

RFC 9796

RFC 9796: SIP Call-Info Parameters for Rich Call Data 📇✨

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction ✨

2. Terminology 📖

3. Overview 🦋

4. A Call-Info Framework for Carrying Rich Call Data ✨

5. "jcard" Call-Info 'purpose' Token 🎀

6. 'call-reason' Call-Info Parameter 💌

7. 'verified' Call-Info Parameter ✨

8. 'integrity' Call-Info Parameter 🔐

9. Usage and an Example of Call-Info for RCD 📇

10. Usage of jCard and Property-Specific Usage 🎀

10.1. Usage of URIs in jCard 🔗

10.2. Usage of Multimedia Data in jCard or with the "icon" Call-Info 'purpose' Token 🎀

10.3. Cardinality 🔢

10.4. Identification Properties 🪪

10.4.1. "fn" Property 💖

10.4.2. "n" Property 🌷

10.4.3. "nickname" Property 🧸

10.4.4. "photo" Property 📸

10.5. Delivery Addressing Properties 📬

10.5.1. "adr" Property 🏠

10.6. Communications Properties 💬

10.6.1. "tel" Property ☎️

10.6.2. "email" Property 📧

10.6.3. "lang" Property 🌍

10.7. Geographical Properties 🗺️

10.7.1. "tz" Property ⏰

10.7.2. "geo" Property 🌏

10.8. Organizational Properties 🏢

10.8.1. "title" Property 👑

10.8.2. "role" Property 🎯

10.8.3. "logo" Property 🎨

10.8.4. "org" Property 🏢

10.9. Explanatory Properties 📝

10.9.1. "categories" Property 🏷️

10.9.2. "note" Property 🗒️

10.9.3. "sound" Property 🔊

10.9.4. "uid" Property 🆔

10.9.5. "url" Property 🔗

10.9.6. "version" Property 🔖

11. Extension of jCard 🧚

12. IANA Considerations 📋

12.1. "jcard" Purpose Parameter Value 💕

12.2. SIP Call-Info Header Field 'call-reason' Parameter 📞

12.3. SIP Call-Info Header Field 'verified' Parameter ✅

12.4. SIP Call-Info Header Field 'integrity' Parameter 🔐

13. Security Considerations 🚨

14. References 📚

14.1. Normative References 📚

14.2. Informative References 🌷

Acknowledgements 🫶

Authors' Addresses 🖋️