Realtime Transport Protocol RTP Recommendations for SIPREC drafteckelsiprecrtprec03

Goals for this sessions 1. Separate RTP roles of SRC within CS vs. RS

Independent Sessions RTP models for CS != those for RS CS = Existing session

RTP Model for SBC (CS) vs. SRC (RS) SBC might act as RTP forwarding

SRC Using Multiple m-lines CS CNAME -> RS CNAME SRS CS SSRCs -> RS

SRC Using SSRC Multiplexing CS CNAME -> RS CNAME SRS CS SSRCs -> RS

SRC Using Mixing CS CNAME -> RS CNAME SRS CS SSRCs -> RS CSRCs

Multiple CNAMEs per Participant What to do about it? 1. Include list of CNAMEs

Recommendations for UAs Most of the draft focuses on the SRC and SRS Loss

Next Steps draft-eckel-siprec-rtp-rec exists a standalone document This was done purposely to facilitate development

Slides: 10

Download presentation

Real-time Transport Protocol (RTP) Recommendations for SIPREC (draft-eckel-siprec-rtp-rec-03) Charles Eckel (eckelcu@cisco. com) IETF 83 SIPREC WG Meeting March 29, 2011

Goals for this sessions 1. Separate RTP roles of SRC within CS vs. RS 2. RTP session usage by SRC 3. Expand recommendations for UA 4. Discuss future of this draft IETF 82 SIPREC WG Meeting, Nov. 17, 2011 2

Independent Sessions RTP models for CS != those for RS CS = Existing session to be recorded RS = Session established with the recorder RTP models for CS != those for RS

RTP Model for SBC (CS) vs. SRC (RS) SBC might act as RTP forwarding or transcoding translator Yet SRC might act as RTP endpoint or mixer SRS RTP SRC UA-A RTP SBC RTP UA-B

SRC Using Multiple m-lines CS CNAME -> RS CNAME SRS CS SSRCs -> RS SSRCs SSRC aa SSRC ba SSRC av UA-A (CNAME-A) SSRC aa SSRC av SRC (CNAME-A, CNAME-B) SSRC bv SSRC ba SSRC bv UA-B (CNAME-B) If SRS does not support, it rejects some m-lines and SRC needs to choose another option.

SRC Using SSRC Multiplexing CS CNAME -> RS CNAME SRS CS SSRCs -> RS SSRCs SSRC aa SSRC ba SSRC av UA-A (CNAME-A) SSRC aa SSRC av SRC (CNAME-A, CNAME-B) SSRC bv SSRC ba SSRC bv UA-B (CNAME-B) If SRS does not support, SRC finds out through RTCP receiver reports and chooses another option

SRC Using Mixing CS CNAME -> RS CNAME SRS CS SSRCs -> RS CSRCs SSRC sa, CSRC aa, ba UA-A (CNAME-A) SSRC aa SSRC av SSRC sv, CSRC av, bv SRC (CNAME-S, CNAME-A, CNAME-B) SSRC ba SSRC bv If SRS does not support, it relies on metadata Does SRC need to know? UA-B (CNAME-B)

Multiple CNAMEs per Participant What to do about it? 1. Include list of CNAMEs in Participant metadata 2. Use SDP attribute to group them 3. Don’t allow it 4. Don’t worry about it 5. . IETF 82 SIPREC WG Meeting, Nov. 17, 2011 8

Recommendations for UAs Most of the draft focuses on the SRC and SRS Loss handling touches on UAs a bit We have the concept of a recording aware UA Should be add recommendations for recording aware UAs? IETF 82 SIPREC WG Meeting, Nov. 17, 2011 9

Next Steps draft-eckel-siprec-rtp-rec exists a standalone document This was done purposely to facilitate development and discussion of RTP related SIPREC functionality Plan of record is to incorporate into draft-ietf-siprecprotocol eventually Is now the appropriate time? Alternatively, do we adopt as its own working group draft? IETF 82 SIPREC WG Meeting, Nov. 17, 2011 10

Related presentations