draft-ietf-avtcore-rtp-multi-stream-optimisation-10.txt   draft-ietf-avtcore-rtp-multi-stream-optimisation-11.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: June 13, 2016 Ericsson Expires: June 17, 2016 Ericsson
Q. Wu Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
December 11, 2015 December 15, 2015
Sending Multiple RTP 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-10 draft-ietf-avtcore-rtp-multi-stream-optimisation-11
Abstract Abstract
RTP allows multiple RTP 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 normally co-located and see the same reception quality. endpoint are normally co-located and see the same reception quality.
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 June 13, 2016. This Internet-Draft will expire on June 17, 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 4, line 18 skipping to change at page 4, line 18
A group of co-located SSRCs that see identical network conditions can A group of co-located SSRCs that see identical network conditions can
form an RTCP reporting group. If reporting groups are in use, an RTP form an RTCP reporting group. If reporting groups are in use, an RTP
endpoint with multiple SSRCs MAY put those SSRCs into a reporting endpoint with multiple SSRCs MAY put those SSRCs into a reporting
group if their view of the network is identical; i.e., if they report group if their view of the network is identical; i.e., if they report
on traffic received at the same interface of an RTP endpoint. SSRCs on traffic received at the same interface of an RTP endpoint. SSRCs
with different views of the network MUST NOT be put into the same with different views of the network MUST NOT be put into the same
reporting group. reporting group.
An endpoint that has combined its SSRCs into an RTCP reporting group An endpoint that has combined its SSRCs into an RTCP reporting group
will choose one (or a subset) of those SSRCs as a "reporting source" will choose one (or a subset) of those SSRCs to act as "reporting
for that RTCP reporting group. A reporting source will send RTCP SR/ source(s)" for that RTCP reporting group. A reporting source will
RR reception quality reports on behalf of the other members of the send RTCP SR/RR reception quality reports on behalf of the other
RTCP reporting group. A reporting source MUST suppress the RTCP SR/ members of the RTCP reporting group. A reporting source MUST
RR reports that relate to other members of the reporting group, and suppress the RTCP SR/RR reports that relate to other members of the
only report on remote SSRCs. The other members (non reporting reporting group, and only report on remote SSRCs. The other members
sources) of the RTCP reporting group will suppress their RTCP (non reporting sources) of the RTCP reporting group will suppress
reception quality reports, and instead send an RTCP RGRS packet (see their RTCP reception quality reports, and instead send an RTCP RGRS
Section 3.2.2) to indicate that they are part of an RTCP reporting packet (see Section 3.2.2) to indicate that they are part of an RTCP
group and give the SSRCs of the reporting sources. reporting group and give the SSRCs of the reporting sources.
If there are large numbers of remote SSRCs in the RTP session, then If there are large numbers of remote SSRCs in the RTP session, then
the reception quality reports generated by the reporting source might the reception quality reports generated by the reporting source might
grow too large to fit into a single compound RTCP packet, forcing the grow too large to fit into a single compound RTCP packet, forcing the
reporting source to use a round-robin policy to determine what remote reporting source to use a round-robin policy to determine what remote
SSRCs it includes in each compound RTCP packet, and so reducing the SSRCs it includes in each compound RTCP packet, and so reducing the
frequency of reports on each SSRC. To avoid this, in sessions with frequency of reports on each SSRC. To avoid this, in sessions with
large numbers of remote SSRCs, an RTCP reporting group MAY use more large numbers of remote SSRCs, an RTCP reporting group MAY use more
than one reporting source. If several SSRCs are acting as reporting than one reporting source. If several SSRCs are acting as reporting
sources for an RTCP reporting group, then each reporting source MUST sources for an RTCP reporting group, then each reporting source MUST
skipping to change at page 6, line 45 skipping to change at page 6, line 45
SSRC of the packet sender, and a list of reporting sources for the SSRC of the packet sender, and a list of reporting sources for the
RTCP reporting group of which the packet sender is a member. RTCP reporting group of which the packet sender is a member.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=RGRS(TBA) | length | |V=2|P| SC | PT=RGRS(TBA) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
: List of SSRCs for the Reporting Source(s) : : List of SSRC(s) for the Reporting Source(s) :
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the RTCP RGRS packet have the following definition: The fields in the RTCP RGRS packet have the following definition:
version (V): 2 bits unsigned integer. This field identifies the RTP version (V): 2 bits unsigned integer. This field identifies the RTP
version. The current RTP version is 2. version. The current RTP version is 2.
padding (P): 1 bit. If set, the padding bit indicates that the RTCP padding (P): 1 bit. If set, the padding bit indicates that the RTCP
packet contains additional padding octets at the end that are not packet contains additional padding octets at the end that are not
skipping to change at page 15, line 24 skipping to change at page 15, line 24
Values: None 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, Q., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-10 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
November 2015. December 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>.
 End of changes. 7 change blocks. 
19 lines changed or deleted 19 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/