draft-ietf-avt-rapid-acquisition-for-rtp-13.txt   draft-ietf-avt-rapid-acquisition-for-rtp-14.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: February 27, 2011 T. VanCaenegem Expires: March 3, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
August 26, 2010 August 30, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-13 draft-ietf-avt-rapid-acquisition-for-rtp-14
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 February 27, 2011. This Internet-Draft will expire on March 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 3, line 19 skipping to change at page 3, line 19
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 9 4. Elements of Delay in Multicast Applications . . . . . . . . . 9
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10 Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 23 6.3. Synchronization of Primary Multicast Streams . . . . . . . 23
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 23 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 24
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 32 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 33
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 35 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 36
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 36 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 38
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 43 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 44
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 43 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 44
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 43 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 44
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 44 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 45
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46
11.6.1. Response Code Definitions . . . . . . . . . . . . . . 48 11.6.1. Response Code Definitions . . . . . . . . . . . . . . 49
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
14.1. Normative References . . . . . . . . . . . . . . . . . . . 49 14.1. Normative References . . . . . . . . . . . . . . . . . . . 51
14.2. Informative References . . . . . . . . . . . . . . . . . . 51 14.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. The Most multicast flows carry a stream of inter-related data. The
receivers need to acquire certain information to start processing any receivers need to acquire certain information to start processing any
data sent in the multicast session. This document refers to this data sent in the multicast session. This document refers to this
information as Reference Information. The Reference Information is information as Reference Information. The Reference Information is
conventionally sent periodically in the multicast session (although conventionally sent periodically in the multicast session (although
its content can change over time) and usually consists of items such its content can change over time) and usually consists of items such
as a description of the schema for the rest of the data, references as a description of the schema for the rest of the data, references
skipping to change at page 15, line 34 skipping to change at page 15, line 34
RTP_Rx cannot send an RTCP feedback message for a minimum of one RTP_Rx cannot send an RTCP feedback message for a minimum of one
second period after joining the session (i.e., Tmin=1.0 second). second period after joining the session (i.e., Tmin=1.0 second).
While this rule has the goal of avoiding problems associated with While this rule has the goal of avoiding problems associated with
flash crowds in typical multi-party sessions, it defeats the purpose flash crowds in typical multi-party sessions, it defeats the purpose
of rapid acquisition. Furthermore, when RTP receivers delay their of rapid acquisition. Furthermore, when RTP receivers delay their
messages requesting a burst by a deterministic or even a random messages requesting a burst by a deterministic or even a random
amount, it still does not make a difference since such messages are amount, it still does not make a difference since such messages are
not related and their timings are independent from each other. Thus, not related and their timings are independent from each other. Thus,
in this specification we initialize Tmin to zero and allow the RTP in this specification we initialize Tmin to zero and allow the RTP
receivers to send a burst request message right at the beginning. receivers to send a burst request message right at the beginning.
For the subsequent messages during rapid acquisition, the timing For the subsequent messages (e.g., updated requests) during rapid
rules of [RFC4585] still apply. acquisition, the timing rules of [RFC4585] still apply.
Figure 3 depicts an example of messaging flow for rapid acquisition. Figure 3 depicts an example of messaging flow for rapid acquisition.
The RTCP feedback messages are explained below. The optional The RTCP feedback messages are explained below. The optional
messages are indicated in parentheses and they might or might not be messages are indicated in parentheses and they might or might not be
present during rapid acquisition. In a scenario where rapid present during rapid acquisition. In a scenario where rapid
acquisition is performed by a feedback target co-located with the acquisition is performed by a feedback target co-located with the
media sender, the same method (with the identical message flows) media sender, the same method (with the identical message flows)
still applies. still applies.
------------------------- -------------------------
skipping to change at page 18, line 46 skipping to change at page 18, line 46
SSRC(s) that matched the RTP stream(s) it serves. The BRS MUST SSRC(s) that matched the RTP stream(s) it serves. The BRS MUST
reject all other requests with an appropriate response code. reject all other requests with an appropriate response code.
* Reject Responses: The BRS MUST take into account any * Reject Responses: The BRS MUST take into account any
limitations that may have been specified by the RTP_Rx in the limitations that may have been specified by the RTP_Rx in the
RAMS-R message when making a decision regarding the request. RAMS-R message when making a decision regarding the request.
If the RTP_Rx has requested to acquire the whole primary If the RTP_Rx has requested to acquire the whole primary
multicast RTP session but the BRS cannot provide a rapid multicast RTP session but the BRS cannot provide a rapid
acquisition service for any of the primary multicast streams, acquisition service for any of the primary multicast streams,
the BRS MUST reject the request via a single RAMS-I message the BRS MUST reject the request via a single RAMS-I message
with a collective reject response code and whose media sender with a collective reject response code, which is defined as
SSRC field is set to one of SSRCs served by this FT_Ap. Upon 510 in Section 11.6, and whose media sender SSRC field is set
receiving this RAMS-I message, the RTP_Rx abandons the rapid to one of SSRCs served by this FT_Ap. Upon receiving this
acquisition attempt and can immediately join the multicast RAMS-I message, the RTP_Rx abandons the rapid acquisition
session by sending an SFGMP Join message towards its upstream attempt and can immediately join the multicast session by
multicast router. sending an SFGMP Join message towards its upstream multicast
router.
In all other cases, the BRS MUST send a separate RAMS-I In all other cases, the BRS MUST send a separate RAMS-I
message with the appropriate response code for each primary message with the appropriate 5xx-level response code (as
multicast stream that has been requested by the RTP_Rx but defined in Section 11.6) for each primary multicast stream
cannot be served by the BRS. There could be multiple reasons that has been requested by the RTP_Rx but cannot be served by
why the BRS has rejected the request, however, the BRS the BRS. There could be multiple reasons why the BRS has
chooses the most appropriate response code to inform the rejected the request, however, the BRS chooses the most
RTP_Rx. appropriate response code to inform the RTP_Rx.
Upon receiving a reject response indicating a transient
problem such as insufficient BRS or network resources, if the
RTP_Rx wants to retry sending the same request, it MUST
follow the RTCP timer rules of [RFC4585] to allow the
transient problems go away. However, if the reject response
indicates a non-transient problem (such as the ones reported
by response codes 504, 505 and 506), the RTP_Rx MUST NOT
attempt a retry.
The BRS can employ a policing mechanism against the broken
RTP_Rx implementations that are not following these rules.
See Section 10 for details.
* Accept Responses: The BRS MUST send at least one separate * Accept Responses: The BRS MUST send at least one separate
RAMS-I message with the appropriate response code (either RAMS-I message with the appropriate response code (either
zero indicating a private response or a 2xx-level response zero indicating a private response or response code 200
code indicating success as listed in Section 11.6) for each indicating success as listed in Section 11.6) for each
primary multicast stream that has been requested by the primary multicast stream that has been requested by the
RTP_Rx and will be served by the BRS. Such RAMS-I messages RTP_Rx and will be served by the BRS. Such RAMS-I messages
comprise fields that can be used to describe the individual comprise fields that can be used to describe the individual
unicast burst streams. When there is a RAMS-R request for unicast burst streams. When there is a RAMS-R request for
multiple primary multicast streams, the BRS MUST include all multiple primary multicast streams, the BRS MUST include all
the individual RAMS-I messages corresponding to that RAMS-R the individual RAMS-I messages corresponding to that RAMS-R
request in the same compound RTCP packet if these messages request in the same compound RTCP packet if these messages
fit in the same packet. fit in the same packet.
The RAMS-I message carries the RTP sequence number of the The RAMS-I message carries the RTP sequence number of the
skipping to change at page 19, line 48 skipping to change at page 20, line 15
receiving RTP packets before receiving a RAMS-I message. An receiving RTP packets before receiving a RAMS-I message. An
RTP-RX implementation MUST NOT assume it will quickly receive RTP-RX implementation MUST NOT assume it will quickly receive
the initial RAMS-I message. For redundancy purposes, it is the initial RAMS-I message. For redundancy purposes, it is
RECOMMENDED that the BRS repeats the RAMS-I messages multiple RECOMMENDED that the BRS repeats the RAMS-I messages multiple
times as long as it follows the RTCP timer rules defined in times as long as it follows the RTCP timer rules defined in
[RFC4585]. [RFC4585].
4. Unicast Burst: For the primary multicast stream(s) for which 4. Unicast Burst: For the primary multicast stream(s) for which
the request is accepted, the BRS starts sending the unicast the request is accepted, the BRS starts sending the unicast
burst(s) that comprises one or more RTP retransmission packets burst(s) that comprises one or more RTP retransmission packets
sent in the unicast burst RTP session. In addition, the BRS MAY sent in the unicast burst RTP session. In addition, in some
send preamble information data to the RTP_Rx in addition to the applications the BRS can send preamble information data to the
requested burst, to prime the media decoder(s). The format of RTP_Rx in addition to the requested burst to prime the media
this preamble data is RTP-payload specific and not specified decoder(s). However, for the BRS to send the preamble
here. information in a particular format, explicit signaling from the
RTP_Rx is required. In other words, the BRS MUST NOT send
preamble information in a particular format unless the RTP_Rx
has signaled support for that format in the RAMS-R message
through a public or private extension as defined in Section 7.1.
The format of this preamble data is RTP-payload specific and not
specified here.
5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message 5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message
(as unicast feedback in the primary multicast RTP session) with (as unicast feedback in the primary multicast RTP session) with
a different value for one or more fields of an earlier RAMS-R a different value for one or more fields of an earlier RAMS-R
message. If there is already a burst planned for or being message. If there is already a burst planned for or being
transmitted to a particular RTP_Rx for a particular stream, the transmitted to a particular RTP_Rx for a particular stream, the
newly arriving RAMS-R is an updated request; otherwise, it is a newly arriving RAMS-R is an updated request; otherwise, it is a
new request. The BRS determines the identity of the requesting new request. It is also possible that the RTP_Rx has sent an
RTP_Rx by looking at its canonical name identifier (CNAME item improperly formatted RAMS-R message or used an invalid value in
in the SDES source description). Thus, the RTP_Rx MUST choose a the RAMS-R message. If notified by the BRS using a 4xx-level
globally unique CNAME identifier. Different such ways are response code (as defined in Section 11.6), the RTP_Rx MAY re-
provided in [I-D.ietf-avt-rtp-cnames]. In addition to one or send its corrected request only after following the timing rules
more fields with updated values, an updated RAMS-R message may of [RFC4585].
also include the fields whose values did not change.
The BRS determines the identity of the requesting RTP_Rx by
looking at its canonical name identifier (CNAME item in the SDES
source description). Thus, the RTP_Rx MUST choose a globally
unique CNAME identifier. Different such ways are provided in
[I-D.ietf-avt-rtp-cnames]. In addition to one or more fields
with updated values, an updated RAMS-R message may also include
the fields whose values did not change.
Upon receiving an updated request, the BRS can use the updated Upon receiving an updated request, the BRS can use the updated
values for sending/shaping the burst, or refine the values and values for sending/shaping the burst, or refine the values and
use the refined values for sending/shaping the burst. use the refined values for sending/shaping the burst.
Subsequently, the BRS MAY send an updated RAMS-I message in the Subsequently, the BRS MAY send an updated RAMS-I message in the
unicast burst RTP session to indicate the changes it made. unicast burst RTP session to indicate the changes it made.
It is an implementation-dependent decision for an RTP_RX whether It is an implementation-dependent decision for an RTP_RX whether
and when to send an updated request. and when to send an updated request.
6. Updated Response: The BRS can send more than one RAMS-I 6. Updated Response: The BRS can send more than one RAMS-I
messages in the unicast burst RTP session, e.g., to update the messages in the unicast burst RTP session, e.g., to update the
value of one or more fields in an earlier RAMS-I message. The value of one or more fields in an earlier RAMS-I message. The
updated RAMS-I messages might or might not be a direct response updated RAMS-I messages might or might not be a direct response
skipping to change at page 32, line 11 skipping to change at page 32, line 49
specific information that will be provided by the BRS. The limits specific information that will be provided by the BRS. The limits
can include local receiver limits as well as network limits that can include local receiver limits as well as network limits that
are known to the receiver. are known to the receiver.
If specified, the total bitrate of the unicast burst(s) plus any If specified, the total bitrate of the unicast burst(s) plus any
payload-specific information MUST NOT be larger than this value. payload-specific information MUST NOT be larger than this value.
Otherwise, congestion and packet loss may occur. Otherwise, congestion and packet loss may occur.
Type: 4 Type: 4
o Request for Preamble Only (0 bits): Optional TLV element that o Preamble-only Allowed (0 bits): Optional TLV element that
indicates that the RTP_Rx is only requesting the preamble indicates that the RTP_Rx is willing to receive only the preamble
information for the desired primary multicast stream(s). If this information for the desired primary multicast stream(s) in case
TLV element exists in the RAMS-R message, the BRS MUST NOT send the BRS cannot send the unicast burst stream(s) (In such cases,
any burst packets other than the preamble packets. Since this TLV the BRS uses the response code 511 in the RAMS-I message as
element does not carry a Value field, the Length field MUST be set defined in Section 11.6). Note that the RTP_Rx signals the
to zero. particular preamble format(s) it supports through a public or a
private extension in the same RAMS-R message.
If this TLV element does not exist in the RAMS-R message, the BRS
MUST NOT respond to the RAMS-R message by sending the preamble
information only. Since this TLV element does not carry a Value
field, the Length field MUST be set to zero.
Type: 5 Type: 5
7.3. RAMS Information 7.3. RAMS Information
The RAMS Information (RAMS-I) message is identified by SFMT=2. This The RAMS Information (RAMS-I) message is identified by SFMT=2. This
message is used to describe the unicast burst that will be sent for message is used to describe the unicast burst that will be sent for
rapid acquisition. It also includes other useful information for the rapid acquisition. It also includes other useful information for the
RTP_Rx as described below. RTP_Rx as described below.
skipping to change at page 46, line 14 skipping to change at page 47, line 14
However, the response codes have been classified and registered However, the response codes have been classified and registered
following an HTTP-style code numbering in this document. New following an HTTP-style code numbering in this document. New
response codes should be classified following the guidelines below: response codes should be classified following the guidelines below:
Code Level Purpose Code Level Purpose
---------- --------------- ---------- ---------------
1xx Informational 1xx Informational
2xx Success 2xx Success
3xx Redirection 3xx Redirection
4xx RTP Receiver Error 4xx RTP Receiver (RTP_Rx) Error
5xx Retransmission Server Error 5xx Burst/Retransmission Source (BRS) Error
The Response code 65535 is reserved for future use. The Response code 65535 is reserved for future use.
The registry is initialized with the following entries: The registry is initialized with the following entries:
Code Description Reference Code Description Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
0 A private response code is included in the message [RFCXXXX] 0 A private response code is included in the message [RFCXXXX]
100 Parameter update for RAMS session [RFCXXXX] 100 Parameter update for RAMS session [RFCXXXX]
200 RAMS request has been accepted [RFCXXXX] 200 RAMS request has been accepted [RFCXXXX]
201 Unicast burst has been completed [RFCXXXX] 201 Unicast burst has been completed [RFCXXXX]
400 Invalid RAMS-R message syntax 400 Invalid RAMS-R message syntax [RFCXXXX]
401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX]
402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX]
403 Invalid max bitrate requirement in RAMS-R message [RFCXXXX] 403 Insufficient max bitrate requirement in RAMS-R
message [RFCXXXX]
404 Invalid RAMS-T message syntax [RFCXXXX]
500 An unspecified BRS internal error has occurred [RFCXXXX] 500 An unspecified BRS internal error has occurred [RFCXXXX]
501 BRS has insufficient bandwidth to start RAMS 501 BRS has insufficient bandwidth to start RAMS
session [RFCXXXX] session [RFCXXXX]
502 Burst is terminated due to network congestion [RFCXXXX] 502 Burst is terminated due to network congestion [RFCXXXX]
503 BRS has insufficient CPU cycles to start RAMS 503 BRS has insufficient CPU cycles to start RAMS
session [RFCXXXX] session [RFCXXXX]
504 RAMS functionality is not available on BRS [RFCXXXX] 504 RAMS functionality is not available on BRS [RFCXXXX]
505 RAMS functionality is not available for RTP_Rx [RFCXXXX] 505 RAMS functionality is not available for RTP_Rx [RFCXXXX]
506 RAMS functionality is not available for 506 RAMS functionality is not available for
skipping to change at page 48, line 7 skipping to change at page 49, line 7
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 Response code describes and o A detailed description of what the new Response code describes and
how it shall be interpreted. how it shall be interpreted.
11.6.1. Response Code Definitions 11.6.1. Response Code Definitions
1xx-Level Response Codes: These response codes are sent for
informational purposes.
o 100: This is used when the BRS wants to update a value that was o 100: This is used when the BRS wants to update a value that was
sent earlier to the RTP_Rx. sent earlier to the RTP_Rx.
2xx-Level Response Codes: These response codes are sent to indicate
success.
o 200: This is used when the server accepts the RAMS request. o 200: This is used when the server accepts the RAMS request.
o 201: This is used when the unicast burst has been completed and o 201: This is used when the unicast burst has been completed and
the BRS wants to notify the RTP_Rx. the BRS wants to notify the RTP_Rx.
4xx-Level Response Codes: These response codes are sent to indicate
that the message sent by the RTP_Rx is either improperly formatted or
contains an invalid value. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 5 in
Section 6.2. The 4xx-level response codes are also used as status
codes in the Multicast Acquisition Report Block
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect RTP_Rx-based
error conditions.
o 400: This is used when the RAMS-R message is improperly o 400: This is used when the RAMS-R message is improperly
formatted. formatted.
o 401: This is used when the minimum RAMS buffer fill requirement o 401: This is used when the minimum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid. value indicated in the RAMS-R message is invalid.
o 402: This is used when the maximum RAMS buffer fill requirement o 402: This is used when the maximum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid. value indicated in the RAMS-R message is invalid.
o 403: This is used when the maximum receive bitrate value o 403: This is used when the maximum receive bitrate value
indicated in the RAMS-R message is invalid. indicated in the RAMS-R message is insufficient.
o 404: This is used when the RAMS-T message is improperly
formatted.
5xx-Level Response Codes: These response codes are sent to indicate
an error on the BRS side. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 3 in
Section 6.2 and Section 7.2. The 5xx-level response codes are also
used as status codes in the Multicast Acquisition Report Block
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect BRS-based
error conditions.
o 500: This is used when the BRS has experienced an internal error o 500: This is used when the BRS has experienced an internal error
and cannot accept the RAMS request. and cannot accept the RAMS request.
o 501: This is used when the BRS does not have enough bandwidth to o 501: This is used when the BRS does not have enough bandwidth to
send the unicast burst stream. send the unicast burst stream.
o 502: This is used when the BRS terminates the unicast burst o 502: This is used when the BRS terminates the unicast burst
stream due to network congestion. stream due to network congestion.
skipping to change at page 49, line 28 skipping to change at page 51, line 8
12. Contributors 12. Contributors
Dave Oran, Magnus Westerlund and Colin Perkins have contributed Dave Oran, Magnus Westerlund and Colin Perkins have contributed
significantly to this specification by providing text and solutions significantly to this specification by providing text and solutions
to some of the issues raised during the development of this to some of the issues raised during the development of this
specification. specification.
13. Acknowledgments 13. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
specification and provided helpful comments: Colin Perkins, Joerg specification and provided helpful comments: Joerg Ott, Roni Even,
Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel
Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui
Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan
Jonathan Lennox, Jose Rey, Sean Sheedy and Keith Drage. Lennox, Jose Rey, Sean Sheedy and Keith Drage.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 22 change blocks. 
77 lines changed or deleted 140 lines changed or added

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