1 Session Recording Protocol Requirements IETF 75, Stockholm (Leon Portman on behalf of the team) Draft authors: Rajnish Jain, Leon Portman, Vijay Gurbani, Hadriel Kaplan, Andrew Hutton, Kenneth Rehor Other presentation contributors: Dan Wing, Alan Johnston, Eric Burger

2 Some 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)

3 Reasons for Standardization Lack of standard protocol for recording currently limits adoption of IP telephony in the enterprises There are many existing proprietary, non- interoperable protocols Migrating multiple implementations of proprietary protocols to an interoperable standard

4 General Overview- Example 1 UA-AB2BUAUA-B Recorder Session Recording Protocol Call Middle-box B2BUA as Recording Client (RC) Examples: IP-PBX, Media Server, SBC, Mixer RC RS

5 General Overview- Example 2 UA-AUA-B Recorder Session Recording Protocol Call UA as Recording Client Examples: phones, softclients, gateways RC RS

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

7 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

8 Alternatives MEDIACTRL – Orthogonal to session recording – May be useful for recorder (media server) control XCON – Orthogonal to session recording – UA participants may not be aware, and do not target, a conference server SRP has some unique requirements – Call-event and user-status notifications – Recording transparency – Persistent vs. dynamic mode – Either RS or RC invoking recording

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

10 SRTP Support – Proposal Decrypting encrypted streams has policy, privacy, legal, business, and security issues – Out of scope of IETF Plan is to simply record “media” – Decryption of SRTP/whatever at the client or B2BUA is a local matter – Some applications desire the media to remain encrypted – SRP can be an independent RTP/SRTP layer connection – SRP media layer may not be “RTP” or “SRTP” – could be a new “raw” or “mirrored” media-layer of opaque, encrypted content

11 Other Topics Playback support: out of scope – Playback of streams has policy, privacy, legal, business, and security issues Using IPFIX: not applicable, and very different semantics Support for other session protocols (H.323, H.248, etc.): out of scope

12 Discussion

13 Requirements Overview (only some listed here – see the draft) 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

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