draft-ietf-avt-rapid-acquisition-for-rtp-03.txt   draft-ietf-avt-rapid-acquisition-for-rtp-04.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: March 8, 2010 T. VanCaenegem Expires: April 11, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
September 4, 2009 October 8, 2009
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-03 draft-ietf-avt-rapid-acquisition-for-rtp-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 8, 2010. This Internet-Draft will expire on April 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 7 skipping to change at page 3, line 7
multicast stream. This unicast RTP flow may be transmitted at a multicast stream. This unicast RTP flow may be transmitted at a
faster than natural rate to further accelerate the acquisition. The faster than natural rate to further accelerate the acquisition. The
motivating use case for this capability is multicast applications motivating use case for this capability is multicast applications
that carry real-time compressed audio and video. However, the that carry real-time compressed audio and video. However, the
proposed method can also be used in other types of multicast proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a applications where the acquisition delay is long enough to be a
problem. problem.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Elements of Delay in Multicast Applications . . . . . . . . . 7 4. Elements of Delay in Multicast Applications . . . . . . . . . 8
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 9 Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 11 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 20 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 21
6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 23
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 23 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 24
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 24 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 25
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 24 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 25
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 26
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 27 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 28
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 29 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 30
8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 30 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 31
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 30 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 33 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 34
10. Known Implementations . . . . . . . . . . . . . . . . . . . . 34 10. Known Implementations . . . . . . . . . . . . . . . . . . . . 35
10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 34 10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 35
10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 35 10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 36
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36
12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 37 13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 38
13.2. Registration of SDP Attribute Values . . . . . . . . . . . 37 13.2. Registration of SDP Attribute Values . . . . . . . . . . . 38
13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 37 13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 39
13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 38 13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 39
13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 38 13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 40
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 13.6. RAMS Response Code Space Registry . . . . . . . . . . . . 40
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 40 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 40 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 42
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 40 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 42
15.4. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 40 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 42
15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 40 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 43
15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 41 15.5. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 43
15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 41 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 43
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 43
16.1. Normative References . . . . . . . . . . . . . . . . . . . 42 15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 44
16.2. Informative References . . . . . . . . . . . . . . . . . . 43 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 16.1. Normative References . . . . . . . . . . . . . . . . . . . 44
16.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Certain Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document processing any data sent in the multicast session. This document
refers to this information as Reference Information. The Reference refers to this information as Reference Information. The Reference
Information is conventionally sent periodically in the multicast Information is conventionally sent periodically in the multicast
session and usually consists of items such as a description of the session and usually consists of items such as a description of the
schema for the rest of the data, references to which data to process, schema for the rest of the data, references to which data to process,
skipping to change at page 7, line 43 skipping to change at page 8, line 43
consuming a media stream. The meaning, format and size of this consuming a media stream. The meaning, format and size of this
information are specific to the application and are out of scope of information are specific to the application and are out of scope of
this document. this document.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference packets that enable an RTP receiver to rapidly acquire the Reference
Information. The burst stream is typically transmitted at an Information. The burst stream is typically transmitted at an
accelerated rate. accelerated rate.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst stream. the retransmission packets and the burst stream. RS may also
generate other non-retransmission packets to aid the RAMS process.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In an any-source (ASM) or a single-source (SSM) multicast delivery In an any-source (ASM) or a single-source (SSM) multicast delivery
system, there are three major elements that contribute to the overall system, there are three major elements that contribute to the overall
acquisition delay when an RTP receiver switches from one multicast acquisition delay when an RTP receiver switches from one multicast
session to another one. These are: session to another one. These are:
o Multicast switching delay o Multicast switching delay
skipping to change at page 17, line 29 skipping to change at page 18, line 29
message and it is RECOMMENDED that the RAMS-I message is sent message and it is RECOMMENDED that the RAMS-I message is sent
early enough in the session to be useful. If RS rejects the early enough in the session to be useful. If RS rejects the
request, this field SHALL NOT exist in the RAMS-I message. request, this field SHALL NOT exist in the RAMS-I message.
It is RECOMMENDED to include a sender report with the RAMS-I It is RECOMMENDED to include a sender report with the RAMS-I
message in the same compound RTCP packet. This allows rapid message in the same compound RTCP packet. This allows rapid
synchronization among multiple RTP flows synchronization among multiple RTP flows
[I-D.ietf-avt-rapid-rtp-sync]. [I-D.ietf-avt-rapid-rtp-sync].
The unicast burst duration MAY be calculated by RS, and its value The unicast burst duration MAY be calculated by RS, and its value
MAY be updated by messages received from RR. The join time MAY be updated by messages received from RR. If RS accepts the
information (for the new multicast session) SHOULD be populated request, the join time information (for the new multicast
in at least one of the RAMS-I messages. Note that RS MAY send session) MUST be populated in at least one of the RAMS-I
the RAMS-I message after a significant delay, so RR SHOULD NOT messages. If RS rejects the request, including the join time
make protocol dependencies on quickly receiving an RAMS-I information in a RAMS-I message is OPTIONAL.
message.
RS MAY send the RAMS-I message after a significant delay, so RR
SHOULD NOT make protocol dependencies on quickly receiving an
RAMS-I message.
3. Unicast Burst: If the request is accepted, RS starts sending the 3. Unicast Burst: If the request is accepted, RS starts sending the
unicast burst that comprises one or more RTP retransmission unicast burst that comprises one or more RTP retransmission
packets (The burst packet(s) are sent by the Burst/Retransmission packets (The burst packet(s) are sent by the Burst/Retransmission
Source logical entity). In addition, there MAY be optional Source logical entity). In addition, there MAY be optional
payload-specific information that RS chooses to send to RR. Such payload-specific information that RS chooses to send to RR. Such
an example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] an example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble]
for transmitting the payload-specific information for MPEG2 for transmitting the payload-specific information for MPEG2
Transport Streams. Transport Streams.
skipping to change at page 27, line 39 skipping to change at page 28, line 41
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of this RAMS-I message. During rapid the sequence number of this RAMS-I message. During rapid
acquisition, multiple RAMS-I messages MAY be sent and/or the same acquisition, multiple RAMS-I messages MAY be sent and/or the same
RAMS-I message MAY be repeated. The first RAMS-I message SHALL RAMS-I message MAY be repeated. The first RAMS-I message SHALL
have an MSN value of 0. This value SHALL NOT be changed if the have an MSN value of 0. This value SHALL NOT be changed if the
same RAMS-I message is sent to the same RR multiple times for same RAMS-I message is sent to the same RR multiple times for
redundancy purposes. If a new information is conveyed in a new redundancy purposes. If a new information is conveyed in a new
RAMS-I message, the MSN value SHALL be incremented by one. RAMS-I message, the MSN value SHALL be incremented by one.
o Response (16 bits): Mandatory field that denotes the RS response o Response (16 bits): Mandatory field that denotes the RS response
code for this RAMS-I message. code for this RAMS-I message. This document defines several
initial response codes and registers them with IANA. If a new
Editor's note: HTTP/SIP-like response codes will be defined and vendor-neutral response code will be defined, it MUST be
registered with IANA in a later version. registered with IANA through the guidelines specified in
Section 13.6. If the new response code is intended to be used
privately by a vendor, there is no need for IANA management.
Instead, the vendor MUST use the private extension mechanism
(Section 7.1.2) to convey its message and MUST indicate this by
putting zero in the Response field.
o RTP Seqnum of the First Packet (16 bits): TLV element that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent in the retransmission session. This allows RR to know sent in the retransmission session. This allows RR to know
whether one or more packets sent by RS have been dropped at the whether one or more packets sent by RS have been dropped at the
beginning of the retransmission session. If RS accepts the RAMS beginning of the retransmission session. If RS accepts the RAMS
request, this element MUST exist. If RS rejects the RAMS request, request, this element MUST exist. If RS rejects the RAMS request,
this element SHALL NOT exist. this element SHALL NOT exist.
Type: 31 Type: 31
o Earliest Multicast Join Time (32 bits): Optional TLV element that o Earliest Multicast Join Time (32 bits): Optional TLV element that
specifies the time difference (i.e., delta time) between the specifies the time difference (i.e., delta time) between the
arrival of this RAMS-I message and the earliest time instant when arrival of this RAMS-I message and the earliest time instant when
RR could join the primary multicast session in RTP ticks. A zero RR could join the primary multicast session in RTP ticks. A zero
value in this field means that RR can join the primary multicast value in this field means that RR can join the primary multicast
session right away. session right away.
Note that if the RAMS request has been accepted, RS SHOULD send Note that if the RAMS request has been accepted, RS MUST send this
this field at least once, so that RR knows when to join the field at least once, so that RR knows when to join the primary
primary multicast session. If the burst request has been rejected multicast session. If the burst request has been rejected as
as indicated in the Response field, this field MAY be omitted or indicated in the Response field, this field MAY be omitted or set
set to 0. In that case, it is up to RR when or whether to join to 0. In that case, it is up to RR when or whether to join the
the primary multicast session. primary multicast session.
Type: 32 Type: 32
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst that RS is planning to send (in RTP ticks). duration of the burst that RS is planning to send (in RTP ticks).
In the absence of additional stimulus, RS will send a burst of In the absence of additional stimulus, RS will send a burst of
this duration. However, the burst duration may be modified by this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast subsequent events, including changes in the primary multicast
stream and reception of RAMS-T messages. stream and reception of RAMS-T messages.
skipping to change at page 30, line 43 skipping to change at page 31, line 46
description, RR MAY send updated requests. RS may or may not be able description, RR MAY send updated requests. RS may or may not be able
to accept value changes in every field in an RAMS-R message. to accept value changes in every field in an RAMS-R message.
However, if the 'rams-updates' attribute is not included in the SDP However, if the 'rams-updates' attribute is not included in the SDP
description, RR SHALL NOT send updated requests (RR MAY repeat its description, RR SHALL NOT send updated requests (RR MAY repeat its
initial request without changes, though). initial request without changes, though).
8.2. Examples 8.2. Examples
This section provides a declarative SDP [RFC4566] example for This section provides a declarative SDP [RFC4566] example for
enabling rapid acquisition of multicast RTP sessions. The following enabling rapid acquisition of multicast RTP sessions. The following
example uses the SDP grouping semantics [RFC3388], the RTP/AVPF example uses the SDP grouping semantics [I-D.ietf-mmusic-rfc3388bis],
profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP the RTP/AVPF profile [RFC4585], the RTP retransmissions [RFC4588],
extensions for SSM sessions with unicast feedback the RTCP extensions for SSM sessions with unicast feedback
[I-D.ietf-avt-rtcpssm] and the source-specific media attributes [I-D.ietf-avt-rtcpssm] and the source-specific media attributes
[I-D.ietf-mmusic-sdp-source-attributes]. [RFC5576].
In the example shown Figure 9, we have a primary multicast stream and In the example shown Figure 9, we have a primary multicast stream and
a unicast retransmission stream. The source stream is multicast from a unicast retransmission stream. The source stream is multicast from
a distribution source (with a source IP address of 192.0.2.2) to the a distribution source (with a source IP address of 192.0.2.2) to the
multicast destination address of 233.252.0.2 and port 41000. A multicast destination address of 233.252.0.2 and port 41000. A
Retransmission Server including feedback target functionality (with Retransmission Server including feedback target functionality (with
an address of 192.0.2.1 and port of 41001) is specified with the an address of 192.0.2.1 and port of 41001) is specified with the
'rtcp' attribute. The RTP receiver(s) can report missing packets on 'rtcp' attribute. The RTP receiver(s) can report missing packets on
the source stream to the feedback target and request retransmissions. the source stream to the feedback target and request retransmissions.
In the RAMS context, the parameter 'rtx-time' specifies the time in In the RAMS context, the parameter 'rtx-time' specifies the time in
skipping to change at page 31, line 38 skipping to change at page 32, line 43
When an RTP receiver requires rapid acquisition for a new multicast When an RTP receiver requires rapid acquisition for a new multicast
session it wants to join, it sends an RAMS-R message to the feedback session it wants to join, it sends an RAMS-R message to the feedback
target of that primary multicast session. This feedback message has target of that primary multicast session. This feedback message has
to have the SSRC of the primary multicast stream for which rapid to have the SSRC of the primary multicast stream for which rapid
acquisition is requested for. However, since this RTP receiver has acquisition is requested for. However, since this RTP receiver has
not received any RTP packets from the primary multicast session yet, not received any RTP packets from the primary multicast session yet,
the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute
of the media description [I-D.ietf-avt-rtcpssm]. In addition to the of the media description [I-D.ietf-avt-rtcpssm]. In addition to the
SSRC value, the 'cname' source attribute MUST also be present in the SSRC value, the 'cname' source attribute MUST also be present in the
SDP description [I-D.ietf-mmusic-sdp-source-attributes]. SDP description [RFC5576].
Note that listing the SSRC values for the primary multicast sessions Note that listing the SSRC values for the primary multicast sessions
in the SDP file does not create a problem in SSM sessions when an in the SDP file does not create a problem in SSM sessions when an
SSRC collision occurs. This is because in SSM sessions, an RTP SSRC collision occurs. This is because in SSM sessions, an RTP
receiver that observed an SSRC collision with a media source MUST receiver that observed an SSRC collision with a media source MUST
change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules
defined in [RFC3550]. defined in [RFC3550].
A feedback target that receives an RAMS-R feedback message becomes A feedback target that receives an RAMS-R feedback message becomes
aware that the prediction chain at the RTP receiver side has been aware that the prediction chain at the RTP receiver side has been
skipping to change at page 33, line 37 skipping to change at page 34, line 37
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp:41003 a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=mid:4 a=mid:4
Figure 10: Example SDP for RR when RAMS support is enabled Figure 10: Example SDP for RR when RAMS support is enabled
The offer/answer model considerations [RFC3264] for the 'rtcp-fb' The offer/answer model considerations [RFC3264] for the 'rtcp-fb'
attribute are provided in Section 4.2 of [RFC4585]. attribute are provided in Section 4.2 of [RFC4585].
In this section, we considered the simplest scenario where the
primary multicast session carried only one multicast stream and the
RTP receiver wanted to rapidly acquire this stream only. Discussions
on scenarios and associated SDP examples where the primary multicast
session carries two or more multicast streams or the RTP receiver
wants to acquire one or more multicast streams from multiple
multicast RTP sessions at the same time are presented in
[I-D.begen-avt-rams-scenarios].
9. NAT Considerations 9. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) are expected to exist between RR and RS. NATs have a called NAT) are expected to exist between RR and RS. NATs have a
variety of operating characteristics for UDP traffic [RFC4787]. For variety of operating characteristics for UDP traffic [RFC4787]. For
a NAT to permit traffic from RS to arrive at RR, the NAT(s) must a NAT to permit traffic from RS to arrive at RR, the NAT(s) must
first either: first either:
a. See UDP traffic sent from RR (which is on the 'inside' of the a. See UDP traffic sent from RR (which is on the 'inside' of the
NAT) to RS (which is on the 'outside' of the NAT). This traffic NAT) to RS (which is on the 'outside' of the NAT). This traffic
skipping to change at page 34, line 25 skipping to change at page 35, line 34
a STUN [RFC5389] message from RR to the RTP port of RS which will be a STUN [RFC5389] message from RR to the RTP port of RS which will be
used for incoming RTP traffic. If RTP/RTCP multiplexing on a single used for incoming RTP traffic. If RTP/RTCP multiplexing on a single
port [I-D.ietf-avt-rtp-and-rtcp-mux] is not supported by RR, it will port [I-D.ietf-avt-rtp-and-rtcp-mux] is not supported by RR, it will
need to send a second STUN message to the RTCP port of RS which will need to send a second STUN message to the RTCP port of RS which will
be used for incoming RTCP traffic. If RTP/RTCP multiplexing is be used for incoming RTCP traffic. If RTP/RTCP multiplexing is
supported by RR, it only needs to learn one port. RS receives the supported by RR, it only needs to learn one port. RS receives the
STUN message(s) and responds to them. RR now knows the UDP ports STUN message(s) and responds to them. RR now knows the UDP ports
from the perspective of RS. from the perspective of RS.
Editor's note: The issues related to using ports across multicast Editor's note: The issues related to using ports across multicast
and unicast RTP sessions will be discussed in a separate draft and and unicast RTP sessions are discussed in
the current document will normatively reference that document. The [I-D.begen-avt-ports-for-ucast-mcast-rtp]. The updated text for this
updated text for this section will be provided in a later version. section will be provided in a later version.
10. Known Implementations 10. Known Implementations
10.1. Open Source RTP Receiver Implementation by Cisco 10.1. Open Source RTP Receiver Implementation by Cisco
An open source RTP Receiver code that implements the functionalities An open source RTP Receiver code that implements the functionalities
introduced in this document is available. For documentation, visit introduced in this document is available. For documentation, visit
the following URL: the following URL:
http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_4/user/guide/ http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_4/user/guide/
skipping to change at page 35, line 18 skipping to change at page 36, line 27
the Microsoft Mediaroom Internet Protocol Television (IPTV) and the Microsoft Mediaroom Internet Protocol Television (IPTV) and
multimedia software platform. This system is in wide commercial multimedia software platform. This system is in wide commercial
deployment. More information can be found at: deployment. More information can be found at:
http://www.microsoft.com/mediaroom http://www.microsoft.com/mediaroom
http://informitv.com/articles/2008/10/13/channelchangetimes/ http://informitv.com/articles/2008/10/13/channelchangetimes/
11. Open Issues 11. Open Issues
o Discussion of acquisition for the individual RTP streams vs. the o Updating the NAT section and SDP examples.
whole RTP session.
o Updating the NAT section.
o Response/status codes for RAMS.
12. Security Considerations 12. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the
payload format defined in [RFC4588]. Thus, these applications are payload format defined in [RFC4588]. Thus, these applications are
subject to the general security considerations discussed in subject to the general security considerations discussed in
[I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an [I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an
overview of the guidelines and suggestions described in these overview of the guidelines and suggestions described in these
specifications from a RAMS perspective. We also discuss the security specifications from a RAMS perspective. We also discuss the security
skipping to change at page 39, line 30 skipping to change at page 40, line 41
Any registration for an unassigned Type value MUST contain the Any registration for an unassigned Type value MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it shall be interpreted. how it shall be interpreted.
13.6. RAMS Response Code Space Registry
This document creates a new IANA TLV space registry for the RAMS
response codes. The registry is called the RAMS Response Code Space
Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226].
The length of the Response field is two octets, allowing 65536 codes.
However, the response codes have been classified and registered
following an HTTP-style code numbering in this document. New
response codes SHALL follow the guidelines below:
Code Level Purpose
---------- ---------------
1xx Informational
2xx Success
3xx Redirection
4xx RTP Receiver Error
5xx Retransmission Server Error
The Response code 65536 is reserved for future use.
The registry is initialized with the following entries:
Code Description Reference
----- -------------------------------------------------- -------------
0 A private response code is included in the message [RFCXXXX]
100 Parameter update for RAMS session [RFCXXXX]
101 RAMS session was terminated by RAMS-T [RFCXXXX]
102 RAMS session was terminated by RS [RFCXXXX]
200 RAMS request has been accepted [RFCXXXX]
201 Unicast burst has been completed [RFCXXXX]
400 Invalid RAMS-R message syntax
401 Invalid min buffer requirement in RAMS-R message [RFCXXXX]
402 Invalid max buffer requirement in RAMS-R message [RFCXXXX]
403 Invalid max bw requirement in RAMS-R message [RFCXXXX]
500 An unspecified RS internal error has occurred [RFCXXXX]
501 RS has no bandwidth to start RAMS session [RFCXXXX]
502 RS has no CPU available to start RAMS session [RFCXXXX]
503 RAMS functionality is not available on RS [RFCXXXX]
504 RAMS functionality is not available for RR [RFCXXXX]
505 RAMS functionality is not available for
the requested multicast stream [RFCXXXX]
506 RS has no a valid starting point available for
the requested multicast stream [RFCXXXX]
507 RS has no reference information available for
the requested multicast stream [RFCXXXX]
Any registration for an unassigned Response code MUST contain the
following information:
o Contact information of the one doing the registration, including
at least name, address, and email.
o A detailed description of what the new Response code describes and
how it shall be interpreted.
14. Acknowledgments 14. Acknowledgments
The authors would like to specially thank Peilin Yang for his The authors would like to specially thank Peilin Yang for his
contributions to this document and detailed reviews. contributions to this document and detailed reviews.
The authors also thank the following individuals for their The authors also thank the following individuals for their
contributions, comments and suggestions to this document: Dave Oran, contributions, comments and suggestions to this document: Dave Oran,
Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin,
Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan
Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and
Sean Sheedy. Sean Sheedy.
15. Change Log 15. Change Log
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-03
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-04
The following are the major changes compared to version 02:
o Clarifications for the definition of RS.
o Response codes have been defined.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o Clarifications for the RAMS-I message. o Clarifications for the RAMS-I message.
o Type values have been assigned. o Type values have been assigned.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-02 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Port mapping discussion has been removed since it will be o Port mapping discussion has been removed since it will be
discussed in a separate draft. discussed in a separate draft.
o Security considerations section has been added. o Security considerations section has been added.
o Burst shaping section has been completed. o Burst shaping section has been completed.
o Most of the outstanding open issues have been addressed. o Most of the outstanding open issues have been addressed.
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-01 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o Formal definitions of vendor-neutral and private extensions and o Formal definitions of vendor-neutral and private extensions and
their IANA registries have been added. their IANA registries have been added.
o SDP examples were explained in more detail. o SDP examples were explained in more detail.
o The sub-FMT field has been introduced in the RAMS messages for o The sub-FMT field has been introduced in the RAMS messages for
message type identification. message type identification.
o Some terminology has been fixed. o Some terminology has been fixed.
o NAT considerations section has been added. o NAT considerations section has been added.
15.4. draft-ietf-avt-rapid-acquisition-for-rtp-00 15.5. draft-ietf-avt-rapid-acquisition-for-rtp-00
This is a resubmission of version 03 as a WG item. This is a resubmission of version 03 as a WG item.
15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-03 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o The title and message names have been changed. o The title and message names have been changed.
o RTCP message semantics have been added. RAMS protocol has been o RTCP message semantics have been added. RAMS protocol has been
revised to handle updated requests and responses. revised to handle updated requests and responses.
o Definitions have been revised. o Definitions have been revised.
o RTP/RTCP muxing reference has been added. o RTP/RTCP muxing reference has been added.
15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-02 15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o The discussion around MPEG2-TS has been moved to another document. o The discussion around MPEG2-TS has been moved to another document.
o The RAMS-R, RAMS-I and RAMS-T messages have been extensively o The RAMS-R, RAMS-I and RAMS-T messages have been extensively
modified and they have been made mandatory. modified and they have been made mandatory.
o IANA Considerations section has been updated. o IANA Considerations section has been updated.
o The discussion of RTCP XR report has been moved to another o The discussion of RTCP XR report has been moved to another
document. document.
o A new section on protocol design considerations has been added. o A new section on protocol design considerations has been added.
15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-01 15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o The core of the rapid synchronization method is now payload- o The core of the rapid synchronization method is now payload-
independent. But, the draft still defines payload-specific independent. But, the draft still defines payload-specific
messages that are required for enabling rapid synch for the RTP messages that are required for enabling rapid synch for the RTP
flows carrying MPEG2-TS. flows carrying MPEG2-TS.
o RTCP APP packets have been removed, new RTCP transport-layer and o RTCP APP packets have been removed, new RTCP transport-layer and
payload-specific feedback messages have been defined. payload-specific feedback messages have been defined.
skipping to change at page 42, line 28 skipping to change at page 45, line 11
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006.
[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.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [I-D.ietf-mmusic-rfc3388bis]
Schulzrinne, "Grouping of Media Lines in the Session Camarillo, G., "The SDP (Session Description Protocol)
Description Protocol (SDP)", RFC 3388, December 2002. Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work
in progress), July 2009.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[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.
[I-D.ietf-avt-rtcpssm] [I-D.ietf-avt-rtcpssm]
Schooler, E., Ott, J., and J. Chesterfield, "RTCP Schooler, E., Ott, J., and J. Chesterfield, "RTCP
Extensions for Single-Source Multicast Sessions with Extensions for Single-Source Multicast Sessions with
Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in
progress), March 2009. progress), March 2009.
[I-D.ietf-mmusic-sdp-source-attributes] [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work (SDP)", RFC 5576, June 2009.
in progress), October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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,
June 2002. June 2002.
[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.
[I-D.begen-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-begen-avt-ports-for-ucast-mcast-rtp-00 (work in
progress), September 2009.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
16.2. Informative References 16.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.ietf-rmt-pi-norm-revised] [I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., London, U., and J. Macker, Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast Transport Protocol", "NACK-Oriented Reliable Multicast Transport Protocol",
draft-ietf-rmt-pi-norm-revised-13 (work in progress), draft-ietf-rmt-pi-norm-revised-14 (work in progress),
June 2009. September 2009.
[I-D.begen-avt-rams-scenarios]
Begen, A., "Considerations for RAMS Scenarios",
draft-begen-avt-rams-scenarios-00 (work in progress),
October 2009.
[I-D.begen-avt-rtp-mpeg2ts-preamble] [I-D.begen-avt-rtp-mpeg2ts-preamble]
Begen, A. and E. Friedrich, "RTP Payload Format for Begen, A. and E. Friedrich, "RTP Payload Format for
MPEG2-TS Preamble", MPEG2-TS Preamble",
draft-begen-avt-rtp-mpeg2ts-preamble-02 (work in draft-begen-avt-rtp-mpeg2ts-preamble-02 (work in
progress), August 2009. progress), August 2009.
[I-D.begen-avt-rapid-sync-rtcp-xr] [I-D.begen-avt-rapid-sync-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTCP XR", Block Type for RTCP XR",
draft-begen-avt-rapid-sync-rtcp-xr-02 (work in progress), draft-begen-avt-rapid-sync-rtcp-xr-02 (work in progress),
August 2009. August 2009.
[I-D.ietf-avt-rapid-rtp-sync] [I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in
progress), July 2009. progress), July 2009.
[I-D.westerlund-avt-ecn-for-rtp] [I-D.westerlund-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., and C. Perkins, "Explicit Westerlund, M., Johansson, I., Perkins, C., and K.
Congestion Notification (ECN) for RTP over UDP", Carlberg, "Explicit Congestion Notification (ECN) for RTP
draft-westerlund-avt-ecn-for-rtp-00 (work in progress), over UDP", draft-westerlund-avt-ecn-for-rtp-01 (work in
July 2009. progress), October 2009.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007. August 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
 End of changes. 31 change blocks. 
101 lines changed or deleted 196 lines changed or added

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