1 / 16

SIPREC draft-ietf-siprec-req-00 Requirements for Media Recording using SIP

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

sumi
Download Presentation

SIPREC draft-ietf-siprec-req-00 Requirements for Media Recording using SIP

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. SIPRECdraft-ietf-siprec-req-00Requirements 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. http://www.ietf.org/mail-archive/web/siprec/current/msg00475.html http://www.ietf.org/mail-archive/web/siprec/current/msg00458.html http://www.ietf.org/mail-archive/web/siprec/current/msg00462.html

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

  6. Proposed Resolution • REQ-025, REQ-026  – recording lifecyclehttp://www.ietf.org/mail-archive/web/siprec/current/msg00449.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.

  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 identificationhttp://www.ietf.org/mail-archive/web/siprec/current/msg00452.html • 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 – securityhttp://www.ietf.org/mail-archive/web/siprec/current/msg00451.html • “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

More Related