1 / 15

Session Recording Protocol Requirements

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

zachery-houston
Download Presentation

Session Recording Protocol Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related