SIPREC draftietfsiprecreq00 Requirements for Media Recording using SIP

Agenda • • Progress since ‘ 77 and Interim Meeting Open Issues and Public

Progress • SIPREC Interim meeting reviewed the individual draft. • draft-ietf-siprec-req-00 adopted by the

Proposed Resolution • Ticket #30, 32 • REQ-017, -018, and -022 consolidated into new

Proposed Resolution • REQ-023 SIP UA request a session is not recorded http: //www.

Proposed Resolution • REQ-025, REQ-026 – recording lifecycle http: //www. ietf. org/mail-archive/web/siprec/current/msg 00449. html

Proposed Resolution • Ticket #19 – Relating single RS with multiple CS – Covered

Open Item: Ticket #40 • What’s the requirement for “Real-time” • “What are the

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

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

Failover, Alarms, etc. • REQ-008 The mechanism SHOULD support SRS failover and migration of

Use Case 10: High Availability • Covers situation where SRS fails – At call

Security, Authentication • Open tickets #35, 37: • REQ-029 – security http: //www. ietf.

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

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

Slides: 16

Download presentation

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

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. http: //www. ietf. org/mail-archive/web/siprec/current/msg 00475. html http: //www. ietf. org/mail-archive/web/siprec/current/msg 00458. html http: //www. ietf. org/mail-archive/web/siprec/current/msg 00462. html 4

Proposed Resolution • REQ-023 SIP UA request a session is not recorded http: //www. ietf. org/mail-archive/web/siprec/current/msg 00423. html ==> clarified that the requirement is for support for requests prior to recording. • Tracker #37 - REQ-028 http: //www. ietf. org/mail-archive/web/siprec/current/msg 00450. html ==> removed 5

Proposed Resolution • REQ-025, REQ-026 – recording lifecycle http: //www. ietf. org/mail-archive/web/siprec/current/msg 00449. html ==> 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 http: //www. ietf. org/mail-archive/web/siprec/current/msg 00452. html – 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 http: //www. ietf. org/mail-archive/web/siprec/current/msg 00451. html – “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 2010 15

Discussion 16