[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Voice quality on 3G and EDGE

From: Vadim Lebedev
Subject: Re: [Linphone-developers] Voice quality on 3G and EDGE
Date: Wed, 08 Sep 2010 11:17:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100713 Lightning/1.0b2pre Thunderbird/3.0.6

 Hi Steve,

Sure FEC could be useful, but simple packet retrasmisions have one enromous advantage: on the receiving side nothis special need to be done... The RTP stack will simply eliminate the duplicates... That means that ANY softphone on the recieving side will
be compatible


On 09/07/2010 06:32 PM, Steve Strobel wrote:
If you have the bandwidth to retransmit packets, you might be better off using forward error correction (FEC) instead. This is often done when sending digital audio between radios (think very advanced walkie-talkie type radios). For example, <> describes sending 2450 bps of codec data and 1150 bps of FEC. I suspect that the FEC used there is optimized for fixing a few bad bits in each packet, but by interleaving data from successive packets (which adds latency), you could make a similar system fill in the data for missing packets.

Another option would be using TCP rather than UDP, so only the packets that were actually missed would be retransmitted. Of course that totally changes how the application handles the networking API calls. It seems like I read somewhere about a masters/doctorate thesis that modified Linphone to use TCP.

Stream Control Transmission Protocol (SCTP) is yet another option.

My limited experience with 3G (Verizon EVCO) is that it is extremely bursty, with huge amounts of jitter (500mS or more) when the signal gets marginal.


At 06:36 AM 9/7/2010, you wrote:
Hi Klaus,

I'm not sure that switching better-compressing codec will have a big impact because IMO most routers worry about number of packets more
than size of the packets.

The strategy of retransmiting some packets did perform excetptionnaly well for me back in time when i was doing VOIP over dialup connections. The trick was - upon detecting a packet loss of x% to retransmit 2x% randmly chosen packets.

Of course 3G end EDGE have different behaviour...


On 09/07/2010 12:31 PM, Klaus Darilion wrote:
Hi Vadim!

Am 07.09.2010 09:54, schrieb Vadim Lebedev:
Hello folks,

We're trying to improve mediastreamer behaviour on 3G and EDGE
For this we use RTCP receiver reports to detect changes in reported
jitter, bandwidth and packet losses.

Once we detect the degradation we can adopt following strategies:

1) We can start retransmitting some/all RTP packets

From my experience this makes things worse. Usually GPRS/EDGE/UMTS is very reliable - you have hardly packet loss. Thus, if the connectivity is bad (=small available bandwidth but still reliable) and you start sending even more packets you will fill up the sending buffers of the mobile device even more, causing even more packet loss in the sending buffer and increasing the delay.

2) We can pack more audio per packet

I think this is a good approach. Maybe you can also switch codec on-the-fly to a more compressing codec.


3) In case of hard congestion we can stop sending media and wait until
congestion resovled

Strategies 1 and 3 are pretty simple to implement.
But strategy 2 is less trivial to implement with mediastreamer.
I'm thinking to hook a reformatting filter just before the encoder this
way i'll need no modifiy all aduio input drivers to
suppport variable payload size per packet.

Simon what do you think?


Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)

Linphone-developers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]