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 14
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.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/