[SR-Users] How to configure ndb_redis sentinel

[mayamatakeshi via sr-users]

Hi,
regarding ndb_redis,
I have 3 sentinels like this:
"192.168.88.155:26379"
"192.168.88.156:26379"
"192.168.88.157:26379"

So was thinking that I would configure ndb_redis this way:

modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=myredis;sentinel_master=1;sentinel=
192.168.88.155:26379")
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel=
192.168.88.156:26379")
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel=
192.168.88.157:26379")

But the samples in the documentation show an extra sentinel key in the
config lines:
# sentinel (for a redis slave)
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=group_name;sentinel_master=0;sentinel=1.2.3.4:26379
;sentinel=1.2.3.5:26379")
# sentinel (for a redis master)
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=group_name;sentinel_master=1;sentinel=1.2.3.4:26379
;sentinel=1.2.3.5:26379")

So I am not sure if my configuration is correct.
Can someone clarify?
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: lookup() and database

[Alex Balashov via sr-users]

PS. Kamailio gives you lots of low-level building blocks that can be used to 
stitch together a custom location service, if you want to rewrite 
usrloc/registrar. There are quite a few ways to replicate data out of Kamailio 
at little to no cost to an external consumer.

But if you want to use the tools in the Kamailio toolbox -- and I would argue 
that in your use-case, a rational actor would -- then you really have two 
choices:

1) db_mode 3 for the database-backed approach;

2) dmq/dmq_usrloc for the distributed, in-memory approach.

That's about it. There may be an honourable mention here for nonrelational DBs 
that can be coerced into acting like RDBMs, e.g. `db_redis`, but that's really 
in the weeds.

-- Alex

> On 20 Oct 2023, at 11:41, Alex Balashov  wrote:
> 
> 
>> On 20 Oct 2023, at 11:34, Jawaid Bazyar  wrote:
>> 
>> Would a DMQ cluster with RAM-based store and a relatively small number of 
>> nodes (say, 5 for example) be able to handle a location table measured in 
>> the scale of 1 million nodes?
> 
> A million rows isn't really that much in contemporary computing scales.
> 
>> Has anyone done this before?
> 
> Yes. 
> 
>> I assume DMQ has some provision to prevent loops / etc ?
>> 
>> Wondering about scaling a location service vertically and separating into a 
>> different layer from the stuff that needs to scale horizontally.
> 
> I think you might be overthinking it for a million contacts. I wouldn't split 
> these hairs. DMQ is either fundamentally viable for something within that 
> order of magnitude (it is), or it's not. It doesn't magically cave in at 1.2 
> million.
> 
> In thinking of reasons not to do DMQ, I would think about it from an even 
> higher-level perspective: you know that data consistency and consensus are 
> pretty difficult problems, and it's unlikely that a module developed by more 
> or less one person and without significant resources and focus invested in 
> these problems is going to rival a widely-used database (of one sort or 
> another).
> 
> In thinking of reasons to do DMQ: if it's fundamentally reliable, edge-cases 
> and failure modes may not be important enough to outweigh the cost savings, 
> simplicity and performance boost of not having to synchronise blocking 
> lookups over a remote database, deal with the problems of making that 
> database highly available, operate and care for and feed the database, etc. 
> Plus, there's a generally correct sense in software engineering that using 
> database as an inter-process communication mechanism for ephemeral, 
> short-term data streams is an antipattern[1][2]. There is room for lively 
> debate about whether is the correct framing of what a SIP location service 
> does.
> 
> -- Alex
> 
> [1] https://en.wikipedia.org/wiki/Database-as-IPC 
> 
> [2] https://stackoverflow.com/questions/3815941/database-as-ipc-antipattern
> 
> -- 
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
> 

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: lookup() and database

[Alex Balashov via sr-users]

> On 20 Oct 2023, at 11:34, Jawaid Bazyar  wrote:
> 
> Would a DMQ cluster with RAM-based store and a relatively small number of 
> nodes (say, 5 for example) be able to handle a location table measured in the 
> scale of 1 million nodes?

A million rows isn't really that much in contemporary computing scales.

> Has anyone done this before?

Yes. 

> I assume DMQ has some provision to prevent loops / etc ?
> 
> Wondering about scaling a location service vertically and separating into a 
> different layer from the stuff that needs to scale horizontally.

I think you might be overthinking it for a million contacts. I wouldn't split 
these hairs. DMQ is either fundamentally viable for something within that order 
of magnitude (it is), or it's not. It doesn't magically cave in at 1.2 million.

In thinking of reasons not to do DMQ, I would think about it from an even 
higher-level perspective: you know that data consistency and consensus are 
pretty difficult problems, and it's unlikely that a module developed by more or 
less one person and without significant resources and focus invested in these 
problems is going to rival a widely-used database (of one sort or another).

In thinking of reasons to do DMQ: if it's fundamentally reliable, edge-cases 
and failure modes may not be important enough to outweigh the cost savings, 
simplicity and performance boost of not having to synchronise blocking lookups 
over a remote database, deal with the problems of making that database highly 
available, operate and care for and feed the database, etc. Plus, there's a 
generally correct sense in software engineering that using database as an 
inter-process communication mechanism for ephemeral, short-term data streams is 
an antipattern[1][2]. There is room for lively debate about whether is the 
correct framing of what a SIP location service does.

-- Alex

[1] https://en.wikipedia.org/wiki/Database-as-IPC 

[2] https://stackoverflow.com/questions/3815941/database-as-ipc-antipattern

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: lookup() and database

[Jawaid Bazyar via sr-users]

Would a DMQ cluster with RAM-based store and a relatively small number of nodes 
(say, 5 for example) be able to handle a location table measured in the scale 
of 1 million nodes?

Has anyone done this before?

I assume DMQ has some provision to prevent loops / etc ?

Wondering about scaling a location service vertically and separating into a 
different layer from the stuff that needs to scale horizontally.


On 10/20/23, 11:16 AM, "Alex Balashov" mailto:abalas...@evaristesys.com>> wrote:






> On 20 Oct 2023, at 09:17, Jawaid Bazyar  > wrote:
> 
> Hi Alex,
> 
> Well I guess the other effects if any are unclear. 
> 
> As to what I want..
> 
> The goal is to ensure that all the nodes in a large-scale 
> geographically-distributed system have routing information to locate the 
> dynamic contacts of registered endpoints.
> 
> This requires that information to be shared with all other nodes somehow. 
> Either you can store it in some kind of database and look it up, or, you have 
> to proactively notify the other nodes of the information. (e.g. with DMQ or 
> something similar).
> 
> DMQ replication is probably only scalable to a very small number of nodes 
> (2-3), and also does not implement message reliability. This will force some 
> other area of the application to shard across many small kamailio clusters. 
> 
> Is there a different way to achieve a similar result? (Perhaps I have an 
> incorrect assumption somewhere along the line)..


Not really, you've pretty much covered it. 


I might disagree with the idea that DMQ doesn't scale to a larger number of 
nodes, but no, its scaling is not infinite.


Still sounds like db_mode 3 is the way to go for what you want, which is to use 
the database as the distribution and synchronisation mechanism. There are of 
course drawbacks to that, but you seem to be okay with those, and that's not 
where the pressure of the overall question appears to lie.


Not sure about your concerns about NAT pinging from another message, but they 
are orthogonal to the storage backend question per se. 


db_mode 3 is the simple answer to your question. You might be splitting hairs 
on some of the other stuff.


-- Alex


-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com 
Tel: +1-706-510-6800






__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: lookup() and database

[Alex Balashov via sr-users]

> On 20 Oct 2023, at 09:17, Jawaid Bazyar  wrote:
> 
> Hi Alex,
> 
> Well I guess the other effects if any are unclear. 
> 
> As to what I want..
> 
> The goal is to ensure that all the nodes in a large-scale 
> geographically-distributed system have routing information to locate the 
> dynamic contacts of registered endpoints.
> 
> This requires that information to be shared with all other nodes somehow. 
> Either you can store it in some kind of database and look it up, or, you have 
> to proactively notify the other nodes of the information. (e.g. with DMQ or 
> something similar).
> 
> DMQ replication is probably only scalable to a very small number of nodes 
> (2-3), and also does not implement message reliability. This will force some 
> other area of the application to shard across many small kamailio clusters. 
> 
> Is there a different way to achieve a similar result? (Perhaps I have an 
> incorrect assumption somewhere along the line)..

Not really, you've pretty much covered it. 

I might disagree with the idea that DMQ doesn't scale to a larger number of 
nodes, but no, its scaling is not infinite.

Still sounds like db_mode 3 is the way to go for what you want, which is to use 
the database as the distribution and synchronisation mechanism. There are of 
course drawbacks to that, but you seem to be okay with those, and that's not 
where the pressure of the overall question appears to lie.

Not sure about your concerns about NAT pinging from another message, but they 
are orthogonal to the storage backend question per se. 

db_mode 3 is the simple answer to your question. You might be splitting hairs 
on some of the other stuff.

-- Alex

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: lookup() and database

[Jawaid Bazyar via sr-users]

Hi,

This is one of the effects I was remembering:

" For example NAT pinging is a killer since during each ping cycle all nated 
contact are loaded from the DB;"




On 10/20/23, 9:17 AM, "Jawaid Bazyar" mailto:baz...@gmail.com>> wrote:


Hi Alex,


Well I guess the other effects if any are unclear. 


As to what I want..


The goal is to ensure that all the nodes in a large-scale 
geographically-distributed system have routing information to locate the 
dynamic contacts of registered endpoints.


This requires that information to be shared with all other nodes somehow. 
Either you can store it in some kind of database and look it up, or, you have 
to proactively notify the other nodes of the information. (e.g. with DMQ or 
something similar).


DMQ replication is probably only scalable to a very small number of nodes 
(2-3), and also does not implement message reliability. This will force some 
other area of the application to shard across many small kamailio clusters. 


Is there a different way to achieve a similar result? (Perhaps I have an 
incorrect assumption somewhere along the line)..


Thanks,


Jawaid








On 10/19/23, 8:57 PM, "Alex Balashov via sr-users" 
mailto:sr-users@lists.kamailio.org> 
>> 
wrote:




If what you want is what you really want, db_mode 3 is the only way to achieve 
it. What other effects of mode 3 are you concerned about?




-- Alex




-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com  
 
Tel: +1-706-510-6800




__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org 
 
>
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:












__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: STIR/SHAKEN with Kamailio

[Ben Kaufman via sr-users]

My point was simply that there's more challenge in the bureaucracy than 
technical implementation.

>From a technical standpoint, the corner cases to consider are:

1. Number validity. Sure things that fit into an e.164 and/or recognizable 
number patterns are simple.  What happens when someone sends a From: URI of 
`sip:anonym...@domain.com` - IIRC, the orig_tn field within the identity header 
is supposed to be numeric.  Do you reject the call?  Attest it as "C" and 
provide this in the `orig_tn` field or in a separate field?

2. Handling of forwarded calls - If you're sending a Diversion: header, do you 
also add an Identity header with a `div` passport?  Rewrite the From header?  
How do you determine the attestation in that case?

3. Known customers sending numbers for which you're not the provider?  Strictly 
speaking this should attest as "B", but supposing that you're a secondary 
vendor for the customer, and they're sending their primary number which is with 
a different provider?  Do you then allow them to submit an LOA (or whatever 
your jurisdictional equivalent is) and attest as A?

The questions above are strictly for STI Authentication.  Verification has some 
other idiosyncrasies.   Consider that there's three attestation levels for 
authentication, and normally as a carrier it is not desirable to pass the 
Identity header to the customer (consider if Privacy: is on).  The general 
practice is to assign this to a verstat parameter to the user portion of a PAI 
header's **USER** field, which is syntactically awkward in Kamailio.  Also 
strictly speaking AFAIK, the verstat only has two values - passed or failed - 
so there's three possible attestation levels but they only map to two 
verification levels.  Therea are suggestions on how to deal with this, but I'm 
not sure on their official status.

This brings up the final complexity:  It's a rapidly evolving system without a 
high degree of consistency vendor to vendor, so there's as much of a challenge 
of staying on top of things as anything else.

-Original Message-
From: Olle E. Johansson via sr-users  
Sent: Friday, October 20, 2023 2:08 AM
To: Kamailio (SER) - Users Mailing List 
Cc: Olle E. Johansson 
Subject: [SR-Users] Re: STIR/SHAKEN with Kamailio

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


> On 19 Oct 2023, at 18:46, Alex Balashov via sr-users 
>  wrote:
>
> Would join Kaufman here to say that free-range STIR/SHAKEN 
> implementations in the US are limited by the small number of certified 
> authentication providers, but presumably the EU version will to some 
> extent avoid US-style Guilded Age corporate welfare...
Sadly that's my view of the US implementation. I can't say if it solved the 
problem, but I can see that a lot of new and old actors got an oppurtunity to 
earn more money.

There's no EU-wide implementation or regulation at this point. I am aware of 
France. There are certainly discussions.
/O
>
> -- Alex
>
>> On 19 Oct 2023, at 09:33, Ben Kaufman via sr-users 
>>  wrote:
>>
>> Like some of the other posters here, we've implemented it as a 302-redirect 
>> server. This was the primary reason for using the secsipid rather than 
>> stirshaken module.  Both modules have a function to append an Identity 
>> header, but secsipid also has functions to simply build the identity header 
>> which can then easily be appended to the reply, rather than only appending 
>> to the request and plucking the Identity header from there.  Secsipid also 
>> has a function secsipid_sign() which allows for creating your own JWT.  This 
>> is useful if you want to create some variations on the Identity header - we 
>> use this to create div passports (as opposed to shaken passports) in some 
>> situations.
>>
>> Not sure how it will be implemented there, but the biggest challenge for me 
>> in the US was acquiring certificates because there is a very limited number 
>> of regulatory approved vendors.
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevar
> istesys.com%2F=05%7C01%7Cbkaufman%40bcmone.com%7C31a9da72c1db4b26
> 7ff308dbd13cd073%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C63833383
> 1362925788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=w9TCfesrCll46onz
> GqiIndpnonmKJpi06JrS1s3FJK4%3D=0
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions To 
> unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:

__
Kamailio - Users Mailing List - Non Commercial 

[SR-Users] Re: lookup() and database

[Henning Westerholt via sr-users]

Hello,

at least for some ideas you can have a look at the p_usrloc module. This 
implements a clustered registration database, where the data location is 
queried from another database table. In the end you can of course also use 
native partition means provided from your database and build it by yourself.

Cheers,

Henning

-- 
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

> -Original Message-
> From: Jawaid Bazyar via sr-users 
> Sent: Freitag, 20. Oktober 2023 15:17
> To: Kamailio (SER) - Users Mailing List 
> Cc: Jawaid Bazyar 
> Subject: [SR-Users] Re: lookup() and database
> 
> Hi Alex,
> 
> Well I guess the other effects if any are unclear.
> 
> As to what I want..
> 
> The goal is to ensure that all the nodes in a large-scale geographically-
> distributed system have routing information to locate the dynamic contacts of
> registered endpoints.
> 
> This requires that information to be shared with all other nodes somehow.
> Either you can store it in some kind of database and look it up, or, you have 
> to
> proactively notify the other nodes of the information. (e.g. with DMQ or
> something similar).
> 
> DMQ replication is probably only scalable to a very small number of nodes (2-
> 3), and also does not implement message reliability. This will force some 
> other
> area of the application to shard across many small kamailio clusters.
> 
> Is there a different way to achieve a similar result? (Perhaps I have an 
> incorrect
> assumption somewhere along the line)..
> 
> Thanks,
> 
> Jawaid
> 
> 
> 
> 
> On 10/19/23, 8:57 PM, "Alex Balashov via sr-users"  us...@lists.kamailio.org > wrote:
> 
> 
> If what you want is what you really want, db_mode 3 is the only way to
> achieve it. What other effects of mode 3 are you concerned about?
> 
> 
> -- Alex
> 
> 
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com 
> Tel: +1-706-510-6800
> 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org  users-le...@lists.kamailio.org>
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
> 
> 
> 
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: lookup() and database

[Jawaid Bazyar via sr-users]

Hi Alex,

Well I guess the other effects if any are unclear. 

As to what I want..

The goal is to ensure that all the nodes in a large-scale 
geographically-distributed system have routing information to locate the 
dynamic contacts of registered endpoints.

This requires that information to be shared with all other nodes somehow. 
Either you can store it in some kind of database and look it up, or, you have 
to proactively notify the other nodes of the information. (e.g. with DMQ or 
something similar).

DMQ replication is probably only scalable to a very small number of nodes 
(2-3), and also does not implement message reliability. This will force some 
other area of the application to shard across many small kamailio clusters. 

Is there a different way to achieve a similar result? (Perhaps I have an 
incorrect assumption somewhere along the line)..

Thanks,

Jawaid




On 10/19/23, 8:57 PM, "Alex Balashov via sr-users" 
mailto:sr-users@lists.kamailio.org>> wrote:


If what you want is what you really want, db_mode 3 is the only way to achieve 
it. What other effects of mode 3 are you concerned about?


-- Alex


-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com 
Tel: +1-706-510-6800


__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org 

Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:




__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Kamailio 5.7 still segfaulting on TLS with Ubuntu Jammy

[Antony Russell via sr-users]

Absolutely like my experience. We also only saw the issue when using TLS in
kamailio, not using SSL for mysql. the advice we received did not make
sense but resolved the problem.

On Fri, 20 Oct 2023 at 14:49, Benoît Panizzon 
wrote:

> Hi Antony
>
> > Are you connecting to mysql?
> >
> > We had similar sounding issues and adding this to kamailio.cfg made a
> > difference
> > modparam( "db_mysql", "opt_ssl_mode", 1 )
>
> I am using MySQL, but I didn't deliberately configure it to use SSL.
>
> I'm using TLS for SIP client registration on port 5061. So I was
> hunting the issue down that rabbit hole.
>
>
> https://www.kamailio.org/docs/modules/devel/modules/db_mysql.html#db_mysql.p.opt_ssl_mode
>
> I try to force disable SSL for mysql off by setting this to 1.
>
> Restarted, let's observe for a hour or so. Usually the crashes occur
> after restarting. At the moment all 4 dev registrars have restarted
> without crashing in the first 2 or so minute. So this somehow looks
> promising!
>
> --
> Mit freundlichen Grüssen
>
> -Benoît Panizzon- @ HomeOffice und normal erreichbar
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>


-- 
*Antony Russell*

Tel  087 820 8113


-- 
https://www.telviva.co.za/legal/email-disclaimer 

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Kamailio 5.7 still segfaulting on TLS with Ubuntu Jammy

[Benoît Panizzon via sr-users]

Hi Antony

> Are you connecting to mysql?
> 
> We had similar sounding issues and adding this to kamailio.cfg made a
> difference
> modparam( "db_mysql", "opt_ssl_mode", 1 )

I am using MySQL, but I didn't deliberately configure it to use SSL.

I'm using TLS for SIP client registration on port 5061. So I was
hunting the issue down that rabbit hole.

https://www.kamailio.org/docs/modules/devel/modules/db_mysql.html#db_mysql.p.opt_ssl_mode

I try to force disable SSL for mysql off by setting this to 1.

Restarted, let's observe for a hour or so. Usually the crashes occur
after restarting. At the moment all 4 dev registrars have restarted
without crashing in the first 2 or so minute. So this somehow looks
promising!

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Kamailio 5.7 still segfaulting on TLS with Ubuntu Jammy

[Antony Russell via sr-users]

Hi Benoit

Are you connecting to mysql?

We had similar sounding issues and adding this to kamailio.cfg made a
difference
modparam( "db_mysql", "opt_ssl_mode", 1 )

On Fri, 20 Oct 2023 at 11:56, Benoît Panizzon via sr-users <
sr-users@lists.kamailio.org> wrote:

> Hi Gang
>
> I just updated our dev plattform from 5.6 to 5.7
>
> 5.5 was working fine with TLS under Ubuntu Focal.
> 5.6 under Jammy started to dump cores.
> 5.7 still shows the same behaviour, usually shortly after a restart.
>
> Oct 20 09:45:01 dev-cpereg01 kamailio[11925]: CRITICAL: 
> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer
> (0x7f1bb0dd4bd8), called from tls: tls_init.c: ser_free(405), first free
> tls: tls_init.c: ser_free(405) - ignoring
> Oct 20 09:45:11 dev-cpereg01 kamailio[11905]: ALERT:  [main.c:776]:
> handle_sigs(): child process 11924 exited by a signal 11
> Oct 20 09:45:11 dev-cpereg01 kamailio[11905]: ALERT:  [main.c:779]:
> handle_sigs(): core was generated
>
> Could anyone point me the correct direction on how to fix this issue?
>
> Am I the only one seeing this issue?
>
> --
> Mit freundlichen Grüssen
>
> -Benoît Panizzon- @ HomeOffice und normal erreichbar
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>


-- 
*Antony Russell*

Tel  087 820 8113


-- 
https://www.telviva.co.za/legal/email-disclaimer 

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Kamailio 5.7 still segfaulting on TLS with Ubuntu Jammy

[Benoît Panizzon via sr-users]

Hi Gang

I just updated our dev plattform from 5.6 to 5.7

5.5 was working fine with TLS under Ubuntu Focal.
5.6 under Jammy started to dump cores.
5.7 still shows the same behaviour, usually shortly after a restart.

Oct 20 09:45:01 dev-cpereg01 kamailio[11925]: CRITICAL:  
[core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer 
(0x7f1bb0dd4bd8), called from tls: tls_init.c: ser_free(405), first free tls: 
tls_init.c: ser_free(405) - ignoring
Oct 20 09:45:11 dev-cpereg01 kamailio[11905]: ALERT:  [main.c:776]: 
handle_sigs(): child process 11924 exited by a signal 11
Oct 20 09:45:11 dev-cpereg01 kamailio[11905]: ALERT:  [main.c:779]: 
handle_sigs(): core was generated

Could anyone point me the correct direction on how to fix this issue?

Am I the only one seeing this issue?

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: STIR/SHAKEN with Kamailio

[Olle E. Johansson via sr-users]

> On 19 Oct 2023, at 18:46, Alex Balashov via sr-users 
>  wrote:
> 
> Would join Kaufman here to say that free-range STIR/SHAKEN implementations in 
> the US are limited by the small number of certified authentication providers, 
> but presumably the EU version will to some extent avoid US-style Guilded Age 
> corporate welfare…
Sadly that’s my view of the US implementation. I can’t say if it solved the 
problem, but I can see that a lot of new and old actors
got an oppurtunity to earn more money.

There’s no EU-wide implementation or regulation at this point. I am aware of 
France. There are certainly discussions.
/O
> 
> -- Alex
> 
>> On 19 Oct 2023, at 09:33, Ben Kaufman via sr-users 
>>  wrote:
>> 
>> Like some of the other posters here, we’ve implemented it as a 302-redirect 
>> server. This was the primary reason for using the secsipid rather than 
>> stirshaken module.  Both modules have a function to append an Identity 
>> header, but secsipid also has functions to simply build the identity header 
>> which can then easily be appended to the reply, rather than only appending 
>> to the request and plucking the Identity header from there.  Secsipid also 
>> has a function secsipid_sign() which allows for creating your own JWT.  This 
>> is useful if you want to create some variations on the Identity header - we 
>> use this to create div passports (as opposed to shaken passports) in some 
>> situations.
>> 
>> Not sure how it will be implemented there, but the biggest challenge for me 
>> in the US was acquiring certificates because there is a very limited number 
>> of regulatory approved vendors.
> 
> -- 
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe: