How does FOP2 fetch the peer information in first instance? I mean, what is the first action perfomed by FOP2 in order to know peers status?

If you are curious about what FOP2 does, you should run it in debug mode to see the manager dialog:

service fop2 stop
cd /usr/local/fop2
./fop2_server -X 3

and watch the show. In particular the SIPPeers command is being sent at startup.

When I start fop2 server it displays all peers as available and looking AMI no Action is performed when starting fop2 server. But when I go offline with any of the peers, fop2 displays the correct information for that peer from that moment on. It seems that by default fop2 "think" all are available. I wouldn't be asking this if I didn't use fop2 before. When using it with Asterisk 1.8.15.1 fop2 shows correct information at start.
B.

I do not think there is any change between the manager output/commands from 1.8.15 to newer versions.

FOP2 does not think anything, it will react to commands. By default it starts with a registration "ok" status, because many people have extensions with unmonitored state completely, or even some channel drivers do not have the concept of registrations (not everyone uses sip).

If you use 2.27 beta and want to change the initial status, look at /var/www/html/fop2/js/presence.js, the settings there are self explanatory:

var startNotRegistered = false;

I'm running 2.27. Which option is it the one that forces all buttons as unavailable?

When I start fop2 server it displays all peers as available and looking AMI no Action is performed when starting fop2 server. But when I go offline with any of the peers, fop2 displays the correct information for that peer from that moment on. It seems that by default fop2 "think" all are available. I wouldn't be asking this if I didn't use fop2 before. When using it with Asterisk 1.8.15.1 fop2 shows correct information at start.

What can I do to have the same behaviour as before?

Regards,

B.

[fop2]
secret = **********
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
read = all
write = all
writetimeout = 1000
eventfilter=!Event: RTCPSent
eventfilter=!Event: RTCPReceived
eventfilter=!Event: VarSet
eventfilter=!Event: Cdr
eventfilter=!Event: ExtensionStatus
eventfilter=!Event: ChannelUpdate

All SIP peers have qualify=yes defined.

We are in production and it worked alright until installing newer Asterisk version. I don't espect to get the solution to the problem here. However, I woul like to know which can be the causes of having all extension buttons showing as available at start. Is there more than one option? Is my reason logic ok? (At FOP2 start, fop2 manager user "asks" for peers' status and it shows them as it gets it. I think Asterisk might be sending that they are available, although it's strange. Where does Asterisk get this information from?..astdb?

Regards,
Borja

In FOP 2.27 (beta) there is now an option in presence.js to start with all extensions in unavailable state, and only enable them when the proper event is received (this is to make it work with sip realtime configuration, where initial state is not advertised by AMI).