1 / 9

Jonathan Lennox jonathan@vidyo Magnus Westerlund magnus.westerlund@ericsson

RTP Considerations for Endpoints sending Multiple Media Streams draft -lennox-avtcore-rtp -multi-stream- 01 AVTCore , IETF 85, 5 November 2012. Jonathan Lennox jonathan@vidyo.com Magnus Westerlund magnus.westerlund@ericsson.com. RTP Multi-source: Motivation.

guang
Download Presentation

Jonathan Lennox jonathan@vidyo Magnus Westerlund magnus.westerlund@ericsson

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. RTP Considerations for Endpoints sending Multiple Media Streamsdraft-lennox-avtcore-rtp-multi-stream-01AVTCore, IETF 85, 5 November 2012 Jonathan Lennox jonathan@vidyo.com Magnus Westerlund magnus.westerlund@ericsson.com

  2. RTP Multi-source: Motivation • Clarify usage of RTP/RTCP with multiple sources per session • A number of use cases emerging where this is used • BUNDLE (or MMT) • CLUE • Multi-source Mixers

  3. Changes from previous version • Added explicit RTCP SDES item to describe RTCP reporting groups. • Added calculations motivating use of reporting groups. • Several additional open issues.

  4. Reporting Groups • A “Reporting Group” is a group of sources that all originate at the same interface of an endpoint, and so have the same view of an RTP session. • Within a reporting group, only one SSRC sends reception reports about any given remote source. • That source also sends any XR or AVPF feedback about that remote source. • No reception reports (or other feedback) are sent about sources within the same reporting group.

  5. Reporting Group: motivation • Semantic: sources are actually received by endpoints, not SSRCs, so gives better transparency about what’s going on. • E.g., if one endpoint with 50 streams receives you fine, but 10 others with one stream each doesn’t. • Efficiency: use much less of your RTCP bandwidth sending redundant reception reports, meaning useful data is more timely. • See draft for example numbers.

  6. Reporting group: details (1) • New RTCP SDES item: RGRP, same syntax as CNAME (RFC6222/bis). • All sources within a reporting group have the same RGRP. • Only one reporting source within a group sends feedback about any given remote source. • The same reporting source can be used for all remote sources, or different local ones can be used for different remote ones. • Using different remote sources could be useful when the number of reports exceed an MTU. • Other sources within the group send RTCP SR/RR packets without reception reports for that remote source.

  7. Reporting group: details (2) • For AVPF, a reporting source gets to use other group members’ immediate or early feedback slots. • The RGRP SDES item is included in any compound RTCP containing that source’s SR or RR. • Sources with the same RGRP need not have the same CNAME. • E.g. multiple synchronization contexts, or a source-projecting mixer. • Sources with the same CNAME need not have the same RGRP. • E.g., a distributed endpoint. • Open issue: how to signal/negotiate in SDP.

  8. Multi-source open issue: avg_rtcp_size • In RFC 3550, a source’s transmission interval is proportional to (session size) * avg_rtcp_size / rtcp_bw. • This calculation works if avg_rtcp_size measures compound RTCP packets sent by a single session member. • However, the draft recommends aggregating several sources’ RTCP into a single compound. • Also in 3550, and this is a good idea for bandwidth use. • Do we need to change how avg_rtcp_size and/or the transmission interval is calculated?

  9. Next steps • Address open issues • Does the WG want the multi-source clarifications for a WG item? • Does the group think RGRP semantics is a reasonable approach?

More Related