<![CDATA[parking lot ghost call]]>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.

]]>http://localhost:4567/topic/709/parking-lot-ghost-callRSS for NodeTue, 27 Oct 2026 09:26:57 GMTThu, 07 Apr 2011 19:52:28 GMT60<![CDATA[Reply to parking lot ghost call on Thu, 09 Jun 2011 10:07:55 GMT]]>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.

]]>http://localhost:4567/post/3117http://localhost:4567/post/3117Thu, 09 Jun 2011 10:07:55 GMT<![CDATA[Reply to parking lot ghost call on Thu, 09 Jun 2011 00:49:06 GMT]]>Hmm I've had this issue as well. Possibly related?

View Post 919

]]>http://localhost:4567/post/3116http://localhost:4567/post/3116Thu, 09 Jun 2011 00:49:06 GMT<![CDATA[Reply to parking lot ghost call on Thu, 09 Jun 2011 00:36:55 GMT]]>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.

]]>http://localhost:4567/post/3115http://localhost:4567/post/3115Thu, 09 Jun 2011 00:36:55 GMT<![CDATA[Reply to parking lot ghost call on Thu, 26 May 2011 17:25:30 GMT]]>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.

]]>http://localhost:4567/post/3114http://localhost:4567/post/3114Thu, 26 May 2011 17:25:30 GMT<![CDATA[Reply to parking lot ghost call on Thu, 26 May 2011 16:24:05 GMT]]>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

]]>http://localhost:4567/post/3113http://localhost:4567/post/3113Thu, 26 May 2011 16:24:05 GMT<![CDATA[Reply to parking lot ghost call on Thu, 12 May 2011 12:35:23 GMT]]>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?

]]>http://localhost:4567/post/3112http://localhost:4567/post/3112Thu, 12 May 2011 12:35:23 GMT<![CDATA[Reply to parking lot ghost call on Tue, 12 Apr 2011 10:22:44 GMT]]>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.

]]>http://localhost:4567/post/3111http://localhost:4567/post/3111Tue, 12 Apr 2011 10:22:44 GMT<![CDATA[Reply to parking lot ghost call on Mon, 11 Apr 2011 18:02:18 GMT]]>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

]]>http://localhost:4567/post/3110http://localhost:4567/post/3110Mon, 11 Apr 2011 18:02:18 GMT<![CDATA[Reply to parking lot ghost call on Sat, 09 Apr 2011 12:46:33 GMT]]>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,

]]>http://localhost:4567/post/3109http://localhost:4567/post/3109Sat, 09 Apr 2011 12:46:33 GMT<![CDATA[Reply to parking lot ghost call on Fri, 08 Apr 2011 13:44:40 GMT]]>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

]]>http://localhost:4567/post/3108http://localhost:4567/post/3108Fri, 08 Apr 2011 13:44:40 GMT<![CDATA[Reply to parking lot ghost call on Fri, 08 Apr 2011 02:27:27 GMT]]>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

]]>http://localhost:4567/post/3107http://localhost:4567/post/3107Fri, 08 Apr 2011 02:27:27 GMT