[MMUSIC] RTCP bandwidth modifiers in a unicast SDP Offer/Answer

["Elad Chomsky" <elad at juniper.net>]

Hello mmusic experts,

I was wondering if there are guidelines to how RTCP bandwidth modifiers
(RFC 3556) should be interpreted in the context of a unicast SDP
Offer/Answer. It appears to me that two interpretations are possible;
one more inline with RFC 3264 and another more inline with RFC 3556.


According to RFC 3264, the bandwidth attributes appearing in an SDP
Offer indicate the amount of bandwidth that the Offerer would like to
accept; and should therefore limit the amount of bandwidth that the
Answerer sends. Applying this principle to the RTCP bandwidth modifiers,
we get the following behavior:

* When the Answerer is an active data-sender, it should send RTCP using
a bandwidth no greater than the sum of the "b=RS" and "b=RR" attributes
that appear in the Offer.

* When the Answerer is not an active data-sender, it should send RTCP
using a bandwidth no greater than the value of the "b=RR" attribute that
appears in the Offer.

The same is true for the RTCP bandwidth modifiers appearing in the
Answer, with the roles of the Offerer and Answerer reversed.


The above interpretation seems straightforward and useful. However I am
not sure how inline it is with RFC 3556. That RFC deals with only a
single pair of "b=RS" and "b=RR" attributes that indicates the _total_
RTCP bandwidth of the session. Therefore we would have something like:

* The Offerer and Answerer should both limit their RTCP to below
(RS+RR)/2; if both are active data-sender.

* The Offerer should limit its RTCP to below RS while the Answerer
sjould limit its RTCP to below RR; if only the Offerer is an active
data-sender.

* Etc.

However I am not sure whether the "b=RS" and "b=RR" should be taken from
the Offer or Answer (or some interaction between the two).


Many thanks,
Elad Chomsky, Juniper Networks
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic