sr-users May 2022

sr-users@lists.kamailio.org

49 participants
59 discussions

TLS connection failure. Not sure if system behavior is correct.
by Володимир Іванець 27 May '22

27 May '22

Hello all! My test Kamailio setup (now updated to version 5.5.4) that was working with MS Teams some time ago, now stopped :) I was wondering if someone could tell me if the current behavior is correct or if there is a problem? Here is a screenshot of the packet capture: [image: image.png] I thought that after MS Teams side sent Change Cipher Spec request, Kamailio should respond with ACK. But instead it just starts sending data (I believe it sends OPTIONS request. sipdump module captured it). Is this correct? There seems to be no issues in the Kamailio debug log: May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/io_wait.h:782]: io_watch_chg(): DBG: io_watch_chg (0xae9560, 24, 0x1, 0xffffffff) fd_no=20 called May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0xae9560, 25, -1, 0x0) fd_no=20 called May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/tcp_main.c:4471]: handle_tcpconn_ev(): sending to child, events 1 May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/tcp_main.c:4144]: send2child(): selected tcp worker idx:1 proc:11 pid:28972 for activity on [tls:172.16.30.206:5062], 0x7fad6a70f6c8 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_read.c:1737]: handle_io(): received n=8 con=0x7fad6a70f6c8, fd=6 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for SSL_CTX-0x7fad6a5e1eb8: (nil) May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_main.c:2720]: tcpconn_do_send(): sending... May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_main.c:2753]: tcpconn_do_send(): after real write: c= 0x7fad6a70f6c8 n=2279 fd=6 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_main.c:2754]: tcpconn_do_send(): buf= May 20 15:29:05 server kamailio[28961]: 7 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): processing io_watch_add(0xb555c0, 6, 2, 0x7fad6a70f6c8) - fd_no=1 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for SSL_CTX-0x7fad6a5e1eb8: (nil) May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_domain.c:790]: sr_ssl_ctx_info_callback(): SSL handshake done May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_domain.c:794]: sr_ssl_ctx_info_callback(): SSL disable renegotiation May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_server.c:542]: tls_connect(): TLS connect successful May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_server.c:549]: tls_connect(): tls_connect: new connection to 52.114.132.46:5061 using TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384 256 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_server.c:552]: tls_connect(): tls_connect: sending socket: 172.16.30.206:0 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_server.c:418]: tls_dump_cert_info(): tls_connect: server certificate subject:/CN=sip.pstnhub.microsoft.com May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls [tls_server.c:422]: tls_dump_cert_info(): tls_connect: server certificate issuer:/C=US/O=Microsoft Corporation/CN=Microsoft RSA TLS CA 01 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_main.c:2720]: tcpconn_do_send(): sending... May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_main.c:2753]: tcpconn_do_send(): after real write: c= 0x7fad6a70f6c8 n=509 fd=6 May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_main.c:2754]: tcpconn_do_send(): buf= May 20 15:29:05 server kamailio[28961]: ▒4▒▒▒▒.▒2T$-▒▒ o▒w)▒(▒▒^▒D▒U{xn9▒' ▒&▒t▒▒)▒▒?▒d▒=g▒▒?▒▒▒4/▒▒▒▒-R+▒tR▒H,▒o▒D2r ▒5Q?m▒▒9▒▒#▒O▒▒▒\eϣ▒݄"▒z=▒U▒? May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0xae9560, 24, -1, 0x0) fd_no=19 called May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/tcp_main.c:4471]: handle_tcpconn_ev(): sending to child, events 1 May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/tcp_main.c:4144]: send2child(): selected tcp worker idx:2 proc:12 pid:28973 for activity on [tls:172.16.30.206:5062], 0x7fad6a6f25a0 May 20 15:29:05 server kamailio[28961]: 12(28973) DEBUG: <core> [core/tcp_read.c:1737]: handle_io(): received n=8 con=0x7fad6a6f25a0, fd=6 May 20 15:29:05 server kamailio[28961]: 12(28973) DEBUG: tls [tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for SSL_CTX-0x7fad6a5e1eb8: (nil) May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_read.c:304]: tcp_read_data(): EOF on connection 0x7fad6a70f6c8 (state: 0, flags: 18) - FD 6, bytes 0, rd-flags 10000 ([52.114.132.46]:5061 -> [52.114.132.46]:0)11(28972) DEBUG: <coreTCP closed event creation triggered (reason: 0) May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_read.c:192]: tcp_emit_closed_event(): no callback registering for handling TCP closed event May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_read.c:1503]: tcp_read_req(): EOF May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0xb555c0, 6, -1, 0x10) fd_no=2 called May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_read.c:1878]: handle_io(): removing from list 0x7fad6a70f6c8 id 2 fd 6, state 2, flags 18, main fd 25, refcnt 2 ([52.114.132.46]:5061 -> [52.114.132.46]:0) May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_read.c:1659]: release_tcpconn(): releasing con 0x7fad6a70f6c8, state -1, fd=6, id=2 ([52.114.132.46]:5061 -> [52.114.132.46]:0) May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core> [core/tcp_read.c:1660]: release_tcpconn(): extra_data 0x7fad6a70f008 May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core> [core/tcp_main.c:3574]: handle_tcp_child(): reader response= 7fad6a70f6c8, -1 from 1 May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: tls [tls_server.c:729]: tls_h_tcpconn_close_f(): Closing SSL connection 0x7fad6a70f008 Thank you!

1 1

Debian: Kamailio: -> FIN - SYN -> on new port
by Kevin Browne 26 May '22

26 May '22

Hi, am looking for some specific Kamailio help i cant seem to find anywhere ( # running Kamailio on Debian/buster ... ## after receipt of tcp FIN, port is closed. when signaling is required again from Kamailio side. Kam is attempting SYN on FINd (closed) port. this is rejected RST. How to change SYN to re-establish tcp on new ephemeral port? ## another description, same problem: FIN received from (external) cisco (call owner) due to port recycling, not to keep port open after x minutes. everything is as expected re ACKs and such. When Kam wants to send REFER to cisco after the FIN, tcp attempts a SYN (as we'd expect) but sends SYN on old closed port. ## Where to change this Kam/OS/other is where i'm attempting to identify, then figure how to change. Thank you.

2 1

TOPOS + RE-INVITE problem - Contact IP not updated
by c c 24 May '22

24 May '22

It seems that TOPOS is not working properly on RE-INVITE and stop masking IP and contact on some RE-INVITE. When a RE-INVITE is send with Kamailio IP as Request-URI TOPOS is not operating. Note : we are using the HTABLE trick to rewrite $ru and match the call but we would need to have TOPOS re-evaluating the dialog once done. We use a standard configuration with 2 modifications. 1. in route[DISPATCH] to set the HTABLE if(is_method("INVITE")) { $sht(ct=>$ci::$ft) = $sel(contact.uri); } 1. in route[WITHINDLG] to find the call if R-URI = myself if(has_totag() && uri==myself) { if($sht(ct=>$ci::$ft) != $null && $T_reply_code > 400) $shtex(ct=>$ci::$ft) = 10 ; if($sht(ct=>$ci::$tt) != $null) { $ru = $sht(ct=>$ci::$tt); if (is_method("BYE")) $shtex(ct=>$ci::$tt) = 10 ; route(RELAY); } } As you can see in the PCAP the RE-INVITE goes directly to calling stating with the Contact not updated and the 200 OK is also sent to called party with wrong Contact info too. [ https://github.com/kamailio/kamailio/files/8730489/topos-issue.zip ] This behavior breaks the BYE procedure. Any advice ? Chris

2 1

Load balancer and consult transfer
by Anh Cao 24 May '22

24 May '22

Hi all, I'm building an simple PBX with 1 Kamailio as load balancer for several Asterisk servers. My issue is if an extension is in-call on Asterisk#1 wants to consult transfer to another number, it makes another call and Kamailio forward this new call to another Asterisk and cause call tranfer will fail. Does anyone here have tips or sugestions to resolve this? Thanks in advance for your help. Best regards

3 3

Kamailio v5.6.0 Released - new major version is out
by Daniel-Constantin Mierla 23 May '22

23 May '22

Kamailio v5.6.0 is out – it comes with 7 new modules and a considerable set of improvements touching again more than 90 existing modules. You can read detailed release notes at: * https://www.kamailio.org/w/kamailio-v5-6-0-release-notes/ Many thanks to all developers and community members that made possible this release. v5.6.0 brings more flexibility and optimizations across many components, plenty of new variables and transformations, load balancer enhancements, generic iterators for SIP headers and body lines, alternative http client, NATS PubSub connector, improvements to STIR/SHAKEN, IMS/VoLTE, rtpengine and tls as well as more functions exported to KEMI interface ... just to list only a few here. Enjoy Kamailio v5.5.0! Thank you for flying Kamailio! Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022 * https://www.asipto.com/sw/kamailio-advanced-training-online/

4 3

Releasing Kamailio v5.6.0
by Daniel-Constantin Mierla 23 May '22

23 May '22

Hello, with some effort directed lately to convert the wiki content to markdown files and host them on github, it's time to now to nail down the path to release nest major release for Kamailio, respectively v5.6.0. What's new in this major release as well as upgrade guidelines have to be built, but I hope to be done in time to release Kamailio v5.6.0 either on Monday, June 23, 2022 or on Wednesday, June 25, 2022. Should anyone consider a different release planning, let's discuss it. If anyone wants to help with them, the content has to be added to the github wiki repository: * https://github.com/kamailio/kamailio-wiki If not there, new files have to be created and linked from the main page. The wiki is built with mkdocs into html and made available for browsing at: * https://kamailio.org/wikidocs/ Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022 * https://www.asipto.com/sw/kamailio-advanced-training-online/

2 3

Re: [SR-Users] TLS connection failure. Not sure if system behavior is correct.
by Ahmed Fouad 22 May '22

22 May '22

Hi, You are currently using TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384 256 Teams stopped using TLSv1/ TLSv1.1 and only allowing TLS1.2+ So change your kamailio TLS settings to enforce only it method = TLSv1.2+ After restarting kamailio your team's connections should be good. -- Best Regards, Ahmed Fouad

1 0

LCR GW
by Antoine DEBARRE 20 May '22

20 May '22

Hi, Is there a way to specify an outbound proxy for just a few lcr gateways added in table lcr_gw ? Thanks in advance ! Antoine

2 6

Path MTU issues over UDP/IPv6
by Rick van Rein 20 May '22

20 May '22

Hello, IPv6 routers never fragment packets. Rather, they drop a packet that is too large for a (local) MTU and send back ICMPv6 "Packet Too Big". This seems to cause loss of larger SIP messages when an ISP tunnels their IPv6 at the expense of the MTU. The pmtu_discovery flag sets Don't Fragment in IPv4 traffic; in IPv6 this is an implied property. Does Kamailio learn a lower MTU from any "Packet Too Big" for IPv6 even if pmtu_discovery is not set? Future resends can then be fragemented appropriately. The udp_mtu setting diverts to another protocol, but that would be a setting as low as the worst peer, impacting all. It would be a weird struggle with a telco serving many. PMTU would be better to rely on, but how does it work in Kamailio? Details on https://www.rfc-editor.org/rfc/rfc3542#section-11.3 https://stackoverflow.com/questions/38817837/how-does-mtu-retransmission-wo… Thanks, -Rick

3 4

Forwarding SIP status code to HTTP client
by Tim Anderson 19 May '22

19 May '22

Hi, I have a kamailio that is has an HTTP message server. Is it possible to send the SIP status code back in the HTTP reply? Is it possible to suspend an xhttp request while some other stuff happens and then send the reply later? The relevant bit of the config currently looks like event_route[xhttp:request]{ if($hu == "/sms"){ $uac_req(method)="MESSAGE"; $uac_req(ruri)="sip:1234@example.com"; $uac_req(furi)="sip:4567@example.com"; $uac_req(turi)="sip:1234@example.com"; $uac_req(body)=$rb; uac_req_send(); xhttp_reply("200", "OK", "text/plain", "Sent") } } Regards, Tim

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users May 2022