Dialer + Gateway concerns and questions

[KeithHBW]

Hello again, Im back with more questions about possibly improving our system.
First my setup and then my questions:
+Dialer:
-Vicibox 3.1.15 + voicesync
-screen -r shows 8 processes

+Gateway:
-Vicibox 3.1.15 + sangoma a104DE
-wancfg_dahdi
Repeat the following steps for each slot on sangoma
Select media type : T1
Keep settings: B8ZS (coding) / ESF (framing)
Clock: Normal
Signal Type: Zaptel/Dahdi PRI CPE
Switch Type: Nortel DMs100
Full T1?: Yes, use all channels
Dialplan context: From-internal
-vicibox-install
svn codebase
telephony
sangoma
-screen -r outputs: "There is no screen to be resumed."

My concern is that I still end up with NAs even though the CPD handles NAs. My errors from CLI are as follows:
Dialer: Unexpected control subclass, Broken pipe and Re-invited to non-existing call leg on other dialog.
Gateway: Fax detected, but no fax extension??* agi://127.0.0.1:4577/call_log failed connection refused.
-I run /usr/share/astguiclient/FastAGI_log.pl --debug which outputs:
DBI connect('asterisk:localhost:3306','cron',...) failed, which is to be expected because there is no database on this server.

Should I just go into that file and modify it to point to the actual database?

*Is this why fax calls are getting through the CPD?

If anyone needs more information let me know.

[williamconley]

1) Welcome back?

2) I see you are diligently trying to post your full specifications, here is a bit of help in that regard:

when you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

this IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) Approach one problem at a time. You listed several "errors" and a conflicting response to "screen".

4) -screen -r shows 8 processes Actually, I'm thinking you meant "screen -l"?

5) screen -r requires indicating WHICH screen you wish to resume (from a screen in the screen -l response list ...).

6) I'm not certain that sangoma CPD "handles" NA, but in theory if you have CPD properly installed, an "NA" response should actually involve a "No Answer Autodial" call as opposed to a disconnected number or other response. However: This is a matter you will likely need to take up with your installation documentation for that package.

7) Each of your other errors should be dealt with one at a time via google to see if any of them can be resolved (or need to be: a couple of them are actually not errors, just notices that are mislabled!).

[KeithHBW]

Well its not that I havent posted my full specifications... I just did it so often before and I know this problem is not related to my vicidial version, hardware... etc. The reason I dont post that stuff is because it keeps changing with each update. But here it is.

Vicibox 3.1.15 from .iso | Vicidialv.2.2.1 Build 110831-2038 | Asterisk 1.4.39.2-vici | Single Server | Sangoma Hardware a104DE | No Extra Software After Installation

My screen responses werent conflicting. One was a screen of the gateway and the other was a screen of the dialer.
screen -l clears my ssh window. screen -r for dialer shows:
There are several suitable screens on:
2859.ASTVDremote (Detached)
2764.asterisk (Detached)
2848.ASTupdate (Detached)
2863.ASTfastlog (Detached)
2861.ASTVDadapt (Detached)
2857.ASTVDauto (Detached)
2851.ASTsend (Detached)
2854.ASTlisten (Detached)
17768.pts-2.dialername (Attached)
for gateway shows:
There is no screen to be resumed.

6) I talked to someone from sangoma and didnt get any further with this issue. He said I shouldnt get NAs because the CPD should handle all the NAs. So he recommended I turn my dial timeout to max. Which it already is. I still havent gotten any further with CPDATB statuses either. I have 184 lines to dial on, I made 100 calls and still got 4 CPDATBs. Which stands for all trunks busy. Not sure how its possible for my trunks to be busy when I didnt even dial enough numbers to fill the lines.
7)I know I listed multiple problems at a time. But to describe my system setup each time is difficult as no one seems to understand it. So just explaining it once and then listing my current problems seems more efficient and maybe I would find the answer to one or more questions.
Also I have googled all these errors and the responses are so random its hard to tell where to start.

Anyhow, I am looking into these problems more today and will edit this post later.

[mcargile]

What do you have the dial timeout set to in the campaign? How many calls end up as NA verse the total number of calls placed. I have had clients using the CPA software that would get about 50 calls a day end up as NA out of 50,000. We were never really able to track it down any further than that though because we would have put the CPA server into debug level logging which can fill a hard drive when it is in production.

As for the Unexpected control subclass and Broken pipe messages those are just Asterisk being stupid and can be ignored. I have seen the Re-invite messages when using the CPA software and was never able to track it down for the same reason as above. At the same time I have not been able to correspond any actual problem calls to these messages so I just wrote them off as Asterisk being stupid as well.

The fax message is because someone is trying to send you a fax on your T1. You can ignore that if you like. It is probably fax spam anyways.

[KeithHBW]

Wow, thanks mcargile. Its basically just as you described. My dial timeout is 99 seconds. I was thinking about removing that field altogether and leave it blank but I have not tested it yet. And now that I have some closure I can stop worrying about those issues.

I have one last problem as described in my previous message. After that I will check campaign/list/server/system settings more to try to figure out other issues that may not be quite as big. Its the CPDATB status. Ive made 34000 calls today and 1600 of them have been CPDATB. Now as I mentioned I get these CPDATB statuses even when I only dial 100 numbers over the course of 30mins. Our max dials per second is 10. Maybe I just dont understand that status.

Anyhow, many thanks for that response. It was what I was hoping for. What I need to do now is analyze the actual amount of answering machines our agents are getting vs what they say they're getting.

[mcargile]

CPDATB is coming from either the carrier or the gateway. It basically means you are placing more calls than one of those can handle.

One thing that a client who had CPA setup for them noticed was that the number of answering machines getting to the agents actually increased, but the number of live people getting to them also increased. The built in Asterisk AMD is so bad that it makes tons of false positives. IE is was detecting live people as answering machines and hanging up on them. The ratio of live people to answering machines also increased. Their sales went up as a result of the change.

[KeithHBW]

So when I first setup a vicidial system with server X we got issues with the dialer not connecting calls. So one day we had to do an emergency replacement of that server. We took the sangoma card out of server X and put it in server Y. We used the same settings otherwise and the server has been dialing ever since.
Well we eventually needed another dialer in a new location (difference office, different city). So we took server X and put a new sangoma card in it and set it up just as we did server Y. Well it had the same problem with connecting calls, it didnt make any sense. I thought, what could be causing this? The network card? It couldnt be the sangoma card. Well after looking around I saw a word, 'switchtype', one day and I thought that was familiar. So I ran wancfg_dahdi and changed my switchtype from Nortel to National (one more commonly used in the US according to the site I read). After that the dialer has been working fine ever since.

My question is, what does that setting affect throughout the whole process? And would changing it on server Y improve calling quality or the CPD server's ability to detect properly (I havent had enough time with server X to determine this yet)? Seems funny to me that server Y works with the same settings and sangoma as server X when it wasnt connecting calls.

[mcargile]

Switchtype determines the signalling that is used when communicating with your carrier. Many of the switchtypes are so similar that they will work, but not very well if they are off. Many T1 carrier switches support several different signaling protocols. One will be better supported than any other. You want to be using that one. In most cases this is NI2 (National ISDN-2). Call your carrier and find out what the native signaling their equipment uses and have them set that as your T1s signalling. Then go into your config and set it to match.