Re: [Ekiga-devel-list] DCCP

[Haeernilion]

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.

___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] DCCP

[thomas schorpp]

Damien Sandras wrote:

Le dimanche 08 juin 2008 à 07:48 +0200, Dr. Christian Hoene a écrit :

Hello Eugen Dedu,

yes I think that will be way VoIP will evolved. It not a question  
whether but when.


As we are planing this implementation for a research project, we need  
to be a bit ahead of the line.


Lets work together on this issues? I am actually not sure where to add it ;-)



and it is not limited to the packets length...



I don't think so.

http://en.wikipedia.org/wiki/User_Datagram_Protocol
The Datagram Congestion Control Protocol (DCCP) is being designed as
a partial solution to this potential problem by adding end host TCP-friendly 
congestion control behavior to high-rate UDP streams such as streaming media.


-so only a partial solution of a becoming less potential problem due to advances 
with codecs which will slow down excessive UDP traffic.


-most soho embedded routers and firewalls are based on very old linux kernels 
without DCCP-
support and the DCCP wikipedia article states not much implementations since 
years.

since 2006 university playground, but patches for Ekiga are welcome ;)

y
tom

___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list