draft-begen-avtcore-rtp-duplication-00.txt   draft-begen-avtcore-rtp-duplication-01.txt 
AVT A. Begen AVT A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track C. Perkins Intended status: Standards Track C. Perkins
Expires: April 26, 2012 University of Glasgow Expires: September 11, 2012 University of Glasgow
October 24, 2011 March 10, 2012
Duplicating RTP Streams Duplicating RTP Streams
draft-begen-avtcore-rtp-duplication-00 draft-begen-avtcore-rtp-duplication-01
Abstract Abstract
Packet loss is undesirable for real-time multimedia sessions, but it Packet loss is undesirable for real-time multimedia sessions, but can
is not avoidable due to congestion or other unplanned network occur due to congestion, or other unplanned network outages. This is
outages. This is especially the case for IP multicast networks. One especially true for IP multicast networks, where packet loss patterns
technique to recover from packet loss without incurring unbounded can vary greatly between receivers. One technique that can be used
delay for all the receivers is to duplicate the packets and send them to recover from packet loss without incurring unbounded delay for all
in separate redundant streams. This document explains how RTP the receivers is to duplicate the packets and send them in separate
streams can be duplicated without breaking RTP and RTP Control redundant streams. This document explains how Real-time Transport
Protocol (RTCP) rules. Protocol (RTP) streams can be duplicated without breaking RTP media
streams, or RTP Control Protocol (RTCP) rules.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 26, 2012. This Internet-Draft will expire on September 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Notation . . . . . . . . . . . . . 3 2. Terminology and Requirements Notation . . . . . . . . . . . . 3
3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . . 3 3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . . 3
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . . 4 3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . . 4 3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Using Separate Source Interfaces . . . . . . . . . . . 4 3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5
3.2.2. Using Separate Destination Addresses and/or Ports . . . 5
3.3. Dual Streaming over a Single Path or Multiple Paths . . . . 5
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . . 6 4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . . 6
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . . 6 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling Considerations . . . . . . . . . . . . . . . . . 6 4.2. Signaling Considerations . . . . . . . . . . . . . . . . . 6
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . . 7 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 7
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . . 7 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8
5.2. Signaling Considerations . . . . . . . . . . . . . . . . . 7 5.2. Signaling Considerations . . . . . . . . . . . . . . . . . 8
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . . 8 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
RTP [RFC3550] transport is widely used today for delivering real-time The Real-time Transport Protocol (RTP) [RFC3550] is widely used today
multimedia streams. Most of the applications also rely on IP for delivering IPTV traffic, and other real-time multimedia sessions.
multicast to reach many receivers efficiently. Many of these applications support very large numbers of receivers,
and rely on intra-domain UDP/IP multicast for efficient distribution
of traffic within the network.
While the combination proves successful, there does exist a weakness. While this combination has proved successful, there does exist a
As [RFC2354] noted, packet loss is not avoidable. This might be due weakness. As [RFC2354] noted, packet loss is not avoidable, even in
to congestion, it might also be a result of an unplanned outage a carefully managed network. This loss might be due to congestion,
caused by a flapping link, link or interface failure, a software bug, it might also be a result of an unplanned outage caused by a flapping
or a maintenance person accidentally cutting the wrong fiber. Since link, link or interface failure, a software bug, or a maintenance
UDP does not provide any means for detecting loss and retransmitting person accidentally cutting the wrong fiber. Since UDP/IP flows do
packets, it leaves up to the RTP or the applications to detect and not provide any means for detecting loss and retransmitting packets,
recover from the loss. For retransmission-based recovery, one it leaves up to the RTP layer and the applications to detect, and
example is described in [RFC4588]. recover from, packet loss.
One technique to recover from packet loss without incurring unbounded One technique to recover from packet loss without incurring unbounded
delay for all the receivers is to duplicate the packets and send them delay for all the receivers is to duplicate the packets and send them
in separate redundant streams. Variations of this technique have in separate redundant streams. Variations on this idea have been
already been implemented and deployed today [IC2011]. However, implemented and deployed today [IC2011]. However, duplication of RTP
duplication of RTP streams without breaking the RTP and RTCP streams without breaking the RTP and RTCP functionality has not been
functionality has not been documented properly. This document documented properly. This document explains how duplication can be
explains how duplication can be achieved for RTP streams. achieved for RTP streams.
Stream duplication offers a simple way to protect media flows from
packet loss. It has a comparatively high bandwidth overhead, since
everything is sent twice, but with a low processor overhead. It is
also very predictable in its overheads. Alternative approaches may
be suitable in some cases, for example retransmission-based recovery
[RFC4588] or forward error correction [RFC5109].
2. Terminology and Requirements Notation 2. Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Dual Streaming Use Cases 3. Dual Streaming Use Cases
Dual streaming refers to a technique that involves transmitting two Dual streaming refers to a technique that involves transmitting two
redundant (often RTP) streams of the same content, with each stream redundant RTP streams of the same content, with each stream capable
itself capable of supporting the playback when there is no packet of supporting the playback when there is no packet loss. Therefore,
loss. Therefore, adding an additional stream provides a protection adding an additional RTP stream provides a protection against packet
against packet loss. The level of protection depends on how the loss. The level of protection depends on how the packets are sent
packets are sent and transmitted inside the network. and transmitted inside the network.
It is important to note that redundant streaming can easily be It is important to note that dual streaming can easily be extended to
extended to support cases when more than two streams are desired. support cases when more than two streams are desired. However, using
But triple, quadruple, or more, streaming is rarely used in practice. three or more streams is rare in practise, due to the high overhead
that it incurs.
3.1. Temporal Redundancy 3.1. Temporal Redundancy
From a routing perspective, two streams are considered identical if From a routing perspective, two streams are considered identical if
their following two fields are the same since they will be both the following two IP header fields are the same, since they will be
routed over the same path: both routed over the same path:
o IP Source Address o IP Source Address
o IP Destination Address o IP Destination Address
Two routing-plane identical RTP streams might carry the same payload Two routing-plane identical RTP streams might carry the same payload,
but they could use different Synchronization Sources (SSRC) to but can use different Synchronization Sources (SSRC) to differentiate
differentiate the RTP packets belonging to each stream. In the the RTP packets belonging to each stream. In the context of dual RTP
context of dual streaming, we assume that the source duplicates the streaming, we assume that the source duplicates the RTP packets and
RTP packets and put them into separate RTP streams each with a unique sends them in separate RTP streams, each with a unique SSRC. All the
SSRC identifier. All the redundant streams are transmitted in the redundant streams are transmitted in the same RTP session.
same RTP session.
For example, two redundant RTP streams can be sent to the same IP For example, one main and one redundant RTP stream can be sent to the
destination address and UDP destination port with a certain delay same IP destination address and UDP destination port with a certain
between them [I-D.begen-mmusic-temporal-interleaving]. The streams delay between them [I-D.begen-mmusic-temporal-interleaving]. The
carry the same payload in their respective RTP packets with identical streams carry the same payload in their respective RTP packets with
sequence numbers. This allows the receiver (or any other node identical sequence numbers. This allows receivers (or other nodes
responsible for duplicate suppression) to identify and suppress the responsible for gap filling and duplicate suppression) to identify
duplicate packets, and subsequently produce a hopefully loss-free and and suppress the duplicate packets, and subsequently produce a
duplication-free output stream (called stream merging). hopefully loss-free and duplication-free output stream. This process
is called stream merging.
3.2. Spatial Redundancy 3.2. Spatial Redundancy
3.2.1. Using Separate Source Interfaces An RTP source might be associated with multiple network interfaces,
allowing it to send two redundant streams from two separate source
An RTP source might have multiple network interfaces associated with addresses. Such streams can be routed over diverse or identical
it and it can send two redundant streams from two separate paths depending on the routing algorithm used inside the network. At
interfaces. Such streams can be routed over diverse or identical the receiving end, the node responsible for duplicate suppression can
paths depending on the routing algorithm inside the network. At the look into various RTP header fields, for example SSRC and sequence
receiving end, the node responsible for duplicate suppression can number, to identify and suppress the duplicate packets.
look into various RTP related fields to identify and suppress the
duplicate packets.
If source-specific multicast (SSM) transport is used to carry such If source-specific multicast (SSM) transport is used to carry such
redundant streams, there will be a separate SSM session for each redundant streams, there will be a separate SSM session for each
redundant stream since the streams are sourced from different redundant stream since the streams are sourced from different
interfaces (i.e., IP addresses). The receiving host has to join each interfaces (i.e., IP addresses). Thus, the receiving host has to
SSM session separately. join each SSM session separately.
3.2.2. Using Separate Destination Addresses and/or Ports
An RTP source might send the redundant streams to separate IP Alternatively, an RTP source might send the redundant streams to
destination addresses and/or UDP ports. separate IP destination addresses.
3.3. Dual Streaming over a Single Path or Multiple Paths 3.3. Dual Streaming over a Single Path or Multiple Paths
Having described the characteristics of the streams, one can reach Having described the characteristics of the streams, one can reach
the following conclusions: the following conclusions:
1. When two routing-plane identical streams are used, the two 1. When two routing-plane identical streams are used, the two
streams will have identical IP headers. This makes it streams will have identical IP headers. This makes it
impractical to forward the packets onto different paths. In impractical to forward the packets onto different paths. In
order to minimize packet loss, the packets belonging to one order to minimize packet loss, the packets belonging to one
stream are often interleaved with packets belonging to the other, stream are often interleaved with packets belonging to the other,
and with a delay, so that if there is a packet loss, such a delay and with a delay, so that if there is a packet loss, such a delay
would allow the same packet from the other stream to reach the would allow the same packet from the other stream to reach the
receiver because the chances that the same packet is lost in receiver because the chances that the same packet is lost in
transit again is often small. This is what is also known as transit again is often small. This is what is also known as
Time-shifted Redundancy, Temporal Redundancy or simply Delayed Time-shifted Redundancy, Temporal Redundancy or simply Delayed
Duplication [I-D.begen-mmusic-temporal-interleaving] [IC2011]. Duplication [I-D.begen-mmusic-temporal-interleaving] [IC2011].
This approach can be used with all three types of dual streaming This approach can be used with both types of dual streaming,
described in Section 3.1, Section 3.2.1 and Section 3.2.2. described in Section 3.1 and Section 3.2.
2. If the two streams have different IP headers, an additional 2. If the two streams have different IP headers, an additional
opportunity arises in that one is able to build a network, with opportunity arises in that one is able to build a network, with
physically diverse paths, to deliver the two streams concurrently physically diverse paths, to deliver the two streams concurrently
to the intended receivers. This reduces the delay when packet to the intended receivers. This reduces the delay when packet
loss occurs and needs to be recovered. Additionally, it also loss occurs and needs to be recovered. Additionally, it also
further reduces chances for packet loss. An unrecoverable loss further reduces chances for packet loss. An unrecoverable loss
happens only when two network failures happen in such a way that happens only when two network failures happen in such a way that
the same packet is affected on both paths. This is referred to the same packet is affected on both paths. This is referred to
as Spatial Diversity or Spatial Redundancy [IC2011]. The as Spatial Diversity or Spatial Redundancy [IC2011]. The
techniques used to build diverse paths are beyond the scope of techniques used to build diverse paths are beyond the scope of
this document. this document.
Note that spatial redundancy often offers less delay in Note that spatial redundancy often offers less delay in
recovering from packet loss provided that the forwarding delay of recovering from packet loss provided that the forwarding delay of
the network paths are more or less the same. For both temporal the network paths are more or less the same. For both temporal
and spatial redundancy approaches, packet misordering might still and spatial redundancy approaches, packet misordering might still
happen and needs to be handled using the RTP sequence numbers. happen and needs to be handled using the sequence numbers of some
sort (e.g., RTP sequence numbers).
To summarize, dual streaming allows an application and a network to To summarize, dual streaming allows an application and a network to
work together to provide a near zero-loss transport with a bounded or work together to provide a near zero-loss transport with a bounded or
minimum delay. The additional advantage includes a predictable minimum delay. The additional advantage includes a predictable
bandwidth overhead that is proportional to the minimum bandwidth bandwidth overhead that is proportional to the minimum bandwidth
needed for the multimedia session, but independent of the number of needed for the multimedia session, but independent of the number of
receivers experiencing a packet loss and requesting a retransmission. receivers experiencing a packet loss and requesting a retransmission.
For a survey and comparison of similar approaches, refer to [IC2011]. For a survey and comparison of similar approaches, refer to [IC2011].
4. Use of RTP and RTCP with Temporal Redundancy 4. Use of RTP and RTCP with Temporal Redundancy
To achieve temporal redundancy, the main and redundant RTP streams To achieve temporal redundancy, the main and redundant RTP streams
are sent using the same source and destination IP addresses and ports MUST be sent using the same 5-tuple of transport protocol, source and
(that is the 5-tuple of transport protocol, source and destination IP destination IP addresses, and source and destination transport ports.
addresses, and source and destination transport ports is the same for This is perhaps overly restrictive, but with the possible presence of
both main and redundant RTP streams). This is perhaps overly network address and port translation (NAPT) devices, using anything
restrictive, but with the possible presence of network address and other than an identical 5-tuple can also cause spatial redundancy.
port translation (NAPT) devices, using anything other than an
identical 5-tuple can also cause spatial redundancy.
Since main and redundant RTP streams follow an identical path, they Since main and redundant RTP streams follow an identical path, they
are part of the same RTP session. Accordingly, the sender MUST are part of the same RTP session. Accordingly, the sender MUST
choose a different SSRC for the redundant RTP stream than it chose choose a different SSRC for the redundant RTP stream than it chose
for the main RTP stream, following the rules in [RFC3550] section 8. for the main RTP stream, following the rules in [RFC3550] Section 8.
4.1. RTCP Considerations 4.1. RTCP Considerations
If RTCP is being sent for the main RTP stream, then the sender MUST If RTCP is being sent for the main RTP stream, then the sender MUST
also generate RTCP for the redundant RTP stream. The RTCP for the also generate RTCP for the redundant RTP stream. The RTCP for the
redundant RTP stream is generated exactly as-if the redundant RTP redundant RTP stream is generated exactly as-if the redundant RTP
stream were a regular media stream; the sender MUST NOT duplicate the stream were a regular media stream. The sender MUST NOT duplicate
RTCP packets sent for the main RTP stream. The sender MUST use the the RTCP packets sent for the main RTP stream when sending the
same RTCP CNAME in the RTCP reports it sends for the main and duplicate stream, instead it MUST generate new RTCP reports for the
redundant streams, so that the receiver can synchronize them. duplicate stream. The sender MUST use the same RTCP CNAME in the
RTCP reports it sends for the main and redundant streams, so that the
Both main and redundant streams, and their corresponding RTCP, will receiver can synchronize them.
be received. If RTCP is used, receivers MUST generate RTCP reports
for both main and redundant streams in the usual way, treating them
as entirely separate media streams.
Editor's note: The receiving node can also produce a new XR report Both the main and redundant RTP streams, and their corresponding RTCP
to report on the (loss/delay/jitter/etc.) performance of the output reports, will be received. If RTCP is used, receivers MUST generate
stream after the stream merging process. This is TBD. RTCP reports for both main and redundant streams in the usual way,
treating them as entirely separate media streams.
4.2. Signaling Considerations 4.2. Signaling Considerations
Signaling is needed to allow the receiver to determine that an RTP Signaling is needed to allow the receiver to determine that an RTP
stream is a redundant copy of another, rather than a separate stream stream is a redundant copy of another, rather than a separate stream
that needs to be rendered in parallel. We need an SDP attribute to that needs to be rendered in parallel. There are two parts to this:
ensure that the receiver supports temporal redundancy, plus a new an SDP extension is needed in the offer/answer exchange to negotiate
RTCP SDES item to indicate that this is a redundant stream that support for temporal redundancy; and signalling is needed to indicate
should not be directly rendered. which stream is the duplicate (the latter can be done in-band using
an RTCP extension, or out-of-band by signalling the SSRCs used by the
duplicate streams in SDP).
Editor's notes: We require out-of-band signalling for both features. The required
SDP attribute to signal duplication in the SDP offer/answer exchange
('duplication-delay') is defined in
[I-D.begen-mmusic-temporal-interleaving]. The required SDP grouping
semantics are defined in [I-D.begen-mmusic-redundancy-grouping].
o How should we correlate the duplicate streams? Grouping is In the following SDP example, a video stream is duplicated, and the
straightforward when streams are SSRC-muxed but what if there are main and redundant streams are transmitted in two separate SSRCs
non-duplicated RTP streams in the same session? Maybe also use (1000 and 1010):
Magnus' srcname proposal?
The required SDP grouping semantics and SDP attribute have been v=0
defined in [I-D.begen-mmusic-redundancy-grouping] and o=ali 1122334455 1122334466 IN IP4 dup.example.com
[I-D.begen-mmusic-temporal-interleaving], respectively. s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:100
a=mid:Group1
It is RECOMMENDED that the SSRC listed first in the "a=ssrc-group:"
line is sent first, with the other RTP SSRC being the time-delayed
duplicate. This is not critical, however, and receivers should size
their playout buffers based on the "a=duplication-delay:" attribute,
and play the stream that arrives first in preference, with the other
stream acting as a repair stream, irrespective of the order in which
they are signalled.
5. Use of RTP and RTCP with Spatial Redundancy 5. Use of RTP and RTCP with Spatial Redundancy
When using spatial redundancy, the redundant RTP stream is sent on When using spatial redundancy, the redundant RTP stream is sent on
using a different source and/or destination address/port pair. This using a different source and/or destination address/port pair. This
will be a separate RTP session to the session conveying the main RTP will be a separate RTP session to the session conveying the main RTP
stream. stream.
SSRC for the redundant stream chosen randomly, following the rules in The SSRCs used for the main and redundant streams MUST be chosen
Section 8 of [RFC3550] and will almost certainly not match that of randomly, following the rules in Section 8 of [RFC3550].
the main RTP stream. Sender MUST use the same RTCP CNAME for both Accordingly, they will almost certainly not match each other. The
main and redundant streams, in their separate sessions. Also the sender MUST, however, use the same RTCP CNAME for both the main and
sender uses the new SDES item to indicate that this is a redundant redundant streams, and MUST include an "a=ssrc:... srcname:..."
stream. This is how the receiver can correlate the flows (can use attribute to correlate the flows. An "a=group:DUP" attribute is used
srcname if appropriate). to indicate duplication.
5.1. RTCP Considerations 5.1. RTCP Considerations
If RTCP is being sent for the main RTP stream, then the sender MUST If RTCP is being sent for the main RTP stream, then the sender MUST
also generate RTCP for the redundant RTP stream. The RTCP for the also generate RTCP for the redundant RTP stream. The RTCP for the
redundant RTP stream is generated exactly as-if the redundant RTP redundant RTP stream is generated exactly as-if the redundant RTP
stream were a regular media stream; the sender MUST NOT duplicate the stream were a regular media stream; the sender MUST NOT duplicate the
RTCP packets sent for the main RTP stream. The sender MUST use the RTCP packets sent for the main RTP stream. The sender MUST use the
same RTCP CNAME in the RTCP reports it sends for the main and same RTCP CNAME in the RTCP reports it sends for the main and
redundant streams, so that the receiver can synchronize them. redundant streams, so that the receiver can synchronize them.
The main and redundant streams are conceptually synchronised using
the standard RTCP SR-based mechanism, deriving a mapping between
their timelines. The RTP timestamps and sequence numbers SHOULD be
identical in the main and redundant streams, however, making the
mapping trivial in most cases.
Both main and redundant streams, and their corresponding RTCP, will Both main and redundant streams, and their corresponding RTCP, will
be received. If RTCP is used, receivers MUST generate RTCP reports be received. If RTCP is used, receivers MUST generate RTCP reports
for both main and redundant streams in the usual way, treating them for both main and redundant streams in the usual way, treating them
as entirely separate media streams. as entirely separate media streams.
Editor's note: The receiving node can also produce a new XR report
to report on the (loss/delay/jitter/etc.) performance of the output
stream after the stream merging process. This is TBD.
5.2. Signaling Considerations 5.2. Signaling Considerations
The required SDP grouping semantics and SDP attribute have been The required SDP grouping semantics have been defined in
defined in [I-D.begen-mmusic-redundancy-grouping] and [I-D.begen-mmusic-redundancy-grouping]. In the following example,
[I-D.begen-mmusic-temporal-interleaving], respectively. the redundant streams have different IP destination addresses. The
example shows the same UDP port number and IP source addresses, but
either or both could have been different for the two streams.
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1000 srcname:45:a8:f4:19:b4:c3
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=ssrc:1010 cname:ch1@example.com
a=ssrc:1010 srcname:45:a8:f4:19:b4:c3
a=mid:S1b
6. Use of RTP and RTCP with Temporal and Spatial Redundancy 6. Use of RTP and RTCP with Temporal and Spatial Redundancy
Editor's note: Nothing new here. This should use the same RTP/RTCP This uses the same RTP/RTCP mechanisms, plus a combination of both
mechanisms, plus a combination of both sets of signaling. sets of signaling.
7. Security Considerations 7. Security Considerations
The security considerations of [RFC3550] apply to this memo. The security considerations of [RFC3550],
[I-D.begen-mmusic-temporal-interleaving], and
Additional security considerations are TBC. [I-D.begen-mmusic-redundancy-grouping] apply.
Editor's note: Email from csp. For the stream de-duplication If stream de-duplication is done by an in-network middlebox, rather
device: it seems that this would work with SRTP encryption than by an end system, that middlebox can work if Secure RTP (SRTP)
[RFC3711], since the headers are in the clear, but would break the encryption is used [RFC3711], since the RTP headers are in the clear.
authentication when the SSRC is rewritten. You could just re- Doing so would break the authentication when the SSRC is rewritten,
authenticate the packets, and avoid re-encryption, with appropriate unless the de-duplication middlebox were trusted to re-authenticate
signaling of who authenticates the packets. the packets. This would require additional signalling which is not
specified here, since de-duplication in the receiver end system is
expected to be the more common use case.
8. IANA Considerations 8. IANA Considerations
TBC. No IANA actions are required.
9. Acknowledgments 9. Acknowledgments
Thanks to Magnus Westerlund for his suggestions. Thanks to Magnus Westerlund for his suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 9, line 25 skipping to change at page 10, line 45
10.2. Informative References 10.2. Informative References
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of
Streaming Media", RFC 2354, June 1998. Streaming Media", RFC 2354, June 1998.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils,
"Toward Lossless Video Transport (to appear in IEEE "Toward Lossless Video Transport (to appear in IEEE
Internet Computing)", November 2011. Internet Computing)", November 2011.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Cisco
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
 End of changes. 41 change blocks. 
149 lines changed or deleted 202 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/