Re: [Ekiga-devel-list] DCCP

[Haeernilion <tdbuman gmail com>]

I'm currently working on a TFRC integration to obtain a video rate control
that is adaptive to the network conditions (e.g. congestion state). Up til
now, I were using RTCP receiver reports (RR) and sender reports (SR) to
calculate the following parameters:

at the sender:
- localRTT = ReceiverReportArrivalTime - LSR - DLSR
- TFRC rate as a function of the RTT and of the loss event rate p. The
encoding rate is then adjusted as a function of this rate.

at the receiver:
- loss event rate, as a function of the received RTT parameter, which is
then returned to the receiver

Both, the loss event rate and the RTT values are transmitted in application
defined messages (APP) with the SR and RR messages using a RTCP compound
packet.
So far, this scheme works pretty well and the encoding rate adapts
"on-the-fly" during an RTP session according to the congestion faced on the
network.

Well, this post is about optimizing this scheme, since I recently came
across a different way of computing and transmitting the necessary TFRC
parameters that seems more efficient concerning the RTCP bandwidth
constraints (RTCP traffic should take no more than 5% of RTP traffic): RTP
with TCP Friendly Rate Control
(http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10)
Especially the requirement for a feedback message to be sent at least every
RTT could generate a considerable overhead (ex. in a LAN) with my scheme. As
this new scheme would eliminate the need for SR or RR (which are used to
calculate the RTT in my scheme), I am wondering why the RTCP SR and RR were
initially used for in Ekiga/Opal. So far, I could not find a reason for
this... I would be glad if someone could explain their use in Ekiga or
whether these reports can be eliminated without loosing any required
functionality.

Thank you,
Thomas


-- 
View this message in context: http://www.nabble.com/DCCP-tp17711387p23938663.html
Sent from the Ekiga Dev mailing list archive at Nabble.com.