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

[Magnus Westerlund <[e-mail]>]

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

> 
> 
> 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.
> 
> FromRFC 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 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).
> 
> 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
> 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:
> 
> *     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 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------