vicidial.org

Good Morning!

I Recently installed a new ViciBox using ViciBox_Redux.x86_64-3.1.15.iso and SVN Update.
VERSION: 2.4-357a
BUILD: 120125-2107
© 2012 ViciDial Group

When Dialing, it shows a large percentage of my leads staying as the new status, and moves them to called. the calls are coming in slower the expected, so I am thinking these numbers are really not getting dialed out.

I also occasionally see these errors in the asterisk console.

WARNING[7914]: rtp.c:953 ast_rtcp_read: RTCP Read too short
WARNING[7982]: file.c:1297 waitstream_core: Unexpected control subclass '-1'
ERROR[6979]: utils.c:967 ast_carefulwrite: write() returned error: Broken pipe

My thought is perhaps I am dialing more lines then my carrier is allowing? I have my trunks set at 300, and my carrier promised me 450. not sure if that would have anything to do with it, but it just seems strange that the leads move to "called", and stay "new"

I really appreciate your help!

Thank you.

what is your dial method?

Ratio Dialing, Dial level of 6.

how many agents?

we are dialing with about 20 agents, why do you ask? it seems to do the same thing with less agents on, also their are hardly any NA's.

Like 6 NA's and 5,000 New Called.

have u tried manual dial and you can connect with no issue?

We don't have a problem getting calls, its just slower the usual, even if I crank it up to 12 for a dial rate override. also why are the calls dispostioning as new, and not like NA or some other status. i Don't believe it to be the network, because I have had to different builds on two different Networks doing it. So its either me dialing to aggressively for my carrier or the way I am setting it up. I have also had two different Carriers.

Could someone Please offer some insight on the messages I am receiving from asterisk console? I just wonder if they might have something to do with it. Especially the RTCP one.

WARNING[7914]: rtp.c:953 ast_rtcp_read: RTCP Read too short
WARNING[7982]: file.c:1297 waitstream_core: Unexpected control subclass '-1'
ERROR[6979]: utils.c:967 ast_carefulwrite: write() returned error: Broken pipe

try updating to the latest svn trunk

I think I already tried that. do you know what the asterisks errors mean?

this one is just fine

ERROR[6979]: utils.c:967 ast_carefulwrite: write() returned error: Broken pipe

not sure what the other message means

by the way i am on this version and never experienced issues
VERSION: 2.6-368a
BUILD: 120518-1456

ERROR[6979]: utils.c:967 ast_carefulwrite: write() returned error: Broken pipe

Is caused by the fact that Digium changed Asterisk to throw and error where it never complained before. Basically Vicidial is connecting to Asterisk, issuing a command, and not sticking around for Asterisk to send the success message. This has not been a huge priority for us as all functionality it still there.

WARNING[7982]: file.c:1297 waitstream_core: Unexpected control subclass '-1'

Has something to do with audio playback. Never fully figured out what, but it does not cause any problems. In my Asterisk 1.8 testing I cannot get Asterisk to create these messages so it is just something in 1.4.

WARNING[7914]: rtp.c:953 ast_rtcp_read: RTCP Read too short

Seen this a few times, and have never gotten a proper answer to what causes it. I know it is something to do with SIP, and it could cause audio problems.


As far as why you are getting new leads that are marked as called, you will need to trace them down in the logs to figure out why. It is normally caused by a lead being loaded with a bad phone number. When Vicidial places sends the action to Asterisk to place the call it will increment the call count. When asterisk tries to call the lead though, it fails so none of the call logging AGI scripts are run. Find one of these leads that was 'called' today and then open the screenlog file like this:

Code: Select all

#> less -r /var/log/astguiclient/screenlog.0

Search for the phone number by using the / key. Once you find it post all of the output from the moment the call started till it ended.

Below is the log.

[Jun 20 14:04:51] -- Executing [919108652784@default:1] Set("Local/919108652784@default-e4
90,2", "CALLERID(name)="Important Call"") in new stack
[Jun 20 14:04:51] -- Executing [919108652784@default:2] AGI("Local/919108652784@default-e4
90,2", "agi://127.0.0.1:4577/call_log") in new stack
[Jun 20 14:04:51] WARNING[29760]: rtp.c:953 ast_rtcp_read
: RTCP Read too short
[Jun 20 14:04:51] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jun 20 14:04:51] -- Executing [919108652784@default:3] Dial("Local/919108652784@default-e
490,2", "SIP/AloIn/19108652784||tToR") in new stack
[Jun 20 14:04:51] -- Called AloIn/19108652784
[Jun 20 14:04:51] WARNING[29736]: rtp.c:953 ast_rtcp_read
: RTCP Read too short

Then several lines down I have:

[Jun 20 14:04:51] -- Got SIP response 302 "Moved Temporarily" back from 4.59.189.245
[Jun 20 14:04:51] -- Now forwarding Local/919108652784@default-e490,2 to 'SIP/19108652784@4.59.189.248:51000' (thanks
to SIP/AloIn-00021b92)


then I don't see any thing else about it. Like nothing saying "making Progress"
the 302 is for 302 redirect. I am considering sending traffic(changing the carrier) to SIP/19108652784@4.59.189.248:51000' so that ip, and port=51000 and bypassing the redirect, but I am not sure that I should.

thanks again for your help, I really appreciate it

What does your carrier dialplan look like?

Account Entry


[AloIn]
allow=ulaw
type=friend
host=4.59.189.245
dtmfmode=rfc2833
context=trunkinbound
port=5060

[AloIn2]
allow=ulaw
type=friend
host=4.59.189.225
dtmfmode=rfc2833
context=trunkinbound
port=5060

[AloIn3]
allow=ulaw
type=friend
host=4.59.189.226
dtmfmode=rfc2833
context=trunkinbound
port=5060

Dialplan Entry

exten => _91XXXXXXXXXX,1,Set(CALLERID(name)="Important Call")
exten => _91XXXXXXXXXX,2,AGI(agi://127.0.0.1:4577/call_log)
exten => _91XXXXXXXXXX,3,Dial(${ALOIN}/1${EXTEN:2},,tToR)
exten => _91XXXXXXXXXX,4,Hangup

I also just got word from the carrier that they only see around 100 calls going out, and the interface shows 200.
That would probably explain why many are getting disposed as New, however, does this sound like a carrier issue or a server issue.
I am starting to worry its my equipment...

If you are calling somewhere other than the US and Canada try this:

exten => _91XXXXXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91XXXXXXXXXX,2,Dial(${ALOIN}/${EXTEN:1},,To)
exten => _91XXXXXXXXXX,3,Hangup

If you are calling in the US and Canada try this:

exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,2,Dial(${ALOIN}/${EXTEN:1},,To)
exten => _91NXXNXXXXXX,3,Hangup

Vicidial uses the Caller ID Name to keep track of calls. Modifying it can cause problems. As for US and Canada the area code cannot begin with a 0 or a 1 and the switch code cannot begin with a 0 or a 1 so by allowing numbers through that have 0 and 1 in those fields is a waste of resources.

As for the redirects, that might be the cause of your problem. I am not sure what that does to the channel variable and if Vicidial keeps track of the call properly after the call redirects.

You my Friend are better then Sliced Bread/Cheese.
that worked like a charm. calls are now showing up as NA and not New, my carrier confirmed that it is indeed passing through over 200 calls, the servers more stressed, and the agents are staying busy

I really Appreciate Everybody's Help.

Do you know how I would be able to change the caller ID name output, or am I better off having the DID Provider set something?

Again, Thank you, Thank you, Thank you

The only country in the world where carriers send out the caller id name you send to them to the customer is Canada. Everywhere else it is done as a look up by the far end carrier. As such if you are not in Canada you need to have your DID provider change it for you. In the US changing this is no guarantee though that it will actually show up on the far end customers phone. Carriers are allowed to cache caller id name for future use. There is also no limit on how long they can cache it for. Most do it for about two week. Some will cache them indefinitely. So if you have called a lead with that DID before, then get the name changed, the caller id name might take a few week, a few months, or even a few years to change, or it may never change for them.

If you are in Canada, there is a work around to allow you to send out caller id names and not mess up Vicidial. Doing so is rather complex though.