draft-ietf-avtcore-rtp-multi-stream-09.txt   draft-ietf-avtcore-rtp-multi-stream-10.txt 
AVTCORE J. Lennox AVTCORE J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Updates: 3550, 4585 (if approved) M. Westerlund Updates: 3550, 4585 (if approved) M. Westerlund
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: April 2, 2016 Q. Wu Expires: May 27, 2016 Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
September 30, 2015 November 24, 2015
Sending Multiple Media Streams in a Single RTP Session Sending Multiple Media Streams in a Single RTP Session
draft-ietf-avtcore-rtp-multi-stream-09 draft-ietf-avtcore-rtp-multi-stream-10
Abstract Abstract
This memo expands and clarifies the behaviour of Real-time Transport This memo expands and clarifies the behaviour of Real-time Transport
Protocol (RTP) endpoints that use multiple synchronization sources Protocol (RTP) endpoints that use multiple synchronization sources
(SSRCs). This occurs, for example, when an endpoint sends multiple (SSRCs). This occurs, for example, when an endpoint sends multiple
media streams in a single RTP session. This memo updates RFC 3550 media streams in a single RTP session. This memo updates RFC 3550
with regards to handling multiple SSRCs per endpoint in RTP sessions, with regards to handling multiple SSRCs per endpoint in RTP sessions,
with a particular focus on RTCP behaviour. It also updates RFC 4585 with a particular focus on RTCP behaviour. It also updates RFC 4585
to update and clarify the calculation of the timeout of SSRCs and the to update and clarify the calculation of the timeout of SSRCs and the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 2, 2016. This Internet-Draft will expire on May 27, 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 38 skipping to change at page 4, line 38
endpoints, and then selectively forwards modified versions of some endpoints, and then selectively forwards modified versions of some
RTP streams toward the other endpoints to which it is connected. For RTP streams toward the other endpoints to which it is connected. For
each connected endpoint, a separate media source appears in the each connected endpoint, a separate media source appears in the
session for every other source connected to the middlebox, session for every other source connected to the middlebox,
"projected" from the original streams, but at any given time many of "projected" from the original streams, but at any given time many of
them can appear to be inactive (and thus are receivers, not senders, them can appear to be inactive (and thus are receivers, not senders,
in RTP). This sort of device is closer to being an RTP mixer than an in RTP). This sort of device is closer to being an RTP mixer than an
RTP translator, in that it terminates RTCP reporting about the mixed RTP translator, in that it terminates RTCP reporting about the mixed
streams, and it can re-write SSRCs, timestamps, and sequence numbers, streams, and it can re-write SSRCs, timestamps, and sequence numbers,
as well as the contents of the RTP payloads, and can turn sources on as well as the contents of the RTP payloads, and can turn sources on
and off at will without appearing to be generating packet loss. Each and off at will without appearing to generate packet loss. Each
projected stream will typically preserve its original RTCP source projected stream will typically preserve its original RTCP source
description (SDES) information. description (SDES) information.
3.4. Multiple SSRCs for a Single Media Source 3.4. Multiple SSRCs for a Single Media Source
There are also several cases where multiple SSRCs can be used to send There are also several cases where multiple SSRCs can be used to send
data from a single media source within a single RTP session. These data from a single media source within a single RTP session. These
include, but are not limited to, transport robustness tools, such as include, but are not limited to, transport robustness tools, such as
the RTP retransmission payload format [RFC4588], that require one the RTP retransmission payload format [RFC4588], that require one
SSRC to be used for the media data and another SSRC for the repair SSRC to be used for the media data and another SSRC for the repair
skipping to change at page 5, line 23 skipping to change at page 5, line 23
is running over a point-to-point connection or a multicast group, is running over a point-to-point connection or a multicast group,
since middleboxes can be used to connect multiple transport since middleboxes can be used to connect multiple transport
connections together into a single RTP session (the RTP session is connections together into a single RTP session (the RTP session is
defined by the shared SSRC space, not by the transport connections). defined by the shared SSRC space, not by the transport connections).
Furthermore, if RTP mixers are used, some SSRCs might only be visible Furthermore, if RTP mixers are used, some SSRCs might only be visible
in the contributing source (CSRC) list of an RTP packet and in RTCP, in the contributing source (CSRC) list of an RTP packet and in RTCP,
and might not appear directly as the SSRC of an RTP data packet. and might not appear directly as the SSRC of an RTP data packet.
Every RTP endpoint will have an allocated share of the available Every RTP endpoint will have an allocated share of the available
session bandwidth, as determined by signalling and congestion session bandwidth, as determined by signalling and congestion
control. The endpoint MUST keep its total media sending rate within control. The endpoint needs to keep its total media sending rate
this share. However, endpoints that send multiple media streams do within this share. However, endpoints that send multiple media
not necessarily need to subdivide their share of the available streams do not necessarily need to subdivide their share of the
bandwidth independently or uniformly to each media stream and its available bandwidth independently or uniformly to each media stream
SSRCs. In particular, an endpoint can vary the bandwidth allocation and its SSRCs. In particular, an endpoint can vary the bandwidth
to different streams depending on their needs, and can dynamically allocation to different streams depending on their needs, and can
change the bandwidth allocated to different SSRCs (for example, by dynamically change the bandwidth allocated to different SSRCs (for
using a variable rate codec), provided the total sending rate does example, by using a variable rate codec), provided the total sending
not exceed its allocated share. This includes enabling or disabling rate does not exceed its allocated share. This includes enabling or
media streams, or their redundancy streams, as more or less bandwidth disabling media streams, or their redundancy streams, as more or less
becomes available. bandwidth becomes available.
5. Use of RTCP by Endpoints that send multiple media streams 5. Use of RTCP by Endpoints that send multiple media streams
The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550]. The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550].
The description of the protocol is phrased in terms of the behaviour The description of the protocol is phrased in terms of the behaviour
of "participants" in an RTP session, under the assumption that each of "participants" in an RTP session, under the assumption that each
endpoint is a participant with a single SSRC. However, for correct endpoint is a participant with a single SSRC. However, for correct
operation in cases where endpoints have multiple SSRC values, the operation in cases where endpoints have multiple SSRC values,
specification MUST be interpreted as each SSRC counting as a separate implementations MUST treat each SSRC as a separate participant in the
participant in the RTP session, so that an endpoint that has multiple RTP session, so that an endpoint that has multiple SSRCs counts as
SSRCs counts as multiple participants. multiple participants.
5.1. RTCP Reporting Requirement 5.1. RTCP Reporting Requirement
An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a
separate participant in the RTP session. Each SSRC will maintain its separate participant in the RTP session. Each SSRC will maintain its
own RTCP-related state information, and hence will have its own RTCP own RTCP-related state information, and hence will have its own RTCP
reporting interval that determines when it sends RTCP reports. If reporting interval that determines when it sends RTCP reports. If
the mechanism in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] is the mechanism in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] is
not used, then each SSRC will send RTCP reports for all other SSRCs, not used, then each SSRC will send RTCP reports for all other SSRCs,
including those co-located at the same endpoint. including those co-located at the same endpoint.
skipping to change at page 6, line 46 skipping to change at page 6, line 46
allows a substantial number of SSRCs to report immediately. allows a substantial number of SSRCs to report immediately.
Endpoints SHOULD prioritize reports on SSRCs that are likely to be Endpoints SHOULD prioritize reports on SSRCs that are likely to be
most immediately useful, e.g., for SSRCs that are initially senders. most immediately useful, e.g., for SSRCs that are initially senders.
An endpoint that needs to report on more SSRCs than will fit into the An endpoint that needs to report on more SSRCs than will fit into the
four compound RTCP reports that can be sent immediately MUST send the four compound RTCP reports that can be sent immediately MUST send the
other reports later, following the usual RTCP timing rules including other reports later, following the usual RTCP timing rules including
timer reconsideration. Those reports MAY be aggregated as described timer reconsideration. Those reports MAY be aggregated as described
in Section 5.3. in Section 5.3.
Note: The above is based on an TCP initial window of 4 packets, Note: The above is chosen to match the TCP initial window of 4
not the larger TCP initial windows for which there is an ongoing packets, not the larger TCP initial windows for which there is an
experiment. The reason for this is a desire to be conservative, ongoing experiment. The reason for this is a desire to be
since an RTP endpoint will also in many cases start sending RTP conservative, since an RTP endpoint will also in many cases start
data packets at the same time as these initial RTCP packets are sending RTP data packets at the same time as these initial RTCP
sent. packets are sent.
5.3. Aggregation of Reports into Compound RTCP Packets 5.3. Aggregation of Reports into Compound RTCP Packets
As outlined in Section 5.1, an endpoint with multiple SSRCs has to As outlined in Section 5.1, an endpoint with multiple SSRCs has to
treat each SSRC as a separate participant when it comes to sending treat each SSRC as a separate participant when it comes to sending
RTCP reports. This will lead to each SSRC sending a compound RTCP RTCP reports. This will lead to each SSRC sending a compound RTCP
packet in each reporting interval. Since these packets are coming packet in each reporting interval. Since these packets are coming
from the same endpoint, it might reasonably be expected that they can from the same endpoint, it might reasonably be expected that they can
be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550]
allows RTP translators and mixers to aggregate packets in similar allows RTP translators and mixers to aggregate packets in similar
skipping to change at page 11, line 37 skipping to change at page 11, line 37
tc could be believed to have negative effect. However, the reason tc could be believed to have negative effect. However, the reason
for this setting is to compensate for bias caused by picking the for this setting is to compensate for bias caused by picking the
shortest tn out of the N aggregated. This bias remains over a shortest tn out of the N aggregated. This bias remains over a
reduction in the number of SSRCs. The reverse reconsideration reduction in the number of SSRCs. The reverse reconsideration
compensates the reduction independently of aggregation being used compensates the reduction independently of aggregation being used
or not. The negative effect that can occur on removing an SSRC is or not. The negative effect that can occur on removing an SSRC is
that the most favourable tn belonged to the removed SSRC. The that the most favourable tn belonged to the removed SSRC. The
impact of this is limited to delaying the transmission, in the impact of this is limited to delaying the transmission, in the
worst case, one reporting interval. worst case, one reporting interval.
In conclusion the investigations performed has found no significant In conclusion the investigations performed have found no significant
negative impact on the scheduling algorithm. negative impact on the scheduling algorithm.
5.4. Use of RTP/AVPF or RTP/SAVPF Feedback 5.4. Use of RTP/AVPF or RTP/SAVPF Feedback
This section discusses the transmission of RTP/AVPF feedback packets This section discusses the transmission of RTP/AVPF feedback packets
when the transmitting endpoint has multiple SSRCs. The guidelines in when the transmitting endpoint has multiple SSRCs. The guidelines in
this section also apply to endpoints using the RTP/SAVPF profile. this section also apply to endpoints using the RTP/SAVPF profile.
5.4.1. Choice of SSRC for Feedback Packets 5.4.1. Choice of SSRC for Feedback Packets
skipping to change at page 15, line 32 skipping to change at page 15, line 32
during the pause; these rules only apply to new RTP streams reusing during the pause; these rules only apply to new RTP streams reusing
an existing SSRC). an existing SSRC).
6.2. Removing RTP Streams 6.2. Removing RTP Streams
An SSRC is removed from an RTP session in one of two ways. When an An SSRC is removed from an RTP session in one of two ways. When an
endpoint stops sending RTP and RTCP packets using an SSRC, then that endpoint stops sending RTP and RTCP packets using an SSRC, then that
SSRC will eventually time out as described in Section 6.3.5 of SSRC will eventually time out as described in Section 6.3.5 of
[RFC3550]. Alternatively, an SSRC can be explicitly removed from use [RFC3550]. Alternatively, an SSRC can be explicitly removed from use
by sending an RTCP BYE packet as described in Section 6.3.7 of by sending an RTCP BYE packet as described in Section 6.3.7 of
[RFC3550]. It is RECOMMENDED that SSRCs are removed from use by [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by
sending an RTCP BYE packet. Note that [RFC3550] requires that the sending an RTCP BYE packet. Note that [RFC3550] requires that the
RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session
for an SSRC. If an endpoint needs to restart an RTP stream after for an SSRC. If an endpoint needs to restart an RTP stream after
sending an RTCP BYE for its SSRC, it needs to generate a new SSRC sending an RTCP BYE for its SSRC, it needs to generate a new SSRC
value for that stream. value for that stream.
The finality of sending RTCP BYE, means that endpoints needs to The finality of sending RTCP BYE, means that endpoints needs to
consider if the ceasing of transmission of an RTP stream is temporary consider if the ceasing of transmission of an RTP stream is temporary
or more permanent. Temporary suspension of media transmission using or more permanent. Temporary suspension of media transmission using
a particular RTP stream (SSRC) needs to maintain that SSRC as an a particular RTP stream (SSRC) needs to maintain that SSRC as an
skipping to change at page 25, line 20 skipping to change at page 25, line 20
[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, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <http://www.rfc-editor.org/info/rfc5506>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-10 (work in ietf-avtcore-multi-media-rtp-session-11 (work in
progress), September 2015. progress), November 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
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:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-06 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-08 (work
in progress), July 2015. in progress), October 2015.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-10 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015. July 2015.
[I-D.ietf-clue-framework] [I-D.ietf-clue-framework]
Duckworth, M., Pepperell, A., and S. Wenger, "Framework Duckworth, M., Pepperell, A., and S. Wenger, "Framework
for Telepresence Multi-Streams", draft-ietf-clue- for Telepresence Multi-Streams", draft-ietf-clue-
framework-23 (work in progress), September 2015. framework-24 (work in progress), November 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015. negotiation-23 (work in progress), July 2015.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
 End of changes. 13 change blocks. 
33 lines changed or deleted 33 lines changed or added

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