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