parking lot ghost call
-
Here is my permissions:
read = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate
write = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originateIs there something missing?
callevents=yes is already present in sip_custom.conf
Thank you,
Gabriel
-
Just to be sure, please add ",all" at the end of both. Reload asterisk and fop2 and try again. I have seen the ghost park problem when not all events are sent via the manager. Some trixbox versions do not send all events unless you have "all" or "hud" permissions. Not sure if that problem is related to a particular asterisk version, the trixbox patched asterisk or what. So, just to be sure, add "all" to both read and write.
Best regards,
-
-
Hi Gabriel,
The next release includes one check for incomplete transfers to parking. It seems to improve the situation with one customer, but it seems not fully (they still see a ghost call every now and then), Those cases are really hard to track/fix, as the AMI events stop to make sense, sometimes there are missing events, or events with funny or inconsistent data. Perhaps you might want to try the beta yourself and see if it improves it for you. Please email me: nicolas at house com ar so I can send you the dev version for you to test.
-
-
I have been trying the Beta at a client of mine for a few weeks and they always have four or five ghost calls in the parking lot. The only way I can clear it is restarting the fop2 server which I have setup a cronjob to do every morning.
I have the manager.conf set to
read = system,call,log,verbose,command,agent,user,all
write = system,call,log,verbose,command,agent,user,allTheir asterisk version is Asterisk-1.4.36-0 on Elastix-1.6.2-36
They use Linksys/SPA962 phones.
Any advice? They complain about this quite often
-
-
Interesting things are happening. I decided to grab you a debug using script and ./fop2_server -X 15 running from a screen session. Usually they had one or two ghost parking lot calls a day. I ran it two days from the screen session using ./fop2_server -X 15, not a single ghost call. Ran the init script and ghost calls appeared.
Don't know if the -d switch would cause issues as opposed to not daemonizing it. Looking forward to the next beta.
-
Hmm I've had this issue as well. Possibly related?
-
Hi,
Functionality wise , using -d or not, or -X 15 or not is the same. You can do the capture in another way, add the options in the init script /etc/rc.d/init.d/fop2, something like
OPTIONS="-d -X 1 -l /tmp"
Then restart fop2 via init script, it will go to the background (-d) and also log output to /tmp/output.log
From what I have seen, ghost calls happens when doing broken attendant native sip transfers with some phones.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login