[OpenSIPS-Users] Dispatcher within a K8s environment

Ben Newlin Ben.Newlin at genesys.com
Thu Aug 25 17:54:53 UTC 2022

The drouting module has a parameter that allows you to disable the DNS lookup.


Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Jonathan Hunter <hunterj91 at hotmail.com>
Date: Thursday, August 25, 2022 at 4:54 AM
To: Bogdan-Andrei Iancu <bogdan at opensips.org>, OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Dispatcher within a K8s environment
 EXTERNAL EMAIL - Please use caution with links and attachments

Hi Bogdan,

Yes it would appear K8s implementations would be a very good topic at the Summit that is for sure!

I understand your comments on dispatcher, its unfortunate as everything else is working fine.

There was a suggestion to add a loopback address for example and then update  when DNS has updated and records resolve?

Is there any benefit in using dr_routing instead or will this behaviour be the same in the event of a dns lookup failure?

Thanks for the response!


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Bogdan-Andrei Iancu<mailto:bogdan at opensips.org>
Sent: 24 August 2022 12:29
To: OpenSIPS users mailling list<mailto:users at lists.opensips.org>; Jonathan Hunter<mailto:hunterj91 at hotmail.com>
Subject: Re: [OpenSIPS-Users] Dispatcher within a K8s environment

Hi Jonathan,

I guess this will be a good topic (DS and K8S) for the OpenSIPS Summit in Athens - I think this is the 3rd time in the last week coming across it :)

Unfortunately there is no way to skip at the moment that DNS failure when loading the destinations :(....even more, there some code that relies on the fact that there is an "IP" attached to any destination.....And I just checked, a local error in sending the ping (like the DNS err) does not results in marking the destination as failed or so..... so it is not so straight as ignoring the DNS error.

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer


OpenSIPS Summit 27-30 Sept 2022, Athens

On 8/24/22 12:24 AM, Jonathan Hunter wrote:
Hi All,

I have a query around dispatcher behaviour, I am running 3.2 in a k8s environment.

I have 2 freeswitch instances defined in a destination set, both of which are pods.

As people may be aware its fun implementing in k8s as pods can restart and disappear at times so I ideally want this reflected in the cache and output of opensips-cli -x mi ds_list where I was hoping the freeswitch entries would be defined but with a state of probing or inactive.

With my current setup, when restarting opensips for example, I have the dispatcher table populated in postgres db , and if opensips cant resolve the URI it wont load it into cache, like wise if opensips is running and freeswitch pod drops, I see this in the logs;

Aug 23 21:22:01 [55] ERROR:dispatcher:add_dest2list: could not resolve freeswitch-opensips-deployment-1.freeswitch-opensips, skipping it
Aug 23 21:22:01 [55] WARNING:dispatcher:ds_load_data: failed to add destination <sip:freeswitch-opensips-deployment-1.freeswitch-opensips:5070;transport=tcp><sip:freeswitch-opensips-deployment-1.freeswitch-opensips:5070;transport=tcp> in group 10

I therefore don’t see it listed in cache when I run ds_list.

Does anyone know if its possible to tweak dispatcher to always load the database entries into cache at startup, and also set their status to probing/inactive if not reachable due to a resolving issue as above?

My dispatcher settings are;

#### Dynamic routing
loadmodule "dispatcher.so"
modparam("dispatcher", "db_url", "postgres://x.x.x.x/opensips")
modparam("dispatcher", "ds_probing_mode", 1)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "persistent_state", 0)
modparam("dispatcher", "ds_ping_interval", 5)
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "cluster_id", 1)

Hope that makes sense!

Many thanks



Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220825/88a9ae8f/attachment-0001.html>

More information about the Users mailing list