draft-ietf-avtcore-rtp-multi-stream-optimisation-03.txt   draft-ietf-avtcore-rtp-multi-stream-optimisation-04.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 02, 2015 Ericsson Expires: February 26, 2015 Ericsson
Q. Wu Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
July 01, 2014 August 25, 2014
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-03 draft-ietf-avtcore-rtp-multi-stream-optimisation-04
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 02, 2015. This Internet-Draft will expire on February 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 9, line 22 skipping to change at page 9, line 22
the RTCP XR packets. If multiple reporting sources are in use, the the RTCP XR packets. If multiple reporting sources are in use, the
reporting source that sends the SR/RR packets that relate to a reporting source that sends the SR/RR packets that relate to a
particular remote SSRC SHOULD send the RTCP XR reports about that particular remote SSRC SHOULD send the RTCP XR reports about that
SSRC. This is motivated as one commonly combine the RTCP XR metrics SSRC. This is motivated as one commonly combine the RTCP XR metrics
with the regular report block to more fully understand the situation. with the regular report block to more fully understand the situation.
Receiving these blocks in different compound packets reduces their Receiving these blocks in different compound packets reduces their
value as the measuring intervals are not synchronized in those cases. value as the measuring intervals are not synchronized in those cases.
Some RTCP XR report blocks are specific to particular types of media, Some RTCP XR report blocks are specific to particular types of media,
and might be relevant to only some members of a reporting group. For and might be relevant to only some members of a reporting group. For
example, it would make no sender for an SSRC that is receiving video example, it would make no sense for an SSRC that is receiving video
to send a VoIP metric RTCP XR report block. Such media specific RTCP to send a VoIP metric RTCP XR report block. Such media specific RTCP
XR report blocks MUST be sent by the SSRC to which they are relevant, XR report blocks MUST be sent by the SSRC to which they are relevant,
and MUST NOT be included in the common report sent by the reporting and MUST NOT be included in the common report sent by the reporting
source. This might mean that some SSRCs send RTCP XR packets in source. This might mean that some SSRCs send RTCP XR packets in
compound RTCP packets that contain an empty RTCP SR/RR packet, and compound RTCP packets that contain an empty RTCP SR/RR packet, and
that the time period covered by the RTCP XR packet is different to that the time period covered by the RTCP XR packet is different to
that covered by the RTCP SR/RR packet. If it is important that the that covered by the RTCP SR/RR packet. If it is important that the
RTCP XR packet and RTCP SR/RR packet cover the same time period, then RTCP XR packet and RTCP SR/RR packet cover the same time period, then
that source SHOULD be removed from the RTCP reporting group, and send that source SHOULD be removed from the RTCP reporting group, and send
standard RTCP packets instead. standard RTCP packets instead.
skipping to change at page 10, line 40 skipping to change at page 10, line 40
(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. A participant that proposes
the use of RTCP Reporting Groups SHALL itself support the reception the use of RTCP Reporting Groups SHALL itself support the reception
of RTCP Reporting Groups. 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. attribute in the answer. The attribute takes no value.
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.
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
skipping to change at page 14, line 40 skipping to change at page 14, line 40
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rtcp-rgrp Attribute name: rtcp-rgrp
Long form: RTCP Reporting Groups Long form: RTCP Reporting Groups
Type of name: att-field Type of name: att-field
Type of attribute: Media or session level Type of attribute: Media or session level
Subject to charset: No Subject to charset: No
Purpose: Negotiate or configure the use of the RTCP Purpose: Negotiate or configure the use of the RTCP
Reporting Group Extension. Reporting Group Extension.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: See [RFCXXXX] Values: None
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-04 (work in progress), draft-ietf-avtcore-rtp-multi-stream-05 (work in progress),
May 2014. July 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.
 End of changes. 8 change blocks. 
9 lines changed or deleted 9 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/