[OpenSIPS-Users] Dispatcher stickyness for external inbound calls

Matthias Kneer matze at roterruler.de
Thu Dec 5 10:01:05 EST 2019


Hi list,

I'm currently building a HA setup with 2 openSIPS 2.4 instances which do 
share a floating IP through keepalived. They are working as 1:1 
mid_registrar, gateway to the PSTN and dispatcher for multiple 
FreeSWITCH instances. Those FreeSWITCH instances hold all accounts, 
domains and media services, they also do the RTP part.

Since we are hosting multiple customers on the same FreeSWITCH 
instances, sperated through domains, we'd like to ensure that all 
registrations of a domain stay on the same FreeSWITCH as long this 
instance is reachable. We want this to ensure that conferences, call 
pickups and so on work reliable. It's not very important for us to 
distribute the load evenly since we have no high call / conference 
volume, the goal is more to have the setup as available as possible with 
some sort of loadbalancing and without having to take manual action if 
one of the FreeSWITCHes dies.

To achieve this, our idea was to set *modparam("dispatcher", 
"hash_pvar", "$fd")* to use the from domain as source for hashing and 
call *ds_select_dst *with the alg "7":

if (!ds_select_dst("2", "7"))
{
   xlog("L_ERR", "$ci|end|no servers avaliable");
   sl_send_reply("480", "Temporarily Unavailable");
   exit;
}

This approach works fine as long as we use it for internal calls since 
those have the from / to domain part properly set. If a call arrives 
from the PSTN openSIPS has no knowledge about the relation of the 
external numbers and internal numbers / domains. Is there a smart way to 
properly route those external calls to the correct FreeSWITCH wihtout 
having openSIPS to access the FreeSWITCH database / duplicating the data 
into the openSIPS database or to run FreeSWITCH in active/standby mode?

Best regards,
Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20191205/56cb0641/attachment.html>


More information about the Users mailing list