[SR-Users] repository not present

[Jyoti bansal]

 Hello all,I was trying to install kamaillio ims following the instructions on page https://www.kamailio.org/wiki/tutorials/ims/installation-howto While coming on the step  “Installation of the Kamailio-IMS-Packages”wget -O - http://repository.ng-voice.com/PublicKey | apt-key add - While performing wget  getting error as respoitory.ng-voice.com is not available.So Please could anyone help me with this repo or what alternative to use instead. Thanks.  Sent from Mail for Windows 


Confidentiality Notice and Disclaimer: This email (including any attachments) contains information that may be confidential, privileged and/or copyrighted. If you are not the intended recipient, please notify the sender immediately and destroy this email. Any unauthorized use of the contents of this email in any manner whatsoever, is strictly prohibited. If improper activity is suspected, all available information may be used by the sender for possible disciplinary action, prosecution, civil claim or any remedy or lawful purpose. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, lost, arrive late, or contain viruses. The sender is not liable whatsoever for damage resulting from the opening of this message and/or the use of the information contained in this message and/or attachments. Expressions in this email cannot be treated as opined by the sender company management – they are solely expressed by the sender unless authorized.

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio Stop processing SIP traffic

[Ovidiu Sas]

Check with htop if you don't have any kamailio procs at 100% CPU (due
to a deadlock).
Do you see any errors in the logs?

-ovidiu


On Wed, Dec 22, 2021 at 11:44 AM pwerspire  wrote:
>
> The CPU is around 30% during the test, is always really stable and memory 
> doesn't increase much.
>
> I'm using children=8.
>
>
>
> Sergio Charrua  escreveu no dia quarta, 22/12/2021 
> à(s) 16:27:
>>
>> any statistics regarding CPU use? how many threads?
>>
>> Sérgio Charrua
>>
>>
>> www.voip.pt
>> Tel.: +351 21 130 71 77
>>
>> Email : sergio.char...@voip.pt
>>
>> This message and any files or documents attached are strictly confidential 
>> or otherwise legally protected.
>>
>> It is intended only for the individual or entity named. If you are not the 
>> named addressee or have received this email in error, please inform the 
>> sender immediately, delete it from your system and do not copy or disclose 
>> it or its contents or use it for any purpose. Please also note that 
>> transmission cannot be guaranteed to be secure or error-free.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Dec 22, 2021 at 3:57 PM pwerspire  wrote:
>>>
>>> Hi Sergio,
>>>
>>> Thanks for your reply.
>>>
>>> This is a google cloud VM with 8 vCPU,  I'm using 100 CPS but the number of 
>>> simultaneous calls is stable at around 1071 at any given time.
>>>
>>> Also, I can always see INVITES going inside the server but Kamailio stops 
>>> answering them, even if you stop sending calls for a long time, and then 
>>> send a single call, Kamailio will not reply anymore to the Invites.
>>>
>>> When Kamailio stops replying to INVITES, If I do for example a "kamcmd 
>>> dispatcher.list" I have the correct output, but if I do a "kamcmd dlg.list" 
>>> it will not provide any output and not give back the prompt( before it 
>>> would just answer that the reply was too big).
>>> I will need to use "control + c" to get the prompt of the shell back and 
>>> after that, all kamcmd commands stop returning any output or giving back 
>>> the prompt.
>>>
>>> If the Kamailio is then restarted, everything starts working correctly 
>>> again. Also, another note is that this seems only to happen when DMQ is in 
>>> use and replicating to the fallback Kamailio.
>>>
>>> Regards,
>>> Tiago
>>>
>>>
>>> Sergio Charrua  escreveu no dia terça, 21/12/2021 
>>> à(s) 13:38:

 What is the call length of each call? How many NICs you have on that 
 server? what networking switches are you using? all these variables have 
 huge impacts on the call flow!

 Let's say you make 100CPS and the call length is 10 minutes.
 At 10 seconds you will have 1.000 ongoing calls using g711 (64kbps). You 
 will have around 64Mbps bandwidth being used.
 At 1 minute you get 6.000 ongoing calls and will use 390Mbps bandwidth!
 Near the 10th minute you will be using almost 4Gbps bandwidth and 60.000 
 ongoing calls!!

 Maybe the issue is not within Kamailio and/or the media server, but within 
 your network capacity ...

 On my side, on a 4 vCPU and 4GB Ram, Kamailio 5.2 gets me around 400cps 
 with calls up to 30seconds length, and RTPEngine goes OK too. I am sure I 
 could do more, but I don't bother much, this is more than enough!
 But I have an enormous amount of bandwidth and 3 NICs on the server. NICs 
 are the key . Remember that Kamailio only processes SIP messages.
 At 5 minutes, using the above call details, you've already sent 30.000 SIP 
 INVITES minimum and many more SIP messages during that time. You need a 
 very good network interface to do that kind of job!
 Add 30.000 channels / RTP ports to your media server and you get a whole 
 lot of data going on in your network. I bet even the UTP5 cables won't 
 handle the heat   =:o)

 Also, check the RTP port range your media server was configured with.
 On Asterisk, usually ports 10.000 to 20.000 are set, which is about 10.000 
 calls. In the above example, you would stop receiving calls at 2minutes 
 because Asterisk has all RTP ports busy/in use!
 I don't know about other media servers, but I would bet this is pretty 
 much the same...

 Hope this helps!


 Sérgio Charrua


 www.voip.pt
 Tel.: +351 21 130 71 77

 Email : sergio.char...@voip.pt

 This message and any files or documents attached are strictly confidential 
 or otherwise legally protected.

 It is intended only for the individual or entity named. If you are not the 
 named addressee or have received this email in error, please inform the 
 sender immediately, delete it from your system and do not copy or disclose 
 it or its contents or use it for any purpose. Please also note that 
 transmission cannot be guaranteed to be secure or error-free.









 On Tue, Dec 21, 2021 at 11:54 AM pwerspire  wrote:
>
> Hi,
>
> I have 

Re: [SR-Users] Kamailio Stop processing SIP traffic

[pwerspire]

The CPU is around 30% during the test, is always really stable and memory
doesn't increase much.

I'm using children=8.



Sergio Charrua  escreveu no dia quarta, 22/12/2021
à(s) 16:27:

> any statistics regarding CPU use? how many threads?
>
> *Sérgio Charrua*
>
>
> *www.voip.pt *
> Tel.: +351  21 130 71 77
>
> Email : *sergio.char...@voip.pt *
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
>
> On Wed, Dec 22, 2021 at 3:57 PM pwerspire  wrote:
>
>> Hi Sergio,
>>
>> Thanks for your reply.
>>
>> This is a google cloud VM with 8 vCPU,  I'm using 100 CPS but the number
>> of simultaneous calls is stable at around 1071 at any given time.
>>
>> Also, I can always see INVITES going inside the server but Kamailio
>> stops answering them, even if you stop sending calls for a long time, and
>> then send a single call, Kamailio will not reply anymore to the Invites.
>>
>> When Kamailio stops replying to INVITES, If I do for example a "kamcmd
>> dispatcher.list" I have the correct output, but if I do a "kamcmd dlg.list"
>> it will not provide any output and not give back the prompt( before it
>> would just answer that the reply was too big).
>> I will need to use "control + c" to get the prompt of the shell back and
>> after that, all kamcmd commands stop returning any output or giving back
>> the prompt.
>>
>> If the Kamailio is then restarted, everything starts working correctly
>> again. Also, another note is that this seems only to happen when DMQ is in
>> use and replicating to the fallback Kamailio.
>>
>> Regards,
>> Tiago
>>
>>
>> Sergio Charrua  escreveu no dia terça,
>> 21/12/2021 à(s) 13:38:
>>
>>> What is the call length of each call? How many NICs you have on that
>>> server? what networking switches are you using? all these variables have
>>> huge impacts on the call flow!
>>>
>>> Let's say you make 100CPS and the call length is 10 minutes.
>>> At 10 seconds you will have 1.000 ongoing calls using g711 (64kbps). You
>>> will have around 64Mbps bandwidth being used.
>>> At 1 minute you get 6.000 ongoing calls and will use 390Mbps bandwidth!
>>> Near the 10th minute you will be using almost 4Gbps bandwidth and 60.000
>>> ongoing calls!!
>>>
>>> Maybe the issue is not within Kamailio and/or the media server, but
>>> within your network capacity ...
>>>
>>> On my side, on a 4 vCPU and 4GB Ram, Kamailio 5.2 gets me around 400cps
>>> with calls up to 30seconds length, and RTPEngine goes OK too. I am sure I
>>> could do more, but I don't bother much, this is more than enough!
>>> But I have an enormous amount of bandwidth and 3 NICs on the server.
>>> NICs are the key . Remember that Kamailio only processes SIP messages.
>>> At 5 minutes, using the above call details, you've already sent 30.000
>>> SIP INVITES minimum and many more SIP messages during that time. You need a
>>> very good network interface to do that kind of job!
>>> Add 30.000 channels / RTP ports to your media server and you get a whole
>>> lot of data going on in your network. I bet even the UTP5 cables won't
>>> handle the heat   =:o)
>>>
>>> Also, check the RTP port range your media server was configured with.
>>> On Asterisk, usually ports 10.000 to 20.000 are set, which is about
>>> 10.000 calls. In the above example, you would stop receiving calls at
>>> 2minutes because Asterisk has all RTP ports busy/in use!
>>> I don't know about other media servers, but I would bet this is pretty
>>> much the same...
>>>
>>> Hope this helps!
>>>
>>>
>>> *Sérgio Charrua*
>>>
>>>
>>> *www.voip.pt *
>>> Tel.: +351  21 130 71 77
>>>
>>> Email : *sergio.char...@voip.pt *
>>>
>>> This message and any files or documents attached are strictly
>>> confidential or otherwise legally protected.
>>>
>>> It is intended only for the individual or entity named. If you are not
>>> the named addressee or have received this email in error, please inform the
>>> sender immediately, delete it from your system and do not copy or disclose
>>> it or its contents or use it for any purpose. Please also note that
>>> transmission cannot be guaranteed to be secure or error-free.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Dec 21, 2021 at 11:54 AM pwerspire  wrote:
>>>
 Hi,

 I have been doing some load testing with Kamailio and having some
 issues.

 I have been trying with 100 CPS and at the beginning, everything is
 working well but after some time (it can be 10 minutes or for example 40
 minutes, is just random but normally happens more in the first 10 minutes)
 

Re: [SR-Users] Kamailio Stop processing SIP traffic

[Sergio Charrua]

any statistics regarding CPU use? how many threads?

*Sérgio Charrua*


*www.voip.pt *
Tel.: +351  21 130 71 77

Email : *sergio.char...@voip.pt *

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Wed, Dec 22, 2021 at 3:57 PM pwerspire  wrote:

> Hi Sergio,
>
> Thanks for your reply.
>
> This is a google cloud VM with 8 vCPU,  I'm using 100 CPS but the number
> of simultaneous calls is stable at around 1071 at any given time.
>
> Also, I can always see INVITES going inside the server but Kamailio
> stops answering them, even if you stop sending calls for a long time, and
> then send a single call, Kamailio will not reply anymore to the Invites.
>
> When Kamailio stops replying to INVITES, If I do for example a "kamcmd
> dispatcher.list" I have the correct output, but if I do a "kamcmd dlg.list"
> it will not provide any output and not give back the prompt( before it
> would just answer that the reply was too big).
> I will need to use "control + c" to get the prompt of the shell back and
> after that, all kamcmd commands stop returning any output or giving back
> the prompt.
>
> If the Kamailio is then restarted, everything starts working correctly
> again. Also, another note is that this seems only to happen when DMQ is in
> use and replicating to the fallback Kamailio.
>
> Regards,
> Tiago
>
>
> Sergio Charrua  escreveu no dia terça, 21/12/2021
> à(s) 13:38:
>
>> What is the call length of each call? How many NICs you have on that
>> server? what networking switches are you using? all these variables have
>> huge impacts on the call flow!
>>
>> Let's say you make 100CPS and the call length is 10 minutes.
>> At 10 seconds you will have 1.000 ongoing calls using g711 (64kbps). You
>> will have around 64Mbps bandwidth being used.
>> At 1 minute you get 6.000 ongoing calls and will use 390Mbps bandwidth!
>> Near the 10th minute you will be using almost 4Gbps bandwidth and 60.000
>> ongoing calls!!
>>
>> Maybe the issue is not within Kamailio and/or the media server, but
>> within your network capacity ...
>>
>> On my side, on a 4 vCPU and 4GB Ram, Kamailio 5.2 gets me around 400cps
>> with calls up to 30seconds length, and RTPEngine goes OK too. I am sure I
>> could do more, but I don't bother much, this is more than enough!
>> But I have an enormous amount of bandwidth and 3 NICs on the server. NICs
>> are the key . Remember that Kamailio only processes SIP messages.
>> At 5 minutes, using the above call details, you've already sent 30.000
>> SIP INVITES minimum and many more SIP messages during that time. You need a
>> very good network interface to do that kind of job!
>> Add 30.000 channels / RTP ports to your media server and you get a whole
>> lot of data going on in your network. I bet even the UTP5 cables won't
>> handle the heat   =:o)
>>
>> Also, check the RTP port range your media server was configured with.
>> On Asterisk, usually ports 10.000 to 20.000 are set, which is about
>> 10.000 calls. In the above example, you would stop receiving calls at
>> 2minutes because Asterisk has all RTP ports busy/in use!
>> I don't know about other media servers, but I would bet this is pretty
>> much the same...
>>
>> Hope this helps!
>>
>>
>> *Sérgio Charrua*
>>
>>
>> *www.voip.pt *
>> Tel.: +351  21 130 71 77
>>
>> Email : *sergio.char...@voip.pt *
>>
>> This message and any files or documents attached are strictly
>> confidential or otherwise legally protected.
>>
>> It is intended only for the individual or entity named. If you are not
>> the named addressee or have received this email in error, please inform the
>> sender immediately, delete it from your system and do not copy or disclose
>> it or its contents or use it for any purpose. Please also note that
>> transmission cannot be guaranteed to be secure or error-free.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Dec 21, 2021 at 11:54 AM pwerspire  wrote:
>>
>>> Hi,
>>>
>>> I have been doing some load testing with Kamailio and having some issues.
>>>
>>> I have been trying with 100 CPS and at the beginning, everything is
>>> working well but after some time (it can be 10 minutes or for example 40
>>> minutes, is just random but normally happens more in the first 10 minutes)
>>> Kamailio stop replying to all SIP messages but still processing HTTP
>>> requests, some commands, etc.
>>>
>>> If I use  "kamcmd dlg.list" no output happens and after that, all kamcmd
>>> commands just keep loading with no output.
>>>
>>> Kamailio is sharing Dialogs and htables using DMQ with other Kamailio
>>> that is the 

Re: [SR-Users] Kamailio Stop processing SIP traffic

[pwerspire]

Hi Sergio,

Thanks for your reply.

This is a google cloud VM with 8 vCPU,  I'm using 100 CPS but the number of
simultaneous calls is stable at around 1071 at any given time.

Also, I can always see INVITES going inside the server but Kamailio
stops answering them, even if you stop sending calls for a long time, and
then send a single call, Kamailio will not reply anymore to the Invites.

When Kamailio stops replying to INVITES, If I do for example a "kamcmd
dispatcher.list" I have the correct output, but if I do a "kamcmd dlg.list"
it will not provide any output and not give back the prompt( before it
would just answer that the reply was too big).
I will need to use "control + c" to get the prompt of the shell back and
after that, all kamcmd commands stop returning any output or giving back
the prompt.

If the Kamailio is then restarted, everything starts working correctly
again. Also, another note is that this seems only to happen when DMQ is in
use and replicating to the fallback Kamailio.

Regards,
Tiago


Sergio Charrua  escreveu no dia terça, 21/12/2021
à(s) 13:38:

> What is the call length of each call? How many NICs you have on that
> server? what networking switches are you using? all these variables have
> huge impacts on the call flow!
>
> Let's say you make 100CPS and the call length is 10 minutes.
> At 10 seconds you will have 1.000 ongoing calls using g711 (64kbps). You
> will have around 64Mbps bandwidth being used.
> At 1 minute you get 6.000 ongoing calls and will use 390Mbps bandwidth!
> Near the 10th minute you will be using almost 4Gbps bandwidth and 60.000
> ongoing calls!!
>
> Maybe the issue is not within Kamailio and/or the media server, but within
> your network capacity ...
>
> On my side, on a 4 vCPU and 4GB Ram, Kamailio 5.2 gets me around 400cps
> with calls up to 30seconds length, and RTPEngine goes OK too. I am sure I
> could do more, but I don't bother much, this is more than enough!
> But I have an enormous amount of bandwidth and 3 NICs on the server. NICs
> are the key . Remember that Kamailio only processes SIP messages.
> At 5 minutes, using the above call details, you've already sent 30.000 SIP
> INVITES minimum and many more SIP messages during that time. You need a
> very good network interface to do that kind of job!
> Add 30.000 channels / RTP ports to your media server and you get a whole
> lot of data going on in your network. I bet even the UTP5 cables won't
> handle the heat   =:o)
>
> Also, check the RTP port range your media server was configured with.
> On Asterisk, usually ports 10.000 to 20.000 are set, which is about 10.000
> calls. In the above example, you would stop receiving calls at 2minutes
> because Asterisk has all RTP ports busy/in use!
> I don't know about other media servers, but I would bet this is pretty
> much the same...
>
> Hope this helps!
>
>
> *Sérgio Charrua*
>
>
> *www.voip.pt *
> Tel.: +351  21 130 71 77
>
> Email : *sergio.char...@voip.pt *
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
>
> On Tue, Dec 21, 2021 at 11:54 AM pwerspire  wrote:
>
>> Hi,
>>
>> I have been doing some load testing with Kamailio and having some issues.
>>
>> I have been trying with 100 CPS and at the beginning, everything is
>> working well but after some time (it can be 10 minutes or for example 40
>> minutes, is just random but normally happens more in the first 10 minutes)
>> Kamailio stop replying to all SIP messages but still processing HTTP
>> requests, some commands, etc.
>>
>> If I use  "kamcmd dlg.list" no output happens and after that, all kamcmd
>> commands just keep loading with no output.
>>
>> Kamailio is sharing Dialogs and htables using DMQ with other Kamailio
>> that is the failover, if I shut down the failover one (so no DMQ
>> replication), the test works well with the 100 CPS.
>>
>> Also tried with modparam("dmq", "worker_usleep", 1000) but the behavior
>> is the same, it will stop processing traffic.
>>
>> This is some of configuration used:
>>
>> # - setting module-specific parameters ---
>> modparam("dmq", "server_address", "sip:INTERNAL_INSTANCE_IP:5060")
>> modparam("dmq", "notification_address", "DMQ_NOTIFICATION_ADDRESS")
>>
>> modparam("dmq", "multi_notify", 1)
>> modparam("dmq", "ping_interval", 10)
>> modparam("dmq", "num_workers",4)
>>
>>
>> modparam("htable", "enable_dmq", 1)
>> modparam("htable", "dmq_init_sync", 1)
>>
>>
>> # - dialog params -
>> modparam("dialog", "dlg_flag", FLD_DLG)
>> modparam("dialog", "dlg_match_mode", 1)
>> 

Re: [SR-Users] Active/active keepalived - Kamailio includes non-local virtual IP in "myself" which breaks DMQ call routing

[Rhys Hanrahan]

Hi Everyone,

I have just opened a feature request and a patch which addresses the request, 
here: https://github.com/kamailio/kamailio/issues/2984

I haven't gone to the extent of doing proper commits and a pull request yet, as 
I'm not sure if anything I've done would get outright rejected. But if it seems 
roughly OK then I will go ahead and do that!

I would really appreciate some feedback on if my approach is OK as this is my 
first time attempting any changes to Kamailio.

Given the depth of the issue  occurring, I felt that a change at the code level 
was the best way to address my issues, as I didn't know how many crazy edge 
cases I might have to deal with if trying to fix this in the config alone - 
this way seemed a lot simpler and neater.

This so far seems to address all the issues I raised below - in my testing so 
far I can at least confirm it allows lookup() to behave correctly with PATH 
support, when a virtual IP is active on one node but not the other.

Thanks!
Rhys.

-Original Message-
From: sr-users [mailto:sr-users-boun...@lists.kamailio.org] On Behalf Of Rhys 
Hanrahan
Sent: Friday, 17 December 2021 2:01 AM
To: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Active/active keepalived - Kamailio includes non-local 
virtual IP in "myself" which breaks DMQ call routing

Hi Arnd (and list),

I'm just wondering, have you had to deal with this situation of having an 
in-active floating IP before? Was it reasonable to handle?

I tried your suggestion, and that part worked great. But the reason I ask the 
above is because I think my issues are much more complicated than I first 
thought. I didn't realise it at first but it looks like the "uri==myself" in my 
config is not the issue currently, and in-fact the issue is with lookup(). 
Lookup uses check_self() in the code, which is the same as uri==myself, and my 
virtual Ips completely break PATH support because check_self returns always 
returns a match.

I could of course implement my own checks for PATH in my config after doing a 
lookup, but realising that there's C code using check_self() everywhere, I feel 
like this is just the first of many problems I will run into with this 
attempted configuration.

Maybe I am over-thinking this, and it won't be so bad? But to me it seems, the 
only reasonable solutions would be the following - though I would love to be 
told I'm wrong and it's easier than I think!

1) See if I can patch check_self() (or really grep_sock_info()) to skip 
matching sockets that are not currently active locally.
2) Move to a full any-cast pair of nodes as Igor had suggested. Anycast has 
it's own challenges of syncing dialogs and such (which I wasn't planning to do) 
but I guess it would avoid this check_self() issue because the IP is actually 
local on both nodes at the same time.
3) Give up on active/active and just live with Keepalived active/passive, which 
again avoids this issue. And seems to be a more common setup. As much as I want 
active/active, it may not be worth the effort - I'm undecided so far.

I'm keen to hear your (or anyone's) thoughts on this.

Thanks!
Rhys.

On 15/12/21, 6:07 pm, "sr-users on behalf of Arnd Schmitter" 
 wrote:

Hi,

For the RPC command, take a look at 
https://kamailio.org/docs/modules/5.5.x/modules/pv.html#pv.rpc.shvSet

Regards
Arnd

Am Mi, Dez 15, 2021 um 04:59:06 schrieb Rhys Hanrahan:
> Hi Guys,
> 
> That's awesome - thanks to you both for the suggestions. I had overlooked 
anycast because my Ips are only active on one box at a time, but it makes sense 
that I'm basically dealing with the same challenges as an anycast setup, thanks 
Igor.
> 
> And thanks Arnd! This is what I was thinking of as a quick fix, but I 
couldn't find anything useful to change via RPC commands. A shared variable 
makes perfect sense!
> 
> I will work through these ideas and post back with whatever I manage to 
come up with.
> 
> Thanks! 
> Rhys.
> 
> On 15/12/21, 12:19 am, "sr-users on behalf of Arnd Schmitter" 
 wrote:
> 
> Hello Rhys,
> 
> 
> For a quick solution, to can use notify scripts in keepalived which 
will alter a shared variable via RPC call. Then you can test the content of 
this variable to see if this instance is master or not.
> 
> 
> Regards,
> Arnd
> 
> 
> Am Di, Dez 14, 2021 um 14:03:27 schrieb Igor Olhovskiy:
> > Rhys,
> > 
> > Seems you're looking into something called "anycast". If it's the 
case, have
> > you checked 
https://github.com/kamailio/kamailio/blob/master/misc/examples/mixed/kamailio-minimal-anycast.cfg
> > ?
> > 
> > But overall you are correct, myself is not enough clever to get if 
interface
> > is active or not.
> > 
> > Regards,
> > Igor
> > 
> > On 14.12.2021 05:50, Rhys Hanrahan wrote:
> > >