Sangoma AMD solution

[ameir1]

We are looking at Sangoma Lyra AMD - what is the recommended vicidial configuration for this?
What are everyone's experiences with this? Installation difficulties?

We have 2 different vicidial setups. One is a single server XeonCPU E5440 @ 2.83GHz, 8 cores, 8 GB RAM, 270 GB HDD which has the database, Asterisk 1.4.39.2, and web server running Vicidal VERSION: 2.4-310a BUILD: 110506-1537 with SuSE Linux 11.3
The other is a vicidial cluster. Same versions of installations, just divided across 2 servers - one is Asterisk and Web server, the other MySQL.
Thanks!

[Michael_N]

vicidial has support for sangoma netborder callanalyser

[mflorell]

Lyra is just another name for Sangoma's Netborder Call Analyzer. Sometimes referred to as CPD(Call Progress Detection) or CPA(Call Progress Analysis). Vicidial has integrated with it for several years and it works great if integrated properly.

[ameir1]

"if integrated properly".
Are there any installation issues? We used vicibox for our install which is SUSE and we were told that it needs centos.
As well, do you have special pricing for this product?

[Michael_N]

Lyra should run on a seperate server windows or centos

[ameir1]

should it not run on the same server as the asterisk dialer?

[williamconley]

it requires a dedicated server. while this server may be Linux, there are port conflicts that would stop it from running on the same server.

[ameir1]

Thanks.
We've set it up on both a Windows Server and Linux, and get the same problem: when we choose to run the call through the proxy with CPA off, it works fine. But when CPA is on, we get one-sided communication. Any ideas?
And that was just testing internal calls - not going outside of our network.

[williamconley]

probably a routing issue. have a look at your sip packets and see who's failing. usually one-sided sound is a firewall issue. so your "internal" network may have an active iptables or other form of firewall blocking ports it believes should not be in use. if so, turn OFF any internal iptables or other firewalls to test.

also, i've often found that "oddities" introduced in making internal calls will introduce a problem that would never be seen with a "real" call. so look at anything unusual you have done for this call to be internalized. and consider that the cost of one or two test calls is mere pennies. test on a real carrier.