1. IETF 78 Ken Rehor on behalf of the team
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

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

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

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

5. 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-028
==> removed

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

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

8. 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.”

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

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

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

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

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

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

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

16. Discussion