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
_______________________________________________
Linphone-developers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/linphone-developers