vicidial.org

I have been playing around with the New ISO since it was handed to me in at the Scale 2 weekends ago, its great to have updates again

Anyway i don't want to be a party pooper but i am having an issue. I am not sure if this is related to the new install method or to the upgrade to Asterisk 11, but blind monitoring is not working for me.

In the user interface i got "SUCCESS" but my phone never ring.

So i went and made the API call directly in my browser

SUCCESS: blind_monitor HAS BEEN LAUNCHED - 2001a|192*168*001*251*08600063|2001|8600063|195018|superuser

It says SUCCESS again, but it is lying, this wasn't successful

So i went to Telnet 5038 and tried to replicate the API Call so i have

Action: Login
ActionID: 1
Username: superuser
Secret: superpassword

ActionID: 1
Message: Authentication accepted


Action: Originate
Channel: Local/192*168*001*251*08600063@default
Context; default
Exten: 2001
Priority: 1
Callerid: "VC Blind Monitor" <0000000000>

Response: Error
Message: Extension does not exist.

So Extension does not exist hummm???, maybe something is missing in the dialplan
So, then i log into asterisk cli and try to replicate the same command from asterisk CLI

channel originate Local/192*168*001*251*08600063@default extension 2000@default

It worked !!, but i am not happy because that confuses me even more

My Setup

VERSION: 2.12-538a BUILD: 160122-1401 | Vicibox 7.0 | 1 x DB/WEB + 2 x Telephony

Note that this error happens no matter if the monitored extension is in the same server of the monitoring extension or if they are in different servers it will failed when executed from the AMI and it will work when i run the command directly in Asterisk CLI.

Exten: 2001
channel originate Local/192*168*001*251*08600063@default extension 2000@default
2001a|192*168*001*251*08600063|2001|8600063|195018|superuser

your cli example which succeeded was 2000, but the previous example was 2001a or 2001.

you may want to check against the asterisk manager db entry to see which extension was tried and try to reconcile these slight differences. also check against the agent login entry (if that works) to see what is different. it may be reporting 2001 back to the user (alias?) but sending the call to the real extension on the real server (or attempting to do so?) 2001a

Sorry it was my mistake, because I was testing multiple scenarios and I mix them when copy the logs here. Neither with 2000a,2000b,2001a or 2000b is working with the API/AMI. But all are working on from asterisk click even cross servers example 2001b, monitoring 2000a

I didn't that from the telnet 5038 I can view real-time of the AMI calls I will try to watch the logs to catch the message directly from the API call

Have you compared those to the agent login, which should use the same technique? It's likely just a technical difference between asterisk 1.8 and asterisk 11 that was fixed in the agent login but not in the monitor/barge scenario. I'd check the asterisk manager entries in the vicidial manager table and see if there is a slight difference between the working and not working. May even be obvious.

Remember: These all start as entries in the DB. That's the simplest method/location to compare them.

Agent Login is working perfect. 2000a logs into server A and 2000b logs into server B so indeed i will compare the AMI logs for both scenarios. I will wait campaign stop working today because during the day a lot of logs are generated.

covarrubiasgg wrote:Agent Login is working perfect. 2000a logs into server A and 2000b logs into server B so indeed i will compare the AMI logs for both scenarios. I will wait campaign stop working today because during the day a lot of logs are generated.

not ami logs. Those are the result of the vicidial manager script sending the requests after taking them from the vicidial manager table. Look in the vicidial manager table for those differences first. You may avoid "log scouring" entirely.

William you were right compare the Login process with the Blind Monitoring was really helpful

Login Process Successful

Code: Select all

Action: Originate
Channel: SIP/2015
Context: default
Exten: 8600053
Priority: 1
Callerid: "S1602101622108600053" <9492032494>


Blind monitoring FAILED

Code: Select all

Action: Originate
Channel: Local/192*168*001*252*08600061@default
Context; default
Exten: 2015
Priority: 1
Callerid: "VC Blind Monitor" <0000000000>


You can see that there is a small difference between those 2, the monitoring uses Context; instead of Context:

A quick look into the non_agent_api.php and there is was the semicolon

Already made a patch and post it to the mantis tracker

Thank you very much for your help

My secret is that I break stuff all the time. Knowing how to find it, where to look, is often an art form. And definitely the most important part of any programming endeavor. The first question you must always ask in any programming process ... how do I check for errors? Where do I look?

We have lists of troubleshooting techniques for every situation.

Just fixed it in svn/trunk. Thanks for posting!

covarrubiasgg wrote:William you were right compare the Login process with the Blind Monitoring was really helpful

Login Process Successful

Code: Select all

Action: Originate
Channel: SIP/2015
Context: default
Exten: 8600053
Priority: 1
Callerid: "S1602101622108600053" <9492032494>


Blind monitoring FAILED

Code: Select all

Action: Originate
Channel: Local/192*168*001*252*08600061@default
Context; default
Exten: 2015
Priority: 1
Callerid: "VC Blind Monitor" <0000000000>


You can see that there is a small difference between those 2, the monitoring uses Context; instead of Context:

A quick look into the non_agent_api.php and there is was the semicolon

Already made a patch and post it to the mantis tracker

Thank you very much for your help

Hi covarrubiasgg

Is there something else besides semicolon that i need to fix in non_agent_api.php file?

because i have updated the file however is not working yet

cristianyctio wrote:Hi covarrubiasgg

Is there something else besides semicolon that i need to fix in non_agent_api.php file?

because i have updated the file however is not working yet

Pretty sure an upgrade would fix the issue these days. Matt fixed it in the code quite some time ago.