[Vtigercrm-developers] Asterisk Good News

[Prasad]

There are couple of setups that has worked well with VtigerAsteriskApp.

We will revisit the integration enhancement / approach as we get more deep
understanding with AMI, AGI.

Keep your feedback posted.

*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 6:46 PM, vtiger at camden.net <vtiger at camden.net>
wrote:

> I dont think there is "issue" with the java proxy approach, what I think
> is issue is this AGI-AMI hybrid thing you have going on, AGI is notoriously
> more difficult to program in to begin with, you literally have to write a
> proper handler for every event that might occur, plus AGI and AMI are not
> inherently meant to work together
>
> this is pretty easy with IVRs, we know we are sending caller there, and we
> can except a few limited outcomes, plus you have to use AGI to capture
> input, but with just a regular phone call there are to many things that can
> happen and we are not expecting input to capture
>
> last night we fixed up our test servers but removed the agi fire for
> inbound context, so we are only running the [vtiger_outbound] this means no
> inbound notification and no logging and voice recording of calls of those
> calls, we are going to test if this thing stays stable for just click to
> call in light of that you also found issue where inbound can be sent to
> endless loop
>
> in our limited testing (just one night) we noticed AMI streaming data in
> your webapp.sh on a inbound call without the agi fire, with some error
> messages we think are related to it was expecting the AGI to fire, it did
> not seem to effect anything and so far has not locked up and continues to
> work
>
> we know your using the AMI to originate outbound, and it seems your using
> AMI for at least part of the inbound, so the question remains why AGI at
> all, you guys say its to limited overhead and cut down on data you need to
> phrase, yet your phrasing it anyway?? if you want to cut down the data you
> get from the AMI stream, have the AMI user have originate and read call
> only rights, you will only get data the pertains to actual phone calls and
> cut out 95% of the data AMI would normally stream that you dont care about
> anyway
>
> now with AGI gone, your problems will be gone, you wont be able to as
> easily do your own CDR logging, and you wont be able to force all calls to
> be recorded (a function we dont think you should be doing anyway) however
> the CDR in vtiger is a good idea but there is better option
>
> use the existing SQL CDR data Asterisk will provide, you say you want to
> use a API, so write one, we think that is better idea that opening SQL to
> world if vtiger and Asterisk are not on same computer anyway
>
>
> write a php file that you would have asterisk admin put on asterisk server
> where Apache can serve up, in that php file, you need to pass it the
> extension and phone number(s) you are going to pull data for, have the php
> run the sql statements and return the data you want (date, time, callerID,
> source, destination, duration), we would use XML put there are lots of
> choices
>
> if you have free PBX check out the user panel, specifically the call
> monitor, what you want to do is reconstruct that but only the extension and
> phone numbers for that instance, you may want to drop the extension search
> part so if I click on a contact then go to PBX manger I see all calls to
> and from that contact and which colleges of mine took or placed those calls
>
> also if asterisk was told to record a call you will notice in the user
> panel under call monitor there is a column "monitor" if there is a
> recording there be 2 icons, one to download the sound file and one to
> listen to it, you could do the same, however I would advise to have access
> to recording off by default with the option for the vtiger admin to allow
> access on a per user basis
>
> the above would allow vtiger to tie all calls in asterisk to vtiger
> records, something AGI can never do, you have no control over forcing uses
> to click to call out of vtiger, If I know a phone number, Im not going to
> go searching for it to click on it, as result the call will not show in
> vtiger, will vtiger log call on inbound if user was not logged into vtiger?
> we have not tested, but if the vtiger PBX CDR records are incomplete they
> are no good
>
>
> ------------------------------
> *From*: "Prasad" <prasad at vtiger.com>
> *Sent*: Thursday, August 28, 2014 12:21 AM
>
> *To*: "vtiger at camden.net" <vtiger at camden.net>, "
> vtigercrm-developers at lists.vtigercrm.com" <
> vtigercrm-developers at lists.vtigercrm.com>
> *Cc*: "Akshath T.A" <akshath.t at vtiger.com>
>
> *Subject*: Re: [Vtigercrm-developers] Asterisk Good News
>
>  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/cd572988/attachment-0001.html>