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

2023-10-19 Thread Alex Balashov via sr-users
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:


[SR-Users] lookup() and database

2023-10-19 Thread Jawaid Bazyar via sr-users
Hi,

 

I have an application as follows:

 

Multiple Kamailio Nodes

Shared Postgres database

 

Auth information will be stored in DB and accessed with Authdb.

 

Here is the behavior I seek:

 

I would like all the Kamailo nodes to cooperate in updating the database, each 
updating data as appropriate:

 
When a registration comes in to any Node, and it authenticated, create or 
update a database record in location table.
When a registration expires on that Node, delete database record in location 
table.
When INVITE comes in on any Node, ignore local cache and always lookup() record 
from database.
 

#1 and #2 are used so that a third SIP system can query the database and look 
up the Node a NAT’d subscriber is ‘connected’ to.

#3 is to let NON-NAT’d subscribers be contacted from any Node.

 

Now I have something close to this now – using following settings:

 

modparam("usrloc", "db_mode", 1)    # immediately write registrations to 
the database.

modparam("usrloc", "db_timer_clean", 0) # do not expire DB records separately

modparam("usrloc", "db_check_update", 1)

 

This takes care of #1 and #2 above. However, #3 seems to still be relying 
purely on local cache and does not hit the database.

 

Is there a way to do #3? I can set db_mode to 3 but that would seem to have 
other effects besides merely making lookup() read from database.

 

Thanks in advance,

 

Jawaid

 

 

__
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

2023-10-19 Thread Alex Balashov via sr-users
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...

-- 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:


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

2023-10-19 Thread Ben Kaufman via sr-users
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.

Regards,
Kaufman
 

-Original Message-
From: Olle E. Johansson via sr-users  
Sent: Wednesday, October 18, 2023 2:24 AM
To: Leonardo Arena via sr-users 
Cc: Olle E. Johansson 
Subject: [SR-Users] 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.


Hello Kamailians!

As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, I’m 
curious on how you’ve implemented it with Kamailio. I asked on our Matrix chat 
and got two responses that seems to not use the Kamailio STIR/SHAKEN support 
but rather a 3rd party service that they’ve integrated using restful APIs.

Please help me and share how you’re implementing STIR/SHAKEN with Kamailio.

I’m not shaken, nor stirred. yet.

Regards,
/O
__
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: TOPOS + Forcing the send socket

2023-10-19 Thread Marrold via sr-users
Thanks Henning I'll give that a try.


For additional context this happens when a single call traverses the
system, fresh after a restart, so if there's a memory leak it seems to
happen rapidly whilst processing a single SIP message

Cheers
Matthew

On Thu, 19 Oct 2023, 07:37 Henning Westerholt,  wrote:

> Hello,
>
>
>
> this is quite too much, then you are probably having a memory leak. Have a
> look e.g. to this for debugging help:
>
> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Marrold 
> *Sent:* Donnerstag, 19. Oktober 2023 02:05
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> Hi Henning,
>
> I bumped the PKG memory up to 24MB all the way up to 128MB and I still get
> the same issue.
>
> Thanks
> Matthew
>
>
>
> On Wed, Oct 18, 2023 at 10:18 AM Henning Westerholt  wrote:
>
> Hello,
>
>
>
> you are running out of private memory. Please try to increase the PKG
> memory pool (e.g. by changing /etc/default/kamailio or similar). You can
> verify with “ps aux”.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Marrold via sr-users 
> *Sent:* Mittwoch, 18. Oktober 2023 10:21
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Marrold 
> *Subject:* [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> Hi Both,
>
>
>
> Thanks for the input. I'm now doing it the proper way:
>
>
>
> modparam("topoh", "use_mode", 1)
> modparam("topos", "mask_callid", 1)
>
>
>
> But it's not masking the caller-id and the logs are full of errors:
>
>
> 18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]:
> qm_free(): BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called
> from core: core/data_lump.c: free_lump(470) - ignoring
>  5(11) ERROR:  [core/msg_translator.c:2241]:
> build_req_buf_from_sip_req(): could not allocate private memory from pkg
> pool
>  5(11) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
> memory for new message
>  5(11) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
> pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
> free_lump(470) - ignoring
>  5(11) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
> message too short: 0 []
>  5(11) ERROR:  [core/parser/parse_fline.c:271]: parse_first_line():
> parse_first_line: bad message (offset: 0)
>  5(11) ERROR:  [core/parser/msg_parser.c:748]: parse_msg(): ERROR:
> parse_msg: message=<>
>  5(11) ERROR:  [core/receive.c:376]: receive_msg(): core parsing of
> SIP message failed (172.24.0.21:5070/1)
>  3(9) ERROR:  [core/msg_translator.c:2241]:
> build_req_buf_from_sip_req(): could not allocate private memory from pkg
> pool
>  3(9) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg
> memory for new message
>  3(9) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad
> pointer 0x2 (out of memory block!) called from core: core/data_lump.c:
> free_lump(470) - ignoring
>  3(9) INFO:  [core/parser/parse_fline.c:80]: parse_first_line():
> message too short: 0 []
>
>
>
> On Wed, 18 Oct 2023, 09:13 Henning Westerholt via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
> Hello,
>
>
>
> actually, there is now a mode where you can use both modules together,
> e.g. refer to the docs:
>
>
> https://kamailio.org/docs/modules/5.7.x/modules/topos.html#topos.p.mask_callid
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Yuriy G via sr-users 
> *Sent:* Mittwoch, 18. Oktober 2023 09:03
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Yuriy G 
> *Subject:* [SR-Users] Re: TOPOS + Forcing the send socket
>
>
>
> In the header of the topic you talking about topos, but inside the
> messages you talking about topoh.
>
> They are 2 different modules. If you usr them together - they can
> conflictin case how they affect message. Try use or just topoh, or just
> topos.
>
>
>
> On Wed, 18 Oct 2023, 00:45 Marrold via sr-users, <
> sr-users@lists.kamailio.org> wrote:
>
> Hi all,
>
> I've dug into this a bit more. Firstly I enabled debug logs and spotted
> the following record-route header being loaded from redis:
>
> 21(28) DEBUG: PY3 {ACK}: topos_redis [topos_redis_storage.c:1079]:
> tps_redis_load_dialog(): r[5]: s[<
> sip:172.24.0.10:5070;sn=internal;r2=on;lr;ftag=202310172234552;did=c1f.18b1;nat=yes
> >,<
> sip:127.0.0.8;line=sr-N6IAzBFlWJZLWxP7WBN7z.VXN6ZQNUKJoSIBzwVLHRQ7z6fLz6g43RNQMByLMlFAM.NLMBM4W.jAMxyAMB1qCRPQ3ltEOBFZ3BFXoEt4H9IINA**
> >]
>
> 127.0.0.8 is the wrong IP which explains why the ACK was not being
> forwarded correctly. A quick look in the source shows it's related to topoh.
>
> I had modparam("topoh", 

[SR-Users] Re: TOPOS + Forcing the send socket

2023-10-19 Thread Henning Westerholt via sr-users
Hello,

this is quite too much, then you are probably having a memory leak. Have a look 
e.g. to this for debugging help:
https://www.kamailio.org/wiki/tutorials/troubleshooting/memory

Cheers,

Henning

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

From: Marrold 
Sent: Donnerstag, 19. Oktober 2023 02:05
To: Henning Westerholt 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Re: TOPOS + Forcing the send socket

Hi Henning,

I bumped the PKG memory up to 24MB all the way up to 128MB and I still get the 
same issue.

Thanks
Matthew

On Wed, Oct 18, 2023 at 10:18 AM Henning Westerholt 
mailto:h...@gilawa.com>> wrote:
Hello,

you are running out of private memory. Please try to increase the PKG memory 
pool (e.g. by changing /etc/default/kamailio or similar). You can verify with 
“ps aux”.

Cheers,

Henning

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

From: Marrold via sr-users 
mailto:sr-users@lists.kamailio.org>>
Sent: Mittwoch, 18. Oktober 2023 10:21
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Cc: Marrold mailto:kamai...@marrold.co.uk>>
Subject: [SR-Users] Re: TOPOS + Forcing the send socket

Hi Both,

Thanks for the input. I'm now doing it the proper way:

modparam("topoh", "use_mode", 1)
modparam("topos", "mask_callid", 1)

But it's not masking the caller-id and the logs are full of errors:

18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]: qm_free(): 
BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called from core: 
core/data_lump.c: free_lump(470) - ignoring
 5(11) ERROR:  [core/msg_translator.c:2241]: 
build_req_buf_from_sip_req(): could not allocate private memory from pkg pool
 5(11) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg 
memory for new message
 5(11) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad pointer 
0x2 (out of memory block!) called from core: core/data_lump.c: free_lump(470) - 
ignoring
 5(11) INFO:  [core/parser/parse_fline.c:80]: parse_first_line(): message 
too short: 0 []
 5(11) ERROR:  [core/parser/parse_fline.c:271]: parse_first_line(): 
parse_first_line: bad message (offset: 0)
 5(11) ERROR:  [core/parser/msg_parser.c:748]: parse_msg(): ERROR: 
parse_msg: message=<>
 5(11) ERROR:  [core/receive.c:376]: receive_msg(): core parsing of SIP 
message failed (172.24.0.21:5070/1)
 3(9) ERROR:  [core/msg_translator.c:2241]: build_req_buf_from_sip_req(): 
could not allocate private memory from pkg pool
 3(9) ERROR: topos [topos_mod.c:518]: tps_msg_received(): not enough pkg memory 
for new message
 3(9) CRITICAL:  [core/mem/q_malloc.c:501]: qm_free(): BUG: bad pointer 
0x2 (out of memory block!) called from core: core/data_lump.c: free_lump(470) - 
ignoring
 3(9) INFO:  [core/parser/parse_fline.c:80]: parse_first_line(): message 
too short: 0 []

On Wed, 18 Oct 2023, 09:13 Henning Westerholt via sr-users, 
mailto:sr-users@lists.kamailio.org>> wrote:
Hello,

actually, there is now a mode where you can use both modules together, e.g. 
refer to the docs:
https://kamailio.org/docs/modules/5.7.x/modules/topos.html#topos.p.mask_callid

Cheers,

Henning

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

From: Yuriy G via sr-users 
mailto:sr-users@lists.kamailio.org>>
Sent: Mittwoch, 18. Oktober 2023 09:03
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Cc: Yuriy G mailto:ovoshl...@gmail.com>>
Subject: [SR-Users] Re: TOPOS + Forcing the send socket

In the header of the topic you talking about topos, but inside the messages you 
talking about topoh.
They are 2 different modules. If you usr them together - they can conflictin 
case how they affect message. Try use or just topoh, or just topos.

On Wed, 18 Oct 2023, 00:45 Marrold via sr-users, 
mailto:sr-users@lists.kamailio.org>> wrote:
Hi all,

I've dug into this a bit more. Firstly I enabled debug logs and spotted the 
following record-route header being loaded from redis:

21(28) DEBUG: PY3 {ACK}: topos_redis [topos_redis_storage.c:1079]: 
tps_redis_load_dialog(): r[5]: 
s[,]

127.0.0.8 is the wrong IP which explains why the ACK was not being forwarded 
correctly. A quick look in the source shows it's related to topoh.

I had modparam("topoh", "mask_callid", 1) in my config so I disabled it and 
sure enough the ACK worked as expected which gets me a bit closer to finding 
the issue.

Looking at the docs for topos and topoh it looks like things have changed since 
I used it last and I should be using the following instead:

modparam("topoh", "use_mode", 1)
modparam("topos", "mask_callid", 1)

But with those configured things go really wrong:

18(25) CRITICAL: PY3 {INVITE}:  [core/mem/q_malloc.c:501]: qm_free(): 
BUG: bad pointer 0x7ffc73e3ca90 (out of memory block!) called from core: