]> Motorola Solutions

Dan.Mongrain@MotorolaSolutions.com

ART sipcore siprec errata SIP-based Media Recording (SIPREC) protocol is defined by both RFC 7865 and RFC 7866. Unfortunately, both RFCs contradict each other regarding how recording metadata is to be labeled. In addition, neither RFCs registered the new media type. This document updates RFC 7866 to align with RFC 7865 when labeling recording metadata and registers the new media type. Status information for this document may be found at . Discussion of this document takes place on the WG Working Group mailing list (), which is archived at . Subscribe at .

Introduction SIPREC is defined by and . The former specifies the use of 'application/rs-metadata+xml' when identifying metadata content, whereas the latter uses "application/rs-metadata". Since defines SIPREC metadata, it was identified as normative, and errata 7987 was created against to report the issue. This document resolves the errata. In addition, as neither document registered the media type with IANA, this document rectifies this gap.

Conventions and Definitions 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.

Updates to RFC 7866 Everywhere the following text occurs:

• application/rs-metadata

Replace with:

• application/rs-metadata+xml

Security Considerations The updates specified in this memo clarify inconsistencies in published documents with regards to identifying recording metadata. They do not introduce new security considerations beyond those listed in .

IANA Considerations

Media Type Registration defined a media type for use with specifying recording metadata in XML data. This media type is to be used when specifying recording metadata in SIPREC. Type name: application Subtype name: rs-metadata+xml Required parameters: N/A Optional parameters: N/A Encoding considerations: Same as encoding considerations of application/xml as specified in . Security considerations: See . Interoperability considerations: Please note that specified the use of "application/rs-metadata", which this document corrects. Published specification: [RFC-to-be] Applications which use this media type: SIPREC Clients (SRC) and Servers (SRS). Fragment identifier considerations: N/A Additional information:

• Deprecated alias names for this type: N/A

• Magic number(s): N/A

• File extension(s): N/A

• Macintosh file type code(s): N/A

Person & email address to contact for further information: IETF SIPCORE Working Group (sipcore@ietf.org) Intended usage: COMMON Restrictions on usage: There are no restrictions on where this media type can be used. Author: IETF SIPCORE Working Group (sipcore@ietf.org) Change controller: IETF

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format. This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document. 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. This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.

Acknowledgments Acknowledgments to Brian Rosen for his guidance with writing my first internet draft using the new tools and for his review.