draft-ietf-avtcore-rtp-multi-stream-optimisation-04.txt   draft-ietf-avtcore-rtp-multi-stream-optimisation-05.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: February 26, 2015 Ericsson Expires: August 21, 2015 Ericsson
Q. Wu Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
August 25, 2014 February 17, 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-04 draft-ietf-avtcore-rtp-multi-stream-optimisation-05
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 February 26, 2015. This Internet-Draft will expire on August 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RTCP Reporting Groups . . . . . . . . . . . . . . . . . . . . 3 3. RTCP Reporting Groups . . . . . . . . . . . . . . . . . . . . 3
3.1. Semantics and Behaviour of RTCP Reporting Groups . . . . 3 3.1. Semantics and Behaviour of RTCP Reporting Groups . . . . 4
3.2. Identifying Members of an RTCP Reporting Group . . . . . 5 3.2. Identifying Members of an RTCP Reporting Group . . . . . 5
3.2.1. Definition and Use of the RTCP RGRP SDES Item . . . . 5 3.2.1. Definition and Use of the RTCP RGRP SDES Item . . . . 5
3.2.2. Definition and Use of the RTCP RGRS Packet . . . . . 6 3.2.2. Definition and Use of the RTCP RGRS Packet . . . . . 6
3.3. Interactions with the RTP/AVPF Feedback Profile . . . . . 8 3.3. Interactions with the RTP/AVPF Feedback Profile . . . . . 8
3.4. Interactions with RTCP Extended Report (XR) Packets . . . 9 3.4. Interactions with RTCP Extended Report (XR) Packets . . . 9
3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9 3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9
3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10 3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10
4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 10 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 11
4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 11 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 11
4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 11 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 media
skipping to change at page 5, line 8 skipping to change at page 5, line 13
and [I-D.ietf-avtcore-rtp-multi-stream]. and [I-D.ietf-avtcore-rtp-multi-stream].
The RTCP timing rules assign different bandwidth fractions to senders The RTCP timing rules assign different bandwidth fractions to senders
and receivers. This lets senders transmit RTCP reception quality and receivers. This lets senders transmit RTCP reception quality
reports more often than receivers. If a reporting source in an RTCP reports more often than receivers. If a reporting source in an RTCP
reporting group is a receiver, but one or more non-reporting SSRCs in reporting group is a receiver, but one or more non-reporting SSRCs in
the RTCP reporting group are senders, then the endpoint MAY treat the the RTCP reporting group are senders, then the endpoint MAY treat the
reporting source as a sender for the purpose of RTCP bandwidth reporting source as a sender for the purpose of RTCP bandwidth
allocation, increasing its RTCP bandwidth allocation, provided it allocation, increasing its RTCP bandwidth allocation, provided it
also treats one of the senders as if it were a receiver and makes the also treats one of the senders as if it were a receiver and makes the
corresponding reduction in RTCP bandwidth for that SSRC. corresponding reduction in RTCP bandwidth for that SSRC. However,
the application needs to consider the impact on the frequency of
transmitting of the synchronization information included in RTCP
Sender Reports.
3.2. Identifying Members of an RTCP Reporting Group 3.2. Identifying Members of an RTCP Reporting Group
When RTCP Reporting Groups are in use, the other SSRCs in the RTP When RTCP Reporting Groups are in use, the other SSRCs in the RTP
session need to be able to identify which SSRCs are members of an session need to be able to identify which SSRCs are members of an
RTCP reporting group. Two RTCP extensions are defined to support RTCP reporting group. Two RTCP extensions are defined to support
this: the RTCP RGRP SDES item is used by the reporting source(s) to this: the RTCP RGRP SDES item is used by the reporting source(s) to
identify an RTCP reporting group, and the RTCP RGRS packet is used by identify an RTCP reporting group, and the RTCP RGRS packet is used by
other members of an RTCP reporting group to identify the reporting other members of an RTCP reporting group to identify the reporting
source(s). source(s).
skipping to change at page 10, line 32 skipping to change at page 10, line 32
If a middlebox rewrites SSRC values in the RTP and RTCP packets that If a middlebox rewrites SSRC values in the RTP and RTCP packets that
it is forwarding, then it MUST make the corresponding changes in RTCP it is forwarding, then it MUST make the corresponding changes in RTCP
SDES packets containing RGRP items and in RTCP RGRS packets, to allow SDES packets containing RGRP items and in RTCP RGRS packets, to allow
them to be associated with the rewritten SSRCs. them to be associated with the rewritten SSRCs.
3.6. SDP Signalling for Reporting Groups 3.6. SDP Signalling for Reporting Groups
This document defines the "a=rtcp-rgrp" Session Description Protocol This document defines the "a=rtcp-rgrp" Session Description Protocol
(SDP) [RFC4566] attribute to indicate if the session participant is (SDP) [RFC4566] attribute to indicate if the session participant is
capable of supporting RTCP Reporting Groups for applications that use capable of supporting RTCP Reporting Groups for applications that use
SDP for configuration of RTP sessions. A participant that proposes SDP for configuration of RTP sessions. The attribute takes no value.
the use of RTCP Reporting Groups SHALL itself support the reception A participant that proposes the use of RTCP Reporting Groups SHALL
of RTCP Reporting Groups. itself support the reception of RTCP Reporting Groups.
An offering client that wishes to use RTCP Reporting Groups MUST An offering client that wishes to use RTCP Reporting Groups MUST
include the attribute "a=rtcp-rgrp" in the SDP offer. If "a=rtcp- include the attribute "a=rtcp-rgrp" in the SDP offer. If "a=rtcp-
rgrp" is present in the offer SDP, the answerer that supports RTCP rgrp" is present in the offer SDP, the answerer that supports RTCP
Reporting Groups and wishes to use it SHALL include the "a=rtcp-rgrp" Reporting Groups and wishes to use it SHALL include the "a=rtcp-rgrp"
attribute in the answer. The attribute takes no value. attribute in the answer. In cases the answer has been excluded,
neither agents SHALL use the RTCP Reporting Groups.
In declarative usage of SDP, such as the Real Time Streaming Protocol In declarative usage of SDP, such as the Real Time Streaming Protocol
(RTSP) [RFC2326] and the Session Announcement Protocol (SAP) (RTSP) [RFC2326] and the Session Announcement Protocol (SAP)
[RFC2974], the presence of the attribute indicates that the session [RFC2974], the presence of the attribute indicates that the session
participant MAY use RTCP Reporting Groups in its RTCP transmissions. participant MAY use RTCP Reporting Groups in its RTCP transmissions.
An implementation that doesn't explicitly support RTCP Reporting
Groups MAY join a RTP session as long as it has been verified that
the implementation doesn't suffer from the problems discussed in
Section 4.2.
4. Properties of RTCP Reporting Groups 4. Properties of RTCP Reporting Groups
This section provides additional information on what the resulting This section provides additional information on what the resulting
properties are with the design specified in Section 3. The content properties are with the design specified in Section 3. The content
of this section is non-normative. of this section is non-normative.
4.1. Bandwidth Benefits of RTCP Reporting Groups 4.1. Bandwidth Benefits of RTCP Reporting Groups
To understand the benefits of RTCP reporting groups, consider a To understand the benefits of RTCP reporting groups, consider a
skipping to change at page 13, line 42 skipping to change at page 13, line 45
This can be done, for example, by using SRTP [RFC3711] with This can be done, for example, by using SRTP [RFC3711] with
appropriate key-management, other options exist as discussed in RTP appropriate key-management, other options exist as discussed in RTP
Security Options [RFC7201]. Security Options [RFC7201].
The Report Group Identifier has a potential privacy impacting The Report Group Identifier has a potential privacy impacting
properties. If this would be generated by an implementation in such properties. If this would be generated by an implementation in such
a way that is long term stable or predictable, it could be used for a way that is long term stable or predictable, it could be used for
tracking a particular end-point. Therefore it is RECOMMENDED that it tracking a particular end-point. Therefore it is RECOMMENDED that it
be generated as a short-term persistent RGRP, following the rules for be generated as a short-term persistent RGRP, following the rules for
short-term persistent CNAMEs in [RFC7022]. The rest of the short-term persistent CNAMEs in [RFC7022]. The rest of the
information revealed, i.e. the SSRCs, the size of reporting group information revealed, i.e. the SSRCs, the size of reporting group and
and the number of reporting sources in a reporting group is of less the number of reporting sources in a reporting group is of less
sensitive nature, considering that the SSRCs and the communication sensitive nature, considering that the SSRCs and the communication
would anyway be revealed without this extension. By encrypting the would anyway be revealed without this extension. By encrypting the
report group extensions the SSRC values would preserved confidential, report group extensions the SSRC values would preserved confidential,
but can still be revealed if SRTP [RFC3711] is used. The size of the but can still be revealed if SRTP [RFC3711] is used. The size of the
reporting groups and number of reporting sources are likely reporting groups and number of reporting sources are likely
determinable from analysis of the packet pattern and sizes. However, determinable from analysis of the packet pattern and sizes. However,
this information appears to have limited value. this information appears to have limited value.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 14, line 21 skipping to change at page 14, line 23
The IANA is requested to register one new RTCP SDES items in the The IANA is requested to register one new RTCP SDES items in the
"RTCP SDES Item Types" registry, as follows: "RTCP SDES Item Types" registry, as follows:
Value Abbrev Name Reference Value Abbrev Name Reference
TBA RGRP Reporting Group Identifier [RFCXXXX] TBA RGRP Reporting Group Identifier [RFCXXXX]
The definition of the RTCP SDES RGRP item is given in Section 3.2.1 The definition of the RTCP SDES RGRP item is given in Section 3.2.1
of this memo. of this memo.
The IANA is also requested to register one new RTCP packet type in The IANA is also requested to register one new RTCP packet type in
the RTCP Control Packet Types (PT) Registry as follows: the "RTCP Control Packet Types (PT)" Registry as follows:
Value Abbrev Name Reference Value Abbrev Name Reference
TBA RGRS Reporting Group Reporting Sources [RFCXXXX] TBA RGRS Reporting Group Reporting Sources [RFCXXXX]
The definition of the RTCP RGRS packet type is given in Section 3.2.2 The definition of the RTCP RGRS packet type is given in Section 3.2.2
of this memo. of this memo.
The IANA is also requested to register one new SDP attribute: The IANA is also requested to register one new SDP attribute:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
skipping to change at page 15, line 12 skipping to change at page 15, line 10
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-05 (work in progress), draft-ietf-avtcore-rtp-multi-stream-06 (work in progress),
July 2014. October 2014.
[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, March 1997.
[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, July 2003.
[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, July 2006.
skipping to change at page 16, line 13 skipping to change at page 16, line 13
July 2006. July 2006.
[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, February 2008.
[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, April 2009.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
Eleftheriadis, "RTP Payload Format for Scalable Video "RTP Payload Format for Scalable Video Coding", RFC 6190,
Coding", RFC 6190, May 2011. May 2011.
[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, April 2014.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Seventh Floor Seventh Floor
 End of changes. 16 change blocks. 
21 lines changed or deleted 29 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/