]> Somos Inc.

US chris@appliedbits.com

Neustar Inc.

1800 Sutter St Suite 570 Concord, CA 94520 US jon.peterson@neustar.biz

art Identity This document describes a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the calling party in order to provide to the called party a description of the caller or details about the reason for the call. RCD includes information about the caller beyond the telephone number such as a calling name, or a logo, photo, or jCard object representing the caller, which can help the called party decide whether to answer the phone. The elements defined for this purpose are intended to be extensible in order to accommodate related information about calls and to be compatible and complimentary with the STIR/PASSporT RCD framework. This document defines a new parameter ('call-reason') for the SIP Call-Info header field and also a new token ("rcd-jcard") for the 'purpose' parameter of the Call-Info header field. It also provides guidance on the use of the Call-Info 'purpose' parameter token, "icon".

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 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 and also a new token ("rcd-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. 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 for SIP and specifically through the use of RCD or the "rcd" PASSporT defined in . Alternatively, this specification can be utilized in conjunction with the protocols defined in 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. provides a means of carrying additional data about callers for the purposes of emergency services (especially Section Owner/Subscriber Information of ). 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 . This document borrows from the capability to carry a data structure as a body, through the use of the "cid" URI scheme .

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 when, and only when, they appear in all capitals, as shown here.

Overview In this document, we provide a framework for the use of Call-Info header field to carry RCD in SIP . The Call-Info header field (defined in ) 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, "rcd-jcard", and a new generic parameter, 'call-reason', for the Call-Info header field to align with RCD as defined in the STIR framework and with "rcd" PASSporTs defined in . The 'purpose' parameter token "rcd-jcard" is used to associate RCD related to the identity of the calling party in the form of a jCard . While there is a "card" token defined in which could be considered to have an overlapping purpose, the "rcd-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 and has been adopted by PASSporT because of the usage of JSON Web Tokens (JWT) . 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.

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 . Typically, a SIP-based call involves multiple hops through different trusted and untrusted networks. The STIR framework addresses the protection of the carriage of call information and identities over untrusted networks, which wasn't addressed in the core SIP specifications. 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 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 . 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 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. With the use of the Call-Info header field for the transmission of RCD, any RCD-related information defined in this specification or future specifications that extend this mechanism MUST be contained in a single Call-Info header field containing all URI and 'purpose' tokens and parameters related to 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 , the calling name uses the display-name value of the From header field of the request. Alternatively, for some calls, the calling name may come from the P-Asserted-ID header field . This is out of scope for Call-Info header field, so will not be covered in this document further. For logos or icons that can represent the calling party, the 'purpose' token "icon" 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 specifies a "card" 'purpose' token, the intent of defining a new "rcd-jcard" 'purpose' token is to use the JSON jCard format 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.

"rcd-jcard" Call-Info 'purpose' Token The Call-Info 'purpose' token "rcd-jcard" indicates support of RCD associated with the identity of a calling party in a SIP call . The format of a Call-Info header field when using the "rcd-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 . The media type for the JSON text MUST be set as application/json with a default encoding of UTF-8 . 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 . 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 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 "rcd-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:

;purpose=rcd-jcard ]]>

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

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

From: Bob ;tag=1928301774> Call-ID: a84b4c76e66710 Call-Info: ;purpose=rcd-jcard;call-reason="Rendezvous for Little Nellie" CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2015 19:12:25 GMT Contact: 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:

From: Bob ;tag=1928301774> Call-ID: a84b4c76e66710 Call-Info: ;purpose=rcd-jcard; call-reason="Rendezvous for Little Nellie" CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2015 19:12:25 GMT Contact: 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"]]] ]]>

'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 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:

;purpose=rcd-jcard; call-reason="For your ears only" ]]>

In the case that there is only a 'call-reason' 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 "rcd-jcard" defined in this document to avoid any conflicts with existing implementations and previously defined purpose parameters. As an example:

;purpose=rcd-jcard; call-reason="For your ears only" ]]>

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 . The following example of a Call-Info header field shows the use of multiple 'purpose' parameters to indicate a jCard and an icon and also a 'call-reason' parameter:

;purpose=rcd-jcard, ;purpose=icon; call-reason="For your ears only" ]]>

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

Usage of URIs in jCard When one or more URIs are used in a jCard, it is important to note that any URI-referenced data, with the exception of the top-level usage of "jcl" as a URI to the jCard itself (unless updated by any future extensions of this specification) MUST NOT contain any URI references. In other words, 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, and therefore MUST be enforced by the client to not follow those URI references or not render that content to the user if any URI are present in that specific URI linked content. The purpose of this is to control the security and more specifically to align with the content-integrity mechanism defined in . The authors do not believe there is a scenario for which deeper URI references would be required or even supported by the typical use of current jCard properties. However, because jCard is extensible, this rule is set to restrict further extension without the proper consideration of security and integrity properties of both Call-Info usage as well as the RCD and STIR signing of the data .

Usage of Multimedia Data in jCard or with Icon For the use of the 'purpose' token "icon" or for the cases where the jCard either incorporates URIs or includes digital images and sounds directly via Base64 encoding, we provide recommendations to facilitate the successful decoding and rendering of these images and media formats. For images, such as for the "photo" and "logo" properties, the default image formats SHOULD be PNG or JPEG , as these files are commonly used to support 24-bit RGB images. Supporting older telephone devices that only support bitmap (BMP) images with a lower bit range (e.g., 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 because, at the time of writing, they are becoming increasingly rare (i.e., typically, devices either have color or color-aware graphical displays that support PNG or JPEG formats or they are exclusively textual displays). In addition, vector images are increasingly popular to use for icons because they support scalable images without having to send multiple resolutions. The SVG format has gained wide support as of this writing as a common format for vector images. At a minimum, the SVG Tiny 1.2 specification SHOULD be supported as an additional default format for devices. For the 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, that signals the height and width of the image to the end device for the convenience of determining the appropriate resolution to retrieve without the need to retrieve all the image files. It is also recommended that images have a square aspect ratio with equal height and width and with 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 is appropriate and useful to include multiple versions of images or sounds so that endpoints that cannot support all formats or resolutions can select the format they do support. The convention that is RECOMMENDED is that files that refer to the same content should 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 (e.g., filename.png, filename.svg, or filename.jpg) or (e.g., filename-32x32.png, filename-64x64.png, filename.svg, filename-32x32.jpg, or filename-64x64.jpg). Because this is a complex and often debated topic that has evolved over the many years of advances in image coding and display technologies, we suggest relying on either future specifications or industry forum specifications that might correspond to supporting particular classes of devices to further define how URIs can reference appropriate image formats and files. For audio files, the recommendation is to provide mp3, m4a or mp4, or wav files , although the usage of sound (for example, a special ring tone for a particular caller) is not well defined in this specification. Future documents should consider both usage and potential security risks of playing sounds that are not specifically authorized by a device user.

Cardinality Property cardinalities are indicated, for convenience, using the following notation and follow the guidance of jCard and vCard , which is based on ABNF (see ):

Identification Properties The following properties, initially defined in , hold the identity information of the entity associated with the jCard. This subset of properties selected for this document are relevant to telephone and messaging applications. jCard is an extensible object; therefore, there may be future specifications that extend the set of properties relevant to the applications that implement this specification.

"fn" Property The "fn" property provides a formatted text corresponding to the name of the object the jCard represents. Reference: . Value type: A single text value. Cardinality: 1*

"n" Property The "n" property provides the components of the name of the object the jCard represents. Reference: . Value type: A single structured text value. Each component can have multiple values. Cardinality: *1

"nickname" Property The "nickname" property provides the text corresponding to the nickname of the object the jCard represents. Reference: . Value type: One or more text values separated by a COMMA character (U+002C). Cardinality: *

"photo" Property The "photo" property provides image or photograph information that annotates some aspect of the object the jCard represents. Reference: . 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: *

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

"adr" Property The "adr" property provides the delivery address of the object the jCard represents. Reference: . Value type: A single structured text value separated by the SEMICOLON character (U+003B). Cardinality: *

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

"tel" Property The "tel" property provides the telephone number for the object the jCard represents. Reference: . 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 potential instances of the "tel" property should not be considered part of the authentication or verification part of STIR or required to match the "orig" claim in the PASSporT . 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 versus 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 , but other schemes MAY be used. Cardinality: *

"email" Property The "email" property provides the electronic mail address of the object the jCard represents. Reference: . Value type: A single text value. Cardinality: *

"lang" Property The "lang" property provides the language(s) that may be used for communicating with the object the jCard represents. Reference: . Value type: A single language-tag value. Cardinality: *

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

"tz" Property The "tz" property provides the time zone of the object the jCard represents. Reference: . 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: *

"geo" Property The "geo" property provides the global positioning of the object the jCard represents. Reference: . Value type: A single URI. Cardinality: *

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

"title" Property The "title" property has the intent of providing the position or job of the object the jCard represents. Reference . Value type: A single text value. Cardinality: *

"role" Property The "role" property has the intent of providing the position or job of the object the jCard represents. Reference . Value type: A single text value. Cardinality: *

"logo" Property The "logo" property has the intent of specifying a graphic image of a logo associated with the object the jCard represents. Reference . Value type: A single URI. Cardinality: *

"] ]]>

"org" Property The "org" property has the intent of specifying the organizational name and units of the object the jCard represents. Reference . Value type: A single structured text value consisting of components separated by the SEMICOLON character (U+003B). Cardinality: *

Explanatory Properties These properties provide additional information such as notes or revisions specific to the jCard.

"categories" Property The "categories" property specifies application category information about the object the jCard represents. Reference: . Value type: One or more text values separated by a COMMA character (U+002C). Cardinality: *

"note" Property The "note" property specifies supplemental information or a comment about the object the jCard represents. Reference: . Value type: A single text value. Cardinality: *

"sound" Property The "sound" property specifies digital sound content information that annotates some aspect of the object the jCard represents. This property is often used to specify the proper pronunciation of the name property value of the jCard. Reference: . Value type: A single URI. Cardinality: *

"] ]]>

"uid" Property The "uid" property specifies a globally unique identifier corresponding to the object the jCard represents. Reference: . Value type: A single URI value. It MAY also be reset to free-form text. Cardinality: *1

"url" Property The "url" property specifies a uniform resource locator associated with the object the jCard represents. Reference: . There are potential security and privacy implications of providing URLs with telephone calls. The end client receiving a jCard with a "url" property MUST only display the URL and not automatically follow the URL or provide automatic preview of the URL, and generally provide good practices in making it clear to the user it is their choice 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: *

"version" Property The "version" property MUST be included and is intended to specify the version of the vCard specification used to format this vCard. Reference: . Value type: A single text value. Cardinality: 1

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 or new specifications.

IANA Considerations

SIP Call-Info Header Field 'purpose' Parameter Token This document defines the token "rcd-jcard" as a new value for the 'purpose' parameter of the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by .

SIP Call-Info Header Field 'call-reason' Parameter This document defines the 'call-reason' 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 . The parameter's token is "call-reason", and it takes the value of a quoted string.

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

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK] This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK] This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK] This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics. The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Somos Inc. Neustar Inc. This document extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network and is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases. W3C ITU-T ISO/IEC In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.

Acknowledgements We would like to thank David Hancock, Alec Fenichel, and other members of the SIPCORE and STIR working groups for their helpful suggestions and comments during the creation of this document.