SIPREC draft-ietf-siprec-req-00 Requirements for Media Recording using SIP Draft authors: K. Rehor, A. Hutton, L. Portman, R. Jain, H. Lum IETF 78 Ken Rehor on behalf of the team

Agenda Progress since ‘77 and Interim Meeting Open Issues and Public Comments Deferred to Version 2 Next Steps 2

Progress SIPREC Interim meeting reviewed the individual draft. draft-ietf-siprec-req-00 adopted by the working group – Closed most open issues. draft-ietf-siprec-req-01 to be published by Aug 15 – Close remaining open issues 3

Proposed Resolution Ticket #30, 32 REQ-017, -018, and -022 consolidated into new 17 and new 18 – REQ-017 The mechanism MUST provide the SRS with metadata describing CSs that are being recorded, including the media being used and the identities of parties involved. – REQ-018 The mechanism MUST provide the SRS with the means to correlate RS media with CS participant media described in metadata

Proposed Resolution REQ-023 SIP UA request a session is not recorded ==> clarified that the requirement is for support for requests prior to recording. Tracker #37 - REQ ==> removed 5

Proposed Resolution REQ-025, REQ-026 – recording lifecycle ==> reworded REQ-026 The mechanism MUST support the initiation of a Recording Session during a Communication Session. REQ-027 The mechanism SHOULD support means to avoid clipping media (leading or trailing samples) when the media is transported from the SRC to the SRS. Note : Media clipping can occur due to delays in recording session establishment. SRC implementations typically buffer some portion of the media to overcome this problem. 6

Proposed Resolution Ticket #19 – Relating single RS with multiple CS – Covered by REQ-033 Ticket #9 – Search and Retrieval – Out of scope Ticket #4 – media codec negotiation – Covered by standard SIP session netogiation Ticket #6 – Persistent Recording Use Cases – Related to guaranteed recording allocation, minimal media clipping Ticket #36- REQ-030 – recording session identification – Reworded: ‘this is a recording session, not just another type of SIP session’ 7

Open Item: Ticket #40 What’s the requirement for “Real-time” “What are the requirements for minimum and maximum delay in streaming media from SRC to SRS, in the context of Use Case 12.” 8

Metadata Transport Ticket #33 – REQ-019, REQ-020, REQ-021: metadata transport – Covered by Architecture Document 9

Outstanding Topics Failure modes and handling Security, Authentication, Privacy 10

Failover, Alarms, etc. REQ-008 The mechanism SHOULD support SRS failover and migration of Recording Sessions to a working SRS without disconnecting the Communication Sessions REQ-009 A request for a new Recording Session MUST be rejected by the SRS if service is unavailable (e.g. system overload, disk full, etc.) REQ-010 A request for a new Recording Session MUST be redirected to an available SRS. REQ-011 If no recording resources are available, appropriate error message MUST be returned. 11

Use Case 10: High Availability Covers situation where SRS fails – At call setup or during a call Does not ensure ‘no loss of recording’ situation – Continuation of recording on a different SRS Rename Use Case 10 to “Handling SRS Failure” Add new use case for “Handling SRC failure” – e.g. failover to secondary SRC Add new use case for ‘no loss of recording’ – e.g. redundant SRSs or redundant SRCs with SRSs 12

Security, Authentication Open tickets #35, 37: REQ-029 – security – “Confidentiality, Integrity, Authentication” REQ-031 – SIP security model – “eavesdropping protection, authorization and authentication." 13

Deferred to Version 2 SRS initiated recording Media transcoding, etc. Zero-media-loss failover 14

Next Steps Resolve any remaining Open Issues and Public Comments Publish final draft Aug

16 Discussion