[SR-Users] blf in kamailio dmq cluster
Aidar Kamalov
aidar.kamalov at gmail.com
Thu Nov 30 07:25:28 CET 2017
I will setup dnsmasq on each kamailio server, which will resolve
sip.example.com to own ip. And clients from this city will use this dns and
connect to sip.example.com
2017-11-30 9:17 GMT+03:00 Yuriy Gorlichenko <ovoshlook at gmail.com>:
> I this here is a way to share user for watcher from any domain using
> rpc.subscribe command after handle_subscribe()
> It is availible to make simple service that will be triggered by subscribe
> request and make fake subscribe request with needed data for other domains.
> Handle this subscribe also by handle_subscribe(). It will put needed
> user at domain pair to watchers from needed whatcher and then will trigger
> publish for user because in watchers table it will exist on every domain.
>
> Also you can use same schema with just publush that will run after handle
> publish on when kamailio will generate publish ( triggering in
> local-request)
>
> just choose sinpliest way for you
>
> On Nov 29, 2017 21:35, "Charles Chance" <charles.chance at sipcentric.com>
> wrote:
>
>> Hello,
>>
>> So I understand that each server has its own FQDN and you want to point
>> users to their closest proxy, but are all servers part of the same
>> 'logical' domain?
>>
>> The SIP domain/realm does not have to be the same as the address/hostname
>> of the individual proxy server that is servicing a request.
>>
>> Unless, of course, you have a reason to maintain a separate domain for
>> each city. In which case, I don't believe there is a way to ignore the
>> domain in handle_publish() - users will need to subscribe to the correct
>> user at domain combination.
>>
>> Cheers,
>>
>> Charles
>>
>>
>>
>> On 29 November 2017 at 13:49, Aidar Kamalov <aidar.kamalov at gmail.com>
>> wrote:
>>
>>> I have some kamailio servers in each city: city1.example.com,
>>> city2.example.com, city3.example.com.
>>> Users in city1 connects to city1.example.com.
>>>
>>> each kamailio has in config:
>>> alias="city1.example.com"
>>> alias="city2.example.com"
>>> alias="city3.example.com"
>>>
>>> modparam("dmq", "server_address", "sip:LOCALIP:5050")
>>> modparam("dmq", "notification_address", "sip:city1.example.com:5050")
>>> modparam("dmq", "notification_address", "sip:city2.example.com:5050")
>>> modparam("dmq", "notification_address", "sip:city3.example.com:5050")
>>> modparam("dmq", "num_workers", 6)
>>> modparam("dmq_usrloc", "enable", 1)
>>> modparam("dmq_usrloc", "sync", 1)
>>>
>>> if(is_method("PUBLISH")) {
>>> handle_publish();
>>> if(!dmq_is_from_node()) dmq_t_replicate();
>>> t_release();
>>> } else if(is_method("SUBSCRIBE")) {
>>> handle_subscribe();
>>> if(!dmq_is_from_node()) dmq_t_replicate();
>>> t_release();
>>> }
>>>
>>>
>>> When publish from city1.example.com replicated to city2.example.com, PUBLISH
>>> sip:34200 at city1.example.com SIP/2.0 but there is no
>>> 34200 at city1.example.com in active_watchers table there is
>>> 34200 at city2.example.com. So when publish is coming to city2.example.com
>>> handle_publish can not found it, and doesn't send NOTIFY.
>>>
>>> Is it any way to ignore domain part in handle_publish()?
>>>
>>>
>>> 2017-11-29 16:23 GMT+03:00 Charles Chance <charles.chance at sipcentric.com
>>> >:
>>>
>>>> Hello,
>>>>
>>>> Why are you trying to operate across domains in the same DMQ cluster?
>>>> Usually, servers operating in different domains do not need to be aware of
>>>> each other's user location and/or subscription records - if a request is
>>>> for another domain, simply forward it to the server(s) responsible for that
>>>> domain.
>>>>
>>>> Also, regardless of DMQ or any replication, publishes for one domain
>>>> would not match subscriptions for another domain; even on a single server.
>>>>
>>>> Can you describe your architecture in more detail and what you are
>>>> looking to achieve with replication?
>>>>
>>>> Cheers,
>>>>
>>>> Charles
>>>>
>>>>
>>>> On 29 November 2017 at 12:45, Aidar Kamalov <aidar.kamalov at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I have two(or more) kamailio servers with dmq module and dmq_usrloc -
>>>>> sip1.example.com and sip2.example.com
>>>>> publish and subcribe replication works too.
>>>>>
>>>>> BLF works fine if clients connected to the same kamailio server,
>>>>> because in active_watchers table stored with same domain
>>>>> sip1.example.com
>>>>>
>>>>> But what to do when call going from one server to second? Is there any
>>>>> configuration to ignore domain in pusblish, subscribe, notify, etc?
>>>>>
>>>>> --
>>>>> Aydar A. Kamalov
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>
>>>> --
>>>> *Charles Chance*
>>>> Managing Director
>>>>
>>>> t. 0330 120 1200 m. 07932 063 891
>>>>
>>>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>>>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>>>> Birmingham Science Park, Birmingham B7 4BB.
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Aydar A. Kamalov
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>> Birmingham Science Park, Birmingham B7 4BB.
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
Aydar A. Kamalov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171130/dfe1f6a2/attachment.html>
More information about the sr-users
mailing list