[SR-Users] Re: SSL key logger for Diffie-Hellman cipher

[Bastian Triller via sr-users]

Some weeks ago I learned about [1]. Didn't play with it yet though.


[1]
https://medium.com/@yunwei356/ebpf-practical-tutorial-capturing-ssl-tls-plain-text-using-uprobe-fccb010cfd64

On Tue, Feb 27, 2024, 02:08 Calvin E. via sr-users <
sr-users@lists.kamailio.org> wrote:

> This was done using the system-provided OpenSSL (Debian 12). It might work
> for tlsa, but I don't know how Kamilio would respond to LD_PRELOAD
> affecting one of its own modules.
>
> If your curious how it works, the code is here:
> https://github.com/voipmonitor/sniffer/blob/master/tools/ssl_keylogger/sslkeylog.cpp
>
> On Fri, Feb 2, 2024 at 1:23 AM Ihor Olkhovskyi via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>> Calvin,
>>
>> Thanks for sharing this, just a question, do you use system-provided
>> OpenSSL or tlsa ?
>>
>> Le mar. 30 janv. 2024 à 03:00, Calvin E. via sr-users <
>> sr-users@lists.kamailio.org> a écrit :
>>
>>> It turns out the system I was on really
>>> uses /lib/systemd/system/kamailio.service, despite /etc/init.d/kamailio
>>> also existing.
>>>
>>> I was able to make it work by following the Systemd process:
>>>
>>> mkdir /etc/default/kamailio.d/
>>> edit /etc/default/kamailio.d/voipmonitor
>>> add lines:
>>> SSLKEYLOG_UDP='127.0.0.1:1234'
>>> LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so
>>> /usr/lib/x86_64-linux-gnu/libssl.so.3"
>>>
>>> The keys are captured by the VoIPmonitor sniffer and everything works as
>>> expected from there. I'd be happy to explain further to anyone interested
>>> in this setup.
>>>
>>> On Sun, Jan 28, 2024 at 3:20 AM Sergey Safarov 
>>> wrote:
>>>
 You can check this PR
 https://github.com/kamailio/kamailio/pull/2785

 On Fri, Jan 26, 2024 at 8:58 PM Calvin E. via sr-users <
 sr-users@lists.kamailio.org> wrote:

> I've been tasked to use LD_PRELOAD to log SSL keys for TLS connections
> using a Diffie-Hellman cipher. The first attempt did not work, so I wanted
> to sanity check whether Kamailio's TLS support is built in such a way that
> would defeat LD_PRELOAD.
>
> The instructions from the vendor are to update /etc/init.d/kamailio
> like this:
>
> env SSLKEYLOG_UDP='127.0.0.1:1234'
> LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so
> /usr/lib/x86_64-linux-gnu/libssl.so.3" \
> start-stop-daemon --start --quiet --pidfile $PIDFILE \
> --exec $DAEMON -- $OPTIONS || log_failure_msg "
> already running"
>
> Is there anything special in Kamailio (5.7.3 on Debian 12) that would
> prevent this from working? Not necessarily something to defeat a 
> keylogger,
> but maybe the way tls.so gets loaded?
>
> The only discrepancy I've noticed is the vendor docs refer
> to libssl.so.3 not libssl.so.1, but the vendor said that should be OK.
>
> I'd love to hear from someone already using VoIPmonitor
> with Diffie-Hellman ciphers and Kamailio.
>
> __
> 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:
>>>
>>
>>
>> --
>> Best regards,
>> Ihor (Igor)
>> __
>> 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:
>
__
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: SSL key logger for Diffie-Hellman cipher

[Joel Serrano via sr-users]

Calvin,

Voipmonitor-sniffer has support for Kamailio’s ‘siptrace’ module, but this
is useful if your goal is to capture SIP over TLS traffic, I’m not sure if
that is the reason you have been asked to capture the DH session keys…

If that's the case, any reason you went with LD_PRELOAD method vs
kamailio’s siptrace module? Using the later you still get the sip traffic
without the need of messing with OpenSSL.

Mind sharing your findings?

Joel.



On Tue, Feb 27, 2024 at 00:18 Bastian Triller via sr-users <
sr-users@lists.kamailio.org> wrote:

> Some weeks ago I learned about [1]. Didn't play with it yet though.
>
>
> [1]
> https://medium.com/@yunwei356/ebpf-practical-tutorial-capturing-ssl-tls-plain-text-using-uprobe-fccb010cfd64
>
> On Tue, Feb 27, 2024, 02:08 Calvin E. via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>> This was done using the system-provided OpenSSL (Debian 12). It might
>> work for tlsa, but I don't know how Kamilio would respond to LD_PRELOAD
>> affecting one of its own modules.
>>
>> If your curious how it works, the code is here:
>> https://github.com/voipmonitor/sniffer/blob/master/tools/ssl_keylogger/sslkeylog.cpp
>>
>> On Fri, Feb 2, 2024 at 1:23 AM Ihor Olkhovskyi via sr-users <
>> sr-users@lists.kamailio.org> wrote:
>>
>>> Calvin,
>>>
>>> Thanks for sharing this, just a question, do you use system-provided
>>> OpenSSL or tlsa ?
>>>
>>> Le mar. 30 janv. 2024 à 03:00, Calvin E. via sr-users <
>>> sr-users@lists.kamailio.org> a écrit :
>>>
 It turns out the system I was on really
 uses /lib/systemd/system/kamailio.service, despite /etc/init.d/kamailio
 also existing.

 I was able to make it work by following the Systemd process:

 mkdir /etc/default/kamailio.d/
 edit /etc/default/kamailio.d/voipmonitor
 add lines:
 SSLKEYLOG_UDP='127.0.0.1:1234'
 LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so
 /usr/lib/x86_64-linux-gnu/libssl.so.3"

 The keys are captured by the VoIPmonitor sniffer and everything works
 as expected from there. I'd be happy to explain further to anyone
 interested in this setup.

 On Sun, Jan 28, 2024 at 3:20 AM Sergey Safarov 
 wrote:

> You can check this PR
> https://github.com/kamailio/kamailio/pull/2785
>
> On Fri, Jan 26, 2024 at 8:58 PM Calvin E. via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>> I've been tasked to use LD_PRELOAD to log SSL keys for TLS
>> connections using a Diffie-Hellman cipher. The first attempt did not 
>> work,
>> so I wanted to sanity check whether Kamailio's TLS support is built in 
>> such
>> a way that would defeat LD_PRELOAD.
>>
>> The instructions from the vendor are to update /etc/init.d/kamailio
>> like this:
>>
>> env SSLKEYLOG_UDP='127.0.0.1:1234'
>> LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so
>> /usr/lib/x86_64-linux-gnu/libssl.so.3" \
>> start-stop-daemon --start --quiet --pidfile $PIDFILE \
>> --exec $DAEMON -- $OPTIONS || log_failure_msg "
>> already running"
>>
>> Is there anything special in Kamailio (5.7.3 on Debian 12) that would
>> prevent this from working? Not necessarily something to defeat a 
>> keylogger,
>> but maybe the way tls.so gets loaded?
>>
>> The only discrepancy I've noticed is the vendor docs refer
>> to libssl.so.3 not libssl.so.1, but the vendor said that should be OK.
>>
>> I'd love to hear from someone already using VoIPmonitor
>> with Diffie-Hellman ciphers and Kamailio.
>>
>> __
>> 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:

>>>
>>>
>>> --
>>> Best regards,
>>> Ihor (Igor)
>>> __
>>> 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,

[SR-Users] Re: loose_route false when using topos? At which point in the call flow, does topos restore the Route header?

[Benoit Panizzon via sr-users]

Hi

By setting: branch_expire to the same value as dialog_expire which is
12 hours, now my headers get correctly restored on UPDATE and BYE.

But in this UPDATE scenario:

CPE A => Registrar A (topos) => Core => Registrar B (topos) => CPE B

I now have the phenomena that the Contact Header is being removed from
the UPDATE by topos on Registrar B.

Any clue what could cause the issue?

I see that Registrar A is adding a P-SR-XUID hader. Maybe I could
filter that header out on the Core?

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
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] best approach to setup SIP Session sharing between servers

[Sergio Charrua via sr-users]

Hi all!

I am having some difficulties/doubts on what would be the best approach to
let multiple Kamailio servers share their SIP sessions between each other.
The goal is to have HA on Kamailio cluster such that if a call is received
and initiated on Kamailio #1, and during any moment of the call (before or
while established) if the server #1 goes down or Kamailio stops working for
any reason, the call can be processed by Kamailio server #n available in
the cluster.
I do not want to mess with Virtual IPs or DNS, that is not the point, but
instead need to get a proper way to share SIP sessions between Kamailio
servers such that any server could continue the call without issue.

I have checked the Dialog and DMQ module, but I am not sure if that is the
way to go

Could any one share a solution for this?

Greatly appreciated.

Cheers,


*Sérgio Charrua*

*www.voip.pt *
__
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: best approach to setup SIP Session sharing between servers

[Alex Balashov via sr-users]

That would require transaction replication, which Kamailio doesn't have. 

Most messages can be processed statelessly, so this isn't a huge obstacle. 
However, CANCELs won't work.

> On 27 Feb 2024, at 06:49, Sergio Charrua via sr-users 
>  wrote:
> 
> Hi all!
> 
> I am having some difficulties/doubts on what would be the best approach to 
> let multiple Kamailio servers share their SIP sessions between each other.
> The goal is to have HA on Kamailio cluster such that if a call is received 
> and initiated on Kamailio #1, and during any moment of the call (before or 
> while established) if the server #1 goes down or Kamailio stops working for 
> any reason, the call can be processed by Kamailio server #n available in the 
> cluster.
> I do not want to mess with Virtual IPs or DNS, that is not the point, but 
> instead need to get a proper way to share SIP sessions between Kamailio 
> servers such that any server could continue the call without issue.
> 
> I have checked the Dialog and DMQ module, but I am not sure if that is the 
> way to go
> 
> Could any one share a solution for this?
> 
> Greatly appreciated.
> 
> Cheers,
> 
> 
> Sérgio Charrua
> www.voip.pt 
>  
> 
> __
> 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:

-- 
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: best approach to setup SIP Session sharing between servers

[Olle E. Johansson via sr-users]

In theory if you set the record-route to a DNS name and not an Ip address, then 
endpoints should be able to failover within a dialog - but as Alex says - 
transactions may fail. In many cases there are retry timers to restart 
transactions that fail. 

This means that if a call starts with an INVITE transaction on one server, it 
should in theory be able to find another server for the BYE. Whether this DNS 
srv based fail over is implemented in end-points is up to testing to prove. If 
not, then virtual IP failover is your best friend.

/O

> On 27 Feb 2024, at 13:33, Alex Balashov via sr-users 
>  wrote:
> 
> That would require transaction replication, which Kamailio doesn't have. 
> 
> Most messages can be processed statelessly, so this isn't a huge obstacle. 
> However, CANCELs won't work.
> 
>> On 27 Feb 2024, at 06:49, Sergio Charrua via sr-users 
>>  wrote:
>> 
>> Hi all!
>> 
>> I am having some difficulties/doubts on what would be the best approach to 
>> let multiple Kamailio servers share their SIP sessions between each other.
>> The goal is to have HA on Kamailio cluster such that if a call is received 
>> and initiated on Kamailio #1, and during any moment of the call (before or 
>> while established) if the server #1 goes down or Kamailio stops working for 
>> any reason, the call can be processed by Kamailio server #n available in the 
>> cluster.
>> I do not want to mess with Virtual IPs or DNS, that is not the point, but 
>> instead need to get a proper way to share SIP sessions between Kamailio 
>> servers such that any server could continue the call without issue.
>> 
>> I have checked the Dialog and DMQ module, but I am not sure if that is the 
>> way to go
>> 
>> Could any one share a solution for this?
>> 
>> Greatly appreciated.
>> 
>> Cheers,
>> 
>> 
>> Sérgio Charrua
>> www.voip.pt 
>> 
>> 
>> __
>> 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:
> 
> -- 
> 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: best approach to setup SIP Session sharing between servers

[Sergio Charrua via sr-users]

Thanks Alex & Olle!
I've done some tests with Keepalived for Virtual IP failover, and I found
that it works more or less as you mentioned, Olle: if an Invite comes from
Server #1, and that server gets offline, the BYE will indeed be correctly
processed by Server #2.

Isn't DMQ supposed to handle this? as i understand, DMQ sends the SIP
messages to other servers, so wouldn't it be enough? (I assume, I haven't
tested DMQ yet )


*Sérgio Charrua*

*www.voip.pt *
Tel.: +351  91 631 11 44

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, Feb 27, 2024 at 2:20 PM Olle E. Johansson via sr-users <
sr-users@lists.kamailio.org> wrote:

> In theory if you set the record-route to a DNS name and not an Ip address,
> then endpoints should be able to failover within a dialog - but as Alex
> says - transactions may fail. In many cases there are retry timers to
> restart transactions that fail.
>
> This means that if a call starts with an INVITE transaction on one server,
> it should in theory be able to find another server for the BYE. Whether
> this DNS srv based fail over is implemented in end-points is up to testing
> to prove. If not, then virtual IP failover is your best friend.
>
> /O
>
> > On 27 Feb 2024, at 13:33, Alex Balashov via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >
> > That would require transaction replication, which Kamailio doesn't have.
> >
> > Most messages can be processed statelessly, so this isn't a huge
> obstacle. However, CANCELs won't work.
> >
> >> On 27 Feb 2024, at 06:49, Sergio Charrua via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >>
> >> Hi all!
> >>
> >> I am having some difficulties/doubts on what would be the best approach
> to let multiple Kamailio servers share their SIP sessions between each
> other.
> >> The goal is to have HA on Kamailio cluster such that if a call is
> received and initiated on Kamailio #1, and during any moment of the call
> (before or while established) if the server #1 goes down or Kamailio stops
> working for any reason, the call can be processed by Kamailio server #n
> available in the cluster.
> >> I do not want to mess with Virtual IPs or DNS, that is not the point,
> but instead need to get a proper way to share SIP sessions between Kamailio
> servers such that any server could continue the call without issue.
> >>
> >> I have checked the Dialog and DMQ module, but I am not sure if that is
> the way to go
> >>
> >> Could any one share a solution for this?
> >>
> >> Greatly appreciated.
> >>
> >> Cheers,
> >>
> >>
> >> Sérgio Charrua
> >> www.voip.pt
> >>
> >>
> >> __
> >> 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:
> >
> > --
> > 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:
>
__
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: best approach to setup SIP Session sharing between servers

[Giovanni Maruzzelli via sr-users]

On Tue, Feb 27, 2024 at 3:36 PM Sergio Charrua via sr-users <
sr-users@lists.kamailio.org> wrote:

> Thanks Alex & Olle!
> I've done some tests with Keepalived for Virtual IP failover, and I found
> that it works more or less as you mentioned, Olle: if an Invite comes from
> Server #1, and that server gets offline, the BYE will indeed be correctly
> processed by Server #2.
>
> Isn't DMQ supposed to handle this? as i understand, DMQ sends the SIP
> messages to other servers, so wouldn't it be enough? (I assume, I haven't
> tested DMQ yet )
>

nope

the dialog must be processed by the same (ip address) server, only reliable
way for multiple kamailios is virtual ip moved by keepalived (etc)

-giovanni

-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
__
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: Roadmap to next major Kamailio release series v5.8.x

[Daniel-Constantin Mierla via sr-users]

Hello,

I propose to aim to get out 5.8.0 next week on Wednesday or Thursday
(March 6 or 7, 2024). I haven't seen much activity around issues in the
new features/modules. If time allows to build the pages for what-is-new
and how-to-upgrade (which I think it should be rather minimal), then I
think it should be no other major task. Overall it will be almost two
weeks since the 5.8 branch was created.

Cheers,
Daniel

On 23.02.24 12:11, Daniel-Constantin Mierla wrote:
> Hello,
>
> quick note that later today I will create the branch 5.8, notification
> emails will be sent once done.
>
> Cheers,
> Daniel
>
> On 16.02.24 08:01, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> hopefully the devel version is now more stabilized after the freezing,
>> the new components being adjusted enough not to need many more changes.
>> Therefore I consider to branch 5.8 out of devel version next week on
>> Friday, February 23, 2024, sometime around noon UTC.
>>
>> After that the master branch becomes open for new features, and branch
>> 5.8 has to be hammered further to build the 5.8.x series.
>>
>> Cheers,
>> Daniel
>>
>> On 10.01.24 10:11, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> discussed a bit during the online Kamailio devel meeting, it is time to
>>> set the milestones towards the next major Kamailio release series v5.8.x.
>>>
>>> If no other suggestions that suit more developers, I would propose to
>>> freeze by end of this month or early February, then test for about 4
>>> weeks as usual and release by end of February or during March.
>>>
>>> If anyone wants to add new features/modules, they have to be published
>>> till freezing date, either pushed in the git repository or proposed as
>>> pull request.
>>>
>>> Cheers,
>>> Daniel
>> -- 
>> Daniel-Constantin Mierla (@ asipto.com)
>> twitter.com/miconda -- linkedin.com/in/miconda
>> Kamailio Consultancy, Training and Development Services -- asipto.com
>> Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
>> Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
>>
> -- 
> Daniel-Constantin Mierla (@ asipto.com)
> twitter.com/miconda -- linkedin.com/in/miconda
> Kamailio Consultancy, Training and Development Services -- asipto.com
> Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
> Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
>
-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com

__
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: SSL key logger for Diffie-Hellman cipher

[Calvin E. via sr-users]

We've been using the siptrace module with Homer to do SIP-only captures,
but decided to use a different approach for VoIPmonitor as it affects more
than just Kamilio. We're also capturing dozens of FreeSWITCH and rtpengine
hosts, which are all using LD_PRELOAD to log their SIP TLS and SRTP DH
session keys. We wanted Kamailio and the other components to focus on their
real jobs (calling) and let a separate process handle the capturing. This
gives us insight/control over any load added by the capturing, and allows
us to see things closer to the network perspective rather than the
application. It's easy to add the VoIPmonitor sniffer to any host without
needing each application to natively support capturing.

I'm sure the siptrace module would have similar results, it's just not part
of the "homogenous deployment" approach we're taking with this project.

On Tue, Feb 27, 2024 at 1:29 AM Joel Serrano via sr-users <
sr-users@lists.kamailio.org> wrote:

> Calvin,
>
> Voipmonitor-sniffer has support for Kamailio’s ‘siptrace’ module, but this
> is useful if your goal is to capture SIP over TLS traffic, I’m not sure if
> that is the reason you have been asked to capture the DH session keys…
>
> If that's the case, any reason you went with LD_PRELOAD method vs
> kamailio’s siptrace module? Using the later you still get the sip traffic
> without the need of messing with OpenSSL.
>
> Mind sharing your findings?
>
> Joel.
>
>
>
> On Tue, Feb 27, 2024 at 00:18 Bastian Triller via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>> Some weeks ago I learned about [1]. Didn't play with it yet though.
>>
>>
>> [1]
>> https://medium.com/@yunwei356/ebpf-practical-tutorial-capturing-ssl-tls-plain-text-using-uprobe-fccb010cfd64
>>
>> On Tue, Feb 27, 2024, 02:08 Calvin E. via sr-users <
>> sr-users@lists.kamailio.org> wrote:
>>
>>> This was done using the system-provided OpenSSL (Debian 12). It might
>>> work for tlsa, but I don't know how Kamilio would respond to LD_PRELOAD
>>> affecting one of its own modules.
>>>
>>> If your curious how it works, the code is here:
>>> https://github.com/voipmonitor/sniffer/blob/master/tools/ssl_keylogger/sslkeylog.cpp
>>>
>>> On Fri, Feb 2, 2024 at 1:23 AM Ihor Olkhovskyi via sr-users <
>>> sr-users@lists.kamailio.org> wrote:
>>>
 Calvin,

 Thanks for sharing this, just a question, do you use system-provided
 OpenSSL or tlsa ?

 Le mar. 30 janv. 2024 à 03:00, Calvin E. via sr-users <
 sr-users@lists.kamailio.org> a écrit :

> It turns out the system I was on really
> uses /lib/systemd/system/kamailio.service, despite /etc/init.d/kamailio
> also existing.
>
> I was able to make it work by following the Systemd process:
>
> mkdir /etc/default/kamailio.d/
> edit /etc/default/kamailio.d/voipmonitor
> add lines:
> SSLKEYLOG_UDP='127.0.0.1:1234'
> LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so
> /usr/lib/x86_64-linux-gnu/libssl.so.3"
>
> The keys are captured by the VoIPmonitor sniffer and everything works
> as expected from there. I'd be happy to explain further to anyone
> interested in this setup.
>
> On Sun, Jan 28, 2024 at 3:20 AM Sergey Safarov 
> wrote:
>
>> You can check this PR
>> https://github.com/kamailio/kamailio/pull/2785
>>
>> On Fri, Jan 26, 2024 at 8:58 PM Calvin E. via sr-users <
>> sr-users@lists.kamailio.org> wrote:
>>
>>> I've been tasked to use LD_PRELOAD to log SSL keys for TLS
>>> connections using a Diffie-Hellman cipher. The first attempt did not 
>>> work,
>>> so I wanted to sanity check whether Kamailio's TLS support is built in 
>>> such
>>> a way that would defeat LD_PRELOAD.
>>>
>>> The instructions from the vendor are to update /etc/init.d/kamailio
>>> like this:
>>>
>>> env SSLKEYLOG_UDP='127.0.0.1:1234'
>>> LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so
>>> /usr/lib/x86_64-linux-gnu/libssl.so.3" \
>>> start-stop-daemon --start --quiet --pidfile $PIDFILE \
>>> --exec $DAEMON -- $OPTIONS || log_failure_msg "
>>> already running"
>>>
>>> Is there anything special in Kamailio (5.7.3 on Debian 12) that
>>> would prevent this from working? Not necessarily something to defeat a
>>> keylogger, but maybe the way tls.so gets loaded?
>>>
>>> The only discrepancy I've noticed is the vendor docs refer
>>> to libssl.so.3 not libssl.so.1, but the vendor said that should be OK.
>>>
>>> I'd love to hear from someone already using VoIPmonitor
>>> with Diffie-Hellman ciphers and Kamailio.
>>>
>>> __
>>> 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 rep

[SR-Users] Re: best approach to setup SIP Session sharing between servers

[Social Boh via sr-users]

Better use corosync and pacemaker to keeep call audio flow during moving 
virtual IP using master-slave redis


---
I'm SoCIaL, MayBe

El 27/02/2024 a las 9:07 a. m., Sergio Charrua via sr-users escribió:

Thanks Alex & Olle!
I've done some tests with Keepalived for Virtual IP failover, and I 
found that it works more or less as you mentioned, Olle: if an Invite 
comes from Server #1, and that server gets offline, the BYE will 
indeed be correctly processed by Server #2.


Isn't DMQ supposed to handle this? as i understand, DMQ sends the SIP 
messages to other servers, so wouldn't it be enough? (I assume, I 
haven't tested DMQ yet )


*
*

*Sérgio Charrua*

*www.voip.pt *
Tel.: +351 91 631 11 44

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, Feb 27, 2024 at 2:20 PM Olle E. Johansson via sr-users 
 wrote:


In theory if you set the record-route to a DNS name and not an Ip
address, then endpoints should be able to failover within a dialog
- but as Alex says - transactions may fail. In many cases there
are retry timers to restart transactions that fail.

This means that if a call starts with an INVITE transaction on one
server, it should in theory be able to find another server for the
BYE. Whether this DNS srv based fail over is implemented in
end-points is up to testing to prove. If not, then virtual IP
failover is your best friend.

/O

> On 27 Feb 2024, at 13:33, Alex Balashov via sr-users
 wrote:
>
> That would require transaction replication, which Kamailio
doesn't have.
>
> Most messages can be processed statelessly, so this isn't a huge
obstacle. However, CANCELs won't work.
>
>> On 27 Feb 2024, at 06:49, Sergio Charrua via sr-users
 wrote:
>>
>> Hi all!
>>
>> I am having some difficulties/doubts on what would be the best
approach to let multiple Kamailio servers share their SIP sessions
between each other.
>> The goal is to have HA on Kamailio cluster such that if a call
is received and initiated on Kamailio #1, and during any moment of
the call (before or while established) if the server #1 goes down
or Kamailio stops working for any reason, the call can be
processed by Kamailio server #n available in the cluster.
>> I do not want to mess with Virtual IPs or DNS, that is not the
point, but instead need to get a proper way to share SIP sessions
between Kamailio servers such that any server could continue the
call without issue.
>>
>> I have checked the Dialog and DMQ module, but I am not sure if
that is the way to go
>>
>> Could any one share a solution for this?
>>
>> Greatly appreciated.
>>
>> Cheers,
>>
>>
>> Sérgio Charrua
>> www.voip.pt 
>>
>>
>> __
>> 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:
>
> --
> 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:


__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email tosr-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.kamai

[SR-Users] Re: best approach to setup SIP Session sharing between servers

[Alex Balashov via sr-users]

Maybe. It's another one of those things where you might spend 99% of your 
effort for that 0.1% marginal gain...

> On 27 Feb 2024, at 14:58, Social Boh via sr-users 
>  wrote:
> 
> Better use corosync and pacemaker to keeep call audio flow  during moving 
> virtual IP using master-slave redis
> ---
> I'm SoCIaL, MayBe
> El 27/02/2024 a las 9:07 a. m., Sergio Charrua via sr-users escribió:

-- 
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: best approach to setup SIP Session sharing between servers

[Ovidiu Sas via sr-users]

That’s a huge marginal gain!
Most of the time is 0.01% or less. :-)

High availability is for hardware failures, not for software failures. If
there’s an issue in one node in the cluster and that node goes down, the
next node in the cluster will have the same issue and it will go down the
same way.

-ovidiu

On Tue, Feb 27, 2024 at 17:04 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

> Maybe. It's another one of those things where you might spend 99% of your
> effort for that 0.1% marginal gain...
>
> > On 27 Feb 2024, at 14:58, Social Boh via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >
> > Better use corosync and pacemaker to keeep call audio flow  during
> moving virtual IP using master-slave redis
> > ---
> > I'm SoCIaL, MayBe
> > El 27/02/2024 a las 9:07 a. m., Sergio Charrua via sr-users escribió:
>
> --
> 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: best approach to setup SIP Session sharing between servers

[Richard Edmands via sr-users]

Then to find out in those 0.1% that Corosync replicates the issue to the node 
it replaces in 60% of the cases where you would have utilised it.

> On 28 Feb 2024, at 8:16 am, Alex Balashov via sr-users 
>  wrote:
> 
> Maybe. It's another one of those things where you might spend 99% of your 
> effort for that 0.1% marginal gain...
> 
>> On 27 Feb 2024, at 14:58, Social Boh via sr-users 
>>  wrote:
>> 
>> Better use corosync and pacemaker to keeep call audio flow  during moving 
>> virtual IP using master-slave redis
>> ---
>> I'm SoCIaL, MayBe
>> El 27/02/2024 a las 9:07 a. m., Sergio Charrua via sr-users escribió:
> 
> --
> 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: [sr-dev] Re: Roadmap to next major Kamailio release series v5.8.x

[Richard Chan via sr-users]

Hi Daniel

===
For the upgrading notes, some ideas —

"tls.so: fixing GH#3635 new global config tls_threads_mode = 0 | 1
0: is the default and is the existing Kamailio behaviour
1: run some initialization functions(libcurl, database) in a thread to
avoid creating thread-locals in thread#1 before fork

On platforms with OpenSSL 3 "tls_threads_mode = 1" is needed to avoid
shared memory contention, especially if other modules (eg. db_mysql,
http_async_client, dispatcher with SIPS URIs) that might use TLS are loaded.

On platforms with OpenSSL 1.1.1 — shared memory contention is much harder
to trigger — but this setting is recommended when other modules that use
TLS are loaded"

===
Deployment note (for the wiki?)
Here is an SRE/deployment note — not sure of a good place to put this
(maybe the wiki)

"To validate the config for OpenSSL 3/1.1.1 memory contention potential run
the main kamailio process
under gdb (don't follow child forks: "set follow-fork-mode parent" — the
default setting anyway)

# ** EITHER **
# deb-based: install dbgsym for libssl3 / libssl1.1
# RPM-based: install debuginfo for openssl, openssl-libs
# ** OR **
# configure gdb to use debuginfod for debug symbols

# STEP 1
# stop at main(), this step is required because the next breakpoint
requires knowledge
# of thread#1
gdb> break main
gdb> run

# STEP 2
# this breakpoint detects if OpenSSL 3 initializes the thread-local
err_thread_local
# in process#0.thread#1 — this causes shared memory contention
gdb> breakpoint CRYPTO_THREAD_set_local thread 1 if
$_caller_is("ossl_err_get_state_int", 32)
gdb> commands
backtrace 32
continue
end

##For OpenSSL 1.1.1
gdb> breakpoint CRYPTO_THREAD_set_local thread 1 if
$_caller_is("ERR_get_state", 32)
gdb> commands
backtrace 32
continue
end

# continue execution of Kamailio
gdb> continue

If this breakpoint is triggered then the configuration has potential for
shared memory contention.
Do file an issue at GH with your configuration and the gdb output.
"

Dev note: I have completed an "audit" of all in-tree modules that load
libssl — libcurl, libmariadb, libcrypto, libpq etc. The only one not
touched is DIAMETER cdp.so with TLS. If anyone uses this and can provide me
with temporary access that would be great.


Regards
Richard

On Tue, 27 Feb 2024 at 23:55, Daniel-Constantin Mierla via sr-dev <
sr-...@lists.kamailio.org> wrote:

> Hello,
>
> I propose to aim to get out 5.8.0 next week on Wednesday or Thursday
> (March 6 or 7, 2024). I haven't seen much activity around issues in the
> new features/modules. If time allows to build the pages for what-is-new
> and how-to-upgrade (which I think it should be rather minimal), then I
> think it should be no other major task. Overall it will be almost two
> weeks since the 5.8 branch was created.
>
> Cheers,
> Daniel
>
> On 23.02.24 12:11, Daniel-Constantin Mierla wrote:
> > Hello,
> >
> > quick note that later today I will create the branch 5.8, notification
> > emails will be sent once done.
> >
> > Cheers,
> > Daniel
> >
> > On 16.02.24 08:01, Daniel-Constantin Mierla wrote:
> >> Hello,
> >>
> >> hopefully the devel version is now more stabilized after the freezing,
> >> the new components being adjusted enough not to need many more changes.
> >> Therefore I consider to branch 5.8 out of devel version next week on
> >> Friday, February 23, 2024, sometime around noon UTC.
> >>
> >> After that the master branch becomes open for new features, and branch
> >> 5.8 has to be hammered further to build the 5.8.x series.
> >>
> >> Cheers,
> >> Daniel
> >>
> >> On 10.01.24 10:11, Daniel-Constantin Mierla wrote:
> >>> Hello,
> >>>
> >>> discussed a bit during the online Kamailio devel meeting, it is time to
> >>> set the milestones towards the next major Kamailio release series
> v5.8.x.
> >>>
> >>> If no other suggestions that suit more developers, I would propose to
> >>> freeze by end of this month or early February, then test for about 4
> >>> weeks as usual and release by end of February or during March.
> >>>
> >>> If anyone wants to add new features/modules, they have to be published
> >>> till freezing date, either pushed in the git repository or proposed as
> >>> pull request.
> >>>
> >>> Cheers,
> >>> Daniel
> >> --
> >> Daniel-Constantin Mierla (@ asipto.com)
> >> twitter.com/miconda -- linkedin.com/in/miconda
> >> Kamailio Consultancy, Training and Development Services -- asipto.com
> >> Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
> >> Kamailio World Conference, April 18-19, 2024, Berlin --
> kamailioworld.com
> >>
> > --
> > Daniel-Constantin Mierla (@ asipto.com)
> > twitter.com/miconda -- linkedin.com/in/miconda
> > Kamailio Consultancy, Training and Development Services -- asipto.com
> > Kamailio Advanced Training, February 20-22, 2024 -- asipto.com
> > Kamailio World Conference, April 18-19, 2024, Berlin --
> kamailioworld.com
> >
> --
> Daniel-Constantin Mierla (@ asipto.com)
> twitte

[SR-Users] Re: best approach to setup SIP Session sharing between servers

[Alex Balashov via sr-users]

> On 27 Feb 2024, at 18:50, Richard Edmands  wrote:
> 
> Then to find out in those 0.1% that Corosync replicates the issue to the node 
> it replaces in 60% of the cases where you would have utilised it.

And the other 40% are outages caused by some bug or malfunction in the fancy HA 
gewgaws -- outages that wouldn't have happened at all if not for your HA stuff.

It's not worth it.

-- 
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: best approach to setup SIP Session sharing between servers

[Alex Balashov via sr-users]

> On 27 Feb 2024, at 18:34, Ovidiu Sas  wrote:
> 
> That’s a huge marginal gain!
> Most of the time is 0.01% or less. :-)
> 
> High availability is for hardware failures, not for software failures. If 
> there’s an issue in one node in the cluster and that node goes down, the next 
> node in the cluster will have the same issue and it will go down the same way.

I strongly agree with all of that. It's rare that someone truly gets this, and 
I salute you, sir.

-- 
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] Clarification on pv_www_authenticate

[James Lipski via sr-users]

Hello,

I would like get further information on the "pv_www_authenticate" function from 
auth module. For the response code "-1", which is listed as "generic error", 
what exactly is covered when this function returns this? Is it just everything 
else that isn't listed reason (invalid password, nonce expired, no credentials, 
etc...). On my production system, I'm seeing this as a response code on some 
registration requests, and just want to know what is causing this (enabling 
full verbose logging is a bit difficult on my production system, and want to 
try to replicate it on my test environment, however just need clarification on 
what this covers).
Thank you.__
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] [Presence] Updating route information for SIP NOTIFY when re-SUBSCRIBE

[Denys Pozniak via sr-users]

Hello!

In my architecture, SIP SUBSCRIBE messages can reach the Kamailio
Presence server in several ways.
And I noticed that re-SUBSCRIBEs messages do not update the record_route
field in the active_watchers table (MySQL), so subsequent SIP NOTIFY
messages do not inherit it and have the routes set of the initial SIP
SUBSCRIBE message.

Is there any way to change this behavior?

modparam("presence", "db_url", DBURL)
modparam("presence", "subs_db_mode", 3)
modparam("presence", "timeout_rm_subs", 0)
modparam("presence", "expires_offset", 0)
modparam("presence", "max_expires", 1800)
modparam("presence", "db_update_period", 30)
modparam("presence", "clean_period", 180)
modparam("presence", "send_fast_notify", 1)
modparam("presence", "pres_htable_size", 32)
modparam("presence", "subs_htable_size", 32)
modparam("presence", "publ_cache", 0)
modparam("presence", "notifier_processes", 0)

# kamailio -v
version: kamailio 5.1.2 (x86_64/linux)
-- 

BR,
Denys Pozniak
__
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: