[Vtigercrm-developers] Asterisk Good News

Thu Aug 28 04:21:10 GMT 2014

The proxy approach taken would help us stay loose coupled with Asterisk and
provide neutral interface to Vtiger. This benefit may not be obvious and
sound like a overhead
but give it a thought.

We generally lean towards working with APIs than DB with other application
- yes there would be performance benefits but would it comes against the
cost of maintenance and configurations. It would be the choice to consider
when you pursuing CRM and Asterisk
to be on the same server.

As said earlier, there are many approaches possible to get the integration
- we have taken one of them that can retain loose coupling. We are
interested to learn other approaches experts from our community would
evolve with.

Regards,
Prasad

*Connect with us on: *Twitter <http://twitter.com/vtigercrm> *I* Facebook
<http://www.facebook.com/pages/vtiger/226866697333578?sk=wall> *I* Blog
<https://blogs.vtiger.com/>* I* Wiki
<http://wiki.vtiger.com/index.php/Main_Page> *I *Forums
<https://discussions.vtiger.com>*I* Website <https://www.vtiger.com/>

On Thu, Aug 28, 2014 at 2:01 AM, vtiger at camden.net <vtiger at camden.net>
wrote:

> I know it does not pull from asterisk DB at all
>
> I was saying if you did it would not be necessary to pull in intervals at
> all, you pull only when data is needed, the fetch cdr by clicking on pbx
> manger was example of needed the data that would cause a pull,
>
> if you did that it would be not be needed for vtiger to maintain its own
> call logging and CDR functions, it would also give bonus that calls make
> outside of scope of vtiger would show in PBX Manager in vtiger
>
> also pulling from asterisk vtiger would not need to force call recording
> on every call, which is a waste of system resources, especially if asterisk
> is already recording calls, not just a waste of HD space but call recording
> uses CPU always introduces latency into a call so you dont want both can
> have negative impacts on call quality
>
> by taking call recording out of vtiger you also put the decision to call
> record or not back in hands of asterisk admins and end users that want or
> dont want call recording, call centers are the only business In my
> experience that want every call recorded no matter what, they typically do
> it out of a call queue and have an announcement to satisfy legalities "your
> call may be recorded for quality and training" most everyone else typically
> just wants the feature code to turn it on and off on the fly
>
>
>
>
>
>
>
> ------------------------------
> *From*: "Akshath T.A" <akshath.t at vtiger.com>
> *Sent*: Wednesday, August 27, 2014 3:45 PM
>
> *To*: vtiger at camden.net
> *Cc*: vtigercrm-developers at lists.vtigercrm.com
> *Subject*: Re: [Vtigercrm-developers] Asterisk Good News
>
>  ?Vtiger will not poll asterisk DB every time when user clicks on
> PBXManager to fetch CDR. Once the call is disconnected connector would send
> the CDR event and vtiger would store these information in
> "vtiger_pbxmanager" table. So whenever PBXManager is opened Vtiger fetches
> information from this table and displays it for the user.
>
>
> regards,
> AKshath
>
> On Wed, Aug 27, 2014 at 9:42 PM, vtiger at camden.net <vtiger at camden.net>
> wrote:
>>
>> yes the overhead for AMI listen can be issue
>>
>> normally dealt with by giving the AMI user Origination and Read Call only
>> rights, that cuts down on 99% of what you need to parse
>>
>> in larger deployments where even the overhead of incoming calls to other
>> extensions is burdensome, AMI proxy where each user has a proxy user that
>> only listens to AMI data relevant to there own channel(s)
>>
>>
>> I would think you would only pull SQL data when user in vtiger clicks on
>> PBXmanager (the user version where they can see the call logs, not the one
>> for admin to change settings), and display the data rather than pulling it
>> all the time and creating your own tables, if remote access to SQL is the
>> concern its easy to write a php XML API, thats how our windows based call
>> notification works for vtiger so we did not have to open SQL to outside
>> world, when call comes in we take incomming phone number send it to our
>> API, the API does all the SQL queries, then returns XML of the results, we
>> did this with php, all that would be required is for you guys to say hey
>> put this php file on your asterisk server and modify the database name,
>> user and secret to match
>>
>>
>>
>>
>>
>> ------------------------------
>> *From*: "Akshath T.A" <akshath.t at vtiger.com>
>> *Sent*: Wednesday, August 27, 2014 11:09 AM
>> *To*: vtiger at camden.net
>> *Cc*: vtigercrm-developers at lists.vtigercrm.com
>>
>> *Subject*: Re: [Vtigercrm-developers] Asterisk Good News
>>
>>  VtigerAsteriskApp does not modify any configuration of Asterisk
>> directly. We have recommended
>> changes to be made in Asterisk configuration to get the AGI request back
>> to the App.
>> Please make sure to track the changes in case you need to revert back.
>>
>> AGI vs AMI
>>
>> AGI events are listened for incoming calls as AMI event parsing had to
>> deal with bit-of overhead
>> (as we did in 5.4.0 Asterisk Integration). To origniate outgoing call AMI
>> action is used
>> (borrowed from our earlier implementation).
>>
>> Working with AGI events is lot-easier than processing AMI ourselves. The
>> hard-work
>> is taken care by the asteriskjava library.
>>
>> Polling Asterisk DB from CRM server was not a model considered as both
>> the applications can be setup on different machines.
>> Also php script used for regular polling in short-intervals (specially
>> during active call handling) demands
>> server resources and impatcts CRM performance - we had encountered this
>> in our earlier implementation.
>>
>> The approach of implementation we have taken may not be the only way to
>> get the integration.
>> We are hopeful to see more such coming from community and take away the
>> learning from the same.
>>
>>
>> regards,
>> AKshath
>>
>>
>>
>>
>> On Wed, Aug 27, 2014 at 7:39 PM, vtiger at camden.net <vtiger at camden.net>
>> wrote:
>>>
>>> yes I am aware of what it was saying... but 101 was most certainly a
>>> valid extension, at the same time this was going on we could send our own
>>> origination command to AMI for 101 to call out and it worked just fine,
>>> that error is not produced by asterisk at all, its not a valid asterisk
>>> error return, you are mis-interrupting some other error and reporting it
>>> back as a asterisk error
>>>
>>> I think it was some error inside your java, at the time this was
>>> happening we only saw data stream on webapp.sh on the click to call
>>> attempts, we where also looking at data streams on your agi.sh saw nothing,
>>> the cli with agi and verbose 10 notifications enabled saw nothing, and we
>>> also looking at the AMI stream, nothing there as well, so we dont even
>>> think your connector was even talking to asterisk at all
>>>
>>> we fixed the issue last night, stopped the webapp.sh and agi.sh files
>>> and prevented them from start @ boot, rebooted, cleared settings in vtiger
>>> PBX manager or rather put in a bunch of junk, saved, rebooted, put settings
>>> back into PBX manager, rebooted then turned the .sh files back on, not sure
>>> what steps fixed but simple stop and start of .sh files and/or system
>>> reboots did not fix
>>>
>>>
>>> we still have issue on on test server where it seems vtiger altered
>>> something in asterisk where all the extensions we had in vtiger no longer
>>> will ring though a call queue, we have no data on the event we where not
>>> actively monitoring data streams, and your asterisk connector has never
>>> written 1 log to its own log directory, everything was working Friday, and
>>> Monday we checked on it again and found that vtiger was stuck in endless
>>> loop of inbound notification and those extensions would no longer sent a
>>> sip invite though call queue, even after they where removed from vtiger and
>>> a reboot, and the asterisk connector was completely shut down, keep in mind
>>> these are test servers dedicated to getting vtiger to work, they are lamp +
>>> asterisk + freepbx + vtiger only we have not moved into phase of testing
>>> with other packages so the problems we are having can only be vtiger, this
>>> is what concerns us about closed source java+agi, beyond we can not see
>>> code to try to help you we now have situation where it seems your connector
>>> and AGI have altered asterisk, we dont know whats it doing.
>>>
>>> the whole reason we advocate for just use the AMI is its simple and
>>> works and your not really doing anything that requires the interactivity
>>> that AGI allows, AMI can be used to originate call as well as be monitored
>>> for inbound, this is how tapi drivers work that plug into on site CRMs like
>>> ACT, SAGE CRM, Lexis Nexus, ect, its also how sugar / sweet crm are
>>> handling it
>>>
>>> I think the tiring the call records to data in vtiger is a great idea,
>>> but why are you generating your own CDR log's via AGI, and this is where I
>>> think you guys are hung up on using AGI, but asterisk does have it own
>>> MySQL tables and CDR reccords, why not during the isntall of vtiger ask for
>>> the asterisk database name and credentials and query them for the info, and
>>> vtiger should not be forcing all calls to record, asterisk gives us ways to
>>> record and not record calls, if you want to link to recordings fine but
>>> again you should be looking to see if a call was recorded, beyond a
>>> performance issue and potential duplication of whats already being done in
>>> the Asterisk, this ventures into a legal issue, a lot of places all parties
>>> must be notified and consent to call recording, with vtiger it forces the
>>> recording
>>>
>>> the general rule of thumb here is if you need user input like your
>>> making a IVR and logging what was entered then you need AGI, if your just
>>> originating calls and monitoring for inbound use AMI, in either case SQL
>>> should be used to get call record data
>>>
>>> AGI has it problems that you are unnecessarily dealing with, they are
>>> common for AGI, what if my agi script finishes before the call ends, what
>>> if the call ends before my agi script finishes and a whole host of other
>>> issues that you simply dont need to deal with for what your trying to do
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From*: "Akshath T.A" <akshath.t at vtiger.com>
>>> *Sent*: Wednesday, August 27, 2014 3:19 AM
>>> *To*: vtiger at camden.net
>>> *Subject*: Re: [Vtigercrm-developers] Asterisk Good News
>>>
>>>  Hi,
>>>
>>> From the logs, it clearly states that the extension - 101 was not found
>>> by your Asterisk server when AMI originate request sent from Vtiger
>>> Connector.
>>>
>>> In order to nail down the issue, can we have a online meeting today or
>>> tomorrow so that it would help us know what really is causing the problem.
>>>
>>> I will be available from 9:00 AM to 8:00 PM IST at my office. Please
>>> tell us your convenient time within this so that I can send you meeting
>>> link.
>>>
>>> Thank you.
>>>
>>>
>>> regards,
>>> Akshath
>>>   Vtiger
>>>
>>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140828/dc54cfdd/attachment-0001.html>