Your example for viewing multiple servers says you need several instances in your fop2.cfg file. I am assuming that because the actual server x line is commented out that it is not meant to be in a "context" type [server 1] line.
However, I am finding with trunks (at least) that if I have the same name trunk in multiple servers (I do) (ie. SIP/MAINTRUNK) that even with the server=n line in the button.cfg file, FOP does not display properly. What is the answer to this?
Thanks
Harold
That's right. For channels with the same name, even if they are on different servers, fop2 will mix their status. The multiserver feature is done for setups where channel names are unique across servers (kamailio/dundi scalability setups). It is not done as in FOP1, at least not right now as server matching will hit adversely on cpu usage.
Regards,
Sorry, but I am confused here. The example you showed was that DHADI/go on server 1 would resolve correctly over DHAH/g0 on server 2 if you explicitly specificed servers in the button.cfg file. WHat is different between the example above and using SIP/MAINTRUNK on both servers and applying the same explicit server=x definition in the button file?
BTW,
I know you worked earlier in the week with Josh on my setup and I am very thankful for your efforts. I think the product is great. FYI, if you need access, I am running 1.6.1.0 Asterisk with Third Lane Multi-tenant and would love a script to import extensions and trunks. I have lots of both and can provide SSH to you if you would like.
Thanks Again
Harold
Hi Harold,
The server definition is currently used for sending commands to the proper asterisk server, but not for device matching on inbound events. That means that SIP/100 on server 1 will be treated the same as SIP/100 on server 2 with respect of monitoring inbound events. The behaviour in fop2 for multiserver setup is like the server=* in fop1. So, the multiserver option will work well only on setups where channel names are unique across servers.
Right now, if you have SIP/mytrunk on server one, and SIP/mytrunk on server two, and want to monitor both servers, you will have to do it with a separate daemon for each one.
The multi server treatment that I have implemented on fop1 it is not currently on the roadmap, as it will be a resource hog. So, for service providers, you can license a daemon for each pbx, or have a big system with unique names across servers.. or maybe just skip trunk monitoring if you use the same trunk names for everyone but unique names for extensions.
Best regards,
Nicolas,
Thank you for that explanation. I now have a clearer understanding as to what to expect with FOP2. Unfortuately, I have no working experience with FOP1 so I realize that I am starting at a huge deficit. I want you to know that I have absolutely no issue with purchasing multiple daemons for my multiple servers, but even in this way, I don't see how I will be able to have a single screen that will show me all of my SIP trunks across my servers without simply taking the time to rename each and every trunk in a unique way. Given the value of your product in presenting the "big" picture, it is well worth my time in doing so.
On the other note, I do not know if you have completed or are interested in working through the auto configure script for third lane single or multi-tenant (MTE). If you are, then please allow me to help you in any way I can, including giving you access to a configured box with this software preinstalled.
I look forward to meeting you this year at Astricon and/or VON, both of which I will be attending with Josh.
Yours,
Harold Bondy
Hi Harold,
I have some auto configuration scripts for third lane *almost* ready. The only missing part now is how to get the extension number for queues and conferences, but it seems that there is no extension assigned by default to this destinations. It is a workable config, but it would be nice to know the extensions in order to enable transfers to queues or conferences. I suppose that the software does not enforce the admin to assign a numeric extension/context for them? And now that I have added the group function you might have an admin context listing each tennant in their own group (groups go only for extensions, not queues , conferences or trunks)
About the multi server monitoring, I understand your need. In fact, DAHDI channels cannot be renamed. So you can consider it as a FOP2 limitation. As FOP2 is focused towards the user (not the admin), even in hosted setups admins don't want their customers to monitor trunks as they usually share a trunk with multiple hosted pbx. Because of this and performance I did not implement the multi server matching as in FOP1. For monitoring same name trunks over multiple servers you will need to use FOP1, it works quite well for that.
Maybe, just MAYBE, i will devise a way to do the multiserver matching without impacting on cpu usage. Right now I am using a hash key (super fast) on channel names. Because of that I am not checking for server. Channel objetcs are based on the name only, and that requires the name to be unique.
Regards,