Skip to main content

9. IANA Considerations

The following contact information shall be used for all registrations included here:

The feedback profile as an extension to the profile for audio-visual conferences with minimal control has been registered for the Session Description Protocol (specifically the type "proto"): "RTP/AVPF".

SDP Protocol ("proto"):

FieldValue
NameRTP/AVPF
Long formExtended RTP Profile with RTCP-based Feedback
Type of nameproto
Type of attributeMedia level only
PurposeRFC 4585
ReferenceRFC 4585

SDP Attribute ("att-field"):

FieldValue
Attribute namertcp-fb
Long formRTCP Feedback parameter
Type of nameatt-field
Type of attributeMedia level only
Subject to charsetNo
PurposeRFC 4585
ReferenceRFC 4585
ValuesSee this document and registrations below

A new registry has been set up for the rtcp-fb attribute, with the following registrations created initially: "ack", "nack", "trr-int", and "app" as defined in this document.

Initial value registration for the attribute rtcp-fb

Value nameLong nameReference
ackPositive acknowledgementRFC 4585.
nackNegative AcknowledgementRFC 4585.
trr-intMinimal receiver report intervalRFC 4585.
appApplication-defined parameterRFC 4585.

Further entries may be registered on a first-come first-serve basis. Each new registration needs to indicate the parameter name and the syntax of possible additional arguments. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.

For use with both "ack" and "nack", a joint sub-registry has been set up that initially registers the following values:

Initial value registration for the attribute values "ack" and "nack":

Value nameLong nameUsable withReference
sliSlice Loss IndicationnackRFC 4585.
pliPicture Loss IndicationnackRFC 4585.
rpsiReference Picture Selection Indicationack, nackRFC 4585.
appApplication layer feedbackack, nackRFC 4585.

Further entries may be registered on a first-come first-serve basis. Each registration needs to indicate the parameter name, the syntax of possible additional arguments, and whether the parameter is applicable to "ack" or "nack" feedback or both or some different rtcp-fb attribute parameter. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.

Two RTCP Control Packet Types: for the class of transport layer FB messages ("RTPFB") and for the class of payload-specific FB messages ("PSFB"). Per Section 6, RTPFB=205 and PSFB=206 have been added to the RTCP registry.

RTP RTCP Control Packet types (PT):

NameLong nameValueReference
RTPFBGeneric RTP Feedback205RFC 4585.
PSFBPayload-specific206RFC 4585.

As AVPF defines additional RTCP payload types, the corresponding "reserved" RTP payload type space (72-76, as defined in [2]), has been expanded accordingly.

A new sub-registry has been set up for the FMT values for both the RTPFB payload type and the PSFB payload type, with the following registrations created initially:

Within the RTPFB range, the following two format (FMT) values are initially registered:

NameLong nameValueReference
Generic NACKGeneric negative acknowledgement1RFC 4585.
ExtensionReserved for future extensions31RFC 4585.

Within the PSFB range, the following five format (FMT) values are initially registered:

NameLong nameValueReference
PLIPicture Loss Indication1RFC 4585.
SLISlice Loss Indication2RFC 4585.
RPSIReference Picture Selection Indication3RFC 4585.
AFBApplication Layer Feedback15RFC 4585.
ExtensionReserved for future extensions.31RFC 4585.

Further entries may be registered following the "Specification Required" rules as defined in RFC 2434 [9]. Each registration needs to indicate the FMT value, if there is a specific FB message to go into the FCI field, and whether or not multiple FB messages may be stacked in a single FCI field. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated FB message (if any). The general registration procedures of [3] apply.

Last updated on