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

[Steve Strobel]

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, 
<http://www.dvsinc.com/products/VC-55.htm> 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.

Steve


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...
>
> Thanks
> Vadim
>
>
>
> 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
> > > environments.
> > > 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.
> >
> > regards
> > Klaus
> >
> > > 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?
> > >
> > >
> > > Thanks
> > > Vadim




---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:address@hidden