What does AGI(agi://127.0.0.1:4577/call_log) do?

[haider_raza]

Hi,

I was reading through the extensions.conf file and don't understand how vicidial places calls. I couldn't find the call_log agi script anywhere. I am assuming asterisk is serving agi:// scripts. Also, after the number is dialed, the dialplan has a hangup command. Shouldn't that hangup the channel? What does this command AGI(agi://127.0.0.1/call_log) do? Where is the call_log stored and what script reads through it to look for HANGUPCAUSE codes?

Thanks,

[williamconley]

Howdy. If you read the manager's manual, you will find some answers on how the setup and interface works.

If you want the "guts", the best method is to build one (vicibox) or even just pop in the demo (also on vicibox, demo) and then look through the files and read the comments in them.

call_log in this case isn't a "script". I note that when you asked:

What does this command AGI(agi://127.0.0.1/call_log) do?

you changed the code slightly from the subject line:

Post subject: What does AGI(agi://127.0.0.1:4577/call_log) do?

the :4577 is extremely important. There is a listener script running on port 4577. This script has a function for call_log, which is what is being invoked.

I'm not sure if I'm describing it correctly, but it's as close as I can get really. The point is: you cannot ignore the :4577, or ANY individual component or even character in a script or a dial plan (even if you know what it is). This software is unique, and accomplishes a task that was heretofor overwhelming for those attempting to write "dialers" in asterisk. As such, Matt (the creator and maintainer of the software, along with his company) has put a great deal of time into making the system work "Just So".

If you build a system (or fire up a demo) and verify that it works ... then you could try some modifications and see what can/can't be ignored/deleted/revised. Until then, if you want to learn the system ... you have two ways to go: install it as given (do not learn how the internal combusion engine interacts with the fuel recovery system, JUST TURN THE KEY, the engine will run ...) OR get ready for a serious learning curve.

Of course, you could do like I am: BOTH. Use it as it is, learn as you go, and make changes to suit your own needs (and the needs of your clients). If you do that, it works better. Also, if you have a live (functioning, in production) system, the learning curve seems much better.

So if you are curious: Start with finding out what is listening on port 4577 of 127.0.0.1 and what will happen in that script if you invoke "call_log" as a switch/argument/function and whether data will be stored or the "call" modified through an agi call or both or what. It is all quite intricate, but also right there in the code.

[gzpxyj]

I think the poster is trying to learn the asterisk. The best place to learn asterisk is from asterisk forum.

[martyn]

Hi haider_raza

Look this http://www.voip-info.org/wiki/view/Asterisk+AGI

Regards.

[williamconley]

I couldn't find the call_log agi script anywhere. I am assuming asterisk is serving agi:// scripts. Also, after the number is dialed, the dialplan has a hangup command. Shouldn't that hangup the channel? What does this command AGI(agi://127.0.0.1/call_log) do? Where is the call_log stored and what script reads through it to look for HANGUPCAUSE codes?

That is because the script is not NAMED call_log.

The agi system fires up a web address (127.0.0.1:4577) which is localhost at port 4577. There is a script listening on port 4577 which receives the data sent by the agi application framework. call_log is a "switch" (a mere piece of information) sent along for the ride to basically say "and log this, while you're at it".

The purpose of the script is to wake up vicidial's scripting/control system to the existence of this call. It will then cause other functions to MODIFY the channel for tracking purposes (essentially "attaching" vicidial to this call).

You've got a lot more learnin' to do before you can wrap your mind around Vicidial. LOL

And to answer the other questions: There are MANY call logs. They are all stored in the asterisk database. Each has a table which ends in "_log". And there are many scripts which look for many things, but I do not have any idea why you believe one is looking for hangupcause codes. But: The "hangup" extension in every context in extensions.conf (as you will note!) has a special agi script that performs this task. And it doesn't actually do the heavy lifting itself, I think, I believe it merely activates another script (or two? never looked ...) that will then go through and find the log entries and modify the call times and kill the necessary table entries based on the termination of the call.

[mcargile]

In particular this AGI command is calling a FastAGI

http://www.voip-info.org/wiki/view/Asterisk+FastAGI

With a regular AGI script Asterisk has to call a script on the local system. This script has to be executed by the operating system like any other program. This takes time. Vicidial's back end scripts are written in perl which adds more time onto this execution as perl scripts have to be compiled every time they run.

With FastAGI the script is launched once on boot. It stays running in memory constantly waiting for a network connection. This means that the script does not need to be compiled or launch by the OS in order to start processing. When one comes in it can immediately start acting on the request.

There used to be a regular call_log agi script that was called every time the system initiated a call or hung up a call. When it was changed from a regular AGI script over to a FastAGI script there was between a 10 and 20% reduction in load on heavy outbound systems.

Before people ask why we have not converted the other AGI scripts over if there is such a reduction in load is because they are called far less than call_log. The performance improvement would be negligible. Also FastAGI scripts are harder to debug and develop for.

[williamconley]

That was quite concise. Has converting it to a C++ binary executable been considered? If you were to build in debugging ... optional for proper loading when debugging is not in use ...

I wonder if anyone has performed a map showing load of each process running to see where the best improvement could be made.