Skip to main content

4. SDP Definitions

This section defines a number of additional SDP parameters that are used to describe a session. All of these are defined as media-level attributes.

4.1. Profile Identification​

The AV profile defined in [4] is referred to as "AVP" in the context of, e.g., the Session Description Protocol (SDP) [3]. The profile specified in this document is referred to as "AVPF".

Feedback information following the modified timing rules as specified in this document MUST NOT be sent for a particular media session unless the description for this session indicates the use of the "AVPF" profile (exclusively or jointly with other AV profiles).

4.2. RTCP Feedback Capability Attribute​

A new payload format-specific SDP attribute is defined to indicate the capability of using RTCP feedback as specified in this document: a=rtcp-fb. The rtcp-fb attribute MUST only be used as an SDP media attribute and MUST NOT be provided at the session level. The rtcp-fb attribute MUST only be used in media sessions for which the "AVPF" is specified.

The rtcp-fb attribute SHOULD be used to indicate which RTCP FB messages MAY be used in this media session for the indicated payload type. A wildcard payload type ("*") MAY be used to indicate that the RTCP feedback attribute applies to all payload types. If several types of feedback are supported and/or the same feedback shall be specified for a subset of the payload types, several a=rtcp-fb lines MUST be used.

If no rtcp-fb attribute is specified, the RTP receivers MAY send feedback using other suitable RTCP feedback packets as defined for the respective media type. The RTP receivers MUST NOT rely on the RTP senders reacting to any of the FB messages. The RTP sender MAY choose to ignore some feedback messages.

If one or more rtcp-fb attributes are present in a media session description, the RTCP receivers for the media session(s) containing the rtcp-fb

  • MUST ignore all rtcp-fb attributes of which they do not fully understand the semantics (i.e., where they do not understand the meaning of all values in the a=rtcp-fb line);

  • SHOULD provide feedback information as specified in this document using any of the RTCP feedback packets as specified in one of the rtcp-fb attributes for this media session; and

  • MUST NOT use other FB messages than those listed in one of the rtcp-fb attribute lines.

When used in conjunction with the offer/answer model [8], the offerer MAY present a set of these AVPF attributes to its peer. The answerer MUST remove all attributes it does not understand as well as those it does not support in general or does not wish to use in this particular media session. The answerer MUST NOT add feedback parameters to the media description and MUST NOT alter values of such parameters. The answer is binding for the media session, and both offerer and answerer MUST only use feedback mechanisms negotiated in this way. Both offerer and answerer MAY independently decide to send RTCP FB messages of only a subset of the negotiated feedback mechanisms, but they SHOULD react properly to all types of the negotiated FB messages when received.

RTP senders MUST be prepared to receive any kind of RTCP FB messages and MUST silently discard all those RTCP FB messages that they do not understand.

The syntax of the rtcp-fb attribute is as follows (the feedback types and optional parameters are all case sensitive):

(In the following ABNF, fmt, SP, and CRLF are used as defined in [3].)

     rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF

     rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
                        / fmt   ; as defined in SDP spec

     rtcp-fb-val        = "ack" rtcp-fb-ack-param
                        / "nack" rtcp-fb-nack-param
                        / "trr-int" SP 1*DIGIT
                        / rtcp-fb-id rtcp-fb-param

     rtcp-fb-id         = 1*(alpha-numeric / "-" / "_")

     rtcp-fb-param      = SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-ack-param  = SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

     rtcp-fb-nack-param = SP "pli"
                        / SP "sli"
                        / SP "rpsi"
                        / SP "app" [SP byte-string]
                        / SP token [SP byte-string]
                        / ; empty

The literals of the above grammar have the following semantics:

Feedback type "ack":

This feedback type indicates that positive acknowledgements for feedback are supported.

The feedback type "ack" MUST only be used if the media session is allowed to operate in ACK mode as defined in Section 3.6.1.

Parameters MUST be provided to further distinguish different types of positive acknowledgement feedback.

The parameter "rpsi" indicates the use of Reference Picture Selection Indication feedback as defined in Section 6.3.3.

If the parameter "app" is specified, this indicates the use of application layer feedback. In this case, additional parameters following "app" MAY be used to further differentiate various types of application layer feedback. This document does not define any parameters specific to "app".

Further parameters for "ack" MAY be defined in other documents.

Feedback type "nack":

This feedback type indicates that negative acknowledgements for feedback are supported.

The feedback type "nack", without parameters, indicates use of the Generic NACK feedback format as defined in Section 6.2.1.

The following three parameters are defined in this document for use with "nack" in conjunction with the media type "video":

  • "pli" indicates the use of Picture Loss Indication feedback as defined in Section 6.3.1.

  • "sli" indicates the use of Slice Loss Indication feedback as defined in Section 6.3.2.

  • "rpsi" indicates the use of Reference Picture Selection Indication feedback as defined in Section 6.3.3.

"app" indicates the use of application layer feedback. Additional parameters after "app" MAY be provided to differentiate different types of application layer feedback. No parameters specific to "app" are defined in this document.

Further parameters for "nack" MAY be defined in other documents.

Other feedback types <rtcp-fb-id>:

Other documents MAY define additional types of feedback; to keep the grammar extensible for those cases, the rtcp-fb-id is introduced as a placeholder. A new feedback scheme name MUST to be unique (and thus MUST be registered with IANA). Along with a new name, its semantics, packet formats (if necessary), and rules for its operation MUST be specified.

Regular RTCP minimum interval "trr-int":

The attribute "trr-int" is used to specify the minimum interval T_rr_interval between two Regular (full compound) RTCP packets in milliseconds for this media session. If "trr-int" is not specified, a default value of 0 is assumed.

Note that it is assumed that more specific information about application layer feedback (as defined in Section 6.4) will be conveyed as feedback types and parameters defined elsewhere. Hence, no further provision for any types and parameters is made in this document.

Further types of feedback as well as further parameters may be defined in other documents.

It is up to the recipients whether or not they send feedback information and up to the sender(s) (how) to make use of feedback provided.

4.3. RTCP Bandwidth Modifiers​

The standard RTCP bandwidth assignments as defined in [1] and [2] MAY be overridden by bandwidth modifiers that explicitly define the maximum RTCP bandwidth. For use with SDP, such modifiers are specified in [4]: b=RS:<bw> and b=RR:<bw> MAY be used to assign a different bandwidth (measured in bits per second) to RTP senders and receivers, respectively. The precedence rules of [4] apply to determine the actual bandwidth to be used by senders and receivers.

Applications operating knowingly over highly asymmetric links (such as satellite links) SHOULD use this mechanism to reduce the feedback rate for high bandwidth streams to prevent deterministic congestion of the feedback path(s).

4.4. Examples​

Example 1: The following session description indicates a session made up from audio and DTMF [18] for point-to-point communication in which the DTMF stream uses Generic NACKs. This session description could be contained in a SIP INVITE, 200 OK, or ACK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Media with feedback
     t=0 0
     c=IN IP4 host.example.com
     m=audio 49170 RTP/AVPF 0 96
     a=rtpmap:0 PCMU/8000
     a=rtpmap:96 telephone-event/8000
     a=fmtp:96 0-16
     a=rtcp-fb:96 nack

This allows sender and receiver to provide reliable transmission of DTMF events in an audio session. Assuming a 64-kbit/s audio stream with one receiver, the receiver has 2.5% RTCP bandwidth available for the negative acknowledgement stream, i.e., 250 bytes per second or some 2 RTCP feedback messages every second. Hence, the receiver can individually communicate up to two missing DTMF audio packets per second.

Example 2: The following session description indicates a multicast video-only session (using either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. Such a description may have been conveyed using the Session Announcement Protocol (SAP).

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

The sender may use an incoming Generic NACK as a hint to send a new intra-frame as soon as possible (congestion control permitting). Receipt of a Reference Picture Selection Indication (RPSI) message allows the sender to avoid sending a large intra-frame; instead it may continue to send inter-frames, however, choosing the indicated frame as new encoding reference.

Example 3: The following session description defines the same media session as example 2 but allows for mixed-mode operation of AVP and AVPF RTP entities (see also next section). Note that both media descriptions use the same addresses; however, two m= lines are needed to convey information about both applicable RTP profiles.

     v=0
     o=alice 3203093520 3203093520 IN IP4 host.example.com
     s=Multicast video with feedback
     t=3203130148 3203137348
     m=audio 49170 RTP/AVP 0
     c=IN IP4 224.2.1.183
     a=rtpmap:0 PCMU/8000
     m=video 51372 RTP/AVP 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     m=video 51372 RTP/AVPF 98 99
     c=IN IP4 224.2.1.184
     a=rtpmap:98 H263-1998/90000
     a=rtpmap:99 H261/90000
     a=rtcp-fb:* nack
     a=rtcp-fb:98 nack rpsi

Note that these two m= lines SHOULD be grouped by some appropriate mechanism to indicate that both are alternatives actually conveying the same contents. A sample framework by which this can be achieved is defined in [10].

In this example, the RTCP feedback-enabled receivers will gain an occasional advantage to report events earlier back to the sender (which may benefit the entire group). On average, however, all RTP receivers will provide the same amount of feedback. The interworking between AVP and AVPF entities is discussed in depth in the next section.

Last updated on