SIP Call-Info Parameters for Rich Call Data
Extracted elements (31)
A new 'call-reason' parameter was defined rather than reusing the SIP Subject header field because Subject has seen little historical use in SIP implementations and its specification describes its potential use in filtering, making a dedicated parameter more appropriate.
A new "jcard" 'purpose' token was defined rather than reusing the existing "card" token in order to specifically denote the jCard profile defined in this document for RCD use, avoiding overlap with the broader and differently-scoped "card" token semantics.
jCard was chosen for RCD because it is an extensible method of providing information about a person or business, has been defined in RFC 9795 and adopted by PASSporT (RFC 8225) due to its use of JSON Web Tokens. This made jCard a natural fit for the STIR RCD framework.
RCD insertion is intended to be singular: the receiving party should not be required to make call-specific decisions based on redundant, duplicate, or conflicting RCD. Information should be added by an authoritative party or translated from a verified STIR RCD PASSporT and left unmodified.
Display-name information in the From or P-Asserted-ID header field is considered verified via RCD PASSporT procedures when a Call-Info header field is present with purpose="jcard", a null data URI ("data:"), and verified="true".
For 'call-reason' or 'verified' parameters that do not require an associated URI, the Call-Info header field URI should be set to the null data URI ("data:") with purpose="jcard" to avoid conflicts with existing implementations and previously defined purpose parameters.
A call and its single RCD-related Call-Info header field MUST only contain a single jCard object represented by an array with two elements, where the first element MUST be the string "vcard".
An end client receiving a jCard with a "url" property MUST only display the URL and MUST NOT automatically follow the URL or provide an automatic preview, and MUST adhere to good practice to make the user's choice clear.
Any additional parties in the call path MUST NOT modify the Call-Info header field or add additional Call-Info header fields related to RCD. The trusted and verified caller RCD information MUST NOT be modified or altered.
For images such as "photo" and "logo" properties, the default image formats SHOULD be PNG or JPEG as these support 24-bit RGB images. SVG Tiny 1.2 SHOULD also be supported as an additional default format for vector images.
If not using the "data" or "cid" URI schemes, the Call-Info header field URI MUST use a transport that can validate the integrity of the source of the resource, such as HTTPS tied to a specific validated domain.
Implementations MUST support the hash algorithms SHA-256, SHA-384, and SHA-512, identified by "sha256", "sha384", and "sha512" respectively, for the 'integrity' parameter.
The 'call-reason' parameter SHOULD be no longer than 64 characters; displays supporting this specification may be forced to truncate messages that cannot fit on a screen.
The "fn" (formatted name) property MUST have a cardinality of 1*, meaning one or more instances per jCard MUST be present.
The jCard "version" property MUST be included and MUST carry exactly one instance per jCard (cardinality 1) with a value of "4.0".
The media type for jCard content referenced or carried via the Call-Info header field MUST be set as application/json with an encoding of UTF-8 (RFC 8259).
The "photo" property SHOULD correspond to a square image with dimensions of 128x128, 256x256, 512x512, or 1024x1024 pixels to promote interoperability and proper rendering.
The values represented in the RCD MUST match the corresponding information in the SIP message to enable proper verification of calling name or icon, consistent with RFC 8224 and RFC 9795 verification procedures.
When URIs are used within a jCard, the content referenced by those URIs MUST NOT contain any URI references; the client MUST ensure that those URI references are not followed, and any URIs present in URI-linked content are not rendered.
The 'call-reason' Call-Info parameter carries a short textual message conveying the caller's intention for the call, intended for display to the end user during call alerting. It is an optional parameter and operates independently of URI and 'purpose' tokens.
The 'integrity' Call-Info parameter associates an integrity hash string with the resource referenced by the Call-Info URI, using the format "<algorithm>-<hash>" (e.g., "sha256-..."). It corresponds conceptually to W3C Subresource Integrity and mirrors the "rcdi" claim in the RCD PASSporT.
The "jcard" Call-Info 'purpose' token indicates that the URI in the Call-Info header field points to a jCard JSON object (RFC 7095) representing the calling party's Rich Call Data. It is distinct from the existing "card" token and is specific to the jCard profile defined for RCD use in SIP.
The 'verified' Call-Info parameter, with the sole valid value of "true", indicates to the recipient that the party inserting the Call-Info header field has successfully performed verification procedures as defined in RFC 9795 Section 8. Its scope is limited to the specific Call-Info header field on which it appears.
IANA has registered the 'call-reason' parameter for the SIP Call-Info header field in the "Header Field Parameters and Parameter Values" registry (RFC 3968). The parameter takes the value of a quoted string with no predefined values.
IANA has registered the 'integrity' parameter for the SIP Call-Info header field in the "Header Field Parameters and Parameter Values" registry (RFC 3968). The parameter takes the value of a quoted string (the integrity hash) with no predefined values.
IANA has registered the "jcard" value for the 'purpose' parameter of the SIP Call-Info header field in the "Header Field Parameters and Parameter Values" registry within the "Session Initiation Protocol (SIP) Parameters" registry group.
IANA has registered the 'verified' parameter for the SIP Call-Info header field in the "Header Field Parameters and Parameter Values" registry (RFC 3968). The parameter takes a quoted string value; the only valid value is "true" (predefined values: Yes).
Inclusion of media directly, via Base64 encoding, or via remote URIs in RCD poses threat vectors: maliciously crafted documents could trigger parsing bugs or install malware, and remote URI access could expose user agent information. Sensitive users should be able to control or disable these mechanisms.
Revealing information such as name, location, and affiliation in RCD entails privacy risks. Transport-level security can protect Call-Info and jCard data from eavesdroppers. RCD information should generally be considered public as this specification defines no confidentiality mechanism beyond SIP signaling itself.
The Call-Info mechanism can enable actors to impersonate a calling party they are not authorized to represent. A management and policy layer that validates participants in the ecosystem and their use of telephone number identifiers is required to mitigate this risk.
A jCard object carried in a Call-Info header field MUST be a JSON array with exactly two elements: the string "vcard" as the first element, and an array of jCard property arrays as the second element. It is encoded as application/json with UTF-8.