I haven't tried it, I thought it worked, I can probably fix it but will need to test first.
Kamailio script to front standard FusionPBX cluster v2.0
- Thread starter DigitalDaz
- Start date
- Status
I haven't tried it, I thought it worked, I can probably fix it but will need to test first.
I've run a sip trace and the packets are being forwarded. Rather than hijack this thread, I've created a new thread: http://www.pbxforums.com/threads/kamailio-fusionpbx-freeswitch-presence.363/
Fantastic script,
Few doubts
1. Here we are forwarding all request to Freeswitch, in this case does Kamailio still keep track of registered Users and only allow INVITE from those endpoints to be forwarded to freeswitch or it just sends all to freeswitch irrespective of registered or not ?
Few doubts
1. Here we are forwarding all request to Freeswitch, in this case does Kamailio still keep track of registered Users and only allow INVITE from those endpoints to be forwarded to freeswitch or it just sends all to freeswitch irrespective of registered or not ?
No, in this particular script kamailio blindly forwards the registrations, ie kamailio is NOT acting as registrar.
lol, that is a terrible slur, Kamailio's documentation is excellent, if you mean step by step how to use it fair enough. You need a fairly deep understanding of the SIP protocol in order to use it effectively though. If I rewrote that today it would probably look quite different already.
When adding Kamailio/Opensips into the mix you really want to do it from day one, it would be much more difficult to implement at a later date.
Performance. At some time so long as you continue to grow, you will reach the limitations of a single freeswitch box.
With regards to redundancy, you are still left with a SPOF, ie the kamailio box but there are different ways to mitigate that.
I personally do not use these methods now. I use cross datacenter pairs of FusionPBX boxes with DNS-SRV/NAPTR. This works very well for me.
I'm also toying with the idea of scrapping the DNS-SRV/NAPTR side of things and instead using PowerDNS with very low TTLs. I have the infrastructure in place for this but just haven't had time to play with it.
With regards to redundancy, you are still left with a SPOF, ie the kamailio box but there are different ways to mitigate that.
I personally do not use these methods now. I use cross datacenter pairs of FusionPBX boxes with DNS-SRV/NAPTR. This works very well for me.
I'm also toying with the idea of scrapping the DNS-SRV/NAPTR side of things and instead using PowerDNS with very low TTLs. I have the infrastructure in place for this but just haven't had time to play with it.
Introducing Kamailio introduced more problems for me than solved.
I.e. DNS mismatches caused by failovers and calls would hangup after 30 seconds with no apparent reason, and on some providers the third party would hang up but the call on the PBX side would remain connected / silent.
DNS failover sounds good. So you just have a mirrored copy which you swap over to on failure?
When you outgrow the PBX you could just launch a new one? Other than the single point of entry with a SIP proxy, you could just do server2.domain per 1000 or 10,000 clients.
I.e. DNS mismatches caused by failovers and calls would hangup after 30 seconds with no apparent reason, and on some providers the third party would hang up but the call on the PBX side would remain connected / silent.
DNS failover sounds good. So you just have a mirrored copy which you swap over to on failure?
When you outgrow the PBX you could just launch a new one? Other than the single point of entry with a SIP proxy, you could just do server2.domain per 1000 or 10,000 clients.
Why do you not use this anymore? What were the disadvantages besides a more complicated setup? NAPTR/SRV was never a good solution for me. A lot of SIP devices do not support it or don't work properly with it.
I do use NAPTR/SRV now and it works really well. What I do now is make pairs of FusionPBX servers in separate datacenters. I do not even replicate the freeswitch db and if a datacenter fails, we lose the calls on at that time. No big deal for the rare time it happens, the benefits far outweigh the cons IMHO.
We have lost the primary datacenter twice in the last five years.
NAPTR/SRV works perfectly on Yealinks and SRV works great with Cisco/Linksys stuff.
I tell all new clients to buy Yealink, which is just getting more and more popular. The ones that don't have a good working DNS-SRV, its there problem, I'm not gonna lose sleep over it, they get a great service anyway unless the primary DC goes out, at which point I will reminfd them that if they had been using Yealink they would still have service
We have lost the primary datacenter twice in the last five years.
NAPTR/SRV works perfectly on Yealinks and SRV works great with Cisco/Linksys stuff.
I tell all new clients to buy Yealink, which is just getting more and more popular. The ones that don't have a good working DNS-SRV, its there problem, I'm not gonna lose sleep over it, they get a great service anyway unless the primary DC goes out, at which point I will reminfd them that if they had been using Yealink they would still have service
I do use NAPTR/SRV now and it works really well. What I do now is make pairs of FusionPBX servers in separate datacenters. I do not even replicate the freeswitch db and if a datacenter fails, we lose the calls on at that time. No big deal for the rare time it happens, the benefits far outweigh the cons IMHO.
We have lost the primary datacenter twice in the last five years.
NAPTR/SRV works perfectly on Yealinks and SRV works great with Cisco/Linksys stuff.
I tell all new clients to buy Yealink, which is just getting more and more popular. The ones that don't have a good working DNS-SRV, its there problem, I'm not gonna lose sleep over it, they get a great service anyway unless the primary DC goes out, at which point I will reminfd them that if they had been using Yealink they would still have service
If you can dictate the phone make/model yes it will work ok. I don't and a lot of people use softphones, most of which do not work with SRV. Some hard phones that support SRV do not fail over. They just keep trying to use the highest priority SRV. Although that can probably be fixed with firmware and maybe it has on some of them. I need something that works all the time on everything for what I do because I don't do very much hand holding.
I have been testing this script with Kamailio v5.1. It seems to be working ok after removing the mi_* modules which no longer exist in Kam v5.x.
It appears that registration would be limited to whatever FusionPBX server the extension was dispatched to when the registration was done if you do not replicate the "freeswitch" db correct?
So if Kamailio were to failover to the other FusionPBX server the extension would need to re-register. Either by rebooting the extension or waiting for the extension to re-register which could be awhile. Has anyone tested if registration is preserved after failover by sharing the freeswitch db?
It appears that registration would be limited to whatever FusionPBX server the extension was dispatched to when the registration was done if you do not replicate the "freeswitch" db correct?
So if Kamailio were to failover to the other FusionPBX server the extension would need to re-register. Either by rebooting the extension or waiting for the extension to re-register which could be awhile. Has anyone tested if registration is preserved after failover by sharing the freeswitch db?
Last edited:
Yes it would need to reregister and if you use registration timers of 120 this should be no more than a minute so nothing to get concerned about.
I do use NAPTR/SRV now and it works really well. What I do now is make pairs of FusionPBX servers in separate datacenters. I do not even replicate the freeswitch db and if a datacenter fails, we lose the calls on at that time. No big deal for the rare time it happens, the benefits far outweigh the cons IMHO.
We have lost the primary datacenter twice in the last five years.
NAPTR/SRV works perfectly on Yealinks and SRV works great with Cisco/Linksys stuff.
I tell all new clients to buy Yealink, which is just getting more and more popular. The ones that don't have a good working DNS-SRV, its there problem, I'm not gonna lose sleep over it, they get a great service anyway unless the primary DC goes out, at which point I will reminfd them that if they had been using Yealink they would still have service
We are currently trying setup NAPTR/SRV for fusionpbx using yealink phones however they when try to register it looks like they aren't passing creds back to the server (observing sngrep). Did you run into this at all? Did you have to use any special trick to get it to work?
- Status