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

[Joel Serrano via sr-users]

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

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

[Calvin E. via sr-users]

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

[SR-Users] Re: from TCP to UDP and Kamailio doing it wrong

[Alex Balashov via sr-users]

if(proto == TCP)
$ru = $(ru{s.replace,transport=TCP,}{s.replace,transport=tcp,});

...

t_relay();

-- Alex

> On 7 Mar 2024, at 10:46, Alberto Diez via sr-users 
>  wrote:
> 
> Hi kamailio community,
> 
> I have an issue with a Kamailio 5.7. It's listening both in TCP and UDP.  In 
> my scenario requests arrive from devices on TCP, but I want to forward to the 
> next hops on UDP.  I am avoiding using any type of DNS resolution; since I am 
> always forwarding to predefined next hops I am using the dispatcher module 
> (defined with the IP addresses and transport=udp) or I wrote config files 
> using t_relay_to_udp or t_relay_to with a udp:  followed by IP address. I 
> never set up FQDNS only IP addresses and in all of them I explicitly mention 
> UDP.
> 
> In all of these scenarios I have tried Kamailio insists in trying to use TCP  
> with the next hop and failing because the next_hop is only UDP. I guess 
> because the message arrived using TCP Kamilio does that but I find the 
> behavior very confusing.
> 
> I nailed down that in my situation its the tm module function prepare_new_uac 
> (in  file src/modules/tm/t_fwd.c line 119) being the one that missbehaves. 
> The documentation of the function says literraly :
> 
> "* t->uac[branch].request.dst will be filled if next_hop !=0 with the result
>  * of the DNS resolution (next_hop, fproto and fsocket).
>  * If next_hop is 0 all the dst members except the send_flags are read-only
>  * (send_flags it's updated) and are supposed to be pre-filled."
> 
> I found out that even when next_hop is 0  the function changes the 
> t->uac[branch].request.dst  proto, socket etc.  its there that the kamailio 
> takes the wrong decision, until that function is called within add_auc,  the 
> destination proto or the fproto etc is always 1 (UDP) which is what I am 
> trying to force from the config file or the dispatcher definition (I tried 
> both ways).  But after calling that function then it comes as a 2 (TCP)
> 
> The problematic function is a monster of 500 lines and I would like to avoid 
> having to understand it. Since I think the scenario is not so unusual I just 
> want to ask if maybe I am missing something that I should do to avoid the 
> Kamailio to select TCP and in order to have the tm module respecting my 
> preference for UDP (either with dispatcher module and the transport param or 
> with t_relay_to or t_relay_to_udp  I don't care the way).
> 
> Any hints are welcome.
> 
> Best regards
> 
> alberto
> 
> __
> 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: from TCP to UDP and Kamailio doing it wrong

[Alex Balashov via sr-users]

If you just strip the incoming ;transport=tcp attribute, I think all should be 
well when t_relay() consumes the modified RURI.

> On 7 Mar 2024, at 12:48, Alberto Diez via sr-users 
>  wrote:
> 
> Hi Sergiu,
> yes I am pretty sure something is going wrong.
> I do have kamailio listening udp sockets and also the dispatcher is on UDP 
> doing SIP OPTIONS over UDP all the time without any problem.
> I have not tried forcing the socket I tried to find out why kamailio is 
> trying to use TCP with the targets even when I use t_relay_to_udp and that's 
> how I ended up finding that function which claims not to do something if 
> next_hop is 0 but doing it nevertheless (which I guess is something going 
> wrong in general in Kamailio not in particular in my setup).
> I will try forcing the socket, but that crazy tm module function rewrites the 
> socket was already given as a destination (yes I already checked that in the 
> C code before!)
> Best regards
> alberto
> El 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
>> You must be doing something essentially wrong if it came down to checking C 
>> functions for something as trivial as transport conversion..
>> 
>> Are you sure you have a UDP listening socket?
>> kamcmd corex.list_sockets
>> 
>> Result of:
>> kamcmd dispatcher.list
>> 
>> Have you tried forcing the send socket?
>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_forced_send_socket
>> 
>> Cheers
>> 
>> On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users 
>>  wrote:
>> Hi kamailio community,
>> 
>> I have an issue with a Kamailio 5.7. It's listening both in TCP and 
>> UDP.  In my scenario requests arrive from devices on TCP, but I want to 
>> forward to the next hops on UDP.  I am avoiding using any type of DNS 
>> resolution; since I am always forwarding to predefined next hops I am 
>> using the dispatcher module (defined with the IP addresses and 
>> transport=udp) or I wrote config files using t_relay_to_udp or 
>> t_relay_to with a udp:  followed by IP address. I never set up FQDNS 
>> only IP addresses and in all of them I explicitly mention UDP.
>> 
>> In all of these scenarios I have tried Kamailio insists in trying to use 
>> TCP  with the next hop and failing because the next_hop is only UDP. I 
>> guess because the message arrived using TCP Kamilio does that but I find 
>> the behavior very confusing.
>> 
>> I nailed down that in my situation its the tm module function 
>> prepare_new_uac (in  file src/modules/tm/t_fwd.c line 119) being the one 
>> that missbehaves. The documentation of the function says literraly :
>> 
>> "* t->uac[branch].request.dst will be filled if next_hop !=0 with the result
>>   * of the DNS resolution (next_hop, fproto and fsocket).
>>   * If next_hop is 0 all the dst members except the send_flags are read-only
>>   * (send_flags it's updated) and are supposed to be pre-filled."
>> 
>> I found out that even when next_hop is 0  the function changes the 
>> t->uac[branch].request.dst  proto, socket etc.  its there that the 
>> kamailio takes the wrong decision, until that function is called within 
>> add_auc,  the destination proto or the fproto etc is always 1 (UDP) 
>> which is what I am trying to force from the config file or the 
>> dispatcher definition (I tried both ways).  But after calling that 
>> function then it comes as a 2 (TCP)
>> 
>> The problematic function is a monster of 500 lines and I would like to 
>> avoid having to understand it. Since I think the scenario is not so 
>> unusual I just want to ask if maybe I am missing something that I should 
>> do to avoid the Kamailio to select TCP and in order to have the tm 
>> module respecting my preference for UDP (either with dispatcher module 
>> and the transport param or with t_relay_to or t_relay_to_udp  I don't 
>> care the way).
>> 
>> Any hints are welcome.
>> 
>> Best regards
>> 
>> alberto
>> 
>> __
>> 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:

-- 
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: direct media between UACs

[Sergio Charrua via sr-users]

I have found the issue! For future reference, here is the explanation.

The JSON object returned from the Routing Logique Engine is the standard
object as per module's description, but with the "extra" property filled
with an extra header value.
The resulting SIP Message is :

INVITE sip:129292929@10.20.0.3:5060 SIP/2.0
Record-Route: 
Via: SIP/2.0/UDP 10.20.0.5:5060
;branch=z9hG4bK9eda.8923b369b80093ea0deadbf4aacfbe87.1
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK7b6c14db
Max-Forwards: 69
From: "Anonymous" ;tag=as0f86b6e9
To: 
Contact: 
Call-ID: 53d119be3283ab831a41827011395c9f@10.20.0.1:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.38.3
Date: Thu, 07 Mar 2024 17:16:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 270
*ExtraHdr*: testing
v=0
o=root 1450091166 1450091166 IN IP4 10.20.0.1
s=Asterisk PBX 13.38.3
c=IN IP4 10.20.0.1
t=0 0
m=audio 10570 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


As you may observe, the extra tag is "*ExtraHdr*: testing" which is here
purely for testing and not used at all!

However, as you may have guessed, the Header part (SIP) and the Body part
(SDP) have no blank line to separate both parts.
This is what was causing the issue! Asterisk (and probably any endpoint)
would not parse the message correctly and fail to initiate RTP audio!

Looking at the documentation, RTJSON Module (kamailio.org)
 , at the end
of the page, the JSON used as an example *does *include \r\n at the end of
the extra header value.
But nowhere in the page it is mentioned that the extra value should end
with a \r\n symbol !
In fact, the extra header could contain multiple values separated by \r\n,
as for example (found in documentation):

"extra": "X-Hdr-A: abc\r\nX-Hdr-B: bcd\r\n"

clearly mentioned in the example of JSON object, in the documentation,
which would result in SIP header containing the following lines:

[...]
Content-Type: application/sdp
Content-Length: 270
X-Hdr-A: abc
X-Hdr-B: bcd

v=0
o=root 1450091166 1450091166 IN IP4 10.20.0.1
[...]


It probably should be common knowledge, I will accept that, but the order
of how and when the extra header is added to the SIP message is not
mentioned, nor it is said that Kamailio will automatically add a \r\n at
the end of each extra header value.

I would like to humbly suggest to mention in the document that any extra
header should always end with \r\n symbol because it will be added at the
end of the SIP Header, which requires a blank line to separate from the SIP
Body.

Hope this helps someone out there!

Cheers!

*Sérgio Charrua*






On Thu, Mar 7, 2024 at 3:44 PM Sergio Charrua 
wrote:

> Hi all!
>
> some additional details for this issue.
>
> Currently, Kamailio is using RTJSON to get routes from the routing engine
> and forward calls to the correct route.
> Please note that the 2 testing endpoints and Kamailio are all in the same
> network, no NAT involved, and firewalls are disabled!
>
> Following route function does the magic:
>
> route[TOCARRIER]{   #Route to send calls to a carrier at
> 192.168.200.130
> route(RELAY_API);   #Route relay
> }
>
> route[RELAY_API]{
># makes the HTTP Assync request
> .
># once response is received from HTTP REST API, go to
> RELAY_API_RESPONSE
> .
> }
>
> # Relay request using the API (response)
> route[RELAY_API_RESPONSE] {
>
> if ($http_ok==1 && $http_rs==200)
> {
>
> xlog("L_INFO","RELAY_API_RESPONSE - RESPONSE: $http_rb\n");
>
> if (jansson_get("rtjson", $http_rb, "$var(rtjson)"))
> {
>
> xlog("L_INFO","RELAY_API_RESPONSE - $var(rtjson)");
>
> rtjson_init_routes("$var(rtjson)");
>
> rtjson_push_routes();
>
> # relay the message
>
> t_on_branch("MANAGE_BRANCH");
>
> t_on_failure("MANAGE_FAILURE");
>
> route(RELAY);
>
> return;
>
> }
>
> }
>
> }
>
> This is working correctly.
> However, as mentioned in previous email, when the call is forwarded to the
> endpoint  using RTJSON module (and for testing purposes, we are using
> Asterisk 13.38.x as an endpoint), it results in a one-way audio issue: A
> Leg sends Audio Streams correctly directly to B Leg (direct media) but B
> Leg seems to not sending any audio, even though both endpoints are playing
> some Music On Hold stuff.
> Even TCPDUMP shows no RTP traffic from B to A, but can find traffic from A
> to B!
>
> What I found out is that if I modify RELAY_API route to be as follows:
>
> route[TOCARRIER]{
>
> rewritehost("10.20.0.3");#Rewrite host to be the endpoint's IP
>
> route(RELAY);
>
> }
>
>
> The audio streams are fully working, both ways! TCPDUMP shows audio
> traffic both ways, no issues!
> The SIP Traces show the same structure, both for SIP and SDP (of course,
> CallID, BranchID and RURI are different), so I think 

[SR-Users] Re: from TCP to UDP and Kamailio doing it wrong

[Alberto Diez via sr-users]

Hi Sergiu,

yes I am pretty sure something is going wrong.

I do have kamailio listening udp sockets and also the dispatcher is on 
UDP doing SIP OPTIONS over UDP all the time without any problem.


I have not tried forcing the socket I tried to find out why kamailio is 
trying to use TCP with the targets even when I use t_relay_to_udp and 
that's how I ended up finding that function which claims not to do 
something if next_hop is 0 but doing it nevertheless (which I guess is 
something going wrong in general in Kamailio not in particular in my setup).


I will try forcing the socket, but that crazy tm module function 
rewrites the socket was already given as a destination (yes I already 
checked that in the C code before!)


Best regards

alberto

El 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
You must be doing something essentially wrong if it came down to 
checking C functions for something as trivial as transport conversion..


Are you sure you have a UDP listening socket?
kamcmd corex.list_sockets

Result of:
kamcmd dispatcher.list

Have you tried forcing the send socket?
https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_forced_send_socket

Cheers

On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users 
 wrote:


Hi kamailio community,

I have an issue with a Kamailio 5.7. It's listening both in TCP and
UDP.  In my scenario requests arrive from devices on TCP, but I
want to
forward to the next hops on UDP.  I am avoiding using any type of DNS
resolution; since I am always forwarding to predefined next hops I am
using the dispatcher module (defined with the IP addresses and
transport=udp) or I wrote config files using t_relay_to_udp or
t_relay_to with a udp:  followed by IP address. I never set up FQDNS
only IP addresses and in all of them I explicitly mention UDP.

In all of these scenarios I have tried Kamailio insists in trying
to use
TCP  with the next hop and failing because the next_hop is only
UDP. I
guess because the message arrived using TCP Kamilio does that but
I find
the behavior very confusing.

I nailed down that in my situation its the tm module function
prepare_new_uac (in  file src/modules/tm/t_fwd.c line 119) being
the one
that missbehaves. The documentation of the function says literraly :

"* t->uac[branch].request.dst will be filled if next_hop !=0 with
the result
  * of the DNS resolution (next_hop, fproto and fsocket).
  * If next_hop is 0 all the dst members except the send_flags are
read-only
  * (send_flags it's updated) and are supposed to be pre-filled."

I found out that even when next_hop is 0  the function changes the
t->uac[branch].request.dst  proto, socket etc.  its there that the
kamailio takes the wrong decision, until that function is called
within
add_auc,  the destination proto or the fproto etc is always 1 (UDP)
which is what I am trying to force from the config file or the
dispatcher definition (I tried both ways).  But after calling that
function then it comes as a 2 (TCP)

The problematic function is a monster of 500 lines and I would
like to
avoid having to understand it. Since I think the scenario is not so
unusual I just want to ask if maybe I am missing something that I
should
do to avoid the Kamailio to select TCP and in order to have the tm
module respecting my preference for UDP (either with dispatcher
module
and the transport param or with t_relay_to or t_relay_to_udp I don't
care the way).

Any hints are welcome.

Best regards

alberto

__
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: from TCP to UDP and Kamailio doing it wrong

[Sergiu Pojoga via sr-users]

You must be doing something essentially wrong if it came down to checking C
functions for something as trivial as transport conversion..

Are you sure you have a UDP listening socket?
kamcmd corex.list_sockets

Result of:
kamcmd dispatcher.list

Have you tried forcing the send socket?
https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_forced_send_socket

Cheers

On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users <
sr-users@lists.kamailio.org> wrote:

> Hi kamailio community,
>
> I have an issue with a Kamailio 5.7. It's listening both in TCP and
> UDP.  In my scenario requests arrive from devices on TCP, but I want to
> forward to the next hops on UDP.  I am avoiding using any type of DNS
> resolution; since I am always forwarding to predefined next hops I am
> using the dispatcher module (defined with the IP addresses and
> transport=udp) or I wrote config files using t_relay_to_udp or
> t_relay_to with a udp:  followed by IP address. I never set up FQDNS
> only IP addresses and in all of them I explicitly mention UDP.
>
> In all of these scenarios I have tried Kamailio insists in trying to use
> TCP  with the next hop and failing because the next_hop is only UDP. I
> guess because the message arrived using TCP Kamilio does that but I find
> the behavior very confusing.
>
> I nailed down that in my situation its the tm module function
> prepare_new_uac (in  file src/modules/tm/t_fwd.c line 119) being the one
> that missbehaves. The documentation of the function says literraly :
>
> "* t->uac[branch].request.dst will be filled if next_hop !=0 with the
> result
>   * of the DNS resolution (next_hop, fproto and fsocket).
>   * If next_hop is 0 all the dst members except the send_flags are
> read-only
>   * (send_flags it's updated) and are supposed to be pre-filled."
>
> I found out that even when next_hop is 0  the function changes the
> t->uac[branch].request.dst  proto, socket etc.  its there that the
> kamailio takes the wrong decision, until that function is called within
> add_auc,  the destination proto or the fproto etc is always 1 (UDP)
> which is what I am trying to force from the config file or the
> dispatcher definition (I tried both ways).  But after calling that
> function then it comes as a 2 (TCP)
>
> The problematic function is a monster of 500 lines and I would like to
> avoid having to understand it. Since I think the scenario is not so
> unusual I just want to ask if maybe I am missing something that I should
> do to avoid the Kamailio to select TCP and in order to have the tm
> module respecting my preference for UDP (either with dispatcher module
> and the transport param or with t_relay_to or t_relay_to_udp  I don't
> care the way).
>
> Any hints are welcome.
>
> Best regards
>
> alberto
>
> __
> 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] from TCP to UDP and Kamailio doing it wrong

[Alberto Diez via sr-users]

Hi kamailio community,

I have an issue with a Kamailio 5.7. It's listening both in TCP and 
UDP.  In my scenario requests arrive from devices on TCP, but I want to 
forward to the next hops on UDP.  I am avoiding using any type of DNS 
resolution; since I am always forwarding to predefined next hops I am 
using the dispatcher module (defined with the IP addresses and 
transport=udp) or I wrote config files using t_relay_to_udp or 
t_relay_to with a udp:  followed by IP address. I never set up FQDNS 
only IP addresses and in all of them I explicitly mention UDP.


In all of these scenarios I have tried Kamailio insists in trying to use 
TCP  with the next hop and failing because the next_hop is only UDP. I 
guess because the message arrived using TCP Kamilio does that but I find 
the behavior very confusing.


I nailed down that in my situation its the tm module function 
prepare_new_uac (in  file src/modules/tm/t_fwd.c line 119) being the one 
that missbehaves. The documentation of the function says literraly :


"* t->uac[branch].request.dst will be filled if next_hop !=0 with the result
 * of the DNS resolution (next_hop, fproto and fsocket).
 * If next_hop is 0 all the dst members except the send_flags are read-only
 * (send_flags it's updated) and are supposed to be pre-filled."

I found out that even when next_hop is 0  the function changes the 
t->uac[branch].request.dst  proto, socket etc.  its there that the 
kamailio takes the wrong decision, until that function is called within 
add_auc,  the destination proto or the fproto etc is always 1 (UDP) 
which is what I am trying to force from the config file or the 
dispatcher definition (I tried both ways).  But after calling that 
function then it comes as a 2 (TCP)


The problematic function is a monster of 500 lines and I would like to 
avoid having to understand it. Since I think the scenario is not so 
unusual I just want to ask if maybe I am missing something that I should 
do to avoid the Kamailio to select TCP and in order to have the tm 
module respecting my preference for UDP (either with dispatcher module 
and the transport param or with t_relay_to or t_relay_to_udp  I don't 
care the way).


Any hints are welcome.

Best regards

alberto

__
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: direct media between UACs

[Sergio Charrua via sr-users]

Hi all!

some additional details for this issue.

Currently, Kamailio is using RTJSON to get routes from the routing engine
and forward calls to the correct route.
Please note that the 2 testing endpoints and Kamailio are all in the same
network, no NAT involved, and firewalls are disabled!

Following route function does the magic:

route[TOCARRIER]{   #Route to send calls to a carrier at 192.168.200.130
route(RELAY_API);   #Route relay
}

route[RELAY_API]{
   # makes the HTTP Assync request
.
   # once response is received from HTTP REST API, go to RELAY_API_RESPONSE
.
}

# Relay request using the API (response)
route[RELAY_API_RESPONSE] {

if ($http_ok==1 && $http_rs==200)
{

xlog("L_INFO","RELAY_API_RESPONSE - RESPONSE: $http_rb\n");

if (jansson_get("rtjson", $http_rb, "$var(rtjson)"))
{

xlog("L_INFO","RELAY_API_RESPONSE - $var(rtjson)");

rtjson_init_routes("$var(rtjson)");

rtjson_push_routes();

# relay the message

t_on_branch("MANAGE_BRANCH");

t_on_failure("MANAGE_FAILURE");

route(RELAY);

return;

}

}

}

This is working correctly.
However, as mentioned in previous email, when the call is forwarded to the
endpoint  using RTJSON module (and for testing purposes, we are using
Asterisk 13.38.x as an endpoint), it results in a one-way audio issue: A
Leg sends Audio Streams correctly directly to B Leg (direct media) but B
Leg seems to not sending any audio, even though both endpoints are playing
some Music On Hold stuff.
Even TCPDUMP shows no RTP traffic from B to A, but can find traffic from A
to B!

What I found out is that if I modify RELAY_API route to be as follows:

route[TOCARRIER]{

rewritehost("10.20.0.3");#Rewrite host to be the endpoint's IP

route(RELAY);

}


The audio streams are fully working, both ways! TCPDUMP shows audio traffic
both ways, no issues!
The SIP Traces show the same structure, both for SIP and SDP (of course,
CallID, BranchID and RURI are different), so I think the issue is *not*
within endpoints, but somewhere in Kamailio (module or configuration).

Any suggestions?

*Sérgio Charrua*



On Tue, Mar 5, 2024 at 1:05 PM Sergio Charrua 
wrote:

> Hi all!
>
> got a weird behavior that I cannot understand the reason for...
> In our LAB environment, we have 2 Asterisk instances (version 13.38.3
> and chan_sip) and 1 Kamailio 5.7 in between.
> All servers are in the same network, so, there is no NAT involved. No
> RTPEngine either.
> Network is 10.20.0.0/24 and Asterisk #1 has IP .1  Asterisk #2 has IP
> .3 and Kamailio has IP .5
>
> The Asterisk servers are used only for testing, nothing serious.
> However, Kamailio is setup to use RTJson requesting routes to a
> Routing Server on the same network. And it works fine.
>
> Both Asterisk servers have the same dialplan, which only Answers the
> call and plays MOH on both ends so that RTP audio streams both ways.
>
> When making a call on Asterisk Server #1 via command line to go
> directly to Asterisk Server #2 without using Kamailio (CLI> channel
> originate SIP/123@10.20.0.3 application MusicOnHold() ) the Asterisk
> #2 receives the call, answers and plays MOH too and I can see RTP
> streams coming from both ends correctly.
>
> However, if I use Kamailio to proxy the call generated from Asterisk
> #1 to Asterisk #2, using similar command line instruction (CLI>
> channel originate SIP/123@10.20.0.5 application MusicOnHold() ), the
> call is indeed received on Kamailio who then sends it to Asterisk #2,
> who answers the call and plays MOH, *but* despite the audio stream
> being sent to Asterisk #1 it is never received, however audio from
> Asterisk #1 is received by Asterisk #2, which configures a typical One
> Way Audio issue due to NAT.
> This is where it gets strange, because there is no NAT, SDP on INVITE
> and SIP 200 messages seem OK, as far as I understand it.
> Also, Asterisk servers have SIP configuration with directmedia enabled
> and NAT disabled to make sure that media is direct. But I have also
> tried with directmedia disabled and NAT enabled and get identical
> results.
>
> I am most probably missing some tiny detail, but I have no clue
> and I bet it is simple and stupid
>
> Could another pair of eyes help me with this? What is wrong? Do I
> really need RTPEngine even when the network has no NAT? I am sure it
> would work that way, but it doesn't make sense...
>
> Here are some screenshots:
>
> Call Scenario #1 - direct call from Asterisk #1 to Asterisk #2 without
> Kamailio in between:
>
> Invite from Asterisk #1 to Asterisk #2 with direct media between both ends:
>
> https://drive.google.com/file/d/1eLjT3nr_Rc-UBaf4QhIgZ95bjETOVvxo/view?usp=drive_link
>
> Replies from Asterisk #2 to Asterisk #1 with direct media between both
> ends:
>
> https://drive.google.com/file/d/11lLcB-V8rWGSrVqWiit-q9WX2FfqB6BZ/view?usp=drive_link
>
> Call Scenario #2 - call from Asterisk #1 using Kamailio to relay call
> to Asterisk #2, with one way audio
> Invite from Asterisk #1 to 

[SR-Users] Kamailio v5.8.0 Released - new major version is out

[Daniel-Constantin Mierla via sr-users]

Kamailio v5.8.0 is out – it comes with 4 new modules and a large set of
improvements touching again more than 50 existing modules.

You can read a bit more detailed release notes at:

   * https://www.kamailio.org/w/kamailio-v5-8-0-release-notes/

Many thanks to all developers and community members that made possible
this release.

v5.8.0 brings more flexibility and optimizations across many existing
components and modules, new parameters, functions, variables and
transformations.

Enjoy Kamailio v5.8.0!

Thank you for flying Kamailio!
Daniel

-- 
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: Using uac_replace_to when forwarding call to another endpoint

[Alex Balashov via sr-users]

> On 7 Mar 2024, at 06:25, Marrold via sr-users  
> wrote:
> 
> After digging through old mailing posts I've been able to resolve this by 
> applying the changes in the BRANCH route. This fixes the corruption, although 
> the logs still show a warning for applying it twice.

This is the way. :-) 

-- 
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: Using uac_replace_to when forwarding call to another endpoint

[Marrold via sr-users]

After digging through old mailing posts I've been able to resolve this by
applying the changes in the BRANCH route. This fixes the corruption,
although the logs still show a warning for applying it twice.

Cheers

On Thu, 7 Mar 2024 at 09:23, Benoit Panizzon  wrote:

> Hi Matthew
>
> > However in my scenario I wish to first try one endpoint and then if it
> gets
> > a 4XX response forward it to another UAC, and update the TO accordingly.
> >
> > Currently trying to call  uac_replace_to twice shows an error and
> corrupts
> > the TO header. Is there a work around for this?
>
> I have no solution, but the same issue. (at the moment more or less
> solved by heavily using dialog variables).
>
> Example scenario showing the issue: Numbers are in e164 format, but
> towards the customer, shall be translated in localized format and
> privacy observed. Assume customer has Call forward on busy active.
>
> So the steps towards the issue are:
>
> * Translate numbers from e164 to local
> * If privacy: id replace numbers and display name with 'anonymous'
> * branch to customer
> * uac_replace
> * Manage reply: 486 busy
> ** Add diversion header ;reason=busy
> ** Add CFW destination RURI
> ** dispatch back to routing core.
>
> Towards core, I would need to revert uac_replace and use the original
> headers again.
>
> 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: Using uac_replace_to when forwarding call to another endpoint

[Benoit Panizzon via sr-users]

Hi Matthew

> However in my scenario I wish to first try one endpoint and then if it gets
> a 4XX response forward it to another UAC, and update the TO accordingly.
> 
> Currently trying to call  uac_replace_to twice shows an error and corrupts
> the TO header. Is there a work around for this?

I have no solution, but the same issue. (at the moment more or less
solved by heavily using dialog variables).

Example scenario showing the issue: Numbers are in e164 format, but
towards the customer, shall be translated in localized format and
privacy observed. Assume customer has Call forward on busy active.

So the steps towards the issue are:

* Translate numbers from e164 to local
* If privacy: id replace numbers and display name with 'anonymous'
* branch to customer
* uac_replace
* Manage reply: 486 busy
** Add diversion header ;reason=busy
** Add CFW destination RURI
** dispatch back to routing core.

Towards core, I would need to revert uac_replace and use the original
headers again.

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: Roadmap to next major Kamailio release series v5.8.x

[Daniel-Constantin Mierla via sr-users]

Hello,

short notification that v5.8.0 is going to be released today, therefore
any commits to branch 5.8 have to be announced to sr-dev and wait for
the ack before pushing to git repository in order to avoid conflicts
with the release building process. Once the announcement is out, commits
can be pushed to branch 5.8 as usual.

Cheers,
Daniel

On 06.03.24 07:56, Daniel-Constantin Mierla wrote:
> Hello,
>
> with still some docs to be updated for v5.8.0, the plan is to get the
> new version out tomorrow, March 7, 2024.
>
> Cheers,
> Daniel
>
> On 27.02.24 16:49, Daniel-Constantin Mierla 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)
>> 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
>>
> -- 
> 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
>
-- 
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: