draft-ietf-avtcore-rtp-multi-stream-optimisation-02.txt   draft-ietf-avtcore-rtp-multi-stream-optimisation-03.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: August 18, 2014 Ericsson Expires: January 02, 2015 Ericsson
Q. Wu Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
February 14, 2014 July 01, 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-02 draft-ietf-avtcore-rtp-multi-stream-optimisation-03
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 August 18, 2014. This Internet-Draft will expire on January 02, 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 2, line 24 skipping to change at page 2, line 24
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 . . . . 3
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 . . . . . 7 3.3. Interactions with the RTP/AVPF Feedback Profile . . . . . 8
3.4. Interactions with RTCP Extended Report (XR) Packets . . . 8 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 . . . . . . . . . . . 9 3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10
4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 9 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 10
4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 10 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 11
4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 10 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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
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
skipping to change at page 4, line 49 skipping to change at page 4, line 49
If a reporting source leaves the RTP session (i.e., if it sends a If a reporting source leaves the RTP session (i.e., if it sends a
RTCP BYE packet, or leaves the session without sending BYE under the RTCP BYE packet, or leaves the session without sending BYE under the
rules of [RFC3550] section 6.3.7), the remaining members of the RTCP rules of [RFC3550] section 6.3.7), the remaining members of the RTCP
reporting group MUST either (a) have another reporting source, if reporting group MUST either (a) have another reporting source, if
existing, report on the remote SSRCs the leaving SSRC reported on, existing, report on the remote SSRCs the leaving SSRC reported on,
(b) choose a new reporting source, or (c) disband the RTCP reporting (b) choose a new reporting source, or (c) disband the RTCP reporting
group and begin sending reception quality reports following [RFC3550] group and begin sending reception quality reports following [RFC3550]
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 to 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.
3.2. Identifying Members of an RTCP Reporting Group 3.2. Identifying Members of an RTCP Reporting Group
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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).
3.2.1. Definition and Use of the RTCP RGRP SDES Item 3.2.1. Definition and Use of the RTCP RGRP SDES Item
A new RTCP SDES item is defined to identify an RTCP reporting group. A new RTCP SDES item is defined to identify an RTCP reporting group.
This motivation for giving a reporting group an identify is to ensure The motivation for giving a reporting group an identify is to ensure
that the RTCP reporting group and its member SSRCs can be correctly that the RTCP reporting group and its member SSRCs can be correctly
associated when there are multiple reporting sources, and to ensure associated when there are multiple reporting sources, and to ensure
that a reporting SSRC can be associated with the correct reporting that a reporting SSRC can be associated with the correct reporting
group if an SSRC collision occurs. group if an SSRC collision occurs.
The RTCP Source Description (SDES) RGRP item is defined. The RTCP The RTCP Source Description (SDES) RGRP item is defined. The RTCP
SDES RGRP item MUST be sent by the reporting sources in a reporting SDES RGRP item MUST be sent by the reporting sources in a reporting
group, and MUST NOT be sent by other members of the reporting group group, and MUST NOT be sent by other members of the reporting group
or by SSRCs that are not members of any RTCP reporting group. or by SSRCs that are not members of any RTCP reporting group.
Specifically, every reporting source in an RTCP reporting group MUST Specifically, every reporting source in an RTCP reporting group MUST
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]. The value of the RTCP that of the RTCP SDES CNAME item [RFC7022], except that the SDES item
SDES RGRP item MUST be chosen with the same concerns about global type field MUST have value RGRP=(TBA) instead of CNAME=1. The value
uniqueness and the same privacy considerations as the RTCP SDES CNAME of the RTCP SDES RGRP item MUST be chosen with the same concerns
them. The value of the RTCP SDES RGRP item MUST be stable throughout about global uniqueness and the same privacy considerations as the
the lifetime of the reporting group, even if the some or all of the RTCP SDES CNAME them. The value of the RTCP SDES RGRP item MUST be
reporting sources change their SSRC due to collisions, or if the set stable throughout the lifetime of the reporting group, even if the
of reporting sources changes. some or all of the reporting sources change their SSRC due to
collisions, or if the set of reporting sources changes.
Note to RFC Editor: please replace (TBA) in the above paragraph
with the RTCP SDES item type number assigned to the RGRP item,
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.
3.2.2. Definition and Use of the RTCP RGRS Packet 3.2.2. Definition and Use of the RTCP RGRS Packet
A new RTCP packet type is defined to allow the members of an RTCP A new RTCP packet type is defined to allow the members of an RTCP
reporting group to identify the reporting sources for that group. reporting group to identify the reporting sources for that group.
skipping to change at page 8, line 8 skipping to change at page 8, line 18
rapid RTCP feedback requests and codec control messages. If use of rapid RTCP feedback requests and codec control messages. If use of
the RTP/AVPF profile has been negotiated in an RTP session, members the RTP/AVPF profile has been negotiated in an RTP session, members
of an RTCP reporting group can send rapid RTCP feedback and codec of an RTCP reporting group can send rapid RTCP feedback and codec
control messages following [RFC4585] and [RFC5104], as updated by control messages following [RFC4585] and [RFC5104], as updated by
Section 5.4 of [I-D.ietf-avtcore-rtp-multi-stream], and by the Section 5.4 of [I-D.ietf-avtcore-rtp-multi-stream], and by the
following considerations. following considerations.
The members of an RTCP reporting group will all see identical network The members of an RTCP reporting group will all see identical network
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 are, however, some 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. to a particular event. For example, an RTP video sender might choose
to treat packet loss feedback received from SSRCs known to be audio
receivers with less urgency than feedback that it receives from video
receivers when deciding what packets to retransmit, and a multimedia
receiver using reporting groups might want to chose the outgoing 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 9, line 6 skipping to change at page 9, line 21
groups, it is RECOMMENDED that the reporting source is used to send groups, it is RECOMMENDED that the reporting source is used to send
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,
so they are relevant to only some members of a reporting group. Such and might be relevant to only some members of a reporting group. For
XR reports MUST be sent by the source to which they are relevant, and example, it would make no sender for an SSRC that is receiving video
MUST NOT be included in the common report sent by the reporting to send a VoIP metric RTCP XR report block. Such media specific RTCP
source. This can mean that some sources send XR packets in a XR report blocks MUST be sent by the SSRC to which they are relevant,
compound packet that contains an empty SR/RR packet and that the time and MUST NOT be included in the common report sent by the reporting
period covered by the XR packet is different to that covered by the source. This might mean that some SSRCs send RTCP XR packets in
SR/RR packet. If it is important that the XR packet and SR/RR packet compound RTCP packets that contain an empty RTCP SR/RR packet, and
cover the same time period, then that source SHOULD be removed from that the time period covered by the RTCP XR packet is different to
the RTCP reporting group, and sent standard RTCP packets. 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
that source SHOULD be removed from the RTCP reporting group, and send
standard RTCP packets instead.
3.5. Middlebox Considerations 3.5. Middlebox Considerations
This section discusses middlebox considerations for Reporting groups. Many different types of middlebox are used with RTP. RTCP reporting
groups are potentially relevant to those types of RTP middlebox that
have their own SSRCs and generate RTCP reports for the traffic they
receive. RTP middleboxes that do not have their own SSRC, and that
don't send RTCP reports on the traffic they receive, cannot use the
RTCP reporting groups extension, since they generate no RTCP reports
to group.
(TBD: write this section) An RTP middlebox that has several SSRCs of its own can use the RTCP
reporting groups extension to group the RTCP reports it generates.
This can occur, for example, if a middlebox is acting as an RTP mixer
for both audio and video flows that are multiplexed onto a single RTP
session, where the middlebox has one SSRC for the audio mixer and one
for the video mixer part, and when the middlebox wants to avoid cross
reporting between audio and video.
A middlebox cannot use the RTCP reporting groups extension to group
RTCP packets from the SSRCs that it is forwarding. It can, however,
group the RTCP packets from the SSRCs it is forwarding into compound
RTCP packets following the rules in Section 6.1 of [RFC3550] and
Section 5.3 of [I-D.ietf-avtcore-rtp-multi-stream]. If the middlebox
is using RTCP reporting groups for its own SSRCs, it MAY include RTCP
packets from the SSRCs that it is forwarding as part of the compound
RTCP packets its reporting source generates.
A middlebox that forwards RTCP SR or RR packets sent by members of a
reporting group MUST forward the corresponding RTCP SDES RGRP items,
as described in Section 3.2.1. A middlebox that forwards RTCP SR or
RR packets sent by member of a reporting group MUST also forward the
corresponding RTCP RGRS packets, as described in Section 3.2.2.
Failure to forward these packets can cause compatibility problems, as
described in Section 4.2.
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
SDES packets containing RGRP items and in RTCP RGRS packets, to allow
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. 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.
skipping to change at page 12, line 34 skipping to change at page 13, line 34
The most significant result from an deliberate attack would be to The most significant result from an deliberate attack would be to
cause the information to be discarded or be inconsistent, including cause the information to be discarded or be inconsistent, including
discard of all RTCP packets that are modified. This causes a lack of discard of all RTCP packets that are modified. This causes a lack of
information at any receiver entity, possibly disregarding the information at any receiver entity, possibly disregarding the
endpoints participation in the session. endpoints participation in the session.
To protect against this type of attacks from external non trusted To protect against this type of attacks from external non trusted
entities, integrity and source authentication SHOULD be applied. entities, integrity and source authentication SHOULD be applied.
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 [I-D.ietf-avtcore-rtp-security-options]. 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 the number of reporting sources in a reporting group is of less and 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
(Note to the RFC-Editor: please replace "TBA" with the IANA-assigned (Note to the RFC-Editor: in the following, please replace "TBA" with
value, and "XXXX" with the number of this document, prior to the IANA-assigned value, and "XXXX" with the number of this document,
publication as an RFC.) then delete this note)
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]
Figure 1: Item for the IANA Source Attribute Registry The definition of the RTCP SDES RGRP item is given in Section 3.2.1
of this memo.
The IANA is also requested to register one new RTCP packet type as The IANA is also requested to register one new RTCP packet type in
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]
Figure 2: Item for the IANA RTCP Control Packet Types (PT) Registry The definition of the RTCP RGRS packet type is given in Section 3.2.2
of this memo.
The IANA is also request to register one new SDP attribute "a=rtcp- The IANA is also requested to register one new SDP attribute:
rgrp":
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 usage 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: See [RFCXXXX]
The definition of the "a=rtcp-rgrp" SDES attribute is given in
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-02 (work in progress), draft-ietf-avtcore-rtp-multi-stream-04 (work in progress),
January 2014. May 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.
[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, September 2013.
7.2. Informative References 7.2. Informative References
[I-D.ietf-avtcore-rtp-security-options]
Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", draft-ietf-avtcore-rtp-security-options-10
(work in progress), January 2014.
[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, April 1998.
[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, October 2000.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003. 2003.
skipping to change at page 15, line 13 skipping to change at page 16, line 17
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.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, May 2011. Coding", RFC 6190, May 2011.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
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
Hackensack, NJ 07601 Hackensack, NJ 07601
US US
Email: jonathan@vidyo.com Email: jonathan@vidyo.com
 End of changes. 26 change blocks. 
69 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/