[SR-Users] Re: loose_route false when using topos? At which point in the call flow, does topos restore the Route header?
Hi Karsten > did you use some kind of db backend for topos like redis or mysql? Well, you have to, to be able to store the route and via sets :-) MySQL in use. We might have figured out a possible cause. This is the topology: CPE <=> Kamailio Registrar <=> Kamailio Core <=> Interconnections. Registrar handles mainly registration, runs rtpengine and this shall be the place to hide topology towards the CPE. The core takes care of routing, is dialogue aware and generates CDR for billing. So in the situation of CPE A calling CPE B we have: CPE A => Registrar => Core => Registrar => CPE B So two legs of the same call running over the same Registrar. It looks like this breaks topos. I'll further investigate in this situation. 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] Re: Topos methods_nocontact parameter
Hi John > Those 5 vias remind me an old firmware of Cisco equipment. I think I found > that > once and solved with sems or something else acting as b2bua. It's not a Cisco. It's an ARRIS CPE which used to be operated as PacketCable CPE but for which also a SIP Firmware is available. I would love to use Kamailio as Registrar, especially as NAT seems to work much better directly on Kamailio compared to when we use our commercial B2BUA SBC in between which completely messes up some 'multiple CPE behind same NAT IP' situations. But we might have figured out, what breaks topos. It's when a call is from one CPE to another, both on the same Registrar. So we have two call legs with the same callID on one registrar and on one topos instance. May I ask what you used as B2BUA? 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 __ pgpN9F4CGd_kM.pgp Description: Digitale Signatur von OpenPGP __ 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
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:
[SR-Users] Re: loose_route false when using topos? At which point in the call flow, does topos restore the Route header?
Hi, did you use some kind of db backend for topos like redis or mysql? Benoit Panizzon via sr-users schrieb am Mo., 26. Feb. 2024, 16:28: > Hi > > https://lists.kamailio.org/pipermail/sr-users/2020-July/109801.html > > I have the exact same issue. > > When the B side is starting a new transaction (UPDATE to refresh the > session in my case) without topos enabled, that transaction contains > one or multiple route header and a to_tag. > > Therefore loose_route() is true and the call is more or less sent to > route(RELAY) immediately without further checks. > > If topos is enabled, all record-route header are removed and only one > Via sent to the CPE. > So when the CPE replies, there is no Route header. > Therefore loose_route returns false. > > This makes me wonder, at which stage is topos restoring the route > headers? Shouldn't that happen before loose_route is evaluated? > > 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: > __ 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 methods_nocontact parameter
El Mon, 26 Feb 2024 15:39:31 +0100 Benoit Panizzon via sr-users escribió: > > The message body is not the issue, this seems to be handled in a > different memory buffer. The CPE crashed with a 'memory buffer too > small' when composing the reply to an invite with 5 or more Via and RR > even with minimalistic SDP. On the other hand, I threw a huge SDP with > ICE and Crypto to that CPE and it handled it well when only one Via and > no RR was present (after being handled by topos). > Those 5 vias remind me an old firmware of Cisco equipment. I think I found that once and solved with sems or something else acting as b2bua. Not sure if this is the same case but it didn't have to do with the length of the message but rather with a limitation on the number of vias in the firmware. -- PekePBX, the multitenant PBX solution https://pekepbx.com pgp52fUHJFEHk.pgp Description: Firma digital OpenPGP __ 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] loose_route false when using topos? At which point in the call flow, does topos restore the Route header?
Hi https://lists.kamailio.org/pipermail/sr-users/2020-July/109801.html I have the exact same issue. When the B side is starting a new transaction (UPDATE to refresh the session in my case) without topos enabled, that transaction contains one or multiple route header and a to_tag. Therefore loose_route() is true and the call is more or less sent to route(RELAY) immediately without further checks. If topos is enabled, all record-route header are removed and only one Via sent to the CPE. So when the CPE replies, there is no Route header. Therefore loose_route returns false. This makes me wonder, at which stage is topos restoring the route headers? Shouldn't that happen before loose_route is evaluated? 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] Re: Topos methods_nocontact parameter
Sadly, there is no way to make Kamailio inject compact headers. That's up to the UAs. Well, if your hands really are that tied, then maybe topos is worth exploring after all. However, I would carefully weigh the complexity and failure modes and overall supportability issues against short-term benefit. Consider, for example, the ways in which `topos` makes troubleshooting that much harder, since you've now got apparently different call legs in and out of the proxy. I was trying to make a somewhat broader, methodological point: Kamailio is an eclectic grab-bag of interesting technical tools, but just because Kamailio is technically capable of something doesn't mean you should do it. It might be worth considering the larger business impact of the solution in many cases, rather than viewing every problem as a nail and Kamailio's dazzling, kaleidoscopic array of SIP manipulation capabilities as a hammer. The simplest possible solution is often not the quickest, nor the most interesting, but may make the most sense in the long run. If the CPE is reacting this poorly to a stack of perfectly standards-compliant Via or RR headers, it really may be worth doing the boring, tedious and time-consuming work of getting the vendor to fix, or replacing the CPE. Otherwise, you'll patch this hole and doubtless find another leak in the boat soon. -- Alex > On 26 Feb 2024, at 09:39, Benoit Panizzon wrote: > > Hi Alex > >> There are lots of strategies for reducing message size, although the >> RFC-recommended (better said, mandated :-) approach is just to switch to TCP >> whenever your message sizes come within 200 bytes of the MTU, if I'm not >> mistaken. > > Those CPE do not support TCP. > >> Otherwise: >> >> 1) Turn on compact (abbreviated) SIP headers; > > I would love to do that. But can I somehow instruct kamailio to > translate all headers to their compact format? > >> 2) Strip header fields you can do without. This is dangerous territory, but >> clearly some headers are less important than others, like "Date" or "Allow"; > > Done that, removed User-Agent and some more. Still not enough if there > are 5 or more Via and RR header. > >> 3) Do not offer any unnecessary codecs, reducing SDP bloat. > > The message body is not the issue, this seems to be handled in a > different memory buffer. The CPE crashed with a 'memory buffer too > small' when composing the reply to an invite with 5 or more Via and RR > even with minimalistic SDP. On the other hand, I threw a huge SDP with > ICE and Crypto to that CPE and it handled it well when only one Via and > no RR was present (after being handled by topos). > > 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 > __ -- 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: Topos methods_nocontact parameter
Hi Alex > There are lots of strategies for reducing message size, although the > RFC-recommended (better said, mandated :-) approach is just to switch to TCP > whenever your message sizes come within 200 bytes of the MTU, if I'm not > mistaken. Those CPE do not support TCP. > Otherwise: > > 1) Turn on compact (abbreviated) SIP headers; I would love to do that. But can I somehow instruct kamailio to translate all headers to their compact format? > 2) Strip header fields you can do without. This is dangerous territory, but > clearly some headers are less important than others, like "Date" or "Allow"; Done that, removed User-Agent and some more. Still not enough if there are 5 or more Via and RR header. > 3) Do not offer any unnecessary codecs, reducing SDP bloat. The message body is not the issue, this seems to be handled in a different memory buffer. The CPE crashed with a 'memory buffer too small' when composing the reply to an invite with 5 or more Via and RR even with minimalistic SDP. On the other hand, I threw a huge SDP with ICE and Crypto to that CPE and it handled it well when only one Via and no RR was present (after being handled by topos). 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] Re: Topos methods_nocontact parameter
There are lots of strategies for reducing message size, although the RFC-recommended (better said, mandated :-) approach is just to switch to TCP whenever your message sizes come within 200 bytes of the MTU, if I'm not mistaken. Otherwise: 1) Turn on compact (abbreviated) SIP headers; 2) Strip header fields you can do without. This is dangerous territory, but clearly some headers are less important than others, like "Date" or "Allow"; 3) Do not offer any unnecessary codecs, reducing SDP bloat. -- Alex > On 26 Feb 2024, at 09:15, Benoit Panizzon wrote: > > Hi Alex > >> Not really a great answer for you, but I think you should reconsider using >> `topos` to reduce SIP message size. >> >> `topos` is complex and I'm not sure the added complexity pays off in this >> case, from a purely thermodynamic point of view. > > So, any idea how to solve the issue? > > At the moment, we have a commercial B2BUA SBC in front of Kamailio. > This SBC has some severe limitations and bugs, costs a lot for > licensing and is declared end of life next year. > > I would love to just get rid of it and let kamailio handle everything. > So far, thinks look much cleaner and work more like expected, without > the SBC. Even IPv6 and tls and even rtp-crypto work thanks to rtpengine. > We loose T.38 fallback, but who cares, this also was not reliable > before. > > But I must make sure, all existing CPE still work and can cope with the > additional Via and RR header and this is where I stumbled over one > vendor which seems to have messed that up by allocating a too small > buffer for composing the reply message. > > Yes, we will contact that vendor, but I would not wonder if the reply > will be that those devices have reached end of life and no bugfixes > will be made. > > Now I am just fighting with topos again. When a CPE to which topology > was hidden is sending an UPDATE. topos is unable to route that update. > Investigating. > > 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 > __ -- 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: Topos methods_nocontact parameter
Hi Alex > Not really a great answer for you, but I think you should reconsider using > `topos` to reduce SIP message size. > > `topos` is complex and I'm not sure the added complexity pays off in this > case, from a purely thermodynamic point of view. So, any idea how to solve the issue? At the moment, we have a commercial B2BUA SBC in front of Kamailio. This SBC has some severe limitations and bugs, costs a lot for licensing and is declared end of life next year. I would love to just get rid of it and let kamailio handle everything. So far, thinks look much cleaner and work more like expected, without the SBC. Even IPv6 and tls and even rtp-crypto work thanks to rtpengine. We loose T.38 fallback, but who cares, this also was not reliable before. But I must make sure, all existing CPE still work and can cope with the additional Via and RR header and this is where I stumbled over one vendor which seems to have messed that up by allocating a too small buffer for composing the reply message. Yes, we will contact that vendor, but I would not wonder if the reply will be that those devices have reached end of life and no bugfixes will be made. Now I am just fighting with topos again. When a CPE to which topology was hidden is sending an UPDATE. topos is unable to route that update. Investigating. 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] Re: Topos methods_nocontact parameter
Not really a great answer for you, but I think you should reconsider using `topos` to reduce SIP message size. `topos` is complex and I'm not sure the added complexity pays off in this case, from a purely thermodynamic point of view. > On 26 Feb 2024, at 06:11, Benoit Panizzon via sr-users > wrote: > > Hi > > I'm having another go at topos trying to solve an issue of sip messages > getting to big for certain clients to process. > > Unfortunately some methods (ACK/PRACK/BYE probably CANCEL) do not > contain a contact header, therefore the topology is still revealed (and > potentially a lot of via header inserted increasing message size). > > Is it safe to set methods_nocontact to an empty string to force > creation of a Contact header for every SIP method? > > Is there another way to completely hide topology aka keeping header > small? > > 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: -- 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] Topos methods_nocontact parameter
Hi I'm having another go at topos trying to solve an issue of sip messages getting to big for certain clients to process. Unfortunately some methods (ACK/PRACK/BYE probably CANCEL) do not contain a contact header, therefore the topology is still revealed (and potentially a lot of via header inserted increasing message size). Is it safe to set methods_nocontact to an empty string to force creation of a Contact header for every SIP method? Is there another way to completely hide topology aka keeping header small? 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] Re: How to keep SIP messages small, possibly below fragmentation limit?
Good morning Henning > one really effective way is the topos module. If you can not use this, you > could switch to compact sip header. This way you save some bytes per > header-field. But this is something that needs to be supported from the user > agent as well. You could remove not needed headers and SDP inside the > Kamailio, but this will probably not help you a lot. In the end the user > agents need to be fixed, probably. topos requires database but not dialog, right? I remember I ran into issues with topos which I was unable to solve. We have a CPE <=> Registrar(kamailio) <=> Routing Core(kamailio) <=> IC topology Topology shall be hidden towards the CPE, not towards the core. But I didn't manage to achieve this, sometimes topology was hidden towards core causing call failure and incorrect restoring of Route/Via header. As I recall this happened in call forwarding scenarios (initiated on the registrar). Btw, is there a way to convert all header to compact header? I'm not sure if our CPE would support them, but it's worth a try. Is there a function returning, or PV containing the sip packet size to try to take actions like removing unnecessary header and codecs if a packet is over a certain size? 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:
