[hxprotocol] CR: b=RR support for SDP generation
Sean Robinson srobinson at real.comIt might be resonable to always include b=SR if we have a configured b=RR value. At least that wasy it's explicit... S > -----Original Message----- > From: Damon Lanphear [mailto:damonlan at real.com] > Sent: Thursday, July 03, 2003 10:51 AM > To: Aaron Colwell > Cc: Go Hori; dev at protocol.helixcommunity.org > Subject: Re: [hxprotocol] CR: b=RR support for SDP generation > > > I think we also need to handle the case where we don't know the average > bitrate of the stream. This may be the case for VBR content, > correct? In > which case we need to provide a way for administrators to specify > a default > RTCP RR/SR rate, and/or specify an update frequency for use when > the stream > rate is ambiguous. > > At 11:46 PM 7/2/2003 -0700, Aaron Colwell wrote: > >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.Transpo > rt.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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe at protocol.helixcommunity.org For additional commands, e-mail: dev-help at protocol.helixcommunity.org