vicidial.org

dspaan wrote:Ulaw/alow only uses 60kbps up/down. Are you telling me these work at home agents don't have that bandwith?

It uses around 100kbps when accouting for the IP traffic, jitter, packet loss on poor connections. Also, there is vicidial webpage and our crm that also takes the bandwidth.

We are ideally trying to get down to less than 50kbps including the ip traffic on the agents endpoints

dspaan wrote:Ulaw/alow only uses 60kbps up/down. Are you telling me these work at home agents don't have that bandwith?

Practical usage is closer to 100k.

And yes: We have many client's who have to use g729 because 100k often exceeds what they have available. Ya know, not every locality has 5Mx5M yet, and in some situations their upload just plain sucks (so Netflix is passable because it's one-way traffic and they may have darn good Download ...). Anything requiring traffic in both directions or for upload is problematic.

williamconley wrote:Soft phones can have g729 embedded. Most hardware VOIP phones have it installed by default. I don't know of any that have OPUS.

Both sides of the tunnel must have the codec for it to work.

GSM, however, is already in almost every VOIP device during a stock install and uses much less bandwidth than ULAW/G711. G729 uses even less bandwidth and is widely accepted in most devices, but costs money up until recently. Not sure if any softphones have g729 free yet, or OPUS. I'd let that be my guide if I were you (find out), but start with GSM as it's less CPU intense and already installed everywhere.

Please note that the codec you use with your agents is in NO way related to the codec you use with your carriers. Some people forget that too easily.

Thanks for the response.

As I have said before, the remote agents use desktops with chrome (webrtc/viciphone) as their endpoint. So whatever codec can run on chrome is what we can use. I am not sure if g729 will work on chrome.

I want to know the ranking for codecs in terms of the quality of the audio achievable on a poor and relatively latent connection between the asterisk cluster and agent endpoint.

I have just tested opus yesterday, even in wideband it kept below 50kbps. I want to try it in narrowband where the bandwidth goes down to just 16-24 kpbs at g711 quality....Where can I put config for opus as I have tried /etc/asterisk/codecs.conf but asterisk doesn't seem to be picking the configuration for opus from there.

Which codec is better to use in chrome/webrtc environment over low bandwidth (100-200kbps) network with 150ms latency to server?
Opus (only tested wideband, couldn't configure narrowband)
G729 (ok quality, worse than working g711, low bandwidth usage, same cpu usage as opus on poorer audio quality)
GSM (jittery, water sounds, quality poor)
G711 (is not able to cope, I have already tested it.)

The cluster has servers that have dual e5-2620 v3 processors. Generally the load is below 30%....Opus adds about 2-5% extra load which about the same as g729 for 30 endpoints.

I think if I am able to get narrowband setup on opus we might be able to get better output.

Based on all that, my opinion is: Test it thoroughly with all of them and report your results to us!

williamconley wrote:Based on all that, my opinion is: Test it thoroughly with all of them and report your results to us!

I will, but I couldn't get this configured to use narrowband. Anyone able to help with configuring opus.

vkad wrote:is opus installed by default in 8.1.2?

If my carrier doesn't do g729, is it even worth to do g729 over opus? in the end my carrier only does g711....

Also, is it possible to switchover to opus if the bandwidth is insufficient.

Also, how do I turn on opus? Any recommended settings?

Yes, I've said it before and I'll say it again, Opus is installed in ViciBox v.8.1.2.

As far as the rest of your questions, I don't even know how to respond. So I'll explain how codecs works:

1) A call is placed showing that it supports codecs X, Y, and Z in preferential order
2) The receiver of the call says that it supports codecs X and Z
3) Both sides agree to use codec X as they both support it and the side the sent the call prefers that over any other codecs

And that's it. There is no magic to be done. About the only thing that is going to support Opus besides Asterisk is WebRTC stuff.

Codec also has zero input or affect on latency. They only have varying techniques to hide jitter which is changes in latency.

As far as bandwidth used on the wire here's how they break down and how cpu heavy they are with least cpu usage at the top:
ULAW/G711 - 87Kbps (standard phone lines for the last 100 years)
GSM - 32 Kbps (What a cell phone uses)
G729 - 28Kbps
Opus - Variable, but 25kbps to 100+ depending on settings

vkad wrote:I will, but I couldn't get this configured to use narrowband. Anyone able to help with configuring opus.

You are literally the only person I know of who has been asking for Opus codec support. I was hoping you had used it before and had experience with it since it seemed like a very important requirement for you. It's literally a drop-in module for Asterisk 13 similar to how G729 works so I figured you had just been copying the two files you need to your Asterisk 13 installs and using it.

I didn’t know gsm used less bandwidth and is just as good. Why doesnt vicidial default to gsm?

Also how does viciphone with WSS compare bandwidth wise?

thephaseusa wrote:I didn’t know gsm used less bandwidth and is just as good. Why doesnt vicidial default to gsm?

Also how does viciphone with WSS compare bandwidth wise?

ULaw sounds better then GSM, and G729 is comprable to ULaw in sound quality. Also almost no carrier support GSM and those that do will have to transcode it which results in audio quality issues.

The only two codecs you can count to work globally with SIP are ULaw and G729.

WSS isn't a codec. It's a protocol like SIP and works in a similar fashion.

There is no magic bullet here. If you want things to just work you will stick with ULaw and G729 for SIP endpoints. WebRTC endpoints all depend on what the far-end browser/WebRTC framework uses.

Anyone else have the ISO hang at Starting D-Bus System Message Bus?

UNRELATED - But is it only me who is having an issue with amd with 8.1.2?

It would seem that we are as well. Call gets passed to agent and it is just silence. Going to rebuild and downgrade to 11 tonight.

Acidshock wrote:Anyone else have the ISO hang at Starting D-Bus System Message Bus?

not on any of our systems.

Sashen2137

It would seem there is specific updates to AMD and Dahdi for asterisk 13 in the last zypper up update, and SVN.

I was also having issues with AMD on asteirsk 13 / 8.1.2 on multiple servers. Alot of the calls are just silence. after downgrading to asterisk 11 / 8.0.1 everything went back to normal.

I am going to do this same tonight. Reports of the updates fixing the problem seem to not be accurate at first.

Interested to hear feedback on the downgrade. Nefariousparity, Did you see better results on the downgrade?

100% night and day difference, from cluster installs, to single instance installs from the 8.1.2 ISO. I reverted all servers back to 8.0.1. There is a way to do newest install with 8.1.2 and roll back to asterisk 11. However when I attempted that on a fresh install of 8.1.2 I would get errors complaining about codec. Like maybe a step was missing in that procedure. I would love to run the latest with just asterisk 11.25.3-vici would be great.

to be clear: you reverted your installation because of errors that could possibly have been easily resolved by changing some deprecated terminology? unless of course, you checked the errors and they were deep function problems instead of simple.

we've not had any problems with 8.1.2 EXCEPT when the version of Vicidial being installed did not support asterisk 13 (8.0 was asterisk 11, 8.1 is asterisk 13).

We also had an error downgrading to asterisk 11 from 8.1.2. we just had to disable the opus module by setting it to no load opus.so in the modules.conf file.

modules are compiled for the version of asterisk available at compile time, and if the module in question didn't exist when you recompile a different version, then a new module will not overwrite that existing one ... and it'll be left in the modules folder ready to run on the wrong version of asterisk with which it's not compatible. so a clean start (at least for the modules) is often best.