Session Recording Protocol Requirements IETF 75, Stockholm (Leon Portman on behalf of the team)

Requirements Draft Authors R. Jain, IPC Systems L. Portman, NICE Systems V. Gurbani, Bell Laboratories, Alcatel-Lucent H. Kaplan, Acme Packet A. Hutton, Siemens Enterprise Communications K. Rehor, Cisco Systems Other contributors to this presentation A. Johnston, Avaya D. Wing, Cisco Systems

Main use cases for recording Trading floor compliance Contact Center quality management Customer analytics Financial institution transactions Insurance and healthcare regulations Emergency services regulations In many cases it’s not a legal requirement, it’s a user requirement – users wanting to protect themselves (i.e., non-repudiation)

Reasons for Standardization Lack of well defined and standard protocol for the recording currently limits or even blocks adoption of IP telephony in the enterprises There is a strong demand from customers and communications systems vendors for such protocol Transforming multiple implementations of proprietary protocols to non-proprietary standard

Main Definitions Recording Server (RS): A Recording Server (RS) is a specialized media server or collector that acts as the sink of the recorded media and metadata events Recording Client (RC): A Recording Client (RC) is a SIP User Agent (UA), SIP Media Server or a Back-to-Back User Agent (B2BUA) that acts as the source of the recorded media and metadata events, sending it to the RS.

Requirements Overview Support for recording control both from RC to RS and from RS to RC Loss-less delivery of the media from RC to RS Support for RS and RC failures Security Mixed and separated recordings Pause and resume of the recordings Support for Session Metadata events Correlation between media and SIP sessions Silent and visible recording

General Overview- Example 1 UA-AB2BUAUA-B Recorder Session Recording Protocol Call Middle-box as Recording Client IP-PBX, MS, SBC, Mixer, Gateway RC RS

General Overview- Example 2 UA-AUA-B Recorder Session Recording Protocol Call End Point as Recording Client RC RS...

Required SRP interfaces Recording Control (RC-> RS or RS->RC) Recorded Media (RC->RS) Call Metadata (RC->RS) (not covered yet)

Why use SIP for SRP? Recording session (SRP) is a media session Call Control functionality: JOIN, REFER SIP Events framework already available Reuse of existing mechanisms: – Codec and transport negotiation – Security mechanisms – Firewall traversal

Scope UA-B UA-C Media Server A/S Recorder (RS) Recorded media MEDIACTRL RTP Session Recording Protocol and Call Metadata events SIP RTP logical or physical B2BUA (the RC)

Other approaches MEDIACTRL and XCON focus on how actually to implement RC and not on the interface between RS and RC Lacks support for integrated signaling and media B2BUA, nor UA/Endpoint acting as RC Does not address all requirements – Recording transparency – Persistent mode – RS invoking recording (instead of RC invoking it)

SRTP Support – current plan If RC has cleartext RTP, it can negotiate/use SRTP for the SRP interface – SRP is an independent RTP/SRTP layer connection If RC only has encrypted SRTP, it can send them as raw “media” payload to RS, to be recorded – Providing any keys to decrypt it is out-of-scope of this work – SRP media layer would not be “RTP” or “SRTP” – it’s a new “raw” or “mirrored” media-layer

Next Steps Is there interest in this? Dispatch to charter a new WG? This document as the starting-point for a charter?

Security Considerations Authentication, authorization, eavesdropping protection, and non-repudiation The RC needs to know the RS it is communicating with is legitimate, and vice- versa, even if they are in different domains. Both the signaling and media for the SRP needs the ability to be authenticated and protected from eavesdropping and non- repudiation.