[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item
Hi Roni, All,
Here is a diff for sections 7 and 13.
Comments are welcome.
-acbegen
> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Wednesday, May 13, 2009 11:59 PM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); avt at ietf.org
> Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working
> group item
>
> Hi Ali,
> I would like to see the text about this extensions mechanism. It was not
> discussed in the mailing list, what was done in a un-official design team or
> breakout session is not binding for a WG document.
>
> If you have a proposal please bring it forward.
> It should address the issue of what extensions are allowed, what is the
> registration procedure for the two types of extensions , do you need a draft
> describing the extension and so on.
> It should be discussed before it is added to a working group document.
>
> Roni
>
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: Thursday, May 14, 2009 2:36 AM
> To: Roni Even; Bill Ver Steeg (versteb); avt at ietf.org
> Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working group item
>
> Inline.
>
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Roni
> Even
> > Sent: Wednesday, May 13, 2009 5:22 AM
> > To: Bill Ver Steeg (versteb); avt at ietf.org
> > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working
> > group item
> >
> > Bill,
> > Any changes that are not editorial should be presented to the list before
> > they are added to the draft.
> >
> > The changes for section 8 and 13 can be added to the draft.
>
> OK.
>
> > For section 7 please send a suggestion to the list since I am not sure
> that
> > there was a preferred way to do it.
>
> As we proposed previously (actually since version -00), we are using TLV
> elements to provide the extension mechanism and avoid the problems
> associated with using special values in various fields. In the update, we
> are saying that the TLV types will be registered with IANA in a new
> registry. Some of the available type space is reserved for vendor-neutral
> extensions whereas the rest is for private extensions. We briefly outline
> the requirements for registering the vendor-neutral extensions.
>
> As proposed by Ingemar previously in the breakout session, we are now using
> sub FMT fields to specify the individual RAMS messages (request, information
> and termination). So, for the message format we have something like:
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | SFMT=1 | Optional TLV-encoded Fields |
> +-+-+-+-+-+-+-+-+ |
> : Optional TLV-encoded Fields (and Padding, if needed) :
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Further RAMS message types could be defined in the future, if needed.
>
> We wanna conclude these issues quickly and address the remaining open items
> (you mentioned some of them already) in the next revision.
>
> BR,
> -acbegen
>
> > Thanks
> > Roni Even
> > AVT co-chair
> >
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Bill
> > Ver Steeg (versteb)
> > Sent: Wednesday, May 13, 2009 3:08 PM
> > To: avt at ietf.org
> > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> > Sessions(RAMS) as a working group item
> >
> >
> >
> > We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp".
> > This is basically a name change from
> > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion
> > with other pending "synchronization" drafts.
> >
> > There were some issues remaining from -03 version that have already been
> > identified on the list and technical breakout session. We are planning
> > to address these issues in the next version of the draft.
> >
> > We hope to address the following areas in the next revision of the
> > draft:
> >
> > - Section 7 - Define a method for vendor-specific and generic extensions
> > to RAMS, lay out the intent to use FMT==6 for all messages and to have
> > an (extensible) enumeration of the RAMS sub-FMTs
> > - Section 8 - Elaborate SDP to describe the various use cases for RAMS
> > - Section 13 - Define a single registry (FMT==6) for all RAMS
> > transactions, and then define Sub-FMT Values for RAMS Messages. Also
> > define an extensible RAMS TLV space registry
> >
> > - We need to make some typographical corrections, mostly changing from
> > RMS to RAMS.
> > - We need to formalize the TLV definitions and extensions (both vendor
> > and private extensions)
> > - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to
> > identify various RAMS messages
> > - We need to clarify the SDP section based on the earlier discussion.
> > The SDP example is still declarative and we are looking forward to
> > include more examples as we move forward.
> > - The IANA concerns section needs to be updated to reflect how to extend
> > the RAMS protocol.
> > - The unicast/multicast addresses need to be fixed according to the
> > idnits tool.
> >
> > Are there other issues that we need to address in the next revision of
> > the draft? The authors would like to address these high priority issues
> > in the next few days, so timely feedback would be appreciated.
> >
> >
> > Bill VerSteeg
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
Section 7., paragraph 1:
OLD:
This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RR) during rapid acquisition. These messages are
payload-independent and MUST be used by all RTP-based multicast
applications that support rapid acquisition regardless of the payload
they carry.
NEW:
This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RR) during rapid acquisition. These messages are
referred to as the RAMS Messages. They are payload-independent and
MUST be used by all RTP-based multicast applications that support
rapid acquisition regardless of the payload they carry.
Section 7., paragraph 2:
OLD:
Specific payload formats are not defined in this document, but a
framework is presented that allows payload-specific information to be
included in the exchange.
NEW:
Payload-specific feedback messages are not defined in this document,
but an extension mechanism is provided where further optional
payload-independent and payload-specific information can be included
in the exchange.
Section 7., paragraph 3:
OLD:
The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as
a variable-length field for feedback control information (FCI). In
the transport-layer feedback messages, the PT field is set to RTPFB
(205).
NEW:
The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as
a variable-length field for feedback control information (FCI).
Section 7., paragraph 4:
OLD:
In the feedback messages defined in this section, optional extensions
are encoded by using TLV elements as described below and sketched in
Figure 4:
NEW:
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
field is set to RAMS (6). Individual RAMS messages are identified by
a sub-field called Sub Feedback Message Type (SFMT).
7.1. Extensions
To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be
encoded as TLV elements as described below and sketched in Figure 4:
Section 7., paragraph 6:
OLD:
o Length: A two-octet field that indicates the length of the Value
field in octets.
NEW:
o Length: A two-octet field that indicates the length of the TLV
element excluding the Type and Length fields in octets. Note that
this length does not include any padding that is required for
alignment.
Section 7., paragraph 9:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
In an RAMS message any vendor-neutral or private extension MUST be
placed after the mandatory fields (if any). The support for
extensions is OPTIONAL.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 10:
OLD:
Figure 4: Structure of a TLV element
Editor's note: The optional fields in the RAMS messages (defined
below) will be converted to TLV elements in a later version of this
document.
NEW:
Figure 4: Structure of a TLV element
Section 7., paragraph 11:
OLD:
7.1. RAMS Request
NEW:
7.1.1. Vendor-Neutral Extensions
Section 7., paragraph 12:
OLD:
The RAMS Request message is identified by PT=RTPFB and FMT=6.
NEW:
If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 13.4.
The current document defines several vendor-neutral extensions in the
following sections.
7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with
each other.
A certain range of TLV Types is reserved for private extensions
(Refer to Section 13.4). IANA management for these extensions is
unnecessary and they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is
depicted in Figure 5. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a private extension
7.2. RAMS Request
The RAMS Request message is identified by SFMT=1.
Section 7., paragraph 15:
OLD:
The FCI field has the structure depicted in Figure 5.
NEW:
The FCI field has the structure depicted in Figure 6.
Section 7., paragraph 17:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min RAMS Buffer Fill Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max RAMS Buffer Fill Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Receive Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+ |
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 18:
OLD:
Figure 5: FCI field syntax for the RAMS Request message
NEW:
Figure 6: FCI field syntax for the RAMS Request message
Section 7., paragraph 22:
OLD:
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum number of octets of content the RTP
receiver can buffer without losing the burst data due to buffer
overflow.
NEW:
Type: TBD
Length: TBD
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum number of octets of content the RTP
receiver can buffer without losing the burst data due to buffer
overflow.
Section 7., paragraph 25:
OLD:
o Max Receive Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can
process the unicast burst. This rate should include whatever
knowledge the receiver has that would provide an upper bound on
the unicast burst bitrate. The limits may include local receiver
limits as well as network limits that are known to the receiver.
NEW:
Type: TBD
Length: TBD
o Max Receive Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can
process the unicast burst. This rate should include whatever
knowledge the receiver has that would provide an upper bound on
the unicast burst bitrate. The limits may include local receiver
limits as well as network limits that are known to the receiver.
Section 7., paragraph 27:
OLD:
The semantics of the RAMS-R feedback message is independent of the
payload type.
NEW:
Type: TBD
Length: TBD
The semantics of the RAMS-R feedback message is independent of the
payload type.
Section 7., paragraph 28:
OLD:
7.2. RAMS Information
NEW:
7.3. RAMS Information
Section 7., paragraph 29:
OLD:
The RAMS Information message is identified by PT=RTPFB and FMT=7.
NEW:
The RAMS Information message is identified by SFMT=2.
Section 7., paragraph 32:
OLD:
The FCI field has the structure depicted in Figure 6.
NEW:
The FCI field has the structure depicted in Figure 7.
Section 7., paragraph 33:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSN |S| Response | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Burst Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest Multicast Join Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Burst Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN |S| Response | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Burst Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 34:
OLD:
Figure 6: FCI field syntax for the RAMS Information message
NEW:
Figure 7: FCI field syntax for the RAMS Information message
Section 7., paragraph 41:
OLD:
1. Success
2. Bad_Request
NEW:
1. Success
2. Bad_Request
Section 7., paragraph 45:
OLD:
o Rsvd (16 bits): Reserved. This field SHALL be set to 0.
NEW:
o Rsvd (8 bits): Reserved. This field SHALL be set to 0.
Section 7., paragraph 50:
OLD:
o Burst Duration (32 bits): Optional TLV element that denotes the
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
this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast
stream and reception of RAMS-T messages.
NEW:
Type: TBD
Length: TBD
o Burst Duration (32 bits): Optional TLV element that denotes the
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
this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast
stream and reception of RAMS-T messages.
Section 7., paragraph 52:
OLD:
o Max Burst Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS
for the unicast burst.
NEW:
Type: TBD
Length: TBD
o Max Burst Bitrate (32 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by RS
for the unicast burst.
Section 7., paragraph 53:
OLD:
The semantics of the RAMS-I feedback message is independent of the
payload type.
NEW:
Type: TBD
Length: TBD
The semantics of the RAMS-I feedback message is independent of the
payload type.
Section 7., paragraph 55:
OLD:
7.3. RAMS Termination
NEW:
7.4. RAMS Termination
Section 7., paragraph 56:
OLD:
The RAMS Termination message is identified by PT=RTPFB and FMT=8.
NEW:
The RAMS Termination message is identified by SFMT=3.
Section 7., paragraph 61:
OLD:
The FCI field has the structure depicted in Figure 7.
NEW:
The FCI field has the structure depicted in Figure 8.
Section 7., paragraph 62:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of First Multicast Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (TLV-encoded Extensions) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+ |
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 7., paragraph 63:
OLD:
Figure 7: FCI field syntax for the RAMS Termination message
NEW:
Figure 8: FCI field syntax for the RAMS Termination message
Section 7., paragraph 65:
OLD:
The semantics of the RAMS-T feedback message is independent of the
payload type.
7.4. Extensions
To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be
defined as TLV elements. If the goal in defining these new fields is
to extend the protocol in a vendor-neutral manner, they MUST be
registered with IANA through an Informational or a Standards-track
RFC. The support for these new fields is OPTIONAL. In an RAMS
message, any extension MUST be placed after any existing mandatory
field for that message.
Editor's note: We should specify the requirements for registering
new TLV elements.
It is also desirable to allow vendors to use vendor-specific
extensions (in TLV format) in any of the RAMS messages. For
interoperability, such extensions MUST NOT collide with each other.
Editor's note: Some approaches are currently being examined for
vendor-specific extensions. A potential solution is depicted in
Figure 8. In this approach, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the vendor-specific extensions.
NEW:
Type: TBD
Section 7., paragraph 66:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mandatory Fields as Defined in This Document :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
Length: TBD
Section 7., paragraph 67:
OLD:
Figure 8: Structure of a vendor-specific extension
NEW:
The semantics of the RAMS-T feedback message is independent of the
payload type.
Section 13., paragraph 1:
OLD:
This document registers a new SDP attribute value and several new
RTCP packets.
The following contact information shall be used for all registrations
in this document:
NEW:
The following contact information shall be used for all registrations
in this document:
Section 13.2., paragraph 1:
OLD:
Within the RTPFB range, the following three format (FMT) values are
registered:
NEW:
Within the RTPFB range, the following format (FMT) value is
registered:
Section 13.2., paragraph 2:
OLD:
Name: RAMS-R
Long name: Rapid Acquisition of Multicast Sessions Request
Value: 6
Reference: This document
NEW:
Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions
Value: 6
Reference: This document
Section 13.2., paragraph 3:
OLD:
Name: RAMS-I
Long name: Rapid Acquisition of Multicast Sessions Information
Value: 7
Reference: This document
NEW:
13.3. SFMT Values for RAMS Messages Registry
Section 13.2., paragraph 4:
OLD:
Name: RAMS-T
Long name: Rapid Acquisition of Multicast Sessions Termination
Value: 8
Reference: This document
NEW:
This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for RAMS
messages. The registry is called the SFMT Values for RAMS Messages
Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226].
The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Value Name Reference
----- -------------------------------------------------- -------------
1 RAMS Request This document
2 RAMS Information This document
3 RAMS Termination This document
The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value 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 SFMT represents and how it
shall be interpreted.
Note that new RAMS functionality should be introduced by using the
extension mechanism within the existing RAMS message types not by
introducing new message types unless it is absolutely necessary.
13.4. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the
Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Type Description Reference
---- -------------------------------------------------- -------------
TBD TBD This document
... ...
The registry entries are TBC.
The TYPE values 0 and 255 are reserved for future use. The TYPE
values between (and including) 128 and 254 are reserved for private
extensions.
Any registration for an unassigned TYPE value 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 TLV element represents and
how it shall be interpreted.