I'll clarify how these fields are intended to be used. In the case where
"b=RS" and "b=RR" lines are not present the sender is allocated 1.25% of
the stream bitrate and the receiver is allocated 3.75% of the stream
bitrate. The "b=RS" and "b=RR" lines let you specify exactly how much
bandwidth to associate with the sender and receiver reports. If only one
of these lines is specified then the other value is assumed to be 5% of
the stream bandwidth minus the value of the specified field.

Damon you are right that by just specifying an b=RR value you are
basically specifying a reporting rate. We should either send a b=SR value
as well to insure a specific sender rate or we need to make sure that 5%
of the stream bandwith minus the b=RR bitrate is large enough for
a reasonable sender rate.

I just realized that the spec does not indicate what should happen if only
a b=RR line is specified and it is larger than 5% of the stream bitrate.
I'll ask a question about this on the AVT mailing list.

Now I'll try to answer your question about why the RTCP RR rate is usually
tied to the stream bitrate. By letting the reporting bitrate scale with the
stream bitrate you are basically able to guarentee a certain number of RR
packets for a certain amount of data sent. It may not make sense to have a
high reporting rate in a low bitrate stream because practically all of
the data would be the same between RR packets. In the high bitrate case
your reporting interval may be too low to quickly react to loss
situations. Scaling the report bitrate relative to the stream bitrate
allows you to deal with these scenarios.

I too am in favor of these parameters being handed into the SDP plugin as
stream headers. This removes any sort of policy decisions from the SDP
plugin and forces them to be in the core where they belong. I'd just reuse
the stream header names that the SDP parser uses when it parses the b=RS
and b=RR lines.

Aaron

On Wed, 2 Jul 2003, Damon Lanphear wrote:

> At 05:14 PM 7/2/2003 -0700, Go Hori wrote:
> >I would think RR value should be passed into the sdpmgen with header prop
> >value so you can actually change the value per stream (maybe based on clip
> >rate or delivery method).
>
> Perhaps I am unclear about the intended purpose of this field.  My
> assumption is that a given RTCP response mechanism will require feedback at
> a certain rate.  This rate is independent of the stream characteristics,
> but is dependent on the characteristics of the response algorithm.  The
> response algorithm is common across the streams.What are some examples of
> cases where we'd want to tie the RTCP RR rate to the stream characteristics?
>
> I think a good path would be to remove the registry query from the SDP
> code, and place it somewhere in the core and use the headers as you
> suggest.  This way we have the option of tieing the RTCP RR rate to stream
> characteristics if we discover a need.
>
>
>
> >Other than that:
> >Why is m_ulRTCPBandwidth a member variable?
>
> I'll just move storage for this info into the headers as you suggest.
>
>
> >Shouldn't config name be "RTCPRRBandwidth" to signify b=RR in case you
> >want to add one for b=RS later?
>
>
> sure.
>
> >Go
> >
> >On 2 Jul 2003, Damon Lanphear wrote:
> >
> > > Please review the following change to add support for setting the b=RR
> > > field in generated SDP descriptions.  The purpose of the change is to
> > > allow an end user to provide a rate at which RTCP ReceiverReports will
> > > be transmitted by the receiver of the described session.
> > >
> > >
> > > Index: sdpmdgen.cpp
> > > ===================================================================
> > > RCS file: /cvs/protocol/sdp/sdpmdgen.cpp,v
> > > retrieving revision 1.8
> > > diff -u -r1.8 sdpmdgen.cpp
> > > --- sdpmdgen.cpp      25 Jun 2003 21:06:03 -0000      1.8
> > > +++ sdpmdgen.cpp      2 Jul 2003 22:44:31 -0000
> > > @@ -52,7 +52,8 @@
> > >      m_ulVersion(ulVersion),
> > >      m_bUseOldEOL(FALSE),
> > >      m_bUseSessionGUID(FALSE),
> > > -    m_bUseAbsoluteURL(FALSE)
> > > +    m_bUseAbsoluteURL(FALSE),
> > > +    m_ulRTCPBandwidth(0)
> > >  {}
> > >
> > >  SDPMediaDescGenerator::~SDPMediaDescGenerator()
> > > @@ -71,7 +72,16 @@
> > >
> > >      if (pContext)
> > >      {
> > > -        pContext->QueryInterface(IID_IHXRegistry,
> > > (void**)&m_pRegistry);
> > > +     if (SUCCEEDED(pContext->QueryInterface(IID_IHXRegistry,
> > > (void**)&m_pRegistry)))
> > > +     {
> > > +         INT32 lTemp = 0;
> > > +         if
> > >
> > (SUCCEEDED(m_pRegistry->GetIntByName("config.MediaDelivery.Transport.RTCPBandwidth",
> > > +                                                 lTemp)))
> > > +         {
> > > +             m_ulRTCPBandwidth = (UINT32)lTemp;
> > > +         }
> > > +
> > > +     }
> > >
> > >          res = pContext->QueryInterface(IID_IHXCommonClassFactory,
> > >                                         (void**)&m_pCCF);
> > > @@ -687,6 +697,12 @@
> > >          SafeSprintf(psz256, 256, "b=AS:%u%s", avgBitRate, pszEOL);
> > >          mDesc += psz256;
> > >          bFoundAvgBitRate = FALSE;
> > > +    }
> > > +
> > > +    if (m_ulRTCPBandwidth)
> > > +    {
> > > +        SafeSprintf(psz256, 256, "b=RR:%u%s", m_ulRTCPBandwidth,
> > > pszEOL);
> > > +        mDesc += psz256;
> > >      }
> > >
> > >      mDesc += "t=0 0";
> > > Index: pub/sdpmdgen.h
> > > ===================================================================
> > > RCS file: /cvs/protocol/sdp/pub/sdpmdgen.h,v
> > > retrieving revision 1.2
> > > diff -u -r1.2 sdpmdgen.h
> > > --- pub/sdpmdgen.h    2 Jan 2003 22:02:02 -0000       1.2
> > > +++ pub/sdpmdgen.h    2 Jul 2003 22:44:31 -0000
> > > @@ -71,6 +71,7 @@
> > >      BOOL m_bUseOldEOL;
> > >      BOOL m_bUseSessionGUID;
> > >      BOOL m_bUseAbsoluteURL;
> > > +    UINT32 m_ulRTCPBandwidth;
> > >  };
> > >
> > >  #endif /* SDPMDESCPACK_H */
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe at protocol.helixcommunity.org
> > > For additional commands, e-mail: dev-help at protocol.helixcommunity.org
> > >
> > >
> >
> >--
> >Go Hori
> >ghori at real.com
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe at protocol.helixcommunity.org
> >For additional commands, e-mail: dev-help at protocol.helixcommunity.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at protocol.helixcommunity.org
> For additional commands, e-mail: dev-help at protocol.helixcommunity.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at protocol.helixcommunity.org
For additional commands, e-mail: dev-help at protocol.helixcommunity.org