Network Working Group C. Wendt
Internet-Draft Comcast
Intended status: Standards Track J. Peterson
Expires: September 10, 2020 Neustar Inc.
March 09, 2020
SIP Call-Info Parameters for Rich Call Data
draft-wendt-sipcore-callinfo-rcd-01
Abstract
This document describes a SIP Call-Info usage defined to include rich
data associated with the identity of the calling party that can be
rendered to called party for providing more useful information about
the caller or the specific reason for the call. This includes
extended comprehensive information about the caller such as what a
jCard object can represent for describing the calling party or other
call specific information such as describing the reason or intent of
the call. The elements defined for this purpose are intended to be
extensible to accommodate related information about calls that helps
people decide whether to pick up the phone and additionally, with the
use of jCard and other elements, to be compatible with the STIR/
PASSporT Rich Call Data framework.
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 September 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wendt & Peterson Expires September 10, 2020 [Page 1]
Internet-Draft Call-Info Rich Call Data March 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 4
5. 'Reason' Call-Info Parameter . . . . . . . . . . . . . . . . 5
6. Usage of jCard and property specific usage . . . . . . . . . 6
6.1. Identification properties . . . . . . . . . . . . . . . . 6
6.1.1. "fn" property . . . . . . . . . . . . . . . . . . . . 6
6.1.2. "n" property . . . . . . . . . . . . . . . . . . . . 7
6.1.3. "nickname" property . . . . . . . . . . . . . . . . . 7
6.1.4. "photo" property . . . . . . . . . . . . . . . . . . 7
6.2. Delivery Addressing Properties . . . . . . . . . . . . . 7
6.2.1. "adr" property . . . . . . . . . . . . . . . . . . . 7
6.3. Communications Properties . . . . . . . . . . . . . . . . 8
6.3.1. "tel" property . . . . . . . . . . . . . . . . . . . 8
6.3.2. "email" property . . . . . . . . . . . . . . . . . . 8
6.3.3. "lang" property . . . . . . . . . . . . . . . . . . . 8
6.4. Geographical Properties . . . . . . . . . . . . . . . . . 9
6.4.1. "tz" property . . . . . . . . . . . . . . . . . . . . 9
6.4.2. "geo" property . . . . . . . . . . . . . . . . . . . 9
6.5. Organizational Properties . . . . . . . . . . . . . . . . 9
6.5.1. "title" property . . . . . . . . . . . . . . . . . . 9
6.5.2. "role" property . . . . . . . . . . . . . . . . . . . 9
6.5.3. "logo" property . . . . . . . . . . . . . . . . . . . 9
6.5.4. "org" property . . . . . . . . . . . . . . . . . . . 10
6.5.5. "member" property . . . . . . . . . . . . . . . . . . 10
6.5.6. "related" property . . . . . . . . . . . . . . . . . 10
6.6. Explanatory Properties . . . . . . . . . . . . . . . . . 10
6.6.1. "catagories" property . . . . . . . . . . . . . . . . 10
6.6.2. "note" property . . . . . . . . . . . . . . . . . . . 10
6.6.3. "sound" property . . . . . . . . . . . . . . . . . . 10
6.6.4. "uid" property . . . . . . . . . . . . . . . . . . . 10
6.6.5. "url" property . . . . . . . . . . . . . . . . . . . 10
7. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Wendt & Peterson Expires September 10, 2020 [Page 2]
Internet-Draft Call-Info Rich Call Data March 2020
9.1. SIP Call-Info Header Field Purpose Token Request . . . . 11
9.2. SIP Call-Info Header Field Purpose Token Request . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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
Wendt & Peterson Expires September 10, 2020 [Page 3]
Internet-Draft Call-Info Rich Call Data March 2020
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.
First, the purpose value of "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]. JSON has become the default and optimally supported
for transmission, parsing, and manipulation of data on IP networks.
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].
Second, a generic parameter for "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]. This MAY
be carried in the body of the SIP request bearing this Call-Info via
Wendt & Peterson Expires September 10, 2020 [Page 4]
Internet-Draft Call-Info Rich Call Data March 2020
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>
An example 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"]
]
]
Examples using the "cid" URI scheme will follow in future versions of
this specification.
5. '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 "reason".
The "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 ten words;
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.
Wendt & Peterson Expires September 10, 2020 [Page 5]
Internet-Draft Call-Info Rich Call Data March 2020
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 "reason"
parameter follows:
Call-Info: <https://example.com/jbond.json>;reason="Regarding your restaurant reservation"
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.
6.1. Identification properties
These types are used to capture information associated with the
identification and naming of the entity associated with the jCard.
6.1.1. "fn" property
The "fn" property MUST be supported with the intent of providing a
formatted text corresponding to the name of the object the jCard
represents. Reference [RFC6350] Section 6.2.1.
Example:
["fn", {}, "text", "Mr. John Q. Public\, Esq."]
Wendt & Peterson Expires September 10, 2020 [Page 6]
Internet-Draft Call-Info Rich Call Data March 2020
6.1.2. "n" property
The "n" property SHOULD be supported with the intent of providing the
components of the name of the object the jCard represents. Reference
[RFC6350] Section 6.2.2.
Example:
["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]
["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]
6.1.3. "nickname" property
The "nickname" property SHOULD be supported with the intent of
providing the text corresponding to the nickname of the object the
jCard represents. Reference [RFC6350] Section 6.2.3.
Example:
["nickname", {}, "text", "Robbie"]
["nickname", {}, "text", "Jim,Jimmie"]
["nickname", {}, "text", "TYPE=work:Boss"]
6.1.4. "photo" property
The "photo" property MUST be supported with the intent of an 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 formating and rendering of images, the
photo SHOULD correspond to a square image size of the sizes 128x128,
256x256, 512x512, or 1024x1024 pixels.
Example:
["photo", {}, "uri", "http://www.example.com/pub/photos/jqpublic.gif"]
6.2. Delivery Addressing Properties
These properties are concerned with information related to the
delivery addressing or label for the jCard object.
6.2.1. "adr" property
The "adr" property MUST be supported with the intent of providing the
delivery address of the object the jCard represents. Reference
[RFC6350] Section 6.3.1.
Wendt & Peterson Expires September 10, 2020 [Page 7]
Internet-Draft Call-Info Rich Call Data March 2020
Example:
["adr", {"type":"work"}, "text",
["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008",
"USA"]
6.3. Communications Properties
These properties describe information about how to communicate with
the object the jCard represents.
6.3.1. "tel" property
The "tel" property MUST be supported with the intent of providing the
telephone number for telephony communication of the object the jCard
represents. Reference [RFC6350] Section 6.4.1.
Relative to the SIP From header field this information may provide
alternate telephone number or other related telephone numbers for
other uses.
Example:
["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
"tel:+1-202-555-1000"]
["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]
6.3.2. "email" property
The "email" property MUST be supported with the intent of providing
the electronic mail address for communication of the object the jCard
represents. Reference [RFC6350] Section 6.4.2.
Example:
["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]
["email", {"pref":"1"}, "text", "jane_doe@example.com"]
6.3.3. "lang" property
The "lang" property MUST be supported with the intent of providing
the language(s) that may be used for contacting of the object the
jCard represents. Reference [RFC6350] Section 6.4.4.
Example:
["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]
["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]
["lang", {"type":"home"}, "language-tag", "fr"]
Wendt & Peterson Expires September 10, 2020 [Page 8]
Internet-Draft Call-Info Rich Call Data March 2020
6.4. Geographical Properties
These properties are concerned with information associated with
geographical positions or regions associated with the object the
jCard represents.
6.4.1. "tz" property
The "tz" property MUST be supported with the intent of providing the
time zone of the object the jCard represents. Reference [RFC6350]
Section 6.5.1.
Editor Note: recommendations of representing Time Zone don't seem to
be clear. TBD.
Example:
["tz", {}, "text", "Raleigh/North America"]
6.4.2. "geo" property
The "geo" property MUST be supported with the intent of providing the
global positioning of the object the jCard represents. Reference
[RFC6350] Section 6.5.2.
Example:
["geo", {}, "uri", "geo:37.386013,-122.082932"]
6.5. Organizational Properties
These properties are concerned with information associated with
characteristics of the organization or organizational units of the
object that the jCard represents.
6.5.1. "title" property
text
6.5.2. "role" property
text
6.5.3. "logo" property
text
Wendt & Peterson Expires September 10, 2020 [Page 9]
Internet-Draft Call-Info Rich Call Data March 2020
6.5.4. "org" property
text
6.5.5. "member" property
text
6.5.6. "related" property
text
6.6. Explanatory Properties
These properties are concerned with additional explanations, such as
that related to informational notes or revisions specific to the
jCard.
6.6.1. "catagories" property
ref 6.7.1
6.6.2. "note" property
ref 6.7.2
6.6.3. "sound" property
ref 6.7.5 (ringtone?)
6.6.4. "uid" property
ref 6.7.6 (origID like value?)
6.6.5. "url" property
ref 6.7.8
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.
Wendt & Peterson Expires September 10, 2020 [Page 10]
Internet-Draft Call-Info Rich Call Data March 2020
8. Acknowledgements
We would like to thank members of the STIR working group for helpful
suggestions and comments for the creation of this draft.
9. IANA Considerations
9.1. SIP Call-Info Header Field Purpose Token Request
[this RFC] defines the "jcard" token for use as a new token in the
Call-Info header in the "Header Field Parameters and Parameter
Values" registry defined by [RFC3968].
+--------------+----------------+-------------------+------------+
| Header Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+------------+
| Call-Info | jcard | No | [this RFC] |
+--------------+----------------+-------------------+------------+
9.2. SIP Call-Info Header Field Purpose Token Request
[this RFC] defines the "reason" generic parameter for use as a new
parameter in the Call-Info header in the "Header Field Parameters and
Parameter Values" registry defined by [RFC3968]. The parameter's
token is "reason" and it takes the value of a quoted string.
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.
11. References
11.1. Normative References
[I-D.ietf-stir-passport-rcd]
Peterson, J. and C. Wendt, "PASSporT Extension for Rich
Call Data", draft-ietf-stir-passport-rcd-05 (work in
progress), November 2019.
[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>.
Wendt & Peterson Expires September 10, 2020 [Page 11]
Internet-Draft Call-Info Rich Call Data March 2020
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, DOI 10.17487/RFC2426, September 1998,
<https://www.rfc-editor.org/info/rfc2426>.
[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>.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
<https://www.rfc-editor.org/info/rfc3324>.
[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>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013,
<https://www.rfc-editor.org/info/rfc6919>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[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>.
[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>.
Wendt & Peterson Expires September 10, 2020 [Page 12]
Internet-Draft Call-Info Rich Call Data March 2020
[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>.
11.2. Informative References
[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>.
[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>.
Authors' Addresses
Chris Wendt
Comcast
Comcast Technology Center
Philadelphia, PA 19103
USA
Email: chris-ietf@chriswendt.net
Jon Peterson
Neustar Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: jon.peterson@neustar.biz
Wendt & Peterson Expires September 10, 2020 [Page 13]