1 / 14

SIPREC Protocol (draft-ietf-siprec-protocol-06)

SIPREC Protocol (draft-ietf-siprec-protocol-06). August 3, 2012 IETF 84. Authors: L. Portman, H. Lum, A. Johnston, A. Hutton, C. Eckel. Changes since last meeting. Draft-ietf-siprec-protocol-04 Merged draft-eckel-siprec-rtp-rec-03 to Section 8 - RTP Handling Draft-ietf-siprec-protocol-05

elroy
Télécharger la présentation

SIPREC Protocol (draft-ietf-siprec-protocol-06)

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. SIPRECProtocol(draft-ietf-siprec-protocol-06) August 3, 2012 IETF 84 Authors: L. Portman, H. Lum, A. Johnston, A. Hutton, C. Eckel

  2. Changes since last meeting • Draft-ietf-siprec-protocol-04 • Merged draft-eckel-siprec-rtp-rec-03 to Section 8 - RTP Handling • Draft-ietf-siprec-protocol-05 • Editorial changes • Draft-ietf-siprec-protocol-06 • Changes in RTP section

  3. Changes since last meeting (1) • Many editorial changes • Improved introduction and overview of operations

  4. Changes since last meeting (2) • Strengthen statements on metadata usage • The SRC MUST deliver metadata to the SRS in a recording session • Metadata SHOULD be provided by the SRC in the initial INVITE request

  5. Changes since last meeting (3) • Clarifications on recording preference • The recording preference attribute is a declaration by the recording-aware UA of its recording preference. • The SRC is not obligated to honor a recording preference provided by a UA, as it is merely an indication of a preference, not a direct command or request to start or stop recording.

  6. Changes since last meeting (4) • Recording-aware UA MUST (previously SHOULD) indicate recording awareness and include option tag “record-aware” the initial INVITE request or response

  7. Todo (1) • Re-allocate text in section 11 with re-organized headings • SIP Handling • Procedures at SRC, SRS, record-aware UA • SDP Handling • Procedures at SRC, SRS, record-aware UA • RTP/RTCP Handling • Metadata

  8. Todo (2) • Can we interpret +sip.src feature tag in a CS that the user agent will act as the role of an SRC?

  9. Todo (3) • Tighten up security section • Require SRC and SRS to mutually authenticate each other in the same administrative domain? • Should we specify SRTP keying mechanism(s)? If so, which ones?

  10. Changes to RTP Recommendations • draft-ietf-siprec-protocol-04 • Incorporated draft-eckel-siprec-rtp-rec-03 into section 7 • draft-ietf-siprec-protocol-05 • Editorial changes • draft-ietf-siprec-protocol-06 • Expand recommendations for UA • Separate RTP roles of SRC within CS vs. RS • RTP session usage by SRC IETF 84 SIPREC WG Meeting, Aug. 2, 2012

  11. SRC Using Multiple m-lines SRS • CS CNAME -> RS CNAME • CS SSRCs -> RS SSRCs SSRC Aa SSRC Av SSRC Ba SSRC Bv UA-A (CNAME-A) SRC (CNAME-A, CNAME-B) UA-B (CNAME-B) SSRC Ba SSRC Aa SSRC Bv SSRC Av • If SRS does not support, it rejects one or more m-lines, and SRC might choose another option.

  12. SRC Using SSRC Multiplexing SRS • CS CNAME -> RS CNAME • CS SSRCs -> RS SSRCs SSRC SAa SSRC SBa SSRC Sav SSRC SBv UA-A (CNAME-A) SRC (CNAME-S) UA-B (CNAME-B) SSRC Ba SSRC Aa SSRC Bv SSRC Av • If SRS does not support, SRC finds out through RTCP receiver reports and might choose another option • SRC may need to rewrite SSRCs to avoid collisions • SRS relies on metadata as CNAME is not preserved

  13. SRC Using Mixing SRS • CS CNAME -> RS CNAME • CS SSRCs -> RS CSRCs SSRC Sa, CSRC Aa,Ba SSRC Sv, CSRC Av,Bv UA-A (CNAME-A) SRC (CNAME-S, CNAME-A, CNAME-B) UA-B (CNAME-B) SSRC Ba SSRC Aa SSRC Bv SSRC Av • If SRS does not support CSRC, it relies on metadata

  14. TODO • RTP Session Usage • Should any specific RTP session usage be recommended or prohibited? • SSRC Multiplexing is the most problematic • What happens if UA is sending mixed stream already to SRC? • SRTP/Keying Mechanism • Recommend EKT as suggested by Richard and presented by Dan in RTCWEB at IETF 83? • Correlation between metadata and RTP? • CNAME/SDES/SSRC/CSRC may/may not be used by UAs

More Related