draft-ietf-avtcore-rtp-multi-stream-optimisation-09.txt | draft-ietf-avtcore-rtp-multi-stream-optimisation-10.txt | |||
---|---|---|---|---|
AVTCORE WG J. Lennox | AVTCORE WG J. Lennox | |||
Internet-Draft Vidyo | Internet-Draft Vidyo | |||
Intended status: Standards Track M. Westerlund | Intended status: Standards Track M. Westerlund | |||
Expires: May 27, 2016 Ericsson | Expires: June 13, 2016 Ericsson | |||
Q. Wu | Q. Wu | |||
Huawei | Huawei | |||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
November 24, 2015 | December 11, 2015 | |||
Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP | Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP | |||
Reception Statistics and Other Feedback | Reception Statistics and Other Feedback | |||
draft-ietf-avtcore-rtp-multi-stream-optimisation-09 | draft-ietf-avtcore-rtp-multi-stream-optimisation-10 | |||
Abstract | Abstract | |||
RTP allows multiple media streams to be sent in a single session, but | RTP allows multiple RTP streams to be sent in a single session, but | |||
requires each Synchronisation Source (SSRC) to send RTCP reception | requires each Synchronisation Source (SSRC) to send RTCP reception | |||
quality reports for every other SSRC visible in the session. This | quality reports for every other SSRC visible in the session. This | |||
causes the number of RTCP reception reports to grow with the number | causes the number of RTCP reception reports to grow with the number | |||
of SSRCs, rather than the number of endpoints. In many cases most of | of SSRCs, rather than the number of endpoints. In many cases most of | |||
these RTCP reception reports are unnecessary, since all SSRCs of an | these RTCP reception reports are unnecessary, since all SSRCs of an | |||
endpoint are co-located and see the same reception quality. This | endpoint are normally co-located and see the same reception quality. | |||
memo defines a Reporting Group extension to RTCP to reduce the | This memo defines a Reporting Group extension to RTCP to reduce the | |||
reporting overhead in such scenarios. | reporting overhead in such scenarios. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 27, 2016. | This Internet-Draft will expire on June 13, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 48 ¶ | skipping to change at page 2, line 48 ¶ | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 16 | 7.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for | The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for | |||
group communication, supporting multiparty multimedia sessions. A | group communication, supporting multiparty multimedia sessions. A | |||
single RTP session can support multiple participants sending at once, | single RTP session can support multiple participants sending at once, | |||
and can also support participants sending multiple simultaneous media | and can also support participants sending multiple simultaneous RTP | |||
streams. Examples of the latter might include a participant with | streams. Examples of the latter might include a participant with | |||
multiple cameras who chooses to send multiple views of a scene, or a | multiple cameras who chooses to send multiple views of a scene, or a | |||
participant that sends audio and video flows multiplexed in a single | participant that sends audio and video flows multiplexed in a single | |||
RTP session. Rules for handling RTP sessions containing multiple | RTP session. Rules for handling RTP sessions containing multiple RTP | |||
media streams are described in [RFC3550] with some clarifications in | streams are described in [RFC3550] with some clarifications in | |||
[I-D.ietf-avtcore-rtp-multi-stream]. | [I-D.ietf-avtcore-rtp-multi-stream]. | |||
An RTP endpoint will have one or more synchronisation sources (SSRCs) | An RTP endpoint will have one or more synchronisation sources | |||
that send media streams. It will have at least one SSRC for each | (SSRCs). It will have at least one RTP Stream, and thus SSRC, for | |||
media stream it sends, and might use multiple SSRCs when using media | each media source it sends, and might use multiple SSRCs per media | |||
scalability features [RFC6190], forward error correction, RTP | source when using media scalability features [RFC6190], forward error | |||
retransmission [RFC4588], or similar mechanisms. An endpoint that is | correction, RTP retransmission [RFC4588], or similar mechanisms. An | |||
not sending any media streams, will have at least one SSRC to use for | endpoint that is not sending any RTP stream, will have at least one | |||
reporting and any feedback messages. Each SSRC has to send RTCP | SSRC to use for reporting and any feedback messages. Each SSRC has | |||
sender reports corresponding to the RTP packets it sends, and | to send RTCP sender reports corresponding to the RTP packets it | |||
receiver reports for traffic it receives. That is, every SSRC will | sends, and receiver reports for traffic it receives. That is, every | |||
send RTCP packets to report on every other SSRC. This rule is | SSRC will send RTCP packets to report on every other SSRC. This rule | |||
simple, but can be quite inefficient for endpoints that send large | is simple, but can be quite inefficient for endpoints that send large | |||
numbers of media streams in a single RTP session. Consider a session | numbers of RTP streams in a single RTP session. Consider a session | |||
comprising ten participants, each sending three media streams with | comprising ten participants, each sending three media sources, each | |||
their own SSRC. There will be 30 SSRCs in such an RTP session, and | with their own RTP stream. There will be 30 SSRCs in such an RTP | |||
each of those 30 SSRCs will send an RTCP Sender Report/Receiver | session, and each of those 30 SSRCs will send an RTCP Sender Report/ | |||
Report packet (containing several report blocks) per reporting | Receiver Report packet (containing several report blocks) per | |||
interval as each SSRC reports on all the others. However, the three | reporting interval as each SSRC reports on all the others. However, | |||
SSRCs comprising each participant will almost certainly see identical | the three SSRCs comprising each participant are commonly co-located | |||
reception quality, since they are co-located. If there was a way to | such that they see identical reception quality. If there was a way | |||
indicate that several SSRCs are co-located, and see the same | to indicate that several SSRCs are co-located, and see the same | |||
reception quality, then two-thirds of those RTCP reports could be | reception quality, then two-thirds of those RTCP reports could be | |||
suppressed. This would allow the remaining RTCP reports to be sent | suppressed. This would allow the remaining RTCP reports to be sent | |||
more often, while keeping within the same RTCP bandwidth fraction. | more often, while keeping within the same RTCP bandwidth fraction. | |||
This memo defines such an RTCP extension, RTCP Reporting Groups. | This memo defines such an RTCP extension, RTCP Reporting Groups. | |||
This extension is used to indicate the SSRCs that originate from the | This extension is used to indicate the SSRCs that originate from the | |||
same endpoint, and therefore have identical reception quality, hence | same endpoint, and therefore have identical reception quality, hence | |||
allowing the endpoints to suppress unnecessary RTCP reception quality | allowing the endpoints to suppress unnecessary RTCP reception quality | |||
reports. | reports. | |||
skipping to change at page 15, line 26 ¶ | skipping to change at page 15, line 26 ¶ | |||
The definition of the "a=rtcp-rgrp" SDES attribute is given in | The definition of the "a=rtcp-rgrp" SDES attribute is given in | |||
Section 3.6 of this memo. | Section 3.6 of this memo. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[I-D.ietf-avtcore-rtp-multi-stream] | [I-D.ietf-avtcore-rtp-multi-stream] | |||
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, | Lennox, J., Westerlund, M., Wu, W., and C. Perkins, | |||
"Sending Multiple Media Streams in a Single RTP Session", | "Sending Multiple Media Streams in a Single RTP Session", | |||
draft-ietf-avtcore-rtp-multi-stream-09 (work in progress), | draft-ietf-avtcore-rtp-multi-stream-10 (work in progress), | |||
September 2015. | November 2015. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | |||
with Session Description Protocol (SDP)", RFC 3264, | with Session Description Protocol (SDP)", RFC 3264, | |||
DOI 10.17487/RFC3264, June 2002, | DOI 10.17487/RFC3264, June 2002, | |||
<http://www.rfc-editor.org/info/rfc3264>. | <http://www.rfc-editor.org/info/rfc3264>. | |||
skipping to change at page 17, line 35 ¶ | skipping to change at page 17, line 35 ¶ | |||
Phone: +46 10 714 82 87 | Phone: +46 10 714 82 87 | |||
Email: magnus.westerlund@ericsson.com | Email: magnus.westerlund@ericsson.com | |||
Qin Wu | Qin Wu | |||
Huawei | Huawei | |||
101 Software Avenue, Yuhua District | 101 Software Avenue, Yuhua District | |||
Nanjing, Jiangsu 210012 | Nanjing, Jiangsu 210012 | |||
China | China | |||
Email: sunseawq@huawei.com | Email: bill.wu@huawei.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
United Kingdom | United Kingdom | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
End of changes. 12 change blocks. | ||||
34 lines changed or deleted | 34 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |