sr-users November 2019

sr-users@lists.kamailio.org

67 participants
100 discussions

Via header force change protocol to TLS?
by Anthony Alba 30 May '24

30 May '24

I have kamailio behind a TLS termination proxy so the sockets are correctly deduced to be TCP. However the clients only talk TLS to the proxy and are confused when the top Via header added by Kamailio is TCP. Is there a way for Kamailio to forcibly pretend its protocol is TLS? Like advertised_address but "advertised_protocol" instead. (With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio and continues to use the persistent TLS transport to proxy. Linphone fails because it tries to honor TCP in Via and is unable to establish TCP transport). BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy as TCP even though the contact addresses specify transport=TLS.

4 10

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
by Daniel Tryba 02 May '23

02 May '23

On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote: > Sure. Attached. Problem appears to be that the topos query can't find > callid-totag (from the response). > > I'll try the same scenario with the mysql backend to see if it behaves > different. Config works fine with mysql as topos backend. So the bug is restricted to topos-redis.

5 19

Re: [SR-Users] t_drop_replies not working with t_suspend in failure route
by Huber Andreas 03 Sep '21

03 Sep '21

Hi, We’re still using kamailio 4.4 but we’ll be migrating to 5.0 soon. Cool so it will be fixed when we migrate ! Thanks, Andreas From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Federico Cabiddu Sent: vendredi 12 mai 2017 11:56 To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] t_drop_replies not working with t_suspend in failure route Hi, which version are you using? A similar case had been reported some months ago and it should be fixed in 5.0. Regards, Federico On Fri, May 12, 2017 at 11:44 AM, Huber Andreas <andreas.huber(a)nagra.com<mailto:andreas.huber@nagra.com>> wrote: Hello, We have a use case where we suspend a transaction in a failure_route to give UEs that might be woken by a push notification more time to REGISTER and join the INVITE. We’d like to drop the previous branches in this case. I tried using t_drop_replies() but it has no effect. The doc states that t_drop_replies() is only working if a new branch is added. And from my understanding t_suspend() adds a new branch. But is it possible that t_drop_replies() cannot be used with t_suspend()? Or am I missing something? Kind Regards, Andreas _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

2 1

Rewrite BYE to Cancel
by Lars Olsson 29 Sep '20

29 Sep '20

hi, I have a Kamailio setup infront of a SIP system that do not handle cancellation of a INVITE correctly. The system sends out a BYE request instead of a Cancel request on non connected dialogs. I am trying to find a way to let Kamailio "translate" the BYE request to a Cancel reqeust for the ongoing INVITE dialog. Alternative if SEMS b2bua can do it, but currently it replies: "not sip-relaying BYE in not connected dlg", and I have not found any obvious way to rewrite it there. Any thoughts. I can not change the behavior of the remote system. Best Regards, Lars

3 11

RTP port range in kuberenetes for kamailio
by Gaurav Bmotra 08 Jun '20

08 Jun '20

hi i have issue audio issue with kamailio in kubernetse cluster anybody , idea how to fix it in kubernetses thank you -- *Regards:* Gaurav Kumar

3 4

nat_uac_test(8)
by Sergiu Pojoga 24 Apr '20

24 Apr '20

When receiving an INVITE over a specific LTE carrier, I'm seeing 'c=IN IP4 192.0.0.4' in SDP, which isn't technically a RFC1918 or RFC6598 IP address and thus nat_uac_test(8) fails. What elegant workaround can be done to catch such specific cases? Thanks.

5 11

Problem with max tcp connections
by Jose Fco. Irles Durá 06 Apr '20

06 Apr '20

Hi I have a kamailio 5.1.2 as load balancer and registration offloading, but I have a problem with the max tcp connections that it can handle. I suspect that is a linux limit, but I don't find the reason or config. When that limit arrives, I can't connect to kamailio and I receive "Connection reset by peer", but I can't view any error message in the logs. If I check the connections in kamailio, I view that it have "free" connections: # kamctl kamcmd core.tcp_info { readers: 8 max_connections: 4096 max_tls_connections: 2048 opened_connections: 2655 opened_tls_connections: 0 write_queued_bytes: 0 } I have this configs in kamailio.conf (related to tcp) disable_tcp=no tcp_connection_lifetime=3610 tcp_connect_timeout=5 tcp_crlf_ping=yes tcp_accept_aliases=no tcp_keepalive=yes tcp_keepidle=5 tcp_rd_buf_size=65536 tcp_conn_wq_max=131072 mlock_pages=yes shm_force_alloc=yes tcp_max_connections=4096 The shm memory to 256 and the pkg memory to 32. And, following this doc: https://github.com/kamailio/kamailio/blob/master/doc/tutorials/tcp_tunning.… I have setted this values: net.ipv4.ip_local_port_range = 1024 65535 net.core.somaxconn = 65535 net.core.netdev_max_backlog = 182757 Also, I had checked the limits for the main process pid: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes unlimited unlimited processes Max open files 1048576 1048576 files Max locked memory 16777216 16777216 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 386297 386297 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us The service is running inside a lxc container, without any resource limit, connected to the outside word throught macvlan interface. Where can I find problem source? Best regards

4 13

need help with RTPProxy in bridged mode
by Grant Bagdasarian 04 Apr '20

04 Apr '20

Hello, I'm using RTPproxy for the first time in bridged mode and I can't get kamailio/rtpproxy to rewrite the c parameter to the correct public ip address of kamailio. The setup is as following: Carrier ------[fiber]------ Kamailio ---------[lan]--------- Freeswitch Kamailio is listening on two interfaces: 1) Private: 172.0.0.1 2) Public: 192.168.0.1 (since we have a dedicated fiber with our carrier, this is its public address) Freeswitch is listening on: 1) 172.0.0.2 Carrier is on: 1) 10.0.0.1 I've started an rtpproxy instance on the Kamailio box using: rtpproxy -s udp:127.0.0.1:7721 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.0.1 172.0.0.1 I've played around with rtpproxy_manage() and the various flags (ie, ei), but I can't get kamailio to set the correct public IP when the 200 OK has to be sent back to the carrier. It always sets it to its private address, instead of its public address. I'm using Kamailio 4.2 with sippy/rtpproxy 2.0. Could someone please point me into the right direction? Thanks! Grant

4 8

Kamailio OPTIONS Round-Trip
by Soltanici Ilie 27 Mar '20

27 Mar '20

Hi, With Asterisk, we are able to get some peer round-trip connection statistic by setting qualify=yes for the specified peer. It sends periodic OPTIONS to the peer and calculates the time round trip time. It's something like - "Status: OK (30 ms)". Is there any way to achieve this in Kamailio by using nathelper module, or any other? Thank you.

9 13

Kamailio stop to process incoming SIP traffic via TCP.
by Kristijan Vrban 16 Jan '20

16 Jan '20

Hi kamailios, i have a creepy situation with v5.2.1 stable Kamilio. After a day or so, Kamailio stop to process incoming SIP traffic via TCP. The incoming TCP network packages get TCP-ACK from the OS (Debian 9, 4.18.0-15-generic-Linux) but Kamailio does not show any processing for the SIP-Traffic incoming via TCP. No logs, nothing. While traffic via UDP is working just totally fine. When i look via command "netstat -ntp" is see, that the Recv-Q get bigger and bigger. e.g.: Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 4566 0 172.17.217.12:5060 xxx.xxx.xxx.xxx:57252 ESTABLISHED 31347/kamailio After Kamailio restart, all is working fine again for a day. We have maybe 10-20 devices online via TCP and low call volume (1-2 call per minute). The only settings for tcp we have is "tcp_delayed_ack=no" How to could we debug this situation? Again, no error, no warings in the log. Just nothing. Kristijan

11 46

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