vicidial.org

Hello all, We are trying to configure a Sangoma D100 transcoding card on GoAutoDial (actually tried several versions of ViciDial). We have it working fine on manual outbound calls and inbound calls. But when I load a list to test predictive dialing with transcoder, it calls 'my cell' I answer but it does not transfer the call to my waiting inbound agent session and it hangs up the call.
Predictive dialing from list works fine when we do not use the transcoding card.
We have Sangoma looking into it but they have not come up with anything yet.
Has anyone gotten this to work with their installation?

We have configured a few of these and have not run into any issues like this.

Can you post Asterisk CLI output from a call where this happens?

Can you post your configuration of the D100?

Here is CLI from dialer calling from list and not passing the call.

-- Executing [912107222479@default:1] AGI("Local/912107222479@default-7265,2", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing [912107222479@default:2] Dial("Local/912107222479@default-7265,2", "SIP/voipinnovationscarrier/12107222479||tTor") in new stack
-- Called voipinnovationscarrier/12107222479
-- SIP/voipinnovationscarrier-00000009 is ringing
== Manager 'sendcron' logged off from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
-- SIP/voipinnovationscarrier-00000009 is making progress passing it to Local/912107222479@default-7265,2
-- SIP/voipinnovationscarrier-00000009 answered Local/912107222479@default-7265,2
-- Executing [8368@default:1] Playback("Local/912107222479@default-7265,1", "sip-silence") in new stack
-- <Local/912107222479@default-7265,1> Playing 'sip-silence' (language 'en')
[Jul 20 08:55:16] WARNING[21305]: file.c:1297 waitstream_core: Unexpected control subclass '-1'
-- Executing [8368@default:2] AGI("Local/912107222479@default-7265,1", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing [8368@default:3] AGI("Local/912107222479@default-7265,1", "agi-VDAD_ALL_outbound.agi|NORMAL-----LB") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi
-- AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0
-- Executing [8368@default:4] AGI("Local/912107222479@default-7265,1", "agi-VDAD_ALL_outbound.agi|NORMAL-----LB") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi
== Manager 'sendcron' logged off from 127.0.0.1
-- AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0
-- Executing [8368@default:5] Hangup("Local/912107222479@default-7265,1", "") in new stack
== Spawn extension (default, 8368, 5) exited non-zero on 'Local/912107222479@default-7265,1'
-- Executing [h@default:1] DeadAGI("Local/912107222479@default-7265,1", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
-- Executing [h@default:1] DeadAGI("Local/912107222479@default-7265,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----17-----4") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... --17-----4 completed, returning 0
== Spawn extension (default, 912107222479, 2) exited non-zero on 'Local/912107222479@default-7265,2'


Dialer LAN is 192.168.25.229
D100 is set to IP 10.1.1.1. , sngtc_cfg --server --asterisk set to dev eth1 as card is eth1 and base IP range for transcoding modules set to default 10.1.1.150 for the transcoder IP, default udp base value set to 15000.

/etc/asterisk/sangoma_codec.conf
register= g729
rtpip=10.1.1.1

This is all config we have done on it so far. Currently try to get it to work with carrier on g729 and agent phone on ulaw. Phones are SNOM320 with all codecs enabled and in order of preference for this config.

Sangoma tech is scheduled to take a look at 11am eastern today.
Mark

In CLI, all I see is that one warning about Unexpected control subclass.
Nothing else unusual.

Mark

Well, Sangoma has not been able to get to my ticket on this. Matt, I am sure I am just missing final configuration steps somewhere. Could you reply back with list of conf files that need to be set? The only one I know of to setup is the sangoma_codec.conf.
I have followed instructions on Sangoma's wiki and have the card working on manual dials and inbound calls, just not on predictive dialed calls.

Sangoma support sees nothing wrong with my config. They spent 3.5 hours in my dialer looking, watching and testing. Here is where we are at.
G729 on both carrier and agent phone is working for inbound calls and manually dialed calls. It does not work when dialing from a list. By does not work, the dialer will connect to a call but not pass it to available agent and when the callee answers, the dialer hangs it up.
CLI shows nothing unusual. VDAD statuses call as NA.
Sangoma support wants to know what the CPA is expecting from the transcoder card during predictive dialing from a list.

What are we doing wrong?

You are using a Sangoma CPA with this setup? I didn't see that mentioned anywhere else in here. I didn't think the CPA worked with anything but g711.

Matt, We are not using Sangoma CPA. I think Sangoma tech is referring to ViciDial doing CPA. This is an out of the box install of GoAutoDial CE 2.1 with no additional software other than the Sangoma sngtc software, codec modules and Micrel drivers for the PCI based card.
We have tried to use the transcoder on recent versions ViciBox Server, Vicibox Redux (Micrel drivers for PCI card will not work consistantly with OpenSuse), scratch Install on CentOS 5.5 - 5.6, Redhat Enterprise 5.0 all with and without SVN trunk.
We have not been able to solve this problem. Sangoma support has exhausted their efforts.
(A quick tip for anyone looking to use Sangoma transcoder with ViciDial, Buy hardware with PCI-e slot and use the Sangoma PCI-e card so you can use ViciBox Redux)

We don't really support redhat-family distros in general because of all of their kernel and stability issues.

We have only installed PCIexpress D100 cards so far, so we aren't really familiar with any PCI issues you may be having.

We have it working on GoAutoDial CE 2.1 with SVN with the exception on the predictive dialing problem when using the card. Matt, if we need to hire someone to look at this for us we are wiling. I am pulling my hair out and my boss is not too happy about the delay on implementing this dialer.
Are you game?

Update: Still no progress on this. When using g729 and dialing from list, VDAD statuses call as NO ANSWER AUTO DIAL with length_in_sec = 0.
I login as agent, fire up my test list, it calls my cell, I answer and dialer hangs up.
Change the carrier and agent phone to ulaw, all is right with the world. Does anyone have any idea what I am doing wrong? Any particular log I should be looking at?

Just call up or email support and ask for Mike, he has the most experience with the D100 here at the ViciDial Group.

We've created a short guide for configuring Sangoma D100 for GoAutoDial here:

http://goautodial.org/projects/goautodialce/wiki/HowTo_configure_SangomaD100

It'll of course work with other Vicidial systems with minor adaptations. Feedback is appreciated.

Many thanks go out to Gardo. To all you Vicidialers (all flavors) out there here are a few tips we learned along the way on this.
If your going to use Sangoma transcoder card on Ubuntu or OpenSuse, use the PCI-e version ONLY. The Micrel drivers for the PCI card are not stable on these OS's. The PCI-e is treated as Broadcom device and works fine with OpenSuse and Ubuntu.
Treat the transcoder card as a network device. That includes firewall considerations, localnet in sip.conf etc including the Soap server subnet for the card, not just the card's physical IP.
Be sure to unregister conflicting codecs in sangoma_codec.conf as per the Sangoma wiki whether you think you need to or not. You will avoid many headaches. Just do it.
After testing the free g729 codec and the Sangoma transcoder, I can tell you the Sangoma device is the way to go.
Our goal was to reduce bandwidth loads and increase call quality particularly in our Jamaica office. Jamaica accesses the dialer in our Texas office through VPN and Jamaica Internet access is not the best in the world but usable. We considered another box in Jamaica using IAX to this one but there are many logistical reasons in Jamaica not to do this.
Once we have this box in production and some dialing time under our belt, I will let the community know what kind of results we have.

Happy dialing!

Thank you very much for posting your experiences. We also have had a very good experience with the D100. We have had one running for the last year and a half in our colo handling upto 300 concurrent G729 channels with great results.

And see, we never use that because we have too much bandwidth. LOL. But now we know where to send users with those issues.

Man this is gett'in weird. Everything was hunky dory over the last few days on this issue. Last worked on July 29th. Came in today to test some more, dialer transferred one call from the list to and agent (me) and that was it. Same problem is back.
Only thing that changed was we relocated the DB onto the production DB server on the 28th. I reconnected dialer back to it's local copy of the Db and the first predictive call it made worked. (Transferred to agent). After that, no more. So I currently I am looking for a date stamp problem on the leads. Any suggestions? Maybe start looking for the Allstate commercial mayhem guy hanging around in my server room?

"Recalculating!"

Take that CentOS cr@p and toss it out the ... LOL

You mentioned "database server", but have not otherwise described your network (unless it was in an earlier post I didn't read).

Did you sync the time on this new server to the rest of the cluster?

Did you remember to change the database reference on all the satellite servers? (non-db)

Did you "regenerate .conf files" on all servers after the switch, and verify IAX2 registration between all servers?

Yeah I really did not want to run CentOS but as mentioned in earlier posts, we have PCI transcoder card and the Micrel drivers are not stable on Ubuntu and OpenSuse. 'Wish I had hardware with PCI-e and the PCI-e version of this card.
Just one DB server and one asterisk/web server on same network. I keep time synced to my internal time server that is synced to public time server.
I did not rebuild conf files. Will look at that. I just finished restoring backup clone image to the dialer and so far it is working well. I have to finish configuration for production so this time I am going to change one item at a time, test and verify. I am sure it is something I changed during final config but I do not know what.

it seems the last changes you made was the reason it went awry.

When you moved your database to another machine, did you check the db connection?

And also have you tried to turn it off and on again?

williamconley wrote:Did you "regenerate .conf files" on all servers after the switch, and verify IAX2 registration between all servers?

And remember I'm not suggesting this as a way to "fix" incorrect settings (since those settings should not have changed!), but more of a confirmation that all the connections work now just like they did before the database server changed. If all the servers have good connections to the database server and can pull data, the configuration files will rebuild and registration will go smoothly. If anything is "wrong" with the connections, either the conf files will never be rewritten OR they will be empty (thus no registrations).

Well, it seems that there is something that the rebuild conf files action touches on the transcoding. When I ran that, it started working again and has remained working.
But, I ran a virtual message campaign of about 1800 leads and audio quality started degrading. I do not yet have cron set to reboot the dialer every night. When I manually rebooted, audio quality came back. Hopefully the transcoder and Asterisk will run for 12 hours maintaining audio quality without needing to be rebooted until the nightly reboot.

Our experience with systems requiring reboot has been 72 hours max. Some every other day. So rebooting nightly has (on all systems presently running) completely resolved the issue.