When we do an attended transfer to a parking lot (we have 4 lots configured) and we then unpark the call (it works), the call stays in the parking lot on the fop2 page. We have to restart fop2 to remove the call from the parking lot.
Any clue?
We run the latest elastix 32 bit with fop2 2.2 final licensed.
Thank you,
Gabriel L.
Be sure you have "all" permissions in /etc/asterisk/manager.conf read and write lines. And that you also have callevents=yes in sip_general_custom.conf
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,originate
Is 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,
I found this problem to be related with the Mitel 5235 phone when you do not complete an attended transfer. Problem solved for me.
Gabriel
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 this issue with a client of mine running elastix 1.6/FOP2 2.2 and Linksys phones. What did you do to your Mitel to clear this up? Did the dev version help you?
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,all
Their 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
The only way for me to debug is to have a log capture level 1 from fop2_server up to until some calls appear on the parking lot.
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.