search

FreePBX / superfecta

Provides simultaneous use of, and complete control over multiple caller id data sources.
http://www.freepbx.org
GNU General Public License v2.0
56 stars 92 forks source link

Configure superfecta to return CNAM as soon as a successful ID has been made #247

Closed ntadmin closed 9 years ago

ntadmin commented 9 years ago

I've had look, and maybe I missed something, but I can't see a way to do this. The scenario is that you have one or more 'slow' ways to get caller id in your scheme list. At the top you have superfecta cache.

Ideally, if superfecta cache finds something, I would like to use that, rather than going through the rest of the last.

In a dream world, I would then like superfecta to continue with the list in the background and update the cache (if necessary) for next time.

Is this currently possible?

If not, is it implementable? I'm guessing 12.x ....

lgaetz commented 9 years ago

On a live call, Superfecta will step through your configured sources from top to bottom in order, and will stop as soon as one source returns a valid result. On debug it never stops until all sources are polled.

Your idea of delaying the slow lookup sources until after the call is done is interesting, but there is no current feature that allows this. If you are running a current Asterisk version, you could call a hangup handler somewhere in the call flow, then have a block of code in extensions_custom.conf with lines similar to this:

[hangup_handler_superfecta]
exten => s,1,noop(Entering user defined context ${CONTEXT} defined in extensions_custom.conf)
exten => s,n,set(scheme=base_hangup)  ;the characters following the _ must match exactly the name of the Superfecta scheme defined in the GUI
exten => s,n,Set(CIDSFSCHEME=${BASE64_ENCODE(${scheme})})
exten => s,n,noop(Running Superfecta scheme ${scheme} with CID of ${CALLERID(number)})
exten => s,n,AGI(/var/www/html/admin/modules/superfecta/agi/superfecta.agi)
exten => s,n,Return()
;  end hanguphandler_superfecta context

This code is untested and it will only work if the variable ${CALLERID(number)} remains set properly after call hangup. You need to create a superfecta scheme in the gui called "hangup" or adjust the code to suit. You can set this scheme to have a very long timeout and of course make sure to include the superfecta cache. Somewhere during the call flow (such as with a custom destination) you must have a line that ensures the call will use the hangup handler. The line would look similar to this:

exten => s,n,Set(CHANNEL(hangup_handler_push)=hangup_handler_superfecta,s,1)
ntadmin commented 9 years ago

OK, so in principle it has the first behaviour I would expect. However, the freepbx logfiles I have seem to suggest that a call to superfecta takes 3-4 seconds if it has to use the GoogleContacts module (a bit long but just within the realm of believable). It takes the same time if the name is in the superfecta cache, which is why I assumed that it had the same behaviour as in debug. Is there a flag I have failed to set?

lgaetz commented 9 years ago

No flags to set. IIRC you are running on Pi, if so that might explain the delay. Superfecta suffers from some very inefficient legacy code that can introduce delays which may explain what you are seeing if you are running on underpowered hardware.

ntadmin commented 9 years ago

I am running on pi, the interesting thing to me what that the time taken was the same whether the info was in the cache or not.

Would I be wise to start using the development branch if I want to delve into these things?

On 5 May 2015, at 19:15, Lorne Gaetz notifications@github.com wrote:

No flags to set. IIRC you are running on Pi, if so that might explain the delay. Superfecta suffers from some very inefficient legacy code that can introduce delays which may explain what you are seeing if you are running on underpowered hardware.

— Reply to this email directly or view it on GitHub.

lgaetz commented 9 years ago

The 12.0 branch would be considered at a beta stage, and is mostly working with one outstanding bug as noted in #239. Feel free to give it a spin and note any issues in that thread.

ntadmin commented 9 years ago

OK, have got 12.0 working, and got Google contacts working in it. I'll report future discoveries on #239.

ntadmin commented 9 years ago

I think this is now resolved in 12.0, but not in 2.11. I leave it to you to decide whether to back port the mod or let it stand.

tm1000 commented 9 years ago

I think we will just leave it fixed in 12 because 12 is a much better code base. At this stage I am probably not going to release 12. Though everything you've done is in 13 (merges up) so it will be in 13 in a couple of weeks when 13 is beta. Im publishing it in 13 right now however