[Vtigercrm-developers] Asterisk Good News

Thu Aug 28 13:16:39 GMT 2014

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 I Facebook I Blog I Wiki I Forums I Website
   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/8dcaf2c1/attachment-0001.html>