Subject: [AVTCORE] Do RFC 4585 and RFC 5104 mandate the usage of the a=rtcp-fb SDP attribute?

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 8 Nov 2012 18:26:02 +0100

Dear RTP/AVPF experts,

Triggered by some recent discussion in 3GPP SA4, I would welcome your opinion on the following question:

Do RFC 4585 and RFC 5104 allow sending the RTCP feedback messages defined in those RFCs, if AVPF has been negotiated using SDP offer-answer, but no  a=rtcp-fb SDP attribute was included in the SDP negotiation?

A more detailed discussion is below:

>From RFC 4585:

4.2.  RTCP Feedback Capability Attribute

...
   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.
...
   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"

   o  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);

   o  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

   o  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.

>From RFC 5104

7.2.  Offer-Answer

   The Offer/Answer [RFC3264] implications for codec control protocol
   feedback messages are similar to those described in [RFC4585].  The
   offerer MAY indicate the capability to support selected codec
   commands and indications.  The answerer MUST remove all CCM
   parameters corresponding to the CCMs that it does not wish to support
   in this particular media session (for example, because it does not
   implement the message in question, or because its application logic
   suggests that support of the message adds no value).  The answerer
   MUST NOT add new ccm parameters in addition to what has been offered.
   The answer is binding for the media session and both offerer and
   answerer MUST NOT use any feedback messages other than what both
   sides have explicitly indicated as being supported.  In other words,
   only the joint subset of CCM parameters from the offer and answer may
   be used.

   Note that including a CCM parameter in an offer or answer indicates
   that the party (offerer or answerer) is at least capable of receiving
   the corresponding CCM(s) and act upon them.  In cases when the
   reception of a negotiated CCM mandates the party to respond with
   another CCM, it must also have that capability.  Although it is not
   mandated to initiate CCMs of any negotiated type, it is generally
   expected that a party will initiate CCMs when appropriate.

   The session maximum packet rate parameter part of the TMMBR
   indication is declarative, and the highest value from offer and
   answer SHALL be used.  If the session maximum packet rate parameter
   is not present in an offer, it SHALL NOT be included by the answerer.

A suggested Interpretation for RFC 4585 in 3GPP SA4 was :

The SDP offer may or may not include one or more a=rtcp-fb attributes for negotiating various AVPF feedback messages. (this is of course assuming that AVPF is negotiated on the m= line).

IF attribute lines with a=rtcp-fb are NOT included THEN
      Both end-points may send any AVPF FB messages (if AVPF is agreed)
      It is not guaranteed that any AVPF FB messages will work (in either direction)

IF attribute lines with a=rtcp-fb are included for some or all of the AVPF FB messages THEN
      The answerer must remove the attribute lines for the AVPF FB messages it does not want to use
      Only those AVPF FB messages that are in the SDP answer are allowed to be used, i.e. it is forbidden to send the AVPF FB messages that are not in the SDP answer

Is that correct?

Does the same interpretation apply for RFC 5104?

Based on:  "The answer is binding for the media session and both offerer and answerer MUST NOT use any feedback messages other than what both  sides have explicitly indicated as being supported. " , the following alternative interpretation has been suggested:
*     Every CCM FB message that one intend to use must be negotiated in SDP offer-answer.
*     Any CCM FB message that has not been negotiated (and therefore is not agreed) in SDP offer-answer cannot be used in the session.

Many thanks for your help,

Thomas

---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 8 Nov 2012 14:11:57 -0500

Hi Thomas,
>
> 
> Do RFC 4585 and RFC 5104allowsendingtheRTCP feedback messages defined in
> those RFCs, if AVPF has beennegotiatedusing SDP offer-answer, but
> no a=rtcp-fb SDP attributewas includedin the SDP negotiation?
> 

Yes, I think it is allowed based on Section 4.2 of RFC 4585:

   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.

The above SHOULD allows for exception to explicitly indicate the FB
messages that is to be used. However, I would remember that this SHOULD
is an IETF SHOULD. See RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

So, if one is not going to do this one better have a good reason for not
using a=rtcp-fb attribute to indicate which feedback messages that are
supported. I would guess that the intention for the SHOULD is to allow
cases where SDP is used, but it is not really possible for the entity
providing the SDP to indicate the actual set of feedback messages that
are supported on the end-point(s).

>From my perspective, I would use the signaling if it is available. It
makes it explicit which of the messages types that are supported by the
end-points.

Cheers

Magnus

> …
> …
> FromRFC 5104
> A suggestedInterpretationforRFC 4585in3GPPSA4was :
> 
> The SDP offer may or may not include one or more a=rtcp-fb attributes
> for negotiating various AVPF feedback messages. (this is of course
> assuming that AVPF is negotiated on the m= line).
> 
>       Only those AVPF FB messages that are in the SDP answer are allowed
> to be used, i.e. it is forbidden to send the AVPF FB messages that are
> not in the SDP answer
> 
> Is that correct?
> 
> 
> Based on: “The answer is binding for the media session and both offerer
> andanswerer MUST NOT use any feedback messages other than what both 
> sides have explicitly indicated as being supported. “, the following
> alternative interpretation has been suggested:
> 
> *     Any CCM FB message that has not been negotiated (and therefore is
> not agreed) in SDP offer-answer cannot be used in the session.
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------