[SR-Users] Re: append_hf not working
According to a packet capture, changing append_hf() to
append_to_reply() affected a 302 message that Kamailio is forwarding
to sending to itself, but the subsequent INVITE did not keep the
header. What am I missing?
On Mon, Mar 11, 2024 at 7:28 AM Ben Kaufman via sr-users
wrote:
>
> There's also the question of when the header was appended as well, right?
> Calling append_hf() after creating a transaction will only apply that header
> to the current branch, not to subsequent branches.
>
>
> -Original Message-
> From: James Browne via sr-users
> Sent: Monday, March 11, 2024 7:03 AM
> To: Kamailio (SER) - Users Mailing List
> Cc: James Browne
> Subject: [SR-Users] Re: append_hf not working
>
> 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.
>
>
> One pitfall would be to think that this function would add this header field
> to any reply that kamailio would send. This append_hf() function should add a
> header field to a SIP request that it *relays*, but would not add it to a
> response that kamailio *generates* (for that, you would use the
> append_to_reply() function).
>
> James
>
> On Mon, 11 Mar 2024 at 11:26, Alex Balashov via sr-users
> wrote:
> >
> > Indeed, it has become a bit of a cliché that msg_apply_changes() should be
> > called after append_hf(), uac_replace_from(), etc.
> >
> > This should be dispelled. In the vast majority of use-cases, it is not only
> > unnecessary, but highly undesirable.
> >
> > -- Alex
> >
> > > On 11 Mar 2024, at 06:45, Henning Westerholt via sr-users
> > > wrote:
> > >
> > > Hello,
> > > the usage of msg_apply_changes is not necessary (not even recommended)
> > > for append_hf (and other functions) to work. The OP was talking about a
> > > packet capture, so I assume that he got the capture after the proxy send
> > > out the message.
> > > Cheers,
> > > Henning
> > > -- Henning Westerholt -
> > > https://sk/
> > > alatan.de%2Fblog%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cb9eabef23
> > > 1974f061db008dc41c47c6b%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7
> > > C638457559371077852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IUKBac
> > > HQspO1gtJ5B3ZULUOt6oAJKaTMBWM6R%2FDiq1Y%3D&reserved=0
> > > Kamailio services - https://gilawa.com/
> > > From: Unai Rodriguez via sr-users
> > > Sent: Montag, 11. März 2024 09:33
> > > To: Calvin E. via sr-users ; Kamailio
> > > (SER) - Users Mailing List
> > > Cc: Unai Rodriguez
> > > Subject: [SR-Users] Re: append_hf not working Using
> > > https://kamailio.org/docs/modules/stable/modules/textopsx.html#textopsx.f.msg_apply_changes
> > > might be relevant in your case...
> > > With best wishes, Unai Rodriguez
> > > On 11 Mar 2024 at 09:22 +0100, Benoit Panizzon via sr-users
> > > , wrote:
> > >
> > > Hi Calvin
> > >
> > >
> > > I'm trying to add something simple like the following:
> > >
> > > append_hf("X-testheader: True\r\n", "From");
> > >
> > > However, I don't see my X-testheader in a packet capture. Are there
> > > any common pitfalls that would prevent append_hf from working as
> > > expected?
> > >
> > > Weird, I use this a lot and it always works. But I never attempted
> > > to specify the header after which it should be appended. Does it
> > > work if you don't specifiy "From"?
> > >
> > > 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 Pratteln Fax +41 61 826 93 01 Schweiz Web
> > > http://www/
> > > .imp.ch%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cb9eabef231974f061d
> > > b008dc41c47c6b%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C63845755
> > > 9371097127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fOFt%2BsXu%2FDg
> > > 3EeKqhoRlybWURiVXfz%2B0Di8aSYFWxvQ%3D&reserved=0
> > > __
> > >
[SR-Users] Re: append_hf not working
Thank you everyone for the feedback. I realized my initial post was
bereft of details. I'm not at liberty to share the entire script, but
I will try to distill it. The original INVITE is sent to our internal
STI-VS which returns a 302. Kamilio handles that locally and then
sends the INVITE back to itself for further processing. I'm not sure
what context that put me in with regards to
request/reply/failure/branch.
Here are some of the pieces:
failure_route[RTF_DISPATCH] {
...
# handle internal redirects ourselves instead of passing back to client
if (t_check_status("3[0-9][0-9]")) {
get_redirects("1:1");
xlog("L_INFO", "|||(RESP) ($ci) redirect
branches: $bR \n");
# see if the first redirect branch is local
if (is_ip_rfc1918($(br{uri.domain}))) {
xlog("L_INFO", "|||(RESP) ($ci) Handling
internal redirect to $br \n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
}
...
route[RELAY] {
if (!has_totag()) {
dlg_manage();
}
# enable additional event routes for forwarded requests
# - serial forking, RTP relaying handling, a.s.o.
if (is_method("INVITE|NOTIFY|REFER|BYE|PRACK")) {
if (is_method("BYE")) {
route(TUI_CALL_REDUNDANCY_CLEAR);
}
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
}
if (is_method("ACK")) {
xlog("L_INFO", "$var(logPrefixIn2) Forwarding ACK\n");
# forward the ACK statelessly
route(NATMANAGE);
forward();
} else {
if (!t_relay()) {
xlog("L_ERROR", "$var(logPrefixCall) Failed to relay request\n");
sl_reply_error();
} else if (is_method("NOTIFY")) {
xlog("L_INFO", "$var(logPrefixIn2) Relaying notify request
with SipFrag($rb)\n");
} else {
xlog("L_INFO", "$var(logPrefixIn2) Relaying request\n");
}
}
exit;
}
On Mon, Mar 11, 2024 at 7:28 AM Ben Kaufman via sr-users
wrote:
>
> There's also the question of when the header was appended as well, right?
> Calling append_hf() after creating a transaction will only apply that header
> to the current branch, not to subsequent branches.
>
>
> -Original Message-
> From: James Browne via sr-users
> Sent: Monday, March 11, 2024 7:03 AM
> To: Kamailio (SER) - Users Mailing List
> Cc: James Browne
> Subject: [SR-Users] Re: append_hf not working
>
> 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.
>
>
> One pitfall would be to think that this function would add this header field
> to any reply that kamailio would send. This append_hf() function should add a
> header field to a SIP request that it *relays*, but would not add it to a
> response that kamailio *generates* (for that, you would use the
> append_to_reply() function).
>
> James
>
> On Mon, 11 Mar 2024 at 11:26, Alex Balashov via sr-users
> wrote:
> >
> > Indeed, it has become a bit of a cliché that msg_apply_changes() should be
> > called after append_hf(), uac_replace_from(), etc.
> >
> > This should be dispelled. In the vast majority of use-cases, it is not only
> > unnecessary, but highly undesirable.
> >
> > -- Alex
> >
> > > On 11 Mar 2024, at 06:45, Henning Westerholt via sr-users
> > > wrote:
> > >
> > > Hello,
> > > the usage of msg_apply_changes is not necessary (not even recommended)
> > > for append_hf (and other functions) to work. The OP was talking about a
> > > packet capture, so I assume that he got the capture after the proxy send
> > > out the message.
> > > Cheers,
> > > Henning
> > > -- Henning Westerholt -
> > > https://sk/
> > > alatan.de%2Fblog%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cb9eabef23
> > > 1974f061db008dc41c47c6b%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7
> > > C638457559371077852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IUKBac
> > > HQspO1gtJ5B3ZULUOt6oAJKaTMBWM6R%2FDiq1Y%3D&reserved=0
> > > Kamailio services - https://gilawa.com/
> > > From: Unai Rodriguez via sr-users
> > > Sent: Montag, 11. März 2024 09:33
> > > To: Calvin E. via sr-users ; Kamailio
> > > (SER) - Users Mailing List
> > > Cc: Unai Rodriguez
> &
[SR-Users] append_hf not working
I'm trying to add something simple like the following:
append_hf("X-testheader: True\r\n", "From");
However, I don't see my X-testheader in a packet capture. Are there
any common pitfalls that would prevent append_hf from working as
expected?
__
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
Try removing `ssl_sessionkey_udp_ip`, I don't have that set on mine. Changing it to 127.0.0.1 might also work, but that's only a guess. Keep in mind this part is open source, if you want to check it out: https://github.com/voipmonitor/sniffer Only the GUI is licensed, but isn't required if you want to use the database and pcaps directly. On Thu, Mar 7, 2024 at 7:56 PM Joel Serrano wrote: > > Damm that was a rabbit hole... > > So the key pointers were found thanks to reading two very helpful links [1] > [2]. > > The TL;DR is that I use setcap to add capabilities to Kamailio to allow to > listen on ports <1024 without root. Once you add capabilities, any LD_* env > var gets stripped out and is not accessible to the process for security > reasons. The solution is to have the sslkeylogger.so lib in a system LD path > with setuid bit added (chmod +s), and load it without any "/" in the name. > > So basically doing this (pseudo commands): > > mv keylogger.so /system/ld/path/keylogger.so > chmod u+s /system/ld/path/keylogger.so > > And then have the /etc/default/kamailio.d/voipmonitor file as: > > SSLKEYLOG_UDP='127.0.0.1:1234' > LD_PRELOAD="sslkeylog.so libssl.so.1.1" > > Restart and boom, sslkeylogger is loaded: > > root@csbc03:~# fgrep ssl /proc/2633948/maps > 7f97ffb92000-7f97ffbaf000 r--p 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f97ffbaf000-7f97ffbfd000 r-xp 0001d000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f97ffbfd000-7f97ffc17000 r--p 0006b000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f97ffc17000-7f97ffc18000 ---p 00085000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f97ffc18000-7f97ffc21000 r--p 00085000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f97ffc21000-7f97ffc25000 rw-p 0008e000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f9800173000-7f9800174000 r--p 08:06 262170 > /usr/lib/x86_64-linux-gnu/sslkeylog.so > 7f9800174000-7f9800175000 r-xp 1000 08:06 262170 > /usr/lib/x86_64-linux-gnu/sslkeylog.so > 7f9800175000-7f9800176000 r--p 2000 08:06 262170 > /usr/lib/x86_64-linux-gnu/sslkeylog.so > 7f9800176000-7f9800177000 r--p 2000 08:06 262170 > /usr/lib/x86_64-linux-gnu/sslkeylog.so > 7f9800177000-7f9800178000 rw-p 3000 08:06 262170 > /usr/lib/x86_64-linux-gnu/sslkeylog.so > root@csbc03:~# > > I have one last question for you Calvin, > > Can you share the settings you have on your local and remote > voipmonitor-sniffers to allow Kamailio to send keys to 127.0.0.1:1234, and > then have the voipmonitor-client forward that to voipmonitor-server for > processing? > > These are mine: > > -CLIENT- > > [general] > id_sensor = 23 > query_cache = yes > server_destination = XXX > server_destination_port = XXX > server_password = XXX > packetbuffer_sender = yes > packetbuffer_enable = yes > packetbuffer_total_maxheap = 512 #in MB > packetbuffer_compress = yes > packetbuffer_file_totalmaxsize = 2000 #MB. Default is disabled. > packetbuffer_file_path = /var/spool/voipmonitor/packetbuffer > interface = eno1,lo > sipport = 5060 > sipport = 5061 > sipport = 5062 > > NOTES: 5060 is regular UDP, 5061 and 5062 are both TLS ports. > > -SERVER- (only the ssl_* settings) > > ssl = yes > ssl_ipport = A.B.C.D : 5061 > ssl_ipport = A.B.C.E : 5061 > ssl_ipport = A.B.C.F : 5061 > ssl_ipport = A.B.C.G : 5061 > ssl_ipport = A.B.C.D : 5062 > ssl_ipport = A.B.C.E : 5062 > ssl_ipport = A.B.C.F : 5062 > ssl_ipport = A.B.C.G : 5062 > ssl_store_sessions_expiration_hours = 48 > ssl_sessionkey_udp = yes > ssl_sessionkey_udp_port = 1234 > ssl_sessionkey_udp_ip = 192.168.1.0/24 > ssl_sessionkey_udp_maxwait_ms = 1 > ssl_store_sessions = persistent > ssl_ignore_error_invalid_mac = yes > > NOTES: All the A.B.C.X are Kamailio instances Public IPs. > > I know I'm missing something to get the combo > Kamailio->Local-Sniffer->Remote-Sniffer to work, any hints there? > > Thanks, > Joel. > > > [1] > https://stackoverflow.com/questions/18058426/does-using-linux-capabilities-disable-ld-preload > [2] > https://unix.stackexchange.com/questions/757484/ld-preload-does-not-work-and-ld-debug-shows-nothing > > > On Thu, Mar 7, 2024 at 4:33 PM Calvin E. wrote: >> >> Does your sslkeylog.so work on that same host with the openssl test? I &g
[SR-Users] Re: SSL key logger for Diffie-Hellman cipher
Does your sslkeylog.so work on that same host with the openssl test? I noticed you're using ansible, so I'm curious if you're compiling on some other host that could have different versions of the openssl-dev stuff. Other things could be file or path permissions, or maybe a security tool blocking it (would auditd do that?). At this point I'd reach out to their support. On Tue, Mar 5, 2024 at 10:24 PM Joel Serrano wrote: > > Hi Calvin, > > Thanks for the tip on capturing on LO interface, I'm sure you just saved me > some headaches ;) > > Interestingly when I check the environ I do see the env vars being set, but > in the maps I don't see the keylogger: > > root@csbc03:~# cat /proc/2216899/environ > LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binPIDFILE=/run/kamailio/kamailio.pidHOME=/run/kamailioLOGNAME=kamailioUSER=kamailioINVOCATION_ID=fb5d2818a5434319ab2381262737dcffJOURNAL_STREAM=8:1642042024RUNTIME_DIRECTORY=/run/kamailioCFGFILE=/etc/kamailio/csbc.cfgSHM_MEMORY=512PKG_MEMORY=32SSLKEYLOG_UDP=10.2.1.19:1234LD_PRELOAD=/opt/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so > > /usr/lib/x86_64-linux-gnu/libssl.so.1.1RUN_KAMAILIO=yesGROUP=kamailioDUMP_CORE=yes > root@csbc03:~# > > root@csbc03:~# fgrep ssl /proc/2216899/maps > 7f1ceef99000-7f1ceefb6000 r--p 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f1ceefb6000-7f1cef004000 r-xp 0001d000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f1cef004000-7f1cef01e000 r--p 0006b000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f1cef01e000-7f1cef01f000 ---p 00085000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f1cef01f000-7f1cef028000 r--p 00085000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > 7f1cef028000-7f1cef02c000 rw-p 0008e000 08:06 266231 > /usr/lib/x86_64-linux-gnu/libssl.so.1.1 > root@csbc03:~# > > This is on a debian 10 box. I have another box for testing on debian12, I set > the exact same config as you and I still don't see the keylogger being loaded: > > root@csbc01:~# lsb_release -a > No LSB modules are available. > Distributor ID: Debian > Description: Debian GNU/Linux 12 (bookworm) > Release: 12 > Codename: bookworm > root@csbc01:~# > > root@csbc01:~# cat /etc/default/kamailio.d/voipmonitor > # ANSIBLE_MANAGED_FILE - Do NOT edit this file as it is auto-generated by > Ansible. > 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" > root@csbc01:~# > > root@csbc01:~# file > /usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so > /usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so: ELF 64-bit > LSB shared object, x86-64, version 1 (SYSV), dynamically linked, > BuildID[sha1]=f1a884cad7648cc38a579b1d00a9ad523297b78c, with debug_info, not > stripped > root@csbc01:~# > > root@csbc01:~# file /usr/lib/x86_64-linux-gnu/libssl.so.3 > /usr/lib/x86_64-linux-gnu/libssl.so.3: ELF 64-bit LSB shared object, x86-64, > version 1 (SYSV), dynamically linked, > BuildID[sha1]=dd6b0615fc5d03f9c698d6d0c9d2da1b1e8f2d24, stripped > root@csbc01:~# > > root@csbc01:~# cat /proc/181454/environ > LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binPIDFILE=/run/kamailio/kamailio.pidHOME=/run/kamailioLOGNAME=kamailioUSER=kamailioINVOCATION_ID=059a5e15f1bb4e2bae17c0b5ec9c731eJOURNAL_STREAM=8:2661302RUNTIME_DIRECTORY=/run/kamailioSYSTEMD_EXEC_PID=181394CFGFILE=/etc/kamailio/csbc.cfgSHM_MEMORY=512PKG_MEMORY=32RUN_KAMAILIO=yesGROUP=kamailioDUMP_CORE=yesSSLKEYLOG_UDP=127.0.0.1:1234LD_PRELOAD=/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so > /usr/lib/x86_64-linux-gnu/libssl.so.3 > root@csbc01:~# > > root@csbc01:~# fgrep ssl /proc/181454/maps > 7f0c537b6000-7f0c537d5000 r--p 08:01 3674382 > /usr/lib/x86_64-linux-gnu/libssl.so.3 > 7f0c537d5000-7f0c53833000 r-xp 0001f000 08:01 3674382 > /usr/lib/x86_64-linux-gnu/libssl.so.3 > 7f0c53833000-7f0c53852000 r--p 0007d000 08:01 3674382 > /usr/lib/x86_64-linux-gnu/libssl.so.3 > 7f0c53852000-7f0c5385c000 r--p 0009c000 08:01 3674382 > /usr/lib/x86_64-linux-gnu/libssl.so.3 > 7f0c5385c000-7f0c5386 rw-p 000a6000 08:01 3674382 > /usr/lib/x86_64-linux-gnu/libssl.so.3 > root@csbc01:~# > > Any other ideas of what I can be missing? > > On Tue, Mar 5, 2024 at 2:30 PM Calvin E. wrote: >> >> Make sure you are preloading the correct OpenSS
[SR-Users] Re: SSL key logger for Diffie-Hellman cipher
Make sure you are preloading the correct OpenSSL library. On my Debian 12 box it is libssl.so.3 not libssl.so.1.1. You can confirm which is loaded by checking the "maps" of a running proc: $ sudo fgrep ssl /proc/2951676/maps 7f26647a4000-7f26647c3000 r--p 08:01 131274 /usr/lib/x86_64-linux-gnu/libssl.so.3 7f26647c3000-7f2664821000 r-xp 0001f000 08:01 131274 /usr/lib/x86_64-linux-gnu/libssl.so.3 7f2664821000-7f266484 r--p 0007d000 08:01 131274 /usr/lib/x86_64-linux-gnu/libssl.so.3 7f266484-7f266484a000 r--p 0009c000 08:01 131274 /usr/lib/x86_64-linux-gnu/libssl.so.3 7f266484a000-7f266484e000 rw-p 000a6000 08:01 131274 /usr/lib/x86_64-linux-gnu/libssl.so.3 7f266484e000-7f266484f000 r--p 08:01 154916 /usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so 7f266484f000-7f266485 r-xp 1000 08:01 154916 /usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so 7f266485-7f2664851000 r--p 2000 08:01 154916 /usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so 7f2664851000-7f2664852000 r--p 2000 08:01 154916 /usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so 7f2664852000-7f2664853000 rw-p 3000 08:01 154916 /usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so My systemd /lib/systemd/system/kamailio.service has a line "EnvironmentFile=-/etc/default/kamailio.d/*" so I dropped a file there: $ cat /etc/default/kamailio.d/voipmonitor 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" In my environment we're using "packetbuffer_sender = yes" to copy all packets to a central processor. I'm sending the keys to localhost so they can get picked up by the sniffer instead of sending them separately to the central processor. For this to work, the sniffer also must capture the "lo" interface. __ 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
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'
[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: SSL key logger for Diffie-Hellman cipher
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:
[SR-Users] SSL key logger for Diffie-Hellman cipher
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:
[SR-Users] Re: Same number of max concurrent requests on backends
Are you using 'ds_load_update()' and 'ds_load_unset()'? These should be keeping track of how many sessions are active at each destination in the set, so the one with the fewest sessions is selected. This assumes you are using SIP INVITE dialogs. Am I missing something specific to MRCP? On Mon, Jan 22, 2024 at 10:06 AM Unai Rodriguez wrote: > We're already using call load distribution. As I said, it sends the same > number of requests to each backend but the max concurrency of each > varies... how can module dispatcher be aware of the number of ongoing > concurrent sessions on each backend unless it connects to them? Thank you > > On Jan 22, 2024, at 18:37, Calvin E. wrote: > > > It sounds like you're looking for "Call Load Distribution", provided by > the dispatcher module, algorithm 10 in 'ds_select_dst'. > > https://www.kamailio.org/docs/modules/devel/modules/dispatcher.html > > Search the page for references to "call load" to see how > 'ds_load_update()' and 'ds_load_unset()' are used. > > You will need to set ds_hash_size to a power of two large enough to track > your peak concurrent sessions. Each destination in a set will need a > unique 'duid' string, and optionally 'maxload'. > > > > On Mon, Jan 22, 2024 at 9:06 AM Unai Rodriguez via sr-users < > sr-users@lists.kamailio.org> wrote: > >> Dear List, >> >> We're load balancing MRCP requests using Kamailio dispatcher module's >> call load distribution algorithm. >> >> We want to achieve the same maximum number of concurrent sessions on each >> MRCP backend but because the duration of each request varies, we’re unable >> to achieve this (at the moment we send the same number of requests to each >> backend but they all have different maximum concurrent requests). >> >> Is there a way/module that will send requests to the backend with the >> least number of ongoing sessions? My guess is, this module needs to connect >> to the backends to know their status. Any pointers appreciated. >> >> Thank you >> >> With best wishes, >> Unai Rodriguez >> >> >> __ >> 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: Same number of max concurrent requests on backends
It sounds like you're looking for "Call Load Distribution", provided by the dispatcher module, algorithm 10 in 'ds_select_dst'. https://www.kamailio.org/docs/modules/devel/modules/dispatcher.html Search the page for references to "call load" to see how 'ds_load_update()' and 'ds_load_unset()' are used. You will need to set ds_hash_size to a power of two large enough to track your peak concurrent sessions. Each destination in a set will need a unique 'duid' string, and optionally 'maxload'. On Mon, Jan 22, 2024 at 9:06 AM Unai Rodriguez via sr-users < sr-users@lists.kamailio.org> wrote: > Dear List, > > We're load balancing MRCP requests using Kamailio dispatcher module's call > load distribution algorithm. > > We want to achieve the same maximum number of concurrent sessions on each > MRCP backend but because the duration of each request varies, we’re unable > to achieve this (at the moment we send the same number of requests to each > backend but they all have different maximum concurrent requests). > > Is there a way/module that will send requests to the backend with the > least number of ongoing sessions? My guess is, this module needs to connect > to the backends to know their status. Any pointers appreciated. > > Thank you > > With best wishes, > Unai Rodriguez > > > __ > 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: Standard on RTP ports
Probably this: https://github.com/sipwise/rtpengine/blob/master/debian/changelog ngcp-rtpengine (12.1.0.0+0~mr12.1.0.0) unstable; urgency=medium * [2fa121c] MT#54294 add GPU support * [b3544be] MT#54294 packaging for rtpengine-gpu * [079bfac] MT#55283 fix up pkg generator for -gpu packages I'm guessing this uses underlying FFmpeg CUDA support. On Thu, Dec 14, 2023 at 1:08 AM Stefan-Cristian Mititelu via sr-users < sr-users@lists.kamailio.org> wrote: > Hi, > > @Richard Edmands, what do you mean by "RTPengine has Cuda offloading..."? > Can you share more references to that? > > Thank you, > Stefan > -- > *From:* Richard Edmands via sr-users > *Sent:* Wednesday, December 13, 2023 11:06:08 AM > *To:* Kamailio (SER) - Users Mailing List > *Cc:* Richard Edmands > *Subject:* [SR-Users] Re: Standard on RTP ports > > Howdy, > > So you’ve got the reserved ports range 0-1023. Then there’s a few other > brackets. > > In Linux there are kernel parameters to adjust these ranges, but it has > been a few years. > > If we’re really at the stage where we are looking at increasing the size > of the range, then looking into these parameters is also worth looking into > on these rtp boxes. > > Typically a box wouldn’t be processing anywhere near the limits to be > genuinely worth considering. > > But now that RTPEngine has Cuda offloading… > > > On 12 Dec 2023, at 2:46 am, Alex Balashov via sr-users < > sr-users@lists.kamailio.org> wrote: > > > > Hello, > > > > Ports are allocated dynamically. Even ports are for RTP, odd ports are > for RTCP. There is no standard that I am aware of, but common practice is > for the lower bound to be UDP 8000. The upper bound varies, but can be as > high as the logical maximum of 65535. > > > > -- Alex > > > >> On 8 Dec 2023, at 05:16, ZZ Wave via sr-users < > sr-users@lists.kamailio.org> wrote: > >> > >> Hello. > >> > >> I have some rant with network security dept. Is there some standard, > RFC, what port range should be used for RTP traffic, how RTP ports are > selected during SIP call negotiation? > >> > >> Thanks. > >> __ > >> 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: > __ 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: Iterating Through Multiple IP Peers for DID Call Termination in Kamailio
Take a look at the Dispatcher module. It has a lot of flexibility built in.
On Mon, Sep 25, 2023, 5:57 PM Shah Hussain Khattak via sr-users <
sr-users@lists.kamailio.org> wrote:
> Hello Team,
>
> I hope you're all doing well. I'm reaching out to request your insights on
> the following scenario.
>
> *Overview:*
> I have successfully configured Kamailio to authenticate IP addresses,
> primarily for PBXs and customers unable to register. With this setup, I can
> flawlessly receive incoming traffic and forward it to our internal
> FreeSwitch servers.
>
> *Current issue:*
> Now, I'm focusing on managing traffic in the opposite
> direction—specifically for DIDs. I have a DID table set up in Kamailio that
> associates DID numbers with their respective IP peers. Upon receiving a
> call, a database lookup is performed to find the destination number, after
> which the call is terminated at the customer's IP.
>
> I'm facing difficulty in handling situations where a customer has multiple
> IP peers (for redundancy). My aim is to try each of these IPs sequentially
> when terminating a specific DID call towards them. The current logic I'm
> employing for the INVITE lookup looks like this:
>
> # Database lookup for INVITEs
>
> if (is_method("INVITE")) {
> sql_query("didrouting_db", "SELECT route_to FROM did_routing WHERE
> did_number='$rU'", "result");
> if ($dbr(result=>rows) > 0) {
> $var(route_to) = $dbr(result=>[0,0]);
> xlog("L_INFO", "Routing DID $rU to $var(route_to)\n");
> $du = "sip:" + $var(route_to) + ":5060";
> } else {
> $du = "sip:" + FS_IP + ":5060";
> }
> }
>
> The above logic works fine for a single IP.
>
> I intend to use a comma-separated list of IPs in my *route_to* column
> (for example 192.168.1.2,192.168.1.3, ...) and then iterate through these
> IPs one by one. I'm having trouble coming up with a workable logic or loop
> to achieve this. Would you be able to offer any guidance or suggestions?
>
> Please also recommend if there is a better approach available to handle
> this scenario.
>
> Thank you in advance for your valuable input.
>
>
> Regards,
> Shah Hussain
> __
> 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] Using maxload in dispatcher list
Should maxload work with all dispatcher algorithms? I'm trying to add a test node to dispatcher.list with maxload=1 and it is getting a lot more than one concurrent call. The test node is the last one in the list. 16 sip:10.x.x.43:5070 0 0 duid=duid01;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.44:5070 0 0 duid=duid02;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.47:5070 0 0 duid=duid03;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.48:5070 0 0 duid=duid04;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.56:5070 0 0 duid=duid05;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.57:5070 0 0 duid=duid06;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.58:5070 0 0 duid=duid07;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.x:5070 0 0 duid=duid08;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.104:5060 0 0 duid=duid09;user=+10007787878;sockname=floating-internal-ip;maxload=1 __ 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: Dialog DMQ state after restart
The question is whether that DMQ synchronization for dialog data is sending all dialogs or only delta/incremental data. Some SBCs I've worked with only synchronize new dialog data, leaving standby nodes only aware of dialogs established since restarting or joining the cluster, not existing dialogs. In that circumstance, a failover to the restarted or new standby would break any dialogs created prior to the restart. If Kamailio dialog DMQ synchronization is "complete" then we just need to know how to confirm the new standby is synchronized before performing a failover. On Thu, Jun 8, 2023 at 12:53 PM Henning Westerholt wrote: > Hello, > > > > are you aware of the DMQ synchronisation for dialog data? It’s not > replicated everything, but certainly a way to seed the dialog information > after a restart. > > Another way is of course the usual shared database, just keep in mind that > you need to configure the dialog module (hash table “step” variables”) to > properly work. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > *From:* Calvin E. > *Sent:* Donnerstag, 8. Juni 2023 19:36 > *To:* Kamailio (SER) - Users Mailing List > *Subject:* [SR-Users] Dialog DMQ state after restart > > > > Does the dialog module do anything similar to the htable dmq_init_sync > behavior? > > > > The scenario is restarting the offline member of an HA pair after > modifying the script. We're unsure of the state of the replicated dialogs > post-restart. Will the standby become aware of the dialogs prior to the > restart? In other words, do we need to wait until the pre-restart calls end > before we can safely failover? > > > > -Calvin E. > __ 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] Dialog DMQ state after restart
Does the dialog module do anything similar to the htable dmq_init_sync behavior? The scenario is restarting the offline member of an HA pair after modifying the script. We're unsure of the state of the replicated dialogs post-restart. Will the standby become aware of the dialogs prior to the restart? In other words, do we need to wait until the pre-restart calls end before we can safely failover? -Calvin E. __ 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: Override listen advertise address
Hi Alex, You make a good point about the listener resources, however, all external traffic is being passed to internal resources so the load on them would be similar. I was more focused on having "one port for all traffic" and only one IP to move between HA hosts. It turns out that may require a lot of work for very little reward now that I know there are literally three people who would care about the port number for internal traffic. I'd still like to have this configuration, but other parties agreed they are just as happy with a two listener configuration using an alternate port. On Thu, May 25, 2023 at 7:25 AM Alex Balashov wrote: > Calvin, > > But if you are okay with having two listeners, remember that you can use > the `socket_workers`[1] configuration directive to limit the number of > worker processes associated with the lesser-utilised listener. > > This produces a simpler configuration while satisfying one's sense that > twice the listeners shouldn't incur twice the resource commitment, or > something like that. > > -- Alex > > [1] https://www.kamailio.org/wikidocs/cookbooks/5.6.x/core/#socket_workers > > > On May 23, 2023, at 2:09 AM, Daniel-Constantin Mierla > wrote: > > > > Hello, > > you can skip setting advertise for listen and try to play with > set_advertised_address() and record_route_preset() along with domain alias > for public address. > > Cheers, > > Daniel > > On 22.05.23 19:11, Calvin E. wrote: > >> Using 5.6.x, a scenario designed for a public IP now needs to support > life in the cloud behind NAT. I'd like to avoid having two listeners to > separate on-net from off-net traffic. In a HA scenario, it would be nice > to have only one floating IP. > >> > >> Is it possible to use the same local address and port for > external/public and internal/private traffic? > >> Should set_advertised_address() override the listen advertise address? > >> > >> Initial testing did not produce the expected result. I want to make > sure I'm following a sane pattern before going down a rabbit hole. The idea > is to toggle the advertised address by checking if the sender or recipient > is rfc1918(). > >> > >> For the dispatcher module, is it possible to use socket names like > below? In testing it appeared that only one of the two names was valid. > >> > >> listen=udp:10.0.0.10:5060 name "onnet" > >> listen=udp:10.0.0.10:5060 advertise 11.11.11.11:5060 name "offnet" > >> > >> > >> > >> __ > >> 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: > >> > > -- > > Daniel-Constantin Mierla -- www.asipto.com > > www.twitter.com/miconda -- www.linkedin.com/in/miconda > > Kamailio World Conference - June 5-7, 2023 - www.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: > > -- > 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] Override listen advertise address
Using 5.6.x, a scenario designed for a public IP now needs to support life in the cloud behind NAT. I'd like to avoid having two listeners to separate on-net from off-net traffic. In a HA scenario, it would be nice to have only one floating IP. Is it possible to use the same local address and port for external/public and internal/private traffic? Should set_advertised_address() override the listen advertise address? Initial testing did not produce the expected result. I want to make sure I'm following a sane pattern before going down a rabbit hole. The idea is to toggle the advertised address by checking if the sender or recipient is rfc1918(). For the dispatcher module, is it possible to use socket names like below? In testing it appeared that only one of the two names was valid. listen=udp:10.0.0.10:5060 name "onnet" listen=udp:10.0.0.10:5060 advertise 11.11.11.11:5060 name "offnet" __ 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: ICMP Port Unreachable using loopback interface with ethernet IP
We added a listen on localhost and forced the outside application server to return 127.0.0.1 instead of the IP of Kamailio. This worked as expected, but wasn't the solution we were looking for. It turns out that enabling sysctl net.ipv4.ip_forward=1 resolves the original issue. Is IP Forwarding a normal requirement for Kamailio in general? For reference, running "ip route get _interface_ip_" on other Linux servers confirms that the "lo" interface is used when sending packets to an assigned Ethernet IP address. On Thu, May 11, 2023 at 3:19 AM Henning Westerholt wrote: > Hello, > > > > usally there are not special requirements regarding the localhost. Is > kamailio actually listening on the localhost? You could check e.g. with > netstat or kamcmd/kamcli commands. > > > > Cheers, > > > > Henning > > > > *From:* Calvin E. > *Sent:* Dienstag, 9. Mai 2023 16:21 > *To:* sr-users@lists.kamailio.org > *Subject:* [SR-Users] ICMP Port Unreachable using loopback interface with > ethernet IP > > > > The scenario is Kamailio on Debian 11 talking to an external application > server that returns a 302 with a Contact that contains Kamailio's own IP > and a different port. Kamailio is listening on the correct port via at the > given IP address. However, when Kamailio creates the packet to talk to > itself, it it send over the loopback adapter "lo" and gets an ICMP port > reply: > > > > listen=udp:KAMAILIO_INTERNAL_FLOATING_IP: > > > > 10.z.a.b.5000 > 10.z.x.y.5060: SIP, length: 849 > SIP/2.0 302 Moved Temporarily > Contact: > > > > 15:39:00.548722 loIn IP (tos 0x10, ttl 64, id 5431, offset 0, flags > [none], proto UDP (17), length 949) > 10.z.x.y.5060 > 10.z.x.y.: SIP, length: 921 > 15:39:00.548732 loIn IP (tos 0xd0, ttl 64, id 19038, offset 0, flags > [none], proto ICMP (1), length 576) > 10.z.x.y > 10.z.x.y: ICMP 10.44.7.136 udp port unreachable, > length 556 > > > > Do I need to configure something in the OS or Kamailio to allow the > ethernet IP to work via the loopback adapter? I haven't set up any special > networking to cause this, it appears to be a Linux kernel behavior. > __ 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] ICMP Port Unreachable using loopback interface with ethernet IP
The scenario is Kamailio on Debian 11 talking to an external application server that returns a 302 with a Contact that contains Kamailio's own IP and a different port. Kamailio is listening on the correct port via at the given IP address. However, when Kamailio creates the packet to talk to itself, it it send over the loopback adapter "lo" and gets an ICMP port reply: listen=udp:KAMAILIO_INTERNAL_FLOATING_IP: 10.z.a.b.5000 > 10.z.x.y.5060: SIP, length: 849 SIP/2.0 302 Moved Temporarily Contact: 15:39:00.548722 loIn IP (tos 0x10, ttl 64, id 5431, offset 0, flags [none], proto UDP (17), length 949) 10.z.x.y.5060 > 10.z.x.y.: SIP, length: 921 15:39:00.548732 loIn IP (tos 0xd0, ttl 64, id 19038, offset 0, flags [none], proto ICMP (1), length 576) 10.z.x.y > 10.z.x.y: ICMP 10.44.7.136 udp port unreachable, length 556 Do I need to configure something in the OS or Kamailio to allow the ethernet IP to work via the loopback adapter? I haven't set up any special networking to cause this, it appears to be a Linux kernel behavior. __ 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] Rancher, AWS, and Elastic IP
I'm looking for documentation//howto/advice/best practices for running Kamailio under Kubernetes on AWS via Rancher. Specifically, how to manage the public/Elastic IP. This is a load balancer (dispatcher) scenario with rtpengine for receiving inbound calls from a DID provider, but a similar configuration might be used for clients. I'm open to using an AWS load balancer, and would like to scale with multiple Kamailio pods behind a single public IP. I'd rather use Rancher-managed EC2 than pay extra for EKS, unless EKS can cancel out its own cost. This sounds like it should be a solved problem, just complex. I see blogs and videos out there, but it's not always obvious if their content is current. Anyone want to help me peel this onion? -Calvin __ 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:
