In Manual Dial No Live Call Showing

[scopor]

I am testing some live manual calls on vicidial but from the agent interface the live call not showing. I can hangup the call from within the agent interface but I can't transfer or place call on hold. I installed on single server with no additional hardware or features. Version 2.14-673a BUILD 180512-2217. I saw someone posted the same issue and they resolved it but they didn't state what the resolution was.

My dialplan entry looks like this.

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

exten => _8868NXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _8868NXXXXXX,2,Dial(SIP/tstt/${EXTEN:4},,To)
exten => _8868NXXXXXX,3,Hangup

Inbound calls work fine. The only issue is manual dial outbound calls. What am I missing? Some feedback would be greatly appreciated.

[mflorell]

Post the Asterisk CLI output from when you try to place a call.

[williamconley]

also provide step-by-step (button by button) method used to manual dial. no assumptions here, this often leads to simple solutions being overlooked.

[scopor]

Hello Matt. How are you thanks for your reply. Will get the output and post it back here. For some reason seemed to have locked myself out of the cli and will have to physically go to the server.

[scopor]

Here's cli output while on an active call.

[Jun 4 00:16:39] Connected to Asterisk 11.25.3-vici currently running on vicibox8 (pid = 2227)
[Jun 4 00:17:00] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:17:00] -- Executing [8600052@default:1] MeetMe("Local/8600052@default-0000002e;2", "8600052,F") in new stack
[Jun 4 00:17:00] > Channel Local/8600052@default-0000002e;1 was answered
[Jun 4 00:17:00] -- Executing [88683366028@default:1] AGI("Local/8600052@default-0000002e;1", "agi://127.0.0.1:4577/call_log") in new stack
[Jun 4 00:17:00] -- AGI Script Executing Application: (EXEC) Options: (Set(_CAMPCUST=05182018))
[Jun 4 00:17:00] -- <Local/8600052@default-0000002e;1>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Jun 4 00:17:00] -- Executing [88683366028@default:2] Dial("Local/8600052@default-0000002e;1", "SIP/tstt/3366028,,To") in new stack
[Jun 4 00:17:00] == Using SIP RTP CoS mark 5
[Jun 4 00:17:00] -- Called SIP/tstt/3366028
[Jun 4 00:17:01] > 0x7fc3e40148a0 -- Strict RTP learning after remote address set to: 172.20.1.4:20812
[Jun 4 00:17:01] -- SIP/tstt-0000003d is making progress passing it to Local/8600052@default-0000002e;1
[Jun 4 00:17:01] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:17:01] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 4 00:17:01] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:17:01] -- Executing [58600052@default:1] MeetMe("Local/58600052@default-0000002f;2", "8600052,Fmq") in new stack
[Jun 4 00:17:01] > Channel Local/58600052@default-0000002f;1 was answered
[Jun 4 00:17:01] -- Executing [8309@default:1] Answer("Local/58600052@default-0000002f;1", "") in new stack
[Jun 4 00:17:01] -- Executing [8309@default:2] Monitor("Local/58600052@default-0000002f;1", "wav,20180604-001700_8683366028") in new stack
[Jun 4 00:17:01] -- Executing [8309@default:3] Wait("Local/58600052@default-0000002f;1", "3600") in new stack
[Jun 4 00:17:01] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 4 00:17:02] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 4 00:17:06] > 0x7fc3e40148a0 -- Strict RTP switching to RTP remote address 172.20.1.4:20812 as source
[Jun 4 00:17:06] > 0x7fc3e40148a0 -- Strict RTP learning complete - Locking on source address 172.20.1.4:20812
[Jun 4 00:17:06] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:17:06] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 4 00:17:15] -- SIP/tstt-0000003d answered Local/8600052@default-0000002e;1
[Jun 4 00:18:01] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:18:01] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 4 00:18:06] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:18:06] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 4 00:19:01] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:19:01] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 4 00:19:06] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 4 00:19:06] == Manager 'sendcron' logged off from 127.0.0.1

Message from agent alert... dial timed out. contact your system administrator

As william asked the steps I took to dial a manual call are these.

1. from the agent interface click manual dial
2. enter 7 or 10 digit phone number in the phone number field
3. click dial now

[williamconley]

Create a new carrier with ID and Name and Description of "Generic" or "Default" or something equally innocuous.

No account entry or globals string. Protocol SIP (not that it matters).

Dialplan Entry:

Code: Select all

exten=> s,1,AGI(agi://127.0.0.1:4577/call_log)
exten=> s,n,NoOp(No Dial Pattern Matches This Extension)
exten=> s,n,Hangup

This should give you an error message you can see in the asterisk dialplan in the future. Handy.

Next we can discuss the dial pattern in your other carriers and why your attempt at manual dial does not generate any traffic in asterisk (likely because none of the patterns match ... the above dialplan entry will make this Visible and more obvious in the future).

What is your "manua dial prefix"?

What is the "Dialplan Entry" for your existing carrier?

[scopor]

Thanks William. You didn't say if to make the generic carrier active. Manual dial prefix is _8.

The dialplan entry for the existing carrier i am using for the said campaign re manual dial
exten => _8NXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _8NXXXXXX,2,Dial(SIP/tstt/${EXTEN:1},,To)
exten => _8NXXXXXX,3,Hangup

exten => _8868NXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _8868NXXXXXX,2,Dial(SIP/tstt/${EXTEN:4},,To)
exten => _8868NXXXXXX,3,Hangup

[williamconley]

Of course it should be active or there is no reason for it to exist.

Manual Dial prefix should be 8 not _8. There is no "_" digit. The ONLY time a "_" is used is to "signal" that what follows is a "pattern" instead of a "literal" and it's only for dialplan entries, not for dialing (ie: You also can not dial an X or an N, those are only for patterns).

Unfortunately, You can have a dial prefix of "X" because that character is stripped out during translation by Vicidial. Confusing when taken into account in this particular discussion.

In other words: It breaks the rules because it gets deleted and never gets anywhere near the actual dialer. Apparently this was done to avoid telling people to leave the dialplan prefix field blank because it would be confusing. lol

[scopor]

Not sure if we misunderstood each other William. In the campaign settings I have 8 not _8. I thought you meant to remove the _from the dialplan. Anyway based on my issue I described and the cli output can you point me as to what is causing the issue and how to correct it. I recall having this in the pass while doing test calls and it only shows up active when the agent saids hello but that's not working either.

[williamconley]

If you have put that default "s" dialplan in place and tried again, you should be getting a dial attempt in the CLI showing that there's no pattern match. This would confirm my suspicion that you have a mismatch between what you're dialing and what your system expects. The number dialed must match an existing pattern or asterisk won't even attempt to dial. So the "s" being active will catch and SHOW that mismatch, confirming my assertion.

But I don't see a CLI sample from after you added the new dialplan.

This is how dialplans match to "number dialed":

Accepted:

Code: Select all

_8NXXXXXX

_ = is dropped. It's ONLY there to signal "pattern, not literal". This is otherwise ignored.
8 = This must be the first digit dialed.
N = The second digit dialed may be 2-9, not 0 or 1
XXXXXX = The third through eighth digits can be any digit 0-9.

Total must be exactly eight digits and follow all the above rules to match this dial pattern.

Sent:

Code: Select all

81?

8 = (dial prefix: Supplied in the campaign, noted in the Manual Dial text around the 3rd line)
1 = (or 0, or nothing, supplied by the Dial Code in the Vicidial Lead Record or Omitted if the "Omit dial code" option is "Y" in the campaign, also in the "Dial Code" field on the agent screen during manual dial)
? Plus whatever the actual number you entered into the Phone Number field on the agent screen during manual dial.

Note that your pattern does NOT allow 1 or 0 to be the 2nd digit in the phone number. So ... "omit dial code" in the campaign and blanking the dial code field during manual dial may be wise.

This would be visible if the "s" Generic carrier were present to catch the "no pattern matches" entry/attempt. You may also see more details if you turn on debug mode and/or check the "vicidial_manager" table.

If your head explodes, take it one thing at a time. You'll get there.

[scopor]

So how do I tell vicidial to use the generic carrier you had me create instead of the real one I was using? is this what you want me to do to verify your suspicion? Should I add a steering digit?

[scopor]

If you have put that default "s" dialplan in place and tried again, you should be getting a dial attempt in the CLI showing that there's no pattern match. This would confirm my suspicion that you have a mismatch between what you're dialing and what your system expects. The number dialed must match an existing pattern or asterisk won't even attempt to dial. So the "s" being active will catch and SHOW that mismatch, confirming my assertion.

But I don't see a CLI sample from after you added the new dialplan.

This is how dialplans match to "number dialed":

Accepted:

Code: Select all

_8NXXXXXX

_ = is dropped. It's ONLY there to signal "pattern, not literal". This is otherwise ignored.
8 = This must be the first digit dialed.
N = The second digit dialed may be 2-9, not 0 or 1
XXXXXX = The third through eighth digits can be any digit 0-9.

Total must be exactly eight digits and follow all the above rules to match this dial pattern.

Sent:

Code: Select all

81?

8 = (dial prefix: Supplied in the campaign, noted in the Manual Dial text around the 3rd line)
1 = (or 0, or nothing, supplied by the Dial Code in the Vicidial Lead Record or Omitted if the "Omit dial code" option is "Y" in the campaign, also in the "Dial Code" field on the agent screen during manual dial)
? Plus whatever the actual number you entered into the Phone Number field on the agent screen during manual dial.

Note that your pattern does NOT allow 1 or 0 to be the 2nd digit in the phone number. So ... "omit dial code" in the campaign and blanking the dial code field during manual dial may be wise.

This would be visible if the "s" Generic carrier were present to catch the "no pattern matches" entry/attempt. You may also see more details if you turn on debug mode and/or check the "vicidial_manager" table.

If your head explodes, take it one thing at a time. You'll get there.

I really appreciate all the explanation William. I really do. I can actually dial out you know. I am calling my cell phone and also answering and can have two way audio. Just that the agent interface is not showing a live call to allow me to transfer or park the call. I can even see that I am on a call from the reporting screen. When I hang up the status goes from Dial M to Disp.

I am testing the closer option. It works if I dial inbound and then transfer to a closer. What I am trying to do is to manual dial out then transfer to closer but the agent window not showing that I am on a live call to allow me to transfer to closer.

[williamconley]

You're not supposed to "use this new carrier instead". This is a catch-all carrier for calls that will fail. Otherwise they would be invisible. We put it on all our servers to catch-kill bad numbers instantly (otherwise they get "stuck" and the system grinds to a halt). Having that active is quite handy. That's what the "s" extension does: It's a failsafe for "unmatched numbers" and is never used otherwise (unless you actually specify "s" in your program). Obviously none of your customer's phone number is ... "s". lol

But my problem was: I did not see that the call had succeeded. I read too quickly! My eyes scanned right over that.

If the vicidial controls are not available when you make a call via manual dial, and you entered the number in "Phone Number" and NOT in "Dial Override", then often the problem is the Asterisk Version during your install or upgrade. If that asterisk version is not correct in both /etc/astguiclient.conf and admin->Servers, Vicidial can use the wrong coding and disable transfers.

[scopor]

Thanks for the correction William. In /etc/astguiclient.conf the asterisk version is 11 and in admin->Servers 11.25.3-vici. The only control that is available when I make a manual dial using the phone number not the override is hangup. Is there anything else I can possibly check?

[williamconley]

Thanks for the correction William. In /etc/astguiclient.conf the asterisk version is 11 and in admin->Servers 11.25.3-vici. The only control that is available when I make a manual dial using the phone number not the override is hangup. Is there anything else I can possibly check?

From "perl install.pl":

Code: Select all

Enter the Asterisk version that you are installing VICIDIAL for
(value should be only one of the options below:)
 1.2
 1.4
 1.8
 11.X
 13.X


11 does not appear in the list. 11.X, however does. You may try that and see if you have luck. You may have to rebuild your .conf files (create a new phone or deactivate that new carrier and wait a minute for the reload before re-activating it)

[scopor]

Thanks for the correction William. In /etc/astguiclient.conf the asterisk version is 11 and in admin->Servers 11.25.3-vici. The only control that is available when I make a manual dial using the phone number not the override is hangup. Is there anything else I can possibly check?

From "perl install.pl":

Code: Select all

Enter the Asterisk version that you are installing VICIDIAL for
(value should be only one of the options below:)
 1.2
 1.4
 1.8
 11.X
 13.X


11 does not appear in the list. 11.X, however does. You may try that and see if you have luck. You may have to rebuild your .conf files (create a new phone or deactivate that new carrier and wait a minute for the reload before re-activating it)

This is what I am seeing in astguiclient.conf
# Asterisk version VICIDIAL is installed for
VARasterisk_version => 11

That's all no 11.X just plain 11.

[williamconley]

I'm saying "11" isn't an option and as such should not be there.

It should be one of the options listed during the install process, which has 11.X not 11. This may have had minor impact during the install (such as choosing which of the sample ".conf" files for that version of asterisk to copy during installation) and other minor impact after install during regular operations (such as writing "-vicidial.conf" files based on the asterisk version).

You may want to re-run the install.pl script with the proper option in place AND select the option to load the sample conf files to be sure. Which will also require re-editing the externip value in sip.conf, plus a reboot and will require verifying that the .conf files are rewritten after all that is done (ie: change a phone or carrier and make sure those changes are reflected in the newly created conf files).

[scopor]

I'm saying "11" isn't an option and as such should not be there.

It should be one of the options listed during the install process, which has 11.X not 11. This may have had minor impact during the install (such as choosing which of the sample ".conf" files for that version of asterisk to copy during installation) and other minor impact after install during regular operations (such as writing "-vicidial.conf" files based on the asterisk version).

You may want to re-run the install.pl script with the proper option in place AND select the option to load the sample conf files to be sure. Which will also require re-editing the externip value in sip.conf, plus a reboot and will require verifying that the .conf files are rewritten after all that is done (ie: change a phone or carrier and make sure those changes are reflected in the newly created conf files).

Appreciate the feedback William. However I am not sure what you mean by re-run the install script with the proper option. My vicidial/linux competence is not that extensive as you might think and I don't pretend to understand if I don't understand. I followed the install procedure on the vicibox7 pdf documentation for a single server setup. I also went back on eflo.net and re-downloaded the same vicibox7 instructions as I didn't see one for vicibox8. I can't recall going through the options you mentioned in the instructions during install. If you can guide me in repairing issue step by step or provide that procedure you mentioned as clearly the instructions I followed did not include those steps of choosing sample .conf files etc, I would greatly appreciate.

[williamconley]

If you look at the "UPGRADE" document in /usr/src/astguiclient/trunk, you will see the instruction for running the perl install.pl script. While you are not upgrading, that script can be used for a quick reinstall and reconfiguration as well.

That needs to be run with the 11.X being chosen and with "sample configuration files" = Y. And the externip value in sip.conf needs to be set in sip.conf after the new conf files are loaded (since that value will be wiped out during the re-install).

All that script does is copy all the necessary files to the proper locations. But it decides which ones based on that asterisk value, if it's not in the list of options, it'll grab a "default" set of configuration files which will not necessarily match your version of asterisk (probably pulls the values for 1.4 or 1.8, not 11).

Alternately, you could completely reinstall the system and that script will run again, during which this time you can choose 11.X instead of typing "11" which is not an option. It's also possible there was a bug in the install script that allowed 11 to be entered by default. In any event, the only way to be truly sure that values is properly populated and used throughout the system is to run the install.pl script again.

Never fear the reinstall. It's free and if you get used to it Vicidial can become much less intimidating. Really. Install it 5 or 6 times for the heck of it. Free. And educational.

[scopor]

Thanks man. Will give it a shot and let you know how it goes.

[williamconley]

Thanks man. Will give it a shot and let you know how it goes.

Note that running the perl install.pl script any time you get bored really shouldn't change anything, since all it does is copy files to where they belong. As long as they are still there, copying them again has zero effect. However: That "externip" value in sip.conf has to be edited each time. This is why we recommend avoiding making any changes to the stock configuration files. Means an upgrade or quick reinstall is simple.

[scopor]

I have never successfully upgraded vicidial without breaking it. That's has always been my fear. Not that I am not willing to try but that I figure the instructions are not as detailed as they ought to be. I think there should be specific instructions for single server install from cluster so that there is no confusion or mixed up. I have run the backup script but I am always afraid even with following instructions to the T. Case in point I followed the database upgrade instructions and got a whole lot of errors. I am so scared I'll have to reinstall from scratch again.

[williamconley]

You don't have to upgrade. You can do a parallel installation with the latest installer and move the DB into that, then upgrade the DB to match the latest code. No danger to the original.

Alternately, we don't ever "just run the sql scripts". We modify the first one to remove any commands that have already been run. That's done by finding the present db_schema and then finding that value in the sql file. Delete everything before it. Run only the commands that come after. Rarely get an error during that upgrade. The exception to that rule is Very Old systems have often have indexes created for values that violate the new index. But in those situations, the values can usually just be delete (the system will usually regenerate them during normal operation).

We've *never* had an upgrade actually fail. We've had a few that had to be re-done because of custom code (ie: upgrade into a different machine, re-code any custom code, then perform the database transfer again when everything works as a "final upgrade" before switching into the new server).

[scopor]

Thanks William for being there with me. I really appreciate you taking the time to explain. There's quite a lot I don't understand and I have the desire to get past this. Remember the reason I reached this point was to try to fix the Asterisk version 11 so that it reads 11.X. Ultimately to solve the issue of in outbound manual calls the live call wasn't showing in the agent window even with an active call. However after rerunning the install.pl script (that gave no errors), the content of the file remains the same.

# Asterisk version VICIDIAL is installed for
VARasterisk_version => 11

Can you please advise what else I can do without having to start over (reinstall).

[williamconley]

However after rerunning the install.pl ...

During this script, you are asked questions. One of the questions was Asterisk version as shown in a prior post viewtopic.php?f=4&t=38407&p=133926#p133864

You need to answer that question with one of the options presented, which is "11.X". You CAN alter that value before running the script and it should put "11.X" in for you when you run the script (simplifies things a bit). But be SURE to answer the question about "sample configuration files" with a "Y".

You can also execute install.pl with an option to "default to Y" for those sample configuration files. In fact, if you can use the install command switches to specify many things ...

Code: Select all

perl install.pl --copy_sample_conf_files --asterisk_version=11.X

[scopor]

Ok thanks for your patience and wisdom. I rerun the script. The first time I rerun it I said no to manual configuration so it did everything automatically. Hence the reason I didn't see where it presented the asterisk version. I was able to rerun it and use the manual configuration. However even though asterisk version is now reading as follows:
# Asterisk version VICIDIAL is installed for
VARasterisk_version => 11.X

It's still not showing an active call in the agent interface. Notice in the image link below I have the option of hanging up the call as well it's showing the recording filename. I ran into an issue with logging into the admin interface by changing the cron password. But after running it again and setting the cron password back to default I was able to log back in.

https://ibb.co/m6z47o


Is there anything else that may be causing this? Again thanks for your patience.

[thephaseusa]

In that screenshot you are trying to call a number (336)602-8. Is that a valid phone number?

[williamconley]

In that screenshot you are trying to call a number (336)602-8. Is that a valid phone number?

Actually, he's calling a local number: 336-6028. Seven digit dialing is a thing in some places. Hasn't been in the US for a long time.

And you're right, this may be a "too short phone number" flaw, but that's debatable.

It would be interesting to see the dialplan entry and possibly make a new one that includes the area code, but strips out the AC before sending the call to the carrier if the area code is forbidden.

The AGI script is firing, so there should be a visible entry in real time unless there is a crashed table or the server doesn't have the proper IP in astguiclient.conf (or admin->servers)

Honestly, I'd be tempted to re-install just because you're scared of it. Reinstall a few times and you won't be scared of it any more. Vicidial serves are disposable. Get good backups off your server nightly and you can rebuild a server whose hard-drive dies in a short time. IF you're not afraid of the re-install, that is. Sleep better at night after learning that, too. lol

[scopor]

You are right William. I can do either 7 digits or 10 digits dialing locally. The dial plan entry was posted earlier. I am not afraid for reinstalling for being afraid sake. Just that I have people on my back and it's in a remote location requiring physical access. Additionally reinstalling mean that we never really identify the root cause so that in the future if I were to be faced with the same situation I would not have known what was the cause and how to fix it other than to wipe the drive clean and reinstall.

Strange thing is that the call is being recorded. Except that I tried accessing the recording link and I am getting this.
Access forbidden!
You don't have permission to access the requested object. It is either read-protected or not readable by the server.

If you think this is a server error, please contact the webmaster.

Error 403
172.20.1.2
Apache

I checked all my permissions and I do have permission. I know you might say all the reason to reinstall (lol). But I love to find solution to issues instead of just giving up and starting over.

[scopor]

You know I just did another test and I am now seeing the live call in the agent interface. Tested with two different manual campaign. I believe the perl install fixed it. Maybe it needed more time to be applied. Not sure. Thanks for your help with this issue William. Really appreciated. If you can help me with error with accessing recording link.

[williamconley]

I checked all my permissions and I do have permission..

Check your apache logs. I bet you're wrong (actually, that's already a given ... when apache returns "you don't have permission" ... You Don't Have Permission. Whatever you checked was wrong). lol

Try to access the file again. Apache will immediately record your failure, and the reason, and the details for the reason, in the error log. So it should be "last line".

It will probably include the folder with the lacking permissions.

One solution, of course, is to invoke the "push to ftp server" function. Once set up properly, the recordings can be pushed via FTP to a web server site that can then share the files OFF the vicidial server. Thus removing the multiple terabytes of storage requirement from the Vicidial server. May not seem like much right now, but when you have a dead HD, reinstalling/restoring Vicidial is not particularly difficult. But restoring 2T of audio recordings? Ouch. Plus, backing all that up in the first place is a pain. Segregating the restore process (and waiting for 2T of restore ...) is a pain in the asp.

But your web server (with ftp to accept the files) can have a simple mirror (even a software-based mirror will work for that). So you'll never lose it all. If you're afraid of a hurricane destroying the entire machine (and both mirrored HDs) there's even a "spare copy" ftp function available so you can have a full copy on another "just ftp" server in another geographical location in case of catastrophic failure of the web server. We used to keep a spare copy of everything in Hawaii. No way Florida and Hawaii are hit during the same event. lol

Vicidial is a mature product. Backups of the backups of the backups is actually built-in. lol

[carpenox]

lol you rock william..... sarcasm/smartass > *