draft-ietf-avt-rapid-acquisition-for-rtp-14.txt   draft-ietf-avt-rapid-acquisition-for-rtp-15.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: March 3, 2011 T. VanCaenegem Expires: March 11, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
August 30, 2010 September 7, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-14 draft-ietf-avt-rapid-acquisition-for-rtp-15
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 March 3, 2011. This Internet-Draft will expire on March 11, 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 30 skipping to change at page 3, line 30
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 33 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 33
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 36 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 36
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 37 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 37 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 38
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 38 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 38
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 41 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 44 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 44
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 44 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 44
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 44 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 44
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 45 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 45
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46
skipping to change at page 19, line 38 skipping to change at page 19, line 38
RAMS-I message with the appropriate response code (either RAMS-I message with the appropriate response code (either
zero indicating a private response or response code 200 zero indicating a private response or response code 200
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. Note that if the BRS is sending only
the preamble information but not the whole unicast burst
stream, it will not accept the request, but will send a
response code 511 instead as defined in Section 11.6.
The RAMS-I message carries the RTP sequence number of the The RAMS-I message carries the RTP sequence number of the
first packet transmitted in the respective RTP stream to first packet transmitted in the respective RTP stream to
allow the RTP_Rx to detect any missing initial packet(s). allow the RTP_Rx to detect any missing initial packet(s).
When the BRS accepts a request for a primary multicast When the BRS accepts a request for a primary multicast
stream, this field MUST always be populated in the RAMS-I stream, this field MUST always be populated in the RAMS-I
message(s) sent for this particular primary multicast stream. message(s) sent for this particular primary multicast stream.
It is RECOMMENDED that the BRS sends a RAMS-I message at the It is RECOMMENDED that the BRS sends a RAMS-I message at the
start of the burst so that the RTP_Rx can quickly detect any start of the burst so that the RTP_Rx can quickly detect any
missing initial packet(s). missing initial packet(s).
skipping to change at page 22, line 37 skipping to change at page 22, line 37
request. request.
Otherwise, the default behavior for the RTP_Rx is to send a Otherwise, the default behavior for the RTP_Rx is to send a
RAMS-T message in the unicast burst RTP session immediately RAMS-T message in the unicast burst RTP session immediately
after it joins the multicast session and started receiving after it joins the multicast session and started receiving
multicast packets. In that case, the RTP_Rx SHALL send a RAMS-T multicast packets. In that case, the RTP_Rx SHALL send a RAMS-T
message with the sequence number of the first RTP packet message with the sequence number of the first RTP packet
received in the primary multicast stream. Then, the BRS MUST received in the primary multicast stream. Then, the BRS MUST
terminate the respective burst after it sends the unicast burst terminate the respective burst after it sends the unicast burst
packet whose Original Sequence Number (OSN) field in the RTP packet whose Original Sequence Number (OSN) field in the RTP
retransmission payload header matches this number minus one. retransmission payload header matches this number minus one. If
the BRS has already sent that unicast burst packet when the
RAMS-T message arrives, the BRS MUST terminate the respective
burst immediately.
If an RTCP BYE message has not been issued yet as described in If an RTCP BYE message has not been issued yet as described in
Step 10, the RTP_Rx MUST send at least one RAMS-T message for Step 10, the RTP_Rx MUST send at least one RAMS-T message for
each primary multicast stream served by the BRS. The RAMS-T each primary multicast stream served by the BRS. The RAMS-T
message(s) MUST be sent to the BRS in the unicast burst RTP message(s) MUST be sent to the BRS in the unicast burst RTP
session. Against the possibility of a message loss, it is session. Against the possibility of a message loss, it is
RECOMMENDED that the RTP_Rx repeats the RAMS-T messages multiple RECOMMENDED that the RTP_Rx repeats the RAMS-T 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].
skipping to change at page 27, line 36 skipping to change at page 27, line 37
messages multiple times based on the RTCP timer rules defined in messages multiple times based on the RTCP timer rules defined in
[RFC4585]. [RFC4585].
In the failure cases where the RAMS-R message is lost and the RTP_Rx In the failure cases where the RAMS-R message is lost and the RTP_Rx
gives up, or the RAMS-I message is lost, the RTP_Rx MUST still gives up, or the RAMS-I message is lost, the RTP_Rx MUST still
terminate the burst(s) it requested by following the rules described terminate the burst(s) it requested by following the rules described
in Section 6.2. in Section 6.2.
In the case a RAMS-T message sent by the RTP_Rx does not reach its In the case a RAMS-T message sent by the RTP_Rx does not reach its
destination, the BRS can continue sending burst packets even though destination, the BRS can continue sending burst packets even though
the RTP_Rx no longer needs them. In such cases, it is RECOMMENDED the RTP_Rx no longer needs them. If an RTP_Rx is receiving burst
that the RTP_Rx repeats the RAMS-T message multiple times based on packets it no longer needs after sending a RAMS-T message, it is
the RTCP timer rules defined in [RFC4585]. The BRS MUST be RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple times
based on the RTCP timer rules defined in [RFC4585]. The BRS MUST be
provisioned to terminate the burst when it can no longer send the provisioned to terminate the burst when it can no longer send the
burst packets faster than it receives the primary multicast stream burst packets faster than it receives the primary multicast stream
packets. packets.
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
out an SSRC. When the BRS accepts to serve the requested burst(s) out an SSRC. When the BRS accepts to serve the requested burst(s)
and establishes the retransmission session, the BRS needs to check and establishes the retransmission session, the BRS needs to check
the liveness of the RTP_Rx via the RTCP messages and reports the the liveness of the RTP_Rx via the RTCP messages and reports the
RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS
as well. as well.
skipping to change at page 29, line 32 skipping to change at page 29, line 32
any padding that is required for alignment. any padding that is required for alignment.
o Value: Variable-size set of octets that contains the specific o Value: Variable-size set of octets that contains the specific
value for the parameter. value for the parameter.
In the extensions, the Reserved field SHALL be set to zero and In the extensions, the Reserved field SHALL be set to zero and
ignored. If a TLV element does not fall on a 32-bit boundary, the ignored. If a TLV element does not fall on a 32-bit boundary, the
last word MUST be padded to the boundary using further bits set to last word MUST be padded to the boundary using further bits set to
zero. zero.
In a RAMS message, any vendor-neutral or private extension MUST be The vendor-neutral and private extensions MAY exist in any RAMS
placed after the mandatory fields and mandatory TLV elements (if message. Such extensions MUST be placed after the mandatory fields
any). The extensions MAY be placed in any order. In a RAMS message, and mandatory TLV elements (if any), and MAY be placed in any order.
multiple TLV elements with the same Type value MUST NOT exist. In a RAMS message, multiple TLV elements with the same Type value
MUST NOT exist.
The support for extensions (unless specified otherwise) is OPTIONAL. The support for extensions (unless specified otherwise) is OPTIONAL.
An RTP_Rx or BRS receiving a vendor-neutral or private extension that
it does not understand MUST ignore that extension.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a TLV element Figure 5: Structure of a TLV element
skipping to change at page 33, line 5 skipping to change at page 33, line 5
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 Preamble-only Allowed (0 bits): Optional TLV element that o Preamble-only Allowed (0 bits): Optional TLV element that
indicates that the RTP_Rx is willing to receive only the preamble indicates that the RTP_Rx is willing to receive only the preamble
information for the desired primary multicast stream(s) in case information for the desired primary multicast stream(s) in case
the BRS cannot send the unicast burst stream(s) (In such cases, the BRS cannot send the unicast burst stream(s) (In such cases,
the BRS uses the response code 511 in the RAMS-I message as the BRS will not accept the request, but will send a response code
defined in Section 11.6). Note that the RTP_Rx signals the 511 in the RAMS-I message as defined in Section 11.6). Note that
particular preamble format(s) it supports through a public or a the RTP_Rx signals the particular preamble format(s) it supports
private extension in the same RAMS-R message. 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 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 MUST NOT respond to the RAMS-R message by sending the preamble
information only. Since this TLV element does not carry a Value information only. Since this TLV element does not carry a Value
field, the Length field MUST be set to zero. field, the Length field MUST be set to zero.
Type: 5 Type: 5
o Supported Enterprise Number(s): Optional TLV element that
indicates the enterprise number(s) that the RTP_Rx implementation
supports. Similar to the private extensions, the enterprise
numbers here are used from
http://www.iana.org/assignments/enterprise-numbers. This TLV
element, if exists, provides a hint information to the BRS about
which private extensions the RTP_Rx can potentially support. Note
that an RTP_Rx does not necessarily support all the private
extensions under a particular enterprise number. Unless the BRS
explicitly knows which private extensions an RTP_Rx supports
(through this or some out-of-band means), the BRS SHOULD NOT use
private extensions in the RAMS-I messages. The BRS SHOULD rather
use only vendor-neutral extensions. The Length field of this TLV
element is set to 4*n, where n is the number of enterprise number
entries.
Type: 6
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.
A separate RAMS-I message with the appropriate response code is sent A separate RAMS-I message with the appropriate response code is sent
in the unicast burst RTP session by the BRS for each primary in the unicast burst RTP session by the BRS for each primary
multicast stream that has been requested by the RTP_Rx. In each of multicast stream that has been requested by the RTP_Rx. In each of
skipping to change at page 34, line 24 skipping to change at page 34, line 39
o Response (16 bits): Mandatory field that denotes the response o Response (16 bits): Mandatory field that denotes the response
code for this RAMS-I message. This document defines several code for this RAMS-I message. This document defines several
initial response codes in Section 11.6 and registers them with initial response codes in Section 11.6 and registers them with
IANA. If a new vendor-neutral response code will be defined, it IANA. If a new vendor-neutral response code will be defined, it
MUST be registered with IANA through the guidelines specified in MUST be registered with IANA through the guidelines specified in
Section 11.6. If the new response code is intended to be used Section 11.6. If the new response code is intended to be used
privately by a vendor, there is no need for IANA management. privately by a vendor, there is no need for IANA management.
Instead, the vendor MUST use the private extension mechanism Instead, the vendor MUST use the private extension mechanism
(Section 7.1.2) to convey its message and MUST indicate this by (Section 7.1.2) to convey its message and MUST indicate this by
putting zero in the Response field. When the RTP_Rx receives an putting zero in the Response field.
RAMS-I message with a private response code that it does not
understand, the RTP_Rx still needs to process the TLV elements it When the RTP_Rx receives a RAMS-I message with a response code
understands. that it does not understand, the RTP_Rx MUST send a RAMS-T message
immediately to the BRS.
The following TLV elements have been defined for the RAMS-I messages: The following TLV elements have been defined for the RAMS-I messages:
o Media Sender SSRC (32 bits): Optional TLV element that specifies o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this the media sender SSRC of the unicast burst stream. While this
information is already available in the message header, it can be information is already available in the message header, it can be
useful to repeat it in an explicit field. If the FT_Ap that useful to repeat it in an explicit field. If the FT_Ap that
received the RAMS-R message is associated with a single primary received the RAMS-R message is associated with a single primary
multicast stream but the requested media sender SSRC does not multicast stream but the requested media sender SSRC does not
match the SSRC of the RTP stream associated with this FT_Ap, the match the SSRC of the RTP stream associated with this FT_Ap, the
skipping to change at page 35, line 22 skipping to change at page 35, line 39
If the RAMS request has been accepted, the BRS sends this field at If the RAMS request has been accepted, the BRS sends this field at
least once, so that the RTP_Rx knows when to join the multicast least once, so that the RTP_Rx knows when to join the multicast
session. If the burst request has been rejected as indicated in session. If the burst request has been rejected as indicated in
the Response field, this field MUST be set to zero. In that case, the Response field, this field MUST be set to zero. In that case,
it is up to the RTP_Rx when or whether to join the multicast it is up to the RTP_Rx when or whether to join the multicast
session. session.
When the BRS serves two or more bursts and sends a separate RAMS-I When the BRS serves two or more bursts and sends a separate RAMS-I
message for each burst, the join times specified in these RAMS-I message for each burst, the join times specified in these RAMS-I
messages should correspond to more or less the same time instant, messages SHOULD correspond to more or less the same time instant,
and the RTP_Rx sends the SFGMP Join message based on the earliest and the RTP_Rx sends the SFGMP Join message based on the earliest
join time. join time.
Type: 33 Type: 33
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
time the burst will last (in ms), i.e., the delta difference time the burst will last (in ms), i.e., the difference between the
between the expected transmission times of the first and the last expected transmission times of the first and the last burst
burst packets that the BRS is planning to send in the respective packets that the BRS is planning to send in the respective unicast
unicast RTP stream. In the absence of additional stimulus, the RTP stream. In the absence of additional stimulus, the BRS will
BRS will send a burst of this duration. However, the burst send a burst of this duration. However, the burst duration can be
duration can be modified by subsequent events, including changes modified by subsequent events, including changes in the primary
in the primary multicast stream and reception of RAMS-T messages. multicast stream and reception of RAMS-T messages.
The BRS MUST terminate the flow in the timeframe indicated by this The BRS MUST terminate the flow in the timeframe indicated by this
burst duration or the duration established by those subsequent burst duration or the duration established by those subsequent
events, even if it does not get a RAMS-T or a BYE message from the events, even if it does not get a RAMS-T or a BYE message from the
RTP_Rx. It is OPTIONAL to send this field in a RAMS-I message RTP_Rx. It is OPTIONAL to send this field in a RAMS-I message
when the burst request is accepted. If the burst request has been when the burst request is accepted. If the burst request has been
rejected as indicated in the Response field, this field MAY be rejected as indicated in the Response field, this field MAY be
omitted or set to zero. omitted or set to zero.
Type: 34 Type: 34
skipping to change at page 40, line 22 skipping to change at page 40, line 22
available for retransmission (measured from the time the packet was available for retransmission (measured from the time the packet was
received by the BRS, not from the time indicated in the packet received by the BRS, not from the time indicated in the packet
timestamp). timestamp).
Once an RTP_Rx has acquired an SDP description, it can ask for rapid Once an RTP_Rx has acquired an SDP description, it can ask for rapid
acquisition before it joins a primary multicast RTP session. To do acquisition before it joins a primary multicast RTP session. To do
so, it sends a RAMS-R message to the feedback target of that primary so, it sends a RAMS-R message to the feedback target of that primary
multicast RTP session. If the FT_Ap is associated with only one RTP multicast RTP session. If the FT_Ap is associated with only one RTP
stream, the RTP_Rx does not need to learn the SSRC of that stream via stream, the RTP_Rx does not need to learn the SSRC of that stream via
an out-of-band method. If the BRS accepts the rapid acquisition an out-of-band method. If the BRS accepts the rapid acquisition
request, it will send an RAMS-I message with the correct SSRC request, it will send a RAMS-I message with the correct SSRC
identifier. If the FT_Ap is associated with a multi-stream RTP identifier. If the FT_Ap is associated with a multi-stream RTP
session and the RTP_Rx is willing to request rapid acquisition for session and the RTP_Rx is willing to request rapid acquisition for
the entire session, the RTP_Rx again does not need to learn the SSRCs the entire session, the RTP_Rx again does not need to learn the SSRCs
via an out-of-band method. However, if the RTP_Rx intends to request via an out-of-band method. However, if the RTP_Rx intends to request
a particular subset of the primary multicast streams, it must learn a particular subset of the primary multicast streams, it must learn
their SSRC identifiers and list them in the RAMS-R message. Since their SSRC identifiers and list them in the RAMS-R message. Since
this RTP_Rx has not yet received any RTP packets for the primary this RTP_Rx has not yet received any RTP packets for the primary
multicast stream(s), the RTP_Rx must in this case learn the SSRC multicast stream(s), the RTP_Rx must in this case learn the SSRC
value(s) from the 'ssrc' attribute of the media description value(s) from the 'ssrc' attribute of the media description
[RFC5576]. In addition to the SSRC value, the 'cname' source [RFC5576]. In addition to the SSRC value, the 'cname' source
skipping to change at page 46, line 21 skipping to change at page 46, line 21
The registry is initialized with the following entries: The registry is initialized with the following entries:
Type Description Reference Type Description Reference
---- -------------------------------------------------- ------------- ---- -------------------------------------------------- -------------
0 Reserved [RFCXXXX] 0 Reserved [RFCXXXX]
1 Requested Media Sender SSRC(s) [RFCXXXX] 1 Requested Media Sender SSRC(s) [RFCXXXX]
2 Min RAMS Buffer Fill Requirement [RFCXXXX] 2 Min RAMS Buffer Fill Requirement [RFCXXXX]
3 Max RAMS Buffer Fill Requirement [RFCXXXX] 3 Max RAMS Buffer Fill Requirement [RFCXXXX]
4 Max Receive Bitrate [RFCXXXX] 4 Max Receive Bitrate [RFCXXXX]
5 Request for Preamble Only [RFCXXXX] 5 Request for Preamble Only [RFCXXXX]
6-30 Assignable - Specification Required 6 Supported Enterprise Number(s) [RFCXXXX]
7-30 Assignable - Specification Required
31 Media Sender SSRC [RFCXXXX] 31 Media Sender SSRC [RFCXXXX]
32 RTP Seqnum of the First Packet [RFCXXXX] 32 RTP Seqnum of the First Packet [RFCXXXX]
33 Earliest Multicast Join Time [RFCXXXX] 33 Earliest Multicast Join Time [RFCXXXX]
34 Burst Duration [RFCXXXX] 34 Burst Duration [RFCXXXX]
35 Max Transmit Bitrate [RFCXXXX] 35 Max Transmit Bitrate [RFCXXXX]
36-60 Assignable - Specification Required 36-60 Assignable - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX]
62-127 Assignable - Specification Required 62-127 Assignable - Specification Required
128-254 No IANA Maintenance 128-254 No IANA Maintenance
255 Reserved [RFCXXXX] 255 Reserved [RFCXXXX]
 End of changes. 17 change blocks. 
32 lines changed or deleted 63 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/