nik600
2009-Apr-05 19:43 UTC
[asterisk-users] what can we do with lost voice packet on a congestioned VPN?
Hi to all in a scenario where: - the bandwith is shared with other traffic (HTTP,VPN,ecc) - the PBX is on a remote VPN peer - due to many reasons Qos is not usable There is a IAX trunk between 2 Asterisk 1.4 i've tried different codecs (ulaw,alaw,gsm) but the main problem still remain the same: too many voice packet get lost. The main problem is surely on the network, but the strange thing is that on the same network there is an H323 trunk from an Alcatel and a Cisco CCM (using g711 codec) and in that case the voice isn't so bad! i've tried to enable jitterbuffer but i can't notice some difference. Is there something else that i can do? Thanks to all -- /*************/ nik600 http://www.kumbe.it
Julio Arruda
2009-Apr-05 19:54 UTC
[asterisk-users] what can we do with lost voice packet on a congestioned VPN?
nik600 wrote:> Hi to all > in a scenario where: > > - the bandwith is shared with other traffic (HTTP,VPN,ecc) > - the PBX is on a remote VPN peer > - due to many reasons Qos is not usable > > There is a IAX trunk between 2 Asterisk 1.4 i've tried different > codecs (ulaw,alaw,gsm) but the main problem still remain the same: too > many voice packet get lost. > > The main problem is surely on the network, but the strange thing is > that on the same network there is an H323 trunk from an Alcatel and a > Cisco CCM (using g711 codec) and in that case the voice isn't so bad! > > i've tried to enable jitterbuffer but i can't notice some difference. >I think if you have packet loss, a jitterbuffer would make no difference.. SOmething like PLC (packet loss concealment maybe ?) come to mind ? Have you tried ILBC ? or SPEEX ? G.711 should be resilient, but I understand iLBC and Speex both have some tricks to handle PLC. Also, GIPS had some kind of magic sauce they offered (code-wise) to offer PLC to vendors ??> Is there something else that i can do? > > Thanks to all >
Jason Aarons (US)
2009-Apr-05 21:10 UTC
[asterisk-users] what can we do with lost voice packet on acongestioned VPN?
I wonder if using the "Internet Low Bit Rate Codec" or iLBC would work better. G711/G279/GSM all suffer when too many packets are lost. You would then need to transcode to G711, etc -jason http://en.wikipedia.org/wiki/Ilbc -----Original Message----- From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of nik600 Sent: Sunday, April 05, 2009 3:43 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [asterisk-users] what can we do with lost voice packet on acongestioned VPN? Hi to all in a scenario where: - the bandwith is shared with other traffic (HTTP,VPN,ecc) - the PBX is on a remote VPN peer - due to many reasons Qos is not usable There is a IAX trunk between 2 Asterisk 1.4 i've tried different codecs (ulaw,alaw,gsm) but the main problem still remain the same: too many voice packet get lost. The main problem is surely on the network, but the strange thing is that on the same network there is an H323 trunk from an Alcatel and a Cisco CCM (using g711 codec) and in that case the voice isn't so bad! i've tried to enable jitterbuffer but i can't notice some difference. Is there something else that i can do? Thanks to all -- /*************/ nik600 http://www.kumbe.it _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ----------------------------------------- Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you.