Hi, I'm having the same issue with fop2.20 (basic license). Could you link/email me a copy of the beta version to test out? Thanks,
~ca
Hi, I'm having the same issue with fop2.20 (basic license). Could you link/email me a copy of the beta version to test out? Thanks,
~ca
Thanks, that seems to have fixed the problem with fop2 stopping.
However, there are two issues that we've noticed. One is that sometimes parked callers aren't removed from fop (we have someone who's supposedly been parked for an hour and a half, but picking up the line gives "no call parked). Sometimes it works fine thought.
The other is that only our IAX trunk shows calls, the ZAP trunks we have constly remain green, and never show a call, despite sometimes being in use.
Thanks,
~ca
What is the status of this? I'm having this problem too. It's basically a deal breaker if I can't get this working.
Is the beta stable enough? I'm not looking for half baked solutions.
Hi,
What is the status of this? I'm having this problem too. It's basically a deal breaker if I can't get this working.
Is the beta stable enough? I'm not looking for half baked solutions.
There are lots of issues discussed in this post, so I am not sure what is the deal breaker for you. I am sorry if you think fop2 is a half baked solution. Asterisk has tons of nasty bugs too, and I do not think it is half baked either.
If you experience a flash client that stops updating, it is because asterisk crashes, not something else. If asterisk is stable, you will not experience the issue. If the connection with asterisk dies unexpectedly while you have flash clients connected into fop2, then you might experience the issue where some flash clients gets updates and some others do not get them. The problem is fixed if you restart fop2. If asterisk never crashes, or if you remember to restart fop2 server when you also restart asterisk, then there is no issue. Anyways, the beta fixes this, it "restarts itself" when asterisk crashes, and avoids the problem.
Now, if your deal breaker is something else, please let me know what it is so I can work on the fix.
Best regards,
However, there are two issues that we've noticed. One is that sometimes parked callers aren't removed from fop (we have someone who's supposedly been parked for an hour and a half, but picking up the line gives "no call parked). Sometimes it works fine thought.
Parking is complicated, the park bugs are related mostly to asterisk bugs or odd cases involving masquerading, local channels, etc. They are really hard to reproduce, and when users were able to capture manager logs of the issues, most of the times is because missing or nonsense manager events related to those parked calls (like parking channel A, and then getting an unpark event for channel B). There is another case when using named parking lots (freepbx does not use them), where the unpark event does not have the parkinglot in the event itself, so fop2 tries to follow the channel life between events, but sometimes it gets lost on the masquerading madness event flow. I will probably a double check for paked calls when receiving events, polling for status and not relying on received events. So, if you want to find out why there is a ghost parked call (perhaps it is a fop2 bug too!), you must capture fop2_server debug level 1 until the problem happens, and then stop capturing and send me the capture log together with your button configuration file.
The other is that only our IAX trunk shows calls, the ZAP trunks we have constly remain green, and never show a call, despite sometimes being in use.
Are you using fop2admin? Did you setup the channel ranges in fop2 buttons? You must do it in order to see status.
Best regards,
Hi,
What is the status of this? I'm having this problem too. It's basically a deal breaker if I can't get this working.
Is the beta stable enough? I'm not looking for half baked solutions.
There are lots of issues discussed in this post, so I am not sure what is the deal breaker for you. I am sorry if you think fop2 is a half baked solution. Asterisk has tons of nasty bugs too, and I do not think it is half baked either.
If you experience a flash client that stops updating, it is because asterisk crashes, not something else. If asterisk is stable, you will not experience the issue. If the connection with asterisk dies unexpectedly while you have flash clients connected into fop2, then you might experience the issue where some flash clients gets updates and some others do not get them. The problem is fixed if you restart fop2. If asterisk never crashes, or if you remember to restart fop2 server when you also restart asterisk, then there is no issue. Anyways, the beta fixes this, it "restarts itself" when asterisk crashes, and avoids the problem.
Now, if your deal breaker is something else, please let me know what it is so I can work on the fix.
Best regards,
The problem is FOP2 is not updating. Has nothing to do with Asterisk which is running properly while this is happening. If I am on a call via a trunk FOP2 still shows the extension and trunk as free unless I refresh my browser. Then when the call ends I need to refresh the browser to have it update the status again. That's a deal breaker if I can't get that working properly.
But sometimes it works. So it's intermittent and not likely a configuration issue.
Hi mustardman,
Restarting fop2_server will fix the issue. The problem happens ONLY if asterisk is restarted while fop2_server is still running AND you have a flash client connected.
Imagine this scenario, you boot the machine:
asterisk starts
fop2 starts
some fop2 client connects via web
everything is fine and dandy
suddenly asterisk crashes
fop2_server is still running
fop2 client is still connected, and it will not see updates, as asterisk is GONE
safe_asterisk relaunches asterisk
at that point, your old connected flash client will not receive updates, but newer fop2 client connections will.
restarting fop2_server fixes the issue. It is a bug in the way fop2 handles asterisk disconnections, and the problem is addressed already in the beta, and will be rolled out on the next version. But it only occurs when asterisk is restarted or dies, without restarting fop2_server.
Try it, instead of hitting F5 in your browser when you notice the problem, just restart fop2 server
service fop2 restart
and the problem will be gone.
Best regards,
Hi mustardman,
Restarting fop2_server will fix the issue. The problem happens ONLY if asterisk is restarted while fop2_server is still running AND you have a flash client connected.
Imagine this scenario, you boot the machine:
asterisk starts
fop2 starts
some fop2 client connects via webeverything is fine and dandy
suddenly asterisk crashes
fop2_server is still running
fop2 client is still connected, and it will not see updates, as asterisk is GONEsafe_asterisk relaunches asterisk
at that point, your old connected flash client will not receive updates, but newer fop2 client connections will.
restarting fop2_server fixes the issue. It is a bug in the way fop2 handles asterisk disconnections, and the problem is addressed already in the beta, and will be rolled out on the next version. But it only occurs when asterisk is restarted or dies, without restarting fop2_server.
Try it, instead of hitting F5 in your browser when you notice the problem, just restart fop2 server
service fop2 restart
and the problem will be gone.
Best regards,
I hope you are not suggesting that requiring us to restart the service is your permanent solution. This happens quite often and your suggestion is a non-starter. You must not use FreePBX where Asterisk restarts happen every time you make a change via the GUI which happens all the time. What is the permanent solution and when can I expect it? Otherwise I may have to go back to FOP1
Normal asterisk installs should not crash, nor asterisk restarted frequently. If *you* restart asterisk, *you* can also restart fop2. That was my suggestion.
A permanent solution could be to have a stable asterisk that does not crash. Or remember to restart fop2 when you restart asterisk. Or if your asterisk still crashes and you are fine with the safe_asterisk script bringing it up again, just add a line to the safe_asterisk script to do a service fop2 restart there too. Something like this (untested)
run_asterisk() { while :; do if test "x$TTY" != "x" ; then cd /tmp stty sane < /dev/${TTY} nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY} else cd /tmp nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} fi # Restart fop2 after asterisk dies or ends service fop2 restart EXITSTATUS=$? message "Asterisk ended with exit status $EXITSTATUS" if test "x$EXITSTATUS" = "x0" ; then # Properly shutdown.... # Stop fop2 when asterisk is shutdown service fop2 stop message "Asterisk shutdown normally." exit 0
Be creative. I tried to describe *when* the issue happens, so you know where to look for to address the problem. If you are unable to avoid asterisk crashes, then you might want to try updating the safe_asterisk script. However, I would not do this myself, I would rather fix asterisk or my asterisk configuration to avoid crashes or ami disconnections.
You know, if asterisk crashes, taking down all your active calls with it.... its much worst that than having some fop2 clients not updating after that crash, fop2 would be my last of concerns. I would try to get asterisk stabilized first. This *only* happens when you have a fop2 client connected to fop2 server, and then the AMI connection gets down or broken. It is not usual in normal circumstances. For me and for the majority of users this does not happen often or at all. It was very hard for me to reproduce the issue, fortunately I got help from users who let me look at their servers when the problem happened, and I was able to find the cause.
Anyways, the next fop2 version fixes this, as it is indeed a fop2 issue. You are welcome to try the beta if you want: http://www.fop2.com/downloads/fop2-2.21 ... 5-i386.tgz
You can also go back to FOP1 if it makes you feel more comfortable. Please excuse me, but I am still sensing a hostile attitude towards me and the software itself. It seems like you want to spread FUD more than anything else.
Nicolas,
Can the beta just be installed over the original?
Or what is the correct process for re-installing on a working system?
thanks.
Normal asterisk installs should not crash, nor asterisk restarted frequently. If *you* restart asterisk, *you* can also restart fop2. That was my suggestion.
A permanent solution could be to have a stable asterisk that does not crash. Or remember to restart fop2 when you restart asterisk. Or if your asterisk still crashes and you are fine with the safe_asterisk script bringing it up again, just add a line to the safe_asterisk script to do a service fop2 restart there too. Something like this (untested)
run_asterisk() { while :; do if test "x$TTY" != "x" ; then cd /tmp stty sane < /dev/${TTY} nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY} else cd /tmp nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} fi # Restart fop2 after asterisk dies or ends service fop2 restart EXITSTATUS=$? message "Asterisk ended with exit status $EXITSTATUS" if test "x$EXITSTATUS" = "x0" ; then # Properly shutdown.... # Stop fop2 when asterisk is shutdown service fop2 stop message "Asterisk shutdown normally." exit 0Be creative. I tried to describe *when* the issue happens, so you know where to look for to address the problem. If you are unable to avoid asterisk crashes, then you might want to try updating the safe_asterisk script. However, I would not do this myself, I would rather fix asterisk or my asterisk configuration to avoid crashes or ami disconnections.
You know, if asterisk crashes, taking down all your active calls with it.... its much worst that than having some fop2 clients not updating after that crash, fop2 would be my last of concerns. I would try to get asterisk stabilized first. This *only* happens when you have a fop2 client connected to fop2 server, and then the AMI connection gets down or broken. It is not usual in normal circumstances. For me and for the majority of users this does not happen often or at all. It was very hard for me to reproduce the issue, fortunately I got help from users who let me look at their servers when the problem happened, and I was able to find the cause.
Anyways, the next fop2 version fixes this, as it is indeed a fop2 issue. You are welcome to try the beta if you want: http://www.fop2.com/downloads/fop2-2.21 ... 5-i386.tgz
You can also go back to FOP1 if it makes you feel more comfortable. Please excuse me, but I am still sensing a hostile attitude towards me and the software itself. It seems like you want to spread FUD more than anything else.
The suggestion of putting fop2 restart in the safe_asterisk restart script is a more practical solution assuming it is initiated everytime FreePBX is updated via the Apply changes GUI button (I'm not sure if it is). Again, I don't know why you are going off on a tangent trying to blame Asterisk. As I said repeatedly asterisk is NOT crashing. Asterisk is NOT crashing. Did I mention that asterisk is NOT crashing?
You seem to have no concept of how people use this. Most use FreePBX and for those people your solution of "just restart fop2 service because it rarely happens" is ridiculous. FreePBX is constantly being used and the way FreePBX works is every change restarts asterisk which kills fop2. That does not seem to sink in with you for some reason. Also a lot of administrators like the ones I deal with do not know linux. They can use a browser and configure Asterisk via FreePBX but asking them to open a command line and restart the FOP2 service is a completely foreign concept to them. I may as well be asking them to fly to the moon.
My attitude about it is irrelevant but welcome to the world of paid apps. I have never complained about FOP1 because it's completely free and has always worked well for me. FOP2 is intentionally limited to encourage people to buy a license and my expectations are much higher for a product like that. At a minimum I do NOT expect show stoppers like this. And in this case where there is a show stopper, I don't expect useless advice about how to get around it.
Frankly, if you just said, "yea it's a problem, these things happen sometimes, I think I fixed it in the current beta which may be buggy right now" and then some sort of estimate on a stable version is a better answer.
admin,
An idea until the next version is final...
Is there a way to make a button, or could you make a button on the Fop2 panel, that would restart the fop2 service?
That way it could be refreshed if there is an issue?
Another way to do it.... Is there any harm in running a cron script that runs:
/etc/init.d/fop2 restart
every 15 minutes?
thanks.
Nicolas,
Can the beta just be installed over the original?
Or what is the correct process for re-installing on a working system?
thanks.
You can install it over...
The suggestion of putting fop2 restart in the safe_asterisk restart script is a more practical solution assuming it is initiated everytime FreePBX is updated via the Apply changes GUI button (I'm not sure if it is).
The problem -that *some* fop2 clients stop responding after a while- does not happen if you reload asterisk. It only happens if asterisk is restarted or the ami connection is lost. I was very precise on the description. The safe_asterisk script will execute the commands only when asterisk crashes or is restarted via the asterisk cli
Again, I don't know why you are going off on a tangent trying to blame Asterisk. As I said repeatedly asterisk is NOT crashing. Asterisk is NOT crashing. Did I mention that asterisk is NOT crashing?
I am not going into any tangent, and I do not try to blame Asterisk. I make it perfectly clear that *if* asterisk crashes, you might experience the issue. Also if the AMI connection is lost. It does not happen if you reload asterisk, or if you apply changes in freepbx. If you are experience the issue, but your asterisk is stable, then check if the ami connection is stable too, you can do it by running fop2_server in debug mode ( -X 1) and let it run and look for manager disconnection messages. By the way, you NEVER said your asterisk did not crash before, on any of your posts. None of your posts is informative, they do not give information about your setup, your settings, your versions, anything. And you are not cooperating either as other users are doing. You are just spreading FUD.
You seem to have no concept of how people use this. Most use FreePBX and for those people your solution of "just restart fop2 service because it rarely happens" is ridiculous. FreePBX is constantly being used and the way FreePBX works is every change restarts asterisk which kills fop2. That does not seem to sink in with you for some reason. Also a lot of administrators like the ones I deal with do not know linux. They can use a browser and configure Asterisk via FreePBX but asking them to open a command line and restart the FOP2 service is a completely foreign concept to them. I may as well be asking them to fly to the moon.
Every change in FreePBX *reloads* asterisk, it does not restart it. A reload does not trigger the problem. And it does not kill fop2. Perhaps your problem is that AMI connections are breaking, if that is the case, you can increase the writetimeout in /etc/asterisk/manager.conf under the fop2 user.
Frankly, if you just said, "yea it's a problem, these things happen sometimes, I think I fixed it in the current beta which may be buggy right now" and then some sort of estimate on a stable version is a better answer.
I said it, but you seem to have a problem reading:
Anyways, the next fop2 version fixes this, as it is indeed a fop2 issue.
The beta is stable, you can use it safely right now.
You can also use fop 2.11 because I *think* the issue was introduced on 2.20.
In any case, I am talking about the issue that I have described here.. Perhaps there are other issues that have a similar symptom but a different cause. For example, in one case I was able to determine that Microsoft ISA server was having troubles with its nat tables and it was affecting fop2 , that stopped receiving updates but because ISA server was not keeping or was mixing connections to port 4445, but only for clients connecting via ISA server.
Look, I will stop responding to offensive or bashing posts. If you need support, please ask for it: provide information, and I will try to offer you a solution. A sane solution/suggestion or fix.
You never contacted me via email or live help (as far as I know), it is clear that your objective here is to spam the forum anonymously with FUD posts, trying to bash the software or myself. That does not help and it does not add up to the discussion. If you are a paid customer, and you are unhappy with the software, I can issue a refund. Please contact me via email or live help for that.
admin,
An idea until the next version is final...
Is there a way to make a button, or could you make a button on the Fop2 panel, that would restart the fop2 service?
That way it could be refreshed if there is an issue?
Another way to do it.... Is there any harm in running a cron script that runs:
/etc/init.d/fop2 restart
every 15 minutes?
thanks.
Hi, it is a dangerous feature. Anyways, it is much easier to update to the beta than to create another new feature to it. The fop2 restart in a cron job can be done, but it will disrupt currently connected fop2 users, it can be a little bit annoying.
Are you experience the issue where some clients stop updating? Can you run fop2_server in debug level 1 to see if the AMI is stable, or have you checked that asterisk is not crashing on you? Doing an "asterisk -rx 'core show uptime'" can give you an idea if asterisk was restarted or not.
admin,
I don't know if I am having a problem yet :D
My current system uptime is 22 hours but I just got to work 1.5 hours ago.
I am still in testing mode and only have one other user trying it out. I want to make sure it works prior to rolling it out to the technically challenged!
I went to download the new beta but noticed it is for centOS, do you have a beta for debian yet? (ubuntu is what I am running)
The reason I wanted the new beta was because I am frequently reloading freepbx and wanted to make sure I didn't have to ssh into the server and issue a fop2 restart everytime. But in reading your prior posts, it doesn't seem freepbx reloads effect fop2?
thanks for the help!
admin,
I don't know if I am having a problem yet :D
My current system uptime is 22 hours but I just got to work 1.5 hours ago.
I am still in testing mode and only have one other user trying it out. I want to make sure it works prior to rolling it out to the technically challenged!
I went to download the new beta but noticed it is for centOS, do you have a beta for debian yet? (ubuntu is what I am running)
The reason I wanted the new beta was because I am frequently reloading freepbx and wanted to make sure I didn't have to ssh into the server and issue a fop2 restart everytime. But in reading your prior posts, it doesn't seem freepbx reloads effect fop2?
thanks for the help!
Hi Matt,
You will NOT have this issue just for reloading FreePBX. This issue is not as big as this post... the post was trolled and abused to spread FUD (fear, uncertainty and doubt). Fop2 is not perfect, but it works quite well, even if you reload freepbx/asterisk a lot of times.
The only thing that you will notice is that if you reload freepbx because you added or removed extensions, the currently connected fop2 users will be disconnected and reconnected back again (so they can get the new button layout). But the status will keep updating with no issues at all.
What debian version do you use, 32 or 64 bits? I can prepare one for you and send you the link.
32 bit.
thanks
The suggestion of putting fop2 restart in the safe_asterisk restart script is a more practical solution assuming it is initiated everytime FreePBX is updated via the Apply changes GUI button (I'm not sure if it is).
The problem -that *some* fop2 clients stop responding after a while- does not happen if you reload asterisk. It only happens if asterisk is restarted or the ami connection is lost. I was very precise on the description. The safe_asterisk script will execute the commands only when asterisk crashes or is restarted via the asterisk cli
Again, I don't know why you are going off on a tangent trying to blame Asterisk. As I said repeatedly asterisk is NOT crashing. Asterisk is NOT crashing. Did I mention that asterisk is NOT crashing?
I am not going into any tangent, and I do not try to blame Asterisk. I make it perfectly clear that *if* asterisk crashes, you might experience the issue. Also if the AMI connection is lost. It does not happen if you reload asterisk, or if you apply changes in freepbx. If you are experience the issue, but your asterisk is stable, then check if the ami connection is stable too, you can do it by running fop2_server in debug mode ( -X 1) and let it run and look for manager disconnection messages. By the way, you NEVER said your asterisk did not crash before, on any of your posts. None of your posts is informative, they do not give information about your setup, your settings, your versions, anything. And you are not cooperating either as other users are doing. You are just spreading FUD.
You seem to have no concept of how people use this. Most use FreePBX and for those people your solution of "just restart fop2 service because it rarely happens" is ridiculous. FreePBX is constantly being used and the way FreePBX works is every change restarts asterisk which kills fop2. That does not seem to sink in with you for some reason. Also a lot of administrators like the ones I deal with do not know linux. They can use a browser and configure Asterisk via FreePBX but asking them to open a command line and restart the FOP2 service is a completely foreign concept to them. I may as well be asking them to fly to the moon.
Every change in FreePBX *reloads* asterisk, it does not restart it. A reload does not trigger the problem. And it does not kill fop2. Perhaps your problem is that AMI connections are breaking, if that is the case, you can increase the writetimeout in /etc/asterisk/manager.conf under the fop2 user.
Frankly, if you just said, "yea it's a problem, these things happen sometimes, I think I fixed it in the current beta which may be buggy right now" and then some sort of estimate on a stable version is a better answer.
I said it, but you seem to have a problem reading:
Anyways, the next fop2 version fixes this, as it is indeed a fop2 issue.
The beta is stable, you can use it safely right now.
You can also use fop 2.11 because I *think* the issue was introduced on 2.20.
In any case, I am talking about the issue that I have described here.. Perhaps there are other issues that have a similar symptom but a different cause. For example, in one case I was able to determine that Microsoft ISA server was having troubles with its nat tables and it was affecting fop2 , that stopped receiving updates but because ISA server was not keeping or was mixing connections to port 4445, but only for clients connecting via ISA server.
Look, I will stop responding to offensive or bashing posts. If you need support, please ask for it: provide information, and I will try to offer you a solution. A sane solution/suggestion or fix.
You never contacted me via email or live help (as far as I know), it is clear that your objective here is to spam the forum anonymously with FUD posts, trying to bash the software or myself. That does not help and it does not add up to the discussion. If you are a paid customer, and you are unhappy with the software, I can issue a refund. Please contact me via email or live help for that.
Whoa boy. So now I am the bad guy for not pointing out that Asterisk is NOT crashing. You have got to be kidding me. And now you are trying to accuse me of trolling. Look. I will give you the IP address and you can see for yourself. But the problem is you are not willing to listen.
Now the thing with AMI disconnecting. That is something new you have not mentioned before. This seems more plausible because fop2 stops responding constantly. This is a completely normal install. Oh, and since you say I am not giving you enough info. Asterisk is NOT crashing. FreePBX is NOT crashing. The internet is NOT crashing. The server is NOT crashing. Everything works......EXCEPT....fop2. How silly of me to not point out all those things in the past.
Is there a 64bit version of fop2 2.21 beta?
CentOS 5.6 64bit
FreePBX 2.9
Asterisk 1.8.4.1
FOP2 2.20