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 May 2021.¶

Copyright Notice

Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

Traditional telephone network signaling protocols have long supported delivering a 'calling name' from the originating 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 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. The same is true of information in the Call-Info header field.¶

To allow calling parties to initiate, and called parties to receive, a more comprehensive, deterministic, and extensible rich call data for incoming calls, we describe new tokens for the SIP [RFC3261] Call-Info header field and a corresponding "purpose" parameter. We also define a new parameter of Call-Info designed for carrying a "reason" value. For this document, depending on the policies of the communications system, calling parties could either be the end user device or an originating service provider, and called parties could also similarly be an end user device or the terminating service provider acting on behalf of the recipient of the call.¶

Used on its own, this specification assumes that called party user agent can trust the SIP network or the SIP provider to deliver the correct rich call data (RCD) information. This may not always be the case and thus, the entity inserting the Call-Info header field and the UAS relying on it SHOULD be part of the same trust domain [RFC3324]. Alternatively, and likely the recommended approach, is that the entity inserting the call-info header should also sign the caller information via STIR mechanisms [RFC8224] and specifically through the [I-D.ietf-stir-passport-rcd]. This STIR signature would likely be provided by the caller itself or the originating service provider using an authoritative signature to authenticate the information is from the originator and hasn't been tampered with in transmission.¶

[RFC7852] provides a means of carrying additional data about callers for the purposes of emergency services (especially its Section 4.4 "Owner/Subscriber" information). 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

The Call-Info header field, defined in [RFC3261] Section 20.9, defines a purpose parameter currently with "info", "icon", and "card" tokens. This document defines one new purpose value and one new generic parameter for Call-Info.¶

The value "jcard" is to be used to associate rich call data related to the identity of the calling party in the form of a jCard [RFC7095]. While there is a "card" token that is already defined with similar purpose, there are two primary reasons for the definition and usage of jCard and the use of JSON over the XML based vCard [RFC2426]. First, JSON has become the default and optimally supported for transmission, parsing, and manipulation of data on IP networks. Second, jCard has also 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].¶

A generic parameter for "call-reason" is to be used to provide a string or other object that is used to convey the intent or reason the caller is calling to help the called party understand better the context of the call and why they may want to answer the call.¶

4. "jcard" Call-Info Token

The use of the new Call-Info Token "jcard" is for the purpose of supporting 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" is as follows.¶

The Call-Info header should include a URI where the resource pointed to by the URI is a jCard JSON object defined in [RFC7095]. The web server serving this file MUST use the MIME media type for JSON text as application/json with a default encoding of UTF-8 [RFC4627]. This also MAY be carried in the body of the SIP request bearing this Call-Info 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 the resource is retrieved.¶

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

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

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

["vcard",
 [
  ["version", {}, "text", "4.0"],
  ["fn", {}, "text", "James Bond"],
  ["n", {}, "text", ["Bond", "James", "", "", "Mr."]],
  ["adr", {"type":"work"}, "text",
    ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
    "20008", "USA"]
  ],
  ["email", {}, "text", "007@mi6-hq.com"],
  ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
    "tel:+1-202-555-1000"],
  ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"],
  ["bday", {}, "date", "19241116"]
  ["logo", {}, "uri",
  "https://upload.wikimedia.org/wikipedia/en/c/c5
  /Fleming007impression.jpg"]
 ]
]

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:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
Call-Info: <cid:12155551212@example.com>;purpose=jcard;call-reason= \
  "For your ears only"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551212@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/vcard+json
Content-ID: <12155551212@example.com>

["vcard",[["version",{},"text","4.0"],["fn",{},"text","James Bond"
],["n",{},"text",["Bond","James","","","Mr."]],["adr",{"type":
"work"},"text",["","","3100 Massachusetts Avenue NW","Washington",
"DC","20008","USA"]],["email",{},"text","007@mi6-hq.com"],["tel",
{"type":["voice","text","cell"],"pref":"1"},"uri",
"tel:+1-202-555-1000"],["tel",{"type":["fax"]},"uri",
"tel:+1-202-555-1001"],["bday",{},"date","19241116"]["logo",{},
"uri","https://upload.wikimedia.org/wikipedia/en/c/c5
/Fleming007impression.jpg"]]]

5. 'call-reason' Call-Info Parameter

In addition to the jCard value defined here, this specification also defines a generic parameter of the Call-Info header 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 160 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.¶

One alternative approach would be to use the baseline [RFC3261] Subject header field value to convey the reason for the call. Because the Subject header has seen little historical use in SIP implementations, however, and its specification describes its potential use in filtering, it seems more 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"

One can readily imagine a need for more structured call reason data that could be reliably processed automatically. Future versions of this specification may explore ways to provide a structured data object in place of a textual string to support things like internationalization or categories of reason that can be parsed by machines.¶

6. 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] specific to making sure there is a mimimum level of supported properties that every implementation of this specification should adhere to. This includes the support of intepreting the value of this property and the ability to render in some form appropriate to the display capabilities of the device. This includes requirements specific to either textual displays and graphics capable displays.¶

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/photos/jqpublic.gif"]

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/pub/logos/abccorp.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:
["catagories", {}, "text", "TRAVEL AGENT"]

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

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

Example:
["sound", {}, "uri", "http://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"]

7. Extension of jCard

Part of the intent of the usage of jCard is that it has it's own extensibility properties where new properties can be defined to relay newly defined 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.¶

8. Acknowledgements

We would like to thank David Hancock and other members of the STIR working group for helpful suggestions and comments for the creation of this draft.¶

9. IANA Considerations

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

10. Security Considerations

Revealing information such as the name, location, and affiliation of a person necessarily entails certain privacy risks. SIP and Call-Info 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.¶

Authors' Addresses