SIP Call-Info Parameters for Rich Call Data

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 22 January 2025.¶

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Signaling protocols in telephone networks have long supported the delivery of a 'calling name' from the originating side to the terminating side, though in practice, the terminating side is often left to derive a name from the calling-party number by consulting a local address book or an external database. SIP [RFC3261] similarly can carry a 'display-name' in the From header field value from the originating to terminating side, though it is an unsecured field that is not commonly trusted and is often replaced or ignored. The same can be considered true of information in the Call-Info header field in SIP.¶

To allow calling parties to initiate, and called parties to receive, a more comprehensive, deterministic, and extensible Rich Call Data (RCD) for incoming calls, this document defines a new parameter ('call-reason') for the SIP Call-Info header field [RFC3261] and also a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. For this document and depending on the policies of the communications system, a calling party could be either the end user device (e.g., a SIP user agent (UA)) or a network service as part of a telephone service provider. Similarly, a called party could be an end user device or the network telephone service provider acting on behalf of the recipient of the call.¶

In order to properly translate and communicate some of the authenticated and trusted properties of 'rcd' claims defined in [I-D.ietf-stir-passport-rcd], this document defines two new parameters, 'verified' and 'integrity'. These parameters help translate RCD information that had been sent via a SIP network to, for example, a SIP entity on the edge of the network-to-network interface (NNI) that contains a verification service as defined in [RFC8224] and further defined specific to RCD information in [I-D.ietf-stir-passport-rcd]. The verification procedures include the concepts of successful verification of the "rcd" claims and can be correspondingly translated and represented in the Call-Info header field via these new parameters.¶

Used on its own, this specification assumes that the called party UA can trust the SIP network or the SIP provider to assign, deliver, and protect the correct RCD information as an end-to-end security policy. However, as is true in many interconnected communications services, this end-to-end trust cannot be guaranteed. Therefore, the recommended approach is that the entity inserting the Call-Info header field should also sign the caller information via STIR-defined protocol tools [RFC7340] for SIP [RFC8224] and specifically through the use of RCD or the "rcd" PASSporT defined in [I-D.ietf-stir-passport-rcd].¶

Alternatively, this specification can be utilized in conjunction with the protocols defined in [I-D.ietf-stir-passport-rcd] as part of the communications signaling path, specifically in the trusted UNI device interface at the terminating side as part of an authenticated, network-to-device, trusted signaling where a device may not have the ability to verify the "rcd" PASSporT, but it can receive the RCD information from the Call-Info header field as defined in this specification.¶

[RFC7852] provides a means of carrying additional data about callers for the purposes of emergency services (especially Section 4.4 (Owner/Subscriber Information) of [RFC7852]). This specification provides an overlapping functionality for non-emergency cases. Rather than overloading its "EmergencyCallData" Call-Info 'purpose' parameter value, this document defines a separate 'purpose' parameter for the more generic delivery of information via jCard [RFC7095]. This document borrows from [RFC7852] the capability to carry a data structure as a body, through the use of the "cid" URI scheme [RFC2392].¶

2. Terminology

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

3. Overview

In this document, we provide a framework for the use of Call-Info header field to carry RCD in SIP [RFC3261]. The Call-Info header field (defined in [RFC3261], Section 20.9) defines a 'purpose' parameter. In addition to providing guidance on calling name practices and the use of the existing 'purpose' parameter token, "icon", this document expands on other types of RCD by defining a new 'purpose' token, "jcard", and three new parameters, 'call-reason', 'verified', and 'integrity' for the Call-Info header field to align with RCD as defined in the STIR framework [RFC8224] and with "rcd" PASSporTs defined in [I-D.ietf-stir-passport-rcd].¶

The 'purpose' parameter token "jcard" is used to associate RCD related to the identity of the calling party in the form of a jCard [RFC7095]. While there is a "card" token defined in [RFC3261] which could be considered to have an overlapping purpose, the "jcard" token is intended to denote the jCard profile defined in this document for use in the Call-Info header field for RCD. The choice of jCard in this specification is guided by two things. First, JSON has become the default and is generally the widely accepted, optimally supported format for transmission, parsing, and manipulation of data on IP networks, and jCard represents an extensible method of providing information about a person or business associated with a call. Second, jCard has been defined in [I-D.ietf-stir-passport-rcd] and has been adopted by PASSporT [RFC8225] because of the usage of JSON Web Tokens (JWT) [RFC7519].¶

The new Call-Info header field parameter 'call-reason' provides a string or other object that conveys the caller's intent or reason for calling to help the called party understand the context and intent of the call and why they may want to answer the call.¶

The new Call-Info header field parameter 'verified' provides an indication, with the value "true", to represent the results of the verification procedures that were performed by the sender of the Call-Info header field. The new Call-Info header field parameter 'integrity' provides a mechanism to associate an integrity hash string, as defined in [I-D.ietf-stir-passport-rcd] in Section 8.2, that is associated with the content of the resource referenced by the URI represented in the Call-Info header field.¶

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

This specification extends the Call-Info header field to be compatible and complimentary to the RCD framework defined in [I-D.ietf-stir-passport-rcd]. Typically, a SIP-based call involves multiple hops through different trusted and untrusted networks. The STIR framework [RFC7340] addresses the protection of the carriage of call information and identities over untrusted networks, which wasn't addressed in the core SIP specifications. [RFC3261], Section 20.9 defines the Call-Info header field as the mechanism for carrying call- and caller-related information and also provides procedures for defining new 'purpose' parameter tokens. This document discusses the use of existing tokens and defines a new 'purpose' token to correspond to the RCD framework.¶

There are a number of RCD information types that can be transmitted in the Call-Info header field of a SIP request. The STIR RCD specification [I-D.ietf-stir-passport-rcd] defines calling name, a logo or icon associated with the caller, and a call reason string. It also discusses an extensible way of carrying caller information using jCard [RFC7095]. It may be that future specifications extend information types and, similar to how this document extends the Call-Info header field to provide corresponding functionality to STIR RCD, it is RECOMMENDED that future specifications also provide corresponding Call-Info extensions.¶

The RCD framework defined both in this document as well as in [I-D.ietf-stir-passport-rcd] carries call-specific information. The insertion of RCD is intended to be singular in that the receiving party should not be required to make any call-specific decisions based on redundant, duplicate, or conflicting RCD. The RCD information is either intended to be added by a party that is authoritative over that information or to have been translated from a verified STIR RCD PASSporT and unmodified once in a trusted domain. Any additional parties involved in the call path SHOULD NOT modify the Call-Info header field or add additional Call-Info header fields related to RCD. The insertion of the RCD Call-Info header field should be considered a trusted action based on trusted information, and the information SHOULD NOT be considered modifiable as a best practice.¶

As discussed in [I-D.ietf-stir-passport-rcd], the calling name uses the display-name value of the From header field [RFC3261] of the request. Alternatively, for some calls, the calling name may come from the P-Asserted-ID header field [RFC3325]. While this is out of scope for Call-Info header field in terms of the representation of the display-name value, this document does discuss the representation of the verification of this value using the 'verified' parameter.¶

For logos or icons that can represent the calling party, the 'purpose' token "icon" [RFC3261] is used to indicate a URI for an image resource that can be displayed to the user receiving the SIP request. For the purpose of this document and the transmission of RCD, the "icon" 'purpose' token should be used as defined. Section 8.2 provides high-level guidance on image formatting and related information.¶

This document defines 'call-reason' as a new parameter for the Call-Info header field. This parameter carries a string indicating the reason for the call.¶

jCard is a comprehensive and extensible mechanism defined in the STIR RCD framework. While [RFC3261] specifies a "card" 'purpose' token, the intent of defining a new "jcard" 'purpose' token is to use the JSON jCard format [RFC7095] and to provide guidance for the use and non-use of jCard attributes to describe the calling party in a communications session as well to provide some security considerations around that information. These topics are covered in the next sections.¶

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

The Call-Info 'purpose' token "jcard" indicates support of RCD associated with the identity of a calling party in a SIP call [RFC3261], Section 20.9. The format of a Call-Info header field when using the "jcard" token is as follows.¶

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 default encoding of UTF-8 [RFC8259]. This 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 bearing this Call-Info header field via the "cid" URI scheme [RFC2392]. Alternatively, the URI MUST define the use HTTPS or a transport that can validate the integrity of the source of the resource as well as the transport channel through which the resource is retrieved. If, in the specific deployment environment of SIP, the source or integrity of the RCD information cannot be trusted, then the use of the STIR RCD framework defined in [I-D.ietf-stir-passport-rcd] should be considered.¶

The jCard is intended to contain multiple information elements about the calling party. A call and its corresponding single RCD-related Call-Info header field MUST only contain a single "jcard" token.¶

The fields like "fn", "photo", or "logo" if used with the use of "icon" calling name in From or P-Asserted-ID header field or purpose token, as described in the previous section, MUST either match or be avoided to allow the called party to clearly determine the intended calling name or icon.¶

An example of a Call-Info header field is:¶

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

An example of the contents of a URL-linked jCard JSON file is shown as follows:¶

["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"]
  ]
]

An example SIP INVITE using the "data" URI scheme is as follows:¶

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 2015 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

An example SIP INVITE using the "cid" URI scheme is as follows:¶

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 2015 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","ht
tps://example.com/photos/quartermaster-256x256.png"],["logo",{},"u
ri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"]]]

6. 'call-reason' Call-Info Parameter

This specification defines a new parameter that extends the overall content of the RCD-related Call-Info header field. As other parameters may be defined in the future, this parameter is intended to be separate and distinct from the other URI and 'purpose' tokens that may proceed these parameters.¶

This new parameter of the Call-Info header field is called 'call-reason'. The 'call-reason' parameter is intended to convey a short textual message suitable for display to an end user during call alerting. As a general guideline, this message SHOULD be no longer than 64 characters; displays that support this specification may be forced to truncate messages that cannot fit onto a screen. This message conveys the caller's intention in contacting the callee. It is an optional parameter, and the sender of a SIP request cannot guarantee that its display will be supported by the terminating endpoint. The manner in which this reason is set by the caller is outside the scope of this specification.¶

An alternative approach would have been to use the value of Subject header field [RFC3261] to convey the reason for the call. However, because the Subject header field has seen little historical use in SIP implementations and its specification describes its potential use in filtering, it seemed prudent to define a new means of carrying a call reason indication.¶

An example of a Call-Info header field value with the "call-reason" parameter follows:¶

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

In the case that there is only a 'call-reason' or 'verified' parameter or any future parameters that may be defined and no need for a purpose parameter with no associated URI, it is RECOMMENDED to include a null data URI, "data:" as the URI. That purpose parameter MUST be "jcard" defined in this document to avoid any conflicts with existing implementations and previously defined purpose parameters. As an example:¶

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

7. 'verified' Call-Info Parameter

This specification defines an additional new parameter, the 'verified' parameter, that extends and complements the content conveyed by the RCD-related Call-Info header field. This parameter is intended to be used to indicate to the recipient that the information contained in the Call-Info header field has been verified by verification procedures for claims defined in [I-D.ietf-stir-passport-rcd] Section 8. It should be considered separate and distinct and appear once for a given Call-Info header instance from the other URI and 'purpose' tokens that may proceed or come after this parameters.¶

There is a single valid value associated with the 'verified' parameter of 'true'. The value 'true' indicates to the recipient that the party that included the Call-Info header field performed a successful verification of the information represented. As a general principle of Call-Info header field information, the recipients ability to trust the 'verified' parameter is based on the trusted relationship of whom they are receiving the SIP request.¶

Example where the parameter verified="true" is used to represent that a verification procedure has been performed within a trust domain to indicate the 'icon' URL has been successfully verified:¶

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

In addition to the use of the indication of successful verification of RCD information, an important usage of the 'verified' parameter is for the indication of verified "display-name" information, sometimes referred to as calling name or CNAM.¶

In the following example, a call was delivered via an NNI network relationship to a terminating provider with the following 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 receives a SIP INVITE with an identity header containing the STIR RCD PASSporT is verified through a verification service. The provider then wants to deliver the call to an end device in the trusted and authenticated UNI network. The provider uses local policies to determine the information desired to present to the end device. The following example SIP INVITE could be used to represent the RCD information using two Call-Info header fields. Because the verification of both the icon and calling name passed, a Call-Info header for the 'icon' is added with a verified="true" parameter, and the use of Call-Info with a null data URI is used, as discussed in the "call-reason" section above. This document defines the convention that when a Call-Info header field with a null data URI, "data:", a default purpose of "jcard" and adding a verified="true" indicates that the display-name information in either the From and/or P-Asserted-ID header field has been verified via RCD verification procedures.¶

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

This specification defines an additional new parameter, the 'integrity' parameter, that extends and complements the integrity information conveyed specifically by the 'rcdi' claim in the RCD-related Call-Info header field. This parameter is intended to be used to indicate, for a URI represented in the Call-Info header field, the resource referenced by that URI has an associated integrity hash value. Section 6.1 of [I-D.ietf-stir-passport-rcd] describes the creation of the digest value including the hash algorithm indicator a '-' separator and the hash value as a string. The JSON pointer object container described as the container of the 'rcdi' hashes is not necessary since each hash value should only correspond to a single URI.¶

Typically, this hash value, assuming the URI and the resource pointed to the URI don't change between the STIR RCD PASSporT and the Call-Info URI value, the integrity value can be directly used as the same corresponding string in both the 'rcdi' claim and the 'integrity' parameter string value.¶

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"
  }
}

Example corresponding SIP INVITE with Call-Info information derived from RCD information 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+kHPyHm1JKbm7+
  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 the usage of URIs and 'purpose' parameter tokens should generally follow the procedures defined in [RFC3261]. The following example provides both the STIR RCD PASSporT and the corresponding set of Call-Info header fields shows the use of multiple 'purpose' parameters to indicate a jCard and an icon and also a 'call-reason' 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 definition of the specific properties or JSON arrays associated with each property, this specification defines a few rules above and beyond [RFC7095] that are specific to the use of jCard for Call-Info and RCD to ensure there is a minimum level of supported properties to which every implementation of this specification should adhere. This includes support for interpreting the value of these properties and the ability to render in some appropriate form the display capabilities of common telephone devices as well as applications, and also includes requirements specific to textual and graphics-capable displays.¶

  +-------------+--------------------------------------------------+
  | 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.  |
  +-------------+--------------------------------------------------+

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

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

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

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

Example:
["adr", {"type":"work"}, "text",
  ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
  "20008", "USA"]

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

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

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

Example:
["tz", {}, "text", "Raleigh/North America"]

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

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

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

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

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

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

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

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

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

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

["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE
      AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
      ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
      <...the remainder of base64-encoded data...>"]

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

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

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

11. Extension of jCard

Part of the intent of using jCard is to leverage its extensibility to define new properties to relay new information related to a caller. This 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 new specifications.¶

12. IANA Considerations

  +--------------+----------------+-------------------+------------+
  | Header Field | Parameter Name | Predefined Values | Reference  |
  +--------------+----------------+-------------------+------------+
  | Call-Info    | purpose        | Yes               | [this RFC] |
  +--------------+----------------+-------------------+------------+

  +--------------+----------------+-------------------+------------+
  | Header Field | Parameter Name | Predefined Values | Reference  |
  +--------------+----------------+-------------------+------------+
  | Call-Info    | call-reason    | No                | [this RFC] |
  +--------------+----------------+-------------------+------------+

  +--------------+----------------+-------------------+------------+
  | Header Field | Parameter Name | Predefined Values | Reference  |
  +--------------+----------------+-------------------+------------+
  | Call-Info    | verified       | Yes               | [this RFC] |
  +--------------+----------------+-------------------+------------+

  +--------------+----------------+-------------------+------------+
  | Header Field | Parameter Name | Predefined Values | Reference  |
  +--------------+----------------+-------------------+------------+
  | Call-Info    | integrity      | No                | [this RFC] |
  +--------------+----------------+-------------------+------------+

13. Security Considerations

Revealing information such as the name, location, and affiliation of a person necessarily entails certain privacy risks. The SIP Call-Info header field has no particular confidentiality requirement, as the information sent in SIP is in the clear anyway. Transport-level security can be used to hide information from eavesdroppers, and the same confidentiality mechanisms would protect any Call-Info or jCard information carried or referred to in SIP.¶

The security framework of signing and providing integrity to this data [I-D.ietf-stir-passport-rcd] should be followed, and the use of constraints and other certificate-based associations should be considered. This includes considerations for information about the calling party, which is generally constant, versus per-call data, which is more transient. This also includes the relationship that certificates with constraints presents to how they relate to each other and how that information is managed, protected, and associated with the correct call corresponding to a calling party.¶

Acknowledgements

We would like to thank David Hancock, Alec Fenichel, Paul Kyzivat, Yi Jing and other members of the SIPCORE and STIR working groups and ATIS/SIP Forum IPNNI for their helpful suggestions and comments during the creation of this document.¶

Authors' Addresses