Hi!
I'm planning a new platform based on Kamailio, to replace an existing Cisco-platform.
- A total of appr. 2000 ATAs/IP Phones (today appr. 300). - Routing to various providers/gateways via custom made OSP-server. - Two Kamailio-servers on different geographic locations. - Load-balancing/Failover of ATA's by use of DNS-SRV.
The main "problem" I see, is how local calls between ATA's registered on each of the Kamailio-servers is routed. How can Kamailio1 route a call to an ATA registered on Kamailio2?
What is best in this scenario?
1. If user not found on local Kamailio-server, forward call to next Kamailio-server. 2. Let the Kamailio-servers share the same database (same location-table)? 3. Let the Kamailio-servers copy the REGISTER to the other Kamailio-server(s) so that the other Kamailio-server(s) update their own location-table.
I would prefer not to use alternative 1...
If alternative 3 is the best, is 't_replicate' the way to do it?
What if I add a third Kamailio-server, will that change the recommendation?
Martin
Hello,
On 05.08.2009 10:37 Uhr, Martin Werne wrote:
Hi!
I'm planning a new platform based on Kamailio, to replace an existing Cisco-platform.
- A total of appr. 2000 ATAs/IP Phones (today appr. 300).
- Routing to various providers/gateways via custom made OSP-server.
- Two Kamailio-servers on different geographic locations.
- Load-balancing/Failover of ATA's by use of DNS-SRV.
The main "problem" I see, is how local calls between ATA's registered on each of the Kamailio-servers is routed. How can Kamailio1 route a call to an ATA registered on Kamailio2?
What is best in this scenario?
- If user not found on local Kamailio-server, forward call to next Kamailio-server.
- Let the Kamailio-servers share the same database (same location-table)?
- Let the Kamailio-servers copy the REGISTER to the other Kamailio-server(s) so that the other Kamailio-server(s) update their own location-table.
I would prefer not to use alternative 1...
If alternative 3 is the best, is 't_replicate' the way to do it?
What if I add a third Kamailio-server, will that change the recommendation?
t_replicate is recommended for 3., but does not scale nice for too many servers - for 3-4 is still ok. However, if you have nat, then you must route back to user through the box where is registered, so 3 is not very helpful there.
If you need more servers or nat, then probably is better to put a load balancer in front of them (with PATH if you have nat) and implement distribution logic there.
There are many solutions that applies depending of platform specifics. If one user can register only once, you ca do a star deployment. A master registrar stays is the middle, and gets updates of where one user is registered. If a registrar does not find the user locally, sends call to master registrar which forwards to appropriate registrar or returns no found.
We can talk hours about possible and best distribution solutions ...
Cheers, Daniel
2009/8/5 Martin Werne martin.werne@googlemail.com:
- A total of appr. 2000 ATAs/IP Phones (today appr. 300).
- Routing to various providers/gateways via custom made OSP-server.
- Two Kamailio-servers on different geographic locations.
- Load-balancing/Failover of ATA's by use of DNS-SRV.
The main "problem" I see, is how local calls between ATA's registered on each of the Kamailio-servers is routed. How can Kamailio1 route a call to an ATA registered on Kamailio2?
What is best in this scenario?
- Let the Kamailio-servers share the same database (same location-table)?
I'd go for that one. It worked really well for me. You can add a multi-master replication between mysql servers for example (to have a lower access time between the openser and db). But if you're using the standard registration time (3600s), it might be an overkill (only 0.555 registrations/s with 2000 clients).
If both proxies can reach any registered phone, you don't have to do anything else. If you have to route through the same proxy the phone is registered on, you can solve it with either path, or some simple custom logic.
Watch out for ATAs and phones with broken SRV randomisation - many will select the first entry every time. If your dns server is normal and doesn't randomise the order, you may end up with every phone using the same proxy all the time, or some strange split (30/70 was fairly standard for me when using any random phones).
Stanisław Pitucha wrote:
But if you're using the standard registration time (3600s), it might be an overkill (only 0.555 registrations/s with 2000 clients).
Assuming an even temporal distribution, of course. :-)
On 05.08.2009 12:22 Uhr, Stanis?aw Pitucha wrote:
2009/8/5 Martin Werne martin.werne@googlemail.com:
- A total of appr. 2000 ATAs/IP Phones (today appr. 300).
- Routing to various providers/gateways via custom made OSP-server.
- Two Kamailio-servers on different geographic locations.
- Load-balancing/Failover of ATA's by use of DNS-SRV.
The main "problem" I see, is how local calls between ATA's registered on each of the Kamailio-servers is routed. How can Kamailio1 route a call to an ATA registered on Kamailio2?
What is best in this scenario?
- Let the Kamailio-servers share the same database (same location-table)?
I'd go for that one. It worked really well for me. You can add a multi-master replication
i am using master-master (cross replication) which works fine but when synchronization screws up, becomes quite tricky. Alternative is one master (writer) per a db table and one or more readers on replicated nodes node.
Cheers, Daniel
between mysql servers for example (to have a lower access time between the openser and db). But if you're using the standard registration time (3600s), it might be an overkill (only 0.555 registrations/s with 2000 clients).
If both proxies can reach any registered phone, you don't have to do anything else. If you have to route through the same proxy the phone is registered on, you can solve it with either path, or some simple custom logic.
Watch out for ATAs and phones with broken SRV randomisation - many will select the first entry every time. If your dns server is normal and doesn't randomise the order, you may end up with every phone using the same proxy all the time, or some strange split (30/70 was fairly standard for me when using any random phones).
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users