draft-ietf-avtcore-rtp-multi-stream-optimisation-06.txt | draft-ietf-avtcore-rtp-multi-stream-optimisation-07.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: January 7, 2016 Ericsson | Expires: April 2, 2016 Ericsson | |||
Q. Wu | Q. Wu | |||
Huawei | Huawei | |||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
July 6, 2015 | September 30, 2015 | |||
Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP | Sending Multiple Media 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-06 | draft-ietf-avtcore-rtp-multi-stream-optimisation-07 | |||
Abstract | Abstract | |||
RTP allows multiple media streams to be sent in a single session, but | RTP allows multiple media 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 co-located and see the same reception quality. This | |||
skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
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 January 7, 2016. | This Internet-Draft will expire on April 2, 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 3, line 21 ¶ | skipping to change at page 3, line 21 ¶ | |||
retransmission [RFC4588], or similar mechanisms. An endpoint that is | retransmission [RFC4588], or similar mechanisms. An endpoint that is | |||
not sending any media streams, will have at least one SSRC to use for | not sending any media streams, will have at least one SSRC to use for | |||
reporting and any feedback messages. Each SSRC has to send RTCP | reporting and any feedback messages. Each SSRC has to send RTCP | |||
sender reports corresponding to the RTP packets it sends, and | sender reports corresponding to the RTP packets it sends, and | |||
receiver reports for traffic it receives. That is, every SSRC will | receiver reports for traffic it receives. That is, every SSRC will | |||
send RTCP packets to report on every other SSRC. This rule is | send RTCP packets to report on every other SSRC. This rule is | |||
simple, but can be quite inefficient for endpoints that send large | 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 media 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 streams with | |||
their own SSRC. There will be 30 SSRCs in such an RTP session, and | their own SSRC. There will be 30 SSRCs in such an RTP session, and | |||
30 RTCP reception reports will be sent per reporting interval as each | each of those 30 SSRCs will send an RTCP Sender Report/Receiver | |||
SSRC reports on all the others. However, the three SSRCs comprising | Report packet (containing several report blocks) per reporting | |||
each participant will almost certainly see identical reception | interval as each SSRC reports on all the others. However, the three | |||
quality, since they are co-located. If there was a way to indicate | SSRCs comprising each participant will almost certainly see identical | |||
that several SSRCs are co-located, and see the same reception | reception quality, since they are co-located. If there was a way to | |||
quality, then two-thirds of those RTCP reports could be suppressed. | indicate that several SSRCs are co-located, and see the same | |||
This would allow the remaining RTCP reports to be sent more often, | reception quality, then two-thirds of those RTCP reports could be | |||
while keeping within the same RTCP bandwidth fraction. | suppressed. This would allow the remaining RTCP reports to be sent | |||
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. | |||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
skipping to change at page 5, line 52 ¶ | skipping to change at page 6, line 6 ¶ | |||
include an RTCP SDES packet containing an RGRP item in every compound | include an RTCP SDES packet containing an RGRP item in every compound | |||
RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP | RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP | |||
packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). | packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). | |||
Syntactically, the format of the RTCP SDES RGRP item is identical to | Syntactically, the format of the RTCP SDES RGRP item is identical to | |||
that of the RTCP SDES CNAME item [RFC7022], except that the SDES item | that of the RTCP SDES CNAME item [RFC7022], except that the SDES item | |||
type field MUST have value RGRP=(TBA) instead of CNAME=1. The value | type field MUST have value RGRP=(TBA) instead of CNAME=1. The value | |||
of the RTCP SDES RGRP item MUST be chosen with the same concerns | of the RTCP SDES RGRP item MUST be chosen with the same concerns | |||
about global uniqueness and the same privacy considerations as the | about global uniqueness and the same privacy considerations as the | |||
RTCP SDES CNAME. The value of the RTCP SDES RGRP item MUST be stable | RTCP SDES CNAME. The value of the RTCP SDES RGRP item MUST be stable | |||
throughout the lifetime of the reporting group, even if the some or | throughout the lifetime of the reporting group, even if some or all | |||
all of the reporting sources change their SSRC due to collisions, or | of the reporting sources change their SSRC due to collisions, or if | |||
if the set of reporting sources changes. | the set of reporting sources changes. | |||
Note to RFC Editor: please replace (TBA) in the above paragraph | Note to RFC Editor: please replace (TBA) in the above paragraph | |||
with the RTCP SDES item type number assigned to the RGRP item, | with the RTCP SDES item type number assigned to the RGRP item, | |||
then delete this note. | then delete this note. | |||
An RTP mixer or translator that forwards RTCP SR or RR packets from | An RTP mixer or translator that forwards RTCP SR or RR packets from | |||
members of a reporting group MUST forward the corresponding RTCP SDES | members of a reporting group MUST forward the corresponding RTCP SDES | |||
RGRP items as well, even if it otherwise strips SDES items other than | RGRP items as well, even if it otherwise strips SDES items other than | |||
the CNAME item. | the CNAME item. | |||
skipping to change at page 8, line 28 ¶ | skipping to change at page 8, line 32 ¶ | |||
conditions. Accordingly, one might therefore think that it doesn't | conditions. Accordingly, one might therefore think that it doesn't | |||
matter which SSRC in the reporting group sends the RTP/AVPF feedback | matter which SSRC in the reporting group sends the RTP/AVPF feedback | |||
or codec control messages. There might be, however, cases where the | or codec control messages. There might be, however, cases where the | |||
sender of the feedback/codec control message has semantic importance, | sender of the feedback/codec control message has semantic importance, | |||
or when only a subset of the members of an RTCP reporting group might | or when only a subset of the members of an RTCP reporting group might | |||
want to send RTP/AVPF feedback or a codec control message in response | want to send RTP/AVPF feedback or a codec control message in response | |||
to a particular event. For example, an RTP video sender might choose | to a particular event. For example, an RTP video sender might choose | |||
to treat packet loss feedback received from SSRCs known to be audio | to treat packet loss feedback received from SSRCs known to be audio | |||
receivers with less urgency than feedback that it receives from video | receivers with less urgency than feedback that it receives from video | |||
receivers when deciding what packets to retransmit, and a multimedia | receivers when deciding what packets to retransmit, and a multimedia | |||
receiver using reporting groups might want to chose the outgoing SSRC | receiver using reporting groups might want to choose the outgoing | |||
for feedback packets to reflect this. | SSRC for feedback packets to reflect this. | |||
Each member of an RTCP reporting group SHOULD therefore send RTP/AVPF | Each member of an RTCP reporting group SHOULD therefore send RTP/AVPF | |||
feedback/codec control messages independently of the other members of | feedback/codec control messages independently of the other members of | |||
the reporting group, to respect the semantic meaning of the message | the reporting group, to respect the semantic meaning of the message | |||
sender. The suppression rules of [RFC4585] will ensure that only a | sender. The suppression rules of [RFC4585] will ensure that only a | |||
single copy of each feedback packet is (typically) generated, even if | single copy of each feedback packet is (typically) generated, even if | |||
several members of a reporting group send the same feedback. When an | several members of a reporting group send the same feedback. When an | |||
endpoint knows that several members of its RTCP reporting group will | endpoint knows that several members of its RTCP reporting group will | |||
be sending identical feedback, and that the sender of the feedback is | be sending identical feedback, and that the sender of the feedback is | |||
not semantically important, then that endpoint MAY choose to send all | not semantically important, then that endpoint MAY choose to send all | |||
skipping to change at page 15, line 12 ¶ | skipping to change at page 15, line 15 ¶ | |||
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-07 (work in progress), | draft-ietf-avtcore-rtp-multi-stream-08 (work in progress), | |||
March 2015. | July 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, March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <http://www.rfc-editor.org/info/rfc3550>. | ||||
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | |||
Description Protocol", RFC 4566, July 2006. | Description Protocol", RFC 4566, DOI 10.17487/RFC4566, | |||
July 2006, <http://www.rfc-editor.org/info/rfc4566>. | ||||
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, | [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, | |||
"Guidelines for Choosing RTP Control Protocol (RTCP) | "Guidelines for Choosing RTP Control Protocol (RTCP) | |||
Canonical Names (CNAMEs)", RFC 7022, September 2013. | Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, | |||
September 2013, <http://www.rfc-editor.org/info/rfc7022>. | ||||
7.2. Informative References | 7.2. Informative References | |||
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time | [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time | |||
Streaming Protocol (RTSP)", RFC 2326, April 1998. | Streaming Protocol (RTSP)", RFC 2326, | |||
DOI 10.17487/RFC2326, April 1998, | ||||
<http://www.rfc-editor.org/info/rfc2326>. | ||||
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session | |||
Announcement Protocol", RFC 2974, October 2000. | Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, | |||
October 2000, <http://www.rfc-editor.org/info/rfc2974>. | ||||
[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, June | with Session Description Protocol (SDP)", RFC 3264, | |||
2002. | DOI 10.17487/RFC3264, June 2002, | |||
<http://www.rfc-editor.org/info/rfc3264>. | ||||
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control | [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | |||
Protocol Extended Reports (RTCP XR)", RFC 3611, November | "RTP Control Protocol Extended Reports (RTCP XR)", | |||
2003. | RFC 3611, DOI 10.17487/RFC3611, November 2003, | |||
<http://www.rfc-editor.org/info/rfc3611>. | ||||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, March 2004. | RFC 3711, DOI 10.17487/RFC3711, March 2004, | |||
<http://www.rfc-editor.org/info/rfc3711>. | ||||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||
"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | |||
2006. | DOI 10.17487/RFC4585, July 2006, | |||
<http://www.rfc-editor.org/info/rfc4585>. | ||||
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | |||
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | |||
July 2006. | DOI 10.17487/RFC4588, July 2006, | |||
<http://www.rfc-editor.org/info/rfc4588>. | ||||
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | |||
"Codec Control Messages in the RTP Audio-Visual Profile | "Codec Control Messages in the RTP Audio-Visual Profile | |||
with Feedback (AVPF)", RFC 5104, February 2008. | with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, | |||
February 2008, <http://www.rfc-editor.org/info/rfc5104>. | ||||
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size | [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size | |||
Real-Time Transport Control Protocol (RTCP): Opportunities | Real-Time Transport Control Protocol (RTCP): Opportunities | |||
and Consequences", RFC 5506, April 2009. | and Consequences", RFC 5506, DOI 10.17487/RFC5506, April | |||
2009, <http://www.rfc-editor.org/info/rfc5506>. | ||||
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, | [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, | |||
"RTP Payload Format for Scalable Video Coding", RFC 6190, | "RTP Payload Format for Scalable Video Coding", RFC 6190, | |||
May 2011. | DOI 10.17487/RFC6190, May 2011, | |||
<http://www.rfc-editor.org/info/rfc6190>. | ||||
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
Sessions", RFC 7201, April 2014. | Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | |||
<http://www.rfc-editor.org/info/rfc7201>. | ||||
Authors' Addresses | Authors' Addresses | |||
Jonathan Lennox | Jonathan Lennox | |||
Vidyo, Inc. | Vidyo, Inc. | |||
433 Hackensack Avenue | 433 Hackensack Avenue | |||
Seventh Floor | Seventh Floor | |||
Hackensack, NJ 07601 | Hackensack, NJ 07601 | |||
US | US | |||
Email: jonathan@vidyo.com | Email: jonathan@vidyo.com | |||
Magnus Westerlund | Magnus Westerlund | |||
skipping to change at page 16, line 37 ¶ | skipping to change at page 17, line 15 ¶ | |||
Vidyo, Inc. | Vidyo, Inc. | |||
433 Hackensack Avenue | 433 Hackensack Avenue | |||
Seventh Floor | Seventh Floor | |||
Hackensack, NJ 07601 | Hackensack, NJ 07601 | |||
US | US | |||
Email: jonathan@vidyo.com | Email: jonathan@vidyo.com | |||
Magnus Westerlund | Magnus Westerlund | |||
Ericsson | Ericsson | |||
Farogatan 6 | Farogatan 2 | |||
SE-164 80 Kista | SE-164 80 Kista | |||
Sweden | Sweden | |||
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 | |||
End of changes. 25 change blocks. | ||||
40 lines changed or deleted | 57 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/ |