I am trying to create a cluster of Kamailio servers. I want users that are registered on one server to be able to contact and call users on other servers. How can I implement this in Kamailio?
PS: My servers are in a private network and I do not have DNS.
I have something similar and I use the following architecture:
NGCP-A-------------------------subscribres A||sip trunk between A and B ||NGCP-B-------------------------subscribers B ||sip trunk between B and C |NGCP-C-------------------------Subscribers C ||sip trunk between A and C |NGCP-A-------------------------subscribres A
The only thing in my scenario is that Subscriber A can only register in NGCP A. ...and the same is valid fo B and C if this is something that will work for you as well email me for more details how to set it up!Ari.
On Sunday, January 31, 2016 8:06 AM, Gholamreza Sabery gr.sabery@gmail.com wrote:
I am trying to create a cluster of Kamailio servers. I want users that are registered on one server to be able to contact and call users on other servers. How can I implement this in Kamailio?
PS: My servers are in a private network and I do not have DNS.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
hi Gholamreza Sabery you should be implement HA on your server.you can use the pacemaker/corosync or other software for run and configuration HA on your server.
On 1/31/16, Gholamreza Sabery gr.sabery@gmail.com wrote:
I am trying to create a cluster of Kamailio servers. I want users that are registered on one server to be able to contact and call users on other servers. How can I implement this in Kamailio?
PS: My servers are in a private network and I do not have DNS.
Dear Hossein; I know about Corosync and Pacemaker and I implemented something using these tools with Ansible ( https://github.com/ghrst/Kamailio-HA). But my question here is about active-active scenarios not an active-passive one!
On Mon, Feb 1, 2016 at 2:14 AM, Hossein Aghaie hossein.a97@gmail.com wrote:
hi Gholamreza Sabery you should be implement HA on your server.you can use the pacemaker/corosync or other software for run and configuration HA on your server.
On 1/31/16, Gholamreza Sabery gr.sabery@gmail.com wrote:
I am trying to create a cluster of Kamailio servers. I want users that
are
registered on one server to be able to contact and call users on other servers. How can I implement this in Kamailio?
PS: My servers are in a private network and I do not have DNS.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Gholamreza,
Most Kamailio functionality can be used in an active-active way as long as there is a database persistence layer that can be shared among them:
In particular, since you asked about the registrar: you can use `db_mode` 3 with `usrloc` to achieve this persistence:
http://kamailio.org/docs/modules/4.3.x/modules/usrloc.html#usrloc.p.db_mode
That is to say, if multiple Kamailio instances are configured to use the same database with usrloc db_mode 3, then any of them can resolve any registration binding regardless of which actual proxy it was saved on.
That said, database-based sharing is certainly not the only approach, particularly to replication of registration contacts. A few others:
1) Replicate registration messages manually with t_replicate():
http://kamailio.org/docs/modules/4.3.x/modules/tm.html#tm.f.t_replicate
2) Use the `dmq` interprocess messaging bus to replicate the location table that way:
http://kamailio.org/docs/modules/4.3.x/modules/dmq_usrloc.html
So, it's fair to say this problem is amply solved in relation to the registrar functionality specifically.
If your question was more general: there is no generic Kamailio clustering concept that can continuously replicate all internal state across multiple proxy instances. In keeping with Kamailio's fairly low-level interior, you must choose and implement your own specific methodologies for this that are appropriate for the architecture and business rules of your applications and services.
-- Alex
Although, the core `dmq` module is a big help in providing a distribution vehicle for messaging you do wish to replicate into a 'cluster':
http://kamailio.org/docs/modules/4.3.x/modules/dmq.html#dmq.f.dmq_t_replicat...
Thank you so much Alex. I tried REGISTER replication and DM_MODE 3. But my problem here is that in these scenarios Kamailio will give you a non-local socket error. I want to have multiple Kamailio servers so that a user that is registered on one server can easily call other users on another server.
On Mon, Feb 1, 2016 at 10:01 AM, Alex Balashov abalashov@evaristesys.com wrote:
Although, the core `dmq` module is a big help in providing a distribution vehicle for messaging you do wish to replicate into a 'cluster':
http://kamailio.org/docs/modules/4.3.x/modules/dmq.html#dmq.f.dmq_t_replicat...
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 02/01/2016 02:33 AM, Gholamreza Sabery wrote:
in these scenarios Kamailio will give you a non-local socket error
It's a warning, not an error. Right?
I don't remember how we solved that...
Here's a thought, though:
If your goal is really for users registered on one server to be able to easily call users registered on another server, you probably don't care to replicate or share the 'location' table per se. You just want one Kamailio server to call the right Kamailio server to reach the user's native home.
In that case, why not create a database view over a composition of the 'location' tables of various servers that exposes a map of AoR -> socket? You can then query those values with 'sqlops' yourself and forward the call to the correct server, which can then do a native lookup().
Yes I want to distribute my users across multiple Kamailio servers. It seems a good idea than you Alex I will try it!
On Mon, Feb 1, 2016 at 11:10 AM, Alex Balashov abalashov@evaristesys.com wrote:
Here's a thought, though:
If your goal is really for users registered on one server to be able to easily call users registered on another server, you probably don't care to replicate or share the 'location' table per se. You just want one Kamailio server to call the right Kamailio server to reach the user's native home.
In that case, why not create a database view over a composition of the 'location' tables of various servers that exposes a map of AoR -> socket? You can then query those values with 'sqlops' yourself and forward the call to the correct server, which can then do a native lookup().
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi,
I think you need to make record routing, so it will keep initial(to what user registered) Kamailio in signaling path.
I hope it will helps.
With kind regards,
Jurijs
2016-02-01 9:33 GMT+02:00 Gholamreza Sabery gr.sabery@gmail.com:
Thank you so much Alex. I tried REGISTER replication and DM_MODE 3. But my problem here is that in these scenarios Kamailio will give you a non-local socket error. I want to have multiple Kamailio servers so that a user that is registered on one server can easily call other users on another server.
On Mon, Feb 1, 2016 at 10:01 AM, Alex Balashov abalashov@evaristesys.com wrote:
Although, the core `dmq` module is a big help in providing a distribution vehicle for messaging you do wish to replicate into a 'cluster':
http://kamailio.org/docs/modules/4.3.x/modules/dmq.html#dmq.f.dmq_t_replicat...
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 02/01/2016 02:59 AM, Jurijs Ivolga wrote:
I think you need to make record routing, so it will keep initial(to what user registered) Kamailio in signaling path.
Ah, no. Record-Route is for INVITEs only. You're thinking of Path.
Hi Alex,
You are right. :)
With kind regards,
2016-02-01 10:09 GMT+02:00 Alex Balashov abalashov@evaristesys.com:
On 02/01/2016 02:59 AM, Jurijs Ivolga wrote:
I think you need to make record routing, so it will keep initial(to what
user registered) Kamailio in signaling path.
Ah, no. Record-Route is for INVITEs only. You're thinking of Path.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi, a solution in this case could be making usage of Path header ( https://tools.ietf.org/html/rfc3327).
You have to load the path module
http://www.kamailio.org/docs/modules/devel/modules/path.html
and enabled its usage in registrar module
http://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar....
If you plan to use REGISTER replication through t_replicate() just call add_path() before replicating the message to the other server(s). If you use a shared database with db_mode = 3, call msg_apply_changes ( http://www.kamailio.org/docs/modules/devel/modules/textopsx.html#textopsx.f....) before saving the contact. In this case also be sure to set path_check_local parametr of the registrar module ( http://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar....) to 1.
Cheers,
Federico
On Mon, Feb 1, 2016 at 9:10 AM, Jurijs Ivolga jurij.ivo@gmail.com wrote:
Hi Alex,
You are right. :)
With kind regards,
2016-02-01 10:09 GMT+02:00 Alex Balashov abalashov@evaristesys.com:
On 02/01/2016 02:59 AM, Jurijs Ivolga wrote:
I think you need to make record routing, so it will keep initial(to what
user registered) Kamailio in signaling path.
Ah, no. Record-Route is for INVITEs only. You're thinking of Path.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Jurijs
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
All right. Thank you so much.
On Mon, Feb 1, 2016 at 11:47 AM, Federico Cabiddu < federico.cabiddu@gmail.com> wrote:
Hi, a solution in this case could be making usage of Path header ( https://tools.ietf.org/html/rfc3327).
You have to load the path module
http://www.kamailio.org/docs/modules/devel/modules/path.html
and enabled its usage in registrar module
http://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar....
If you plan to use REGISTER replication through t_replicate() just call add_path() before replicating the message to the other server(s). If you use a shared database with db_mode = 3, call msg_apply_changes ( http://www.kamailio.org/docs/modules/devel/modules/textopsx.html#textopsx.f....) before saving the contact. In this case also be sure to set path_check_local parametr of the registrar module ( http://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar....) to 1.
Cheers,
Federico
On Mon, Feb 1, 2016 at 9:10 AM, Jurijs Ivolga jurij.ivo@gmail.com wrote:
Hi Alex,
You are right. :)
With kind regards,
2016-02-01 10:09 GMT+02:00 Alex Balashov abalashov@evaristesys.com:
On 02/01/2016 02:59 AM, Jurijs Ivolga wrote:
I think you need to make record routing, so it will keep initial(to what
user registered) Kamailio in signaling path.
Ah, no. Record-Route is for INVITEs only. You're thinking of Path.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Jurijs
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Also one of the most siplies ways to resolve your issue is using queries at the databases that select needed fields from db with (where socket="<your_local_socket>").
2016-02-01 11:43 GMT+03:00 Gholamreza Sabery gr.sabery@gmail.com:
All right. Thank you so much.
On Mon, Feb 1, 2016 at 11:47 AM, Federico Cabiddu < federico.cabiddu@gmail.com> wrote:
Hi, a solution in this case could be making usage of Path header ( https://tools.ietf.org/html/rfc3327).
You have to load the path module
http://www.kamailio.org/docs/modules/devel/modules/path.html
and enabled its usage in registrar module
http://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar....
If you plan to use REGISTER replication through t_replicate() just call add_path() before replicating the message to the other server(s). If you use a shared database with db_mode = 3, call msg_apply_changes ( http://www.kamailio.org/docs/modules/devel/modules/textopsx.html#textopsx.f....) before saving the contact. In this case also be sure to set path_check_local parametr of the registrar module ( http://www.kamailio.org/docs/modules/devel/modules/registrar.html#registrar....) to 1.
Cheers,
Federico
On Mon, Feb 1, 2016 at 9:10 AM, Jurijs Ivolga jurij.ivo@gmail.com wrote:
Hi Alex,
You are right. :)
With kind regards,
2016-02-01 10:09 GMT+02:00 Alex Balashov abalashov@evaristesys.com:
On 02/01/2016 02:59 AM, Jurijs Ivolga wrote:
I think you need to make record routing, so it will keep initial(to what
user registered) Kamailio in signaling path.
Ah, no. Record-Route is for INVITEs only. You're thinking of Path.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Jurijs
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Mon, Feb 01, 2016 at 09:17:41AM +0100, Federico Cabiddu wrote:
a solution in this case could be making usage of Path header ( https://tools.ietf.org/html/rfc3327). You have to load the path module http://www.kamailio.org/docs/modules/devel/modules/path.html and enabled its usage in registrar module
Be warned that any stateful firewall or NATed client will not accept the messages from any other sipserver to that client. My solution was to use edge/loadbalancer proxies which add the Path header using add_path_received to store both the edge/loadbalancer ip and client source before passing the request to the backends (using dispatcher).
Any backend will send messages based on the Path headers to the edge/loadbalancer and that will pass it to the client to appease statefull firewalls.
Actually I think something is not clear here. Suppose I want to use two Kamailio servers such that a client which is registered on server A is able to call another client registered on server B. In this case I use DB_MODE 3. Both servers have access to location database but sockets are non-local and cleints are behind symmetric NATs.Now only the server on which the client is registered and sent it's request to is able to respond(because of symmetric NAT). Is it possible to implement this scenario using Path header?
Regards
On Wed, Feb 3, 2016 at 12:55 PM, Daniel Tryba d.tryba@pocos.nl wrote:
On Mon, Feb 01, 2016 at 09:17:41AM +0100, Federico Cabiddu wrote:
a solution in this case could be making usage of Path header ( https://tools.ietf.org/html/rfc3327). You have to load the path module http://www.kamailio.org/docs/modules/devel/modules/path.html and enabled its usage in registrar module
Be warned that any stateful firewall or NATed client will not accept the messages from any other sipserver to that client. My solution was to use edge/loadbalancer proxies which add the Path header using add_path_received to store both the edge/loadbalancer ip and client source before passing the request to the backends (using dispatcher).
Any backend will send messages based on the Path headers to the edge/loadbalancer and that will pass it to the client to appease statefull firewalls.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi,
If you have following:
UA A ====> Kamilio 1
UA B ====> Kamailio 2
With path you just make sure that all calls are routed to that server where UA initially registered.
So if UA A is calling UA B, call will go in such way: UA A=> Kamilio 1 => Kamailio 2 => UA B.
I hope I answered your question.
With kind regards,
2016-02-03 12:18 GMT+02:00 Gholamreza Sabery gr.sabery@gmail.com:
Actually I think something is not clear here. Suppose I want to use two Kamailio servers such that a client which is registered on server A is able to call another client registered on server B. In this case I use DB_MODE 3. Both servers have access to location database but sockets are non-local and cleints are behind symmetric NATs.Now only the server on which the client is registered and sent it's request to is able to respond(because of symmetric NAT). Is it possible to implement this scenario using Path header?
Regards
On Wed, Feb 3, 2016 at 12:55 PM, Daniel Tryba d.tryba@pocos.nl wrote:
On Mon, Feb 01, 2016 at 09:17:41AM +0100, Federico Cabiddu wrote:
a solution in this case could be making usage of Path header ( https://tools.ietf.org/html/rfc3327). You have to load the path module http://www.kamailio.org/docs/modules/devel/modules/path.html and enabled its usage in registrar module
Be warned that any stateful firewall or NATed client will not accept the messages from any other sipserver to that client. My solution was to use edge/loadbalancer proxies which add the Path header using add_path_received to store both the edge/loadbalancer ip and client source before passing the request to the backends (using dispatcher).
Any backend will send messages based on the Path headers to the edge/loadbalancer and that will pass it to the client to appease statefull firewalls.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Wed, Feb 03, 2016 at 01:48:50PM +0330, Gholamreza Sabery wrote:
Actually I think something is not clear here. Suppose I want to use two Kamailio servers such that a client which is registered on server A is able to call another client registered on server B. In this case I use DB_MODE 3. Both servers have access to location database but sockets are non-local and cleints are behind symmetric NATs.Now only the server on which the client is registered and sent it's request to is able to respond(because of symmetric NAT). Is it possible to implement this scenario using Path header?
This is still ambigious, server B can't call the client due to nat, but server B can call server A. The trick might be to add a Path header on server A before save the register on server A. Or to use custom queries to find out that the registered socket isn't local so send the invite to the non local adress instead.
I asked similar questions: http://lists.sip-router.org/pipermail/sr-users/2015-April/087867.html
My final solution is using a really loadbalancer with static config, which adds Path and dispatches to individual backends. Difference is that server B doesn't INVITE to server A but to the loadbalancer for a client registered on server A.
Hi, Interesting discussion going on. Ive to ask can OP use shared location table between different kamailio servers and use db mode 3. All he has to do is if UA B calls UA A via Kamailio2 he just needs to find the received socket and if it is not local Kamailio2 then route to the IP maybe attach a custom header and relay call to Kamailio1. Kamailio1 gets call with the custom headers sends call to route(LOCATION) or w/e he has for lookups.
Regards, Sammy On Feb 3, 2016 06:19, "Daniel Tryba" d.tryba@pocos.nl wrote:
On Wed, Feb 03, 2016 at 01:48:50PM +0330, Gholamreza Sabery wrote:
Actually I think something is not clear here. Suppose I want to use two Kamailio servers such that a client which is registered on server A is
able
to call another client registered on server B. In this case I use DB_MODE 3. Both servers have access to location database but sockets are
non-local
and cleints are behind symmetric NATs.Now only the server on which the client is registered and sent it's request to is able to respond(because
of
symmetric NAT). Is it possible to implement this scenario using Path
header?
This is still ambigious, server B can't call the client due to nat, but server B can call server A. The trick might be to add a Path header on server A before save the register on server A. Or to use custom queries to find out that the registered socket isn't local so send the invite to the non local adress instead.
I asked similar questions: http://lists.sip-router.org/pipermail/sr-users/2015-April/087867.html
My final solution is using a really loadbalancer with static config, which adds Path and dispatches to individual backends. Difference is that server B doesn't INVITE to server A but to the loadbalancer for a client registered on server A.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
The solution I am using is to have each Kamailio servers read subscriber/location data from a local database server. Each of these local databases is replicated from a Master database. We have db_mode=3 for sqlops, so it's always reading from the database to identify the user/phone.
-H
On 2016-01-31 1:06 AM, Gholamreza Sabery wrote: I am trying to create a cluster of Kamailio servers. I want users that are registered on one server to be able to contact and call users on other servers. How can I implement this in Kamailio?
PS: My servers are in a private network and I do not have DNS.
-
Alex Balashov -
Aria Mill -
Daniel Tryba -
Federico Cabiddu -
Gholamreza Sabery -
Henry Fernandes -
Hossein Aghaie -
Jurijs Ivolga -
SamyGo -
Yuriy Gorlichenko