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-A B2BUA UA-B

RecorderRecorder

Session Recording Protocol

Call Call

• Middle-box as Recording Client• IP-PBX, MS, SBC, Mixer, Gateway

RC

RS

General Overview- Example 2

UA-A UA-B

RecorderRecorder

Session Recording Protocol

Call 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-CMedia Server

A/S Recorder (RS)

Recorder (RS)

Recorded media

MEDIACTRL

RTP

Session Recording Protocoland Call Metadata events

SIP SIP

RTP

logical or physicalB2BUA (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.