draft-ietf-avtcore-rtp-multi-stream-optimisation-11.txt   draft-ietf-avtcore-rtp-multi-stream-optimisation-12.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 17, 2016 Ericsson Expires: September 3, 2016 Ericsson
Q. Wu Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
December 15, 2015 March 2, 2016
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-11 draft-ietf-avtcore-rtp-multi-stream-optimisation-12
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 17, 2016. This Internet-Draft will expire on September 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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 . . . . 4 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 . . . . . . . . . . . . . 11 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 12
4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 11 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 12
4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 12 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 RTP 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
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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. The attribute takes no value. SDP for configuration of RTP sessions. It is a property attribute,
A participant that proposes the use of RTCP Reporting Groups SHALL and hence takes no value. The multiplexing category
itself support the reception of RTCP Reporting Groups. The formal [I-D.ietf-mmusic-sdp-mux-attributes] is IDENTICAL, as the
definition of this attribute is: functionality applies on RTP session level. A participant that
proposes the use of RTCP Reporting Groups SHALL itself support the
reception of RTCP Reporting Groups. The formal definition of this
attribute is:
Name: rtcp-rgrp Name: rtcp-rgrp
Value: Value:
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Example: Example:
a=rtcp-rgrp a=rtcp-rgrp
When doing SDP Offer/Answer [RFC3264] an offering client that wishes
to use RTCP Reporting Groups MUST include the attribute "a=rtcp-rgrp" When using SDP Offer/Answer [RFC3264], the following procedures are
in the SDP offer. If "a=rtcp-rgrp" is present in the offer SDP, the to be used:
answerer that supports RTCP Reporting Groups and wishes to use it
SHALL include the "a=rtcp-rgrp" attribute in the answer. If the o Generating the initial SDP offer: If the offerer supports the RTCP
answerer does not wish to use RTCP Reporting Groups, it MUST NOT reporting group extensions, and is willing to accept RTCP packets
include the "a=rtcp-rgrp" attribute in the answer. containing those extensions, then it MUST include an "a=rtcp-rgrp"
attribute in the initial offer. If the offerer does not support
RTCP reporting groups extensions, or is not willing to accept RTCP
packets containing those extensions, then it MUST NOT include the
"a=rtcp-rgrp" attribute in the offer.
o Generating the SDP answer: If the SDP offer contains an "a=rtcp-
rgrp" attribute, and if the answerer supports RTCP reporting
groups and is willing to receive RTCP packets using the RTCP
reporting groups extensions, then the answerer MAY include an
"a=rtcp-rgrp" attribute in the answer and MAY send RTCP packets
containing the RTCP reporting groups extensions. If the offer
does not contain an "a=rtcp-rgrp" attribute, or if the offer does
contain such an attribute but the answerer does not wish to accept
RTCP packets using the RTCP reporting groups extensions, then the
answer MUST NOT include an "a=rtcp-rgrp" attribute.
o Offerer Processing of the SDP Answer: If the SDP answer contains
an "a=rtcp-rgrp" attribute, and the corresponding offer also
contained an "a=rtcp-rgrp" attribute, then the offerer MUST be
prepared to accept and process RTCP packets that contain the
reporting groups extension, and MAY send RTCP packets that contain
the reporting groups extension. If the SDP answer contains an
"a=rtcp-rgrp" attribute, but the corresponding offer did not
contain the "a=rtcp-rgrp" attribute, then the offerer MUST reject
the call. If the SDP answer does not contain an "a=rtcp-rgrp"
attribute, then the offerer MUST NOT send packets containing the
RTCP reporting groups extensions, and does not need to process
packet containing the RTCP reporting groups extensions.
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 An implementation that doesn't explicitly support RTCP Reporting
Groups MAY join a RTP session as long as it has been verified that Groups MAY join a RTP session as long as it has been verified that
the implementation doesn't suffer from the problems discussed in the implementation doesn't suffer from the problems discussed in
Section 4.2. Section 4.2.
skipping to change at page 15, line 29 skipping to change at page 16, line 15
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, Q., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
December 2015. December 2015.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2016.
[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. 10 change blocks. 
24 lines changed or deleted 60 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/