|
From: | Steve Strobel |
Subject: | Re: [Linphone-developers] Voice quality on 3G and EDGE |
Date: | Tue, 07 Sep 2010 10:32:17 -0600 |
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 morethan 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 packetsFrom 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 packetI think this is a good approach. Maybe you can also switch codec on-the-fly to a more compressing codec.regards Klaus3) 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
[Prev in Thread] | Current Thread | [Next in Thread] |