sr-users December 2019

sr-users@lists.kamailio.org

63 participants
78 discussions

CSeq values in dialog OPTIONS keepalives

by Alex Balashov

Hi, I'd like to reopen an old thread of discussion: Using Kamailio 4.4.x latest, when I enable dialog OPTIONS keepalives on both sides of a call - ka-dst and ka-src dialog params, that is - I get OPTIONS pings sent to one side with a CSeq value like this: CSeq: 0 OPTIONS and the other side: CSeq: (CSeq of e2e ACK - 1) OPTIONS The 0 CSeq is acceptable to most UAs--at least, among the small number I've tested--and they answer 200 OK, but the second one results in a '500 Server Internal Error'. I have read the prior literature on this: https://lists.kamailio.org/pipermail/sr-users/2012-May/073069.html https://lists.kamailio.org/pipermail/sr-users/2018-April/101096.html and I (mostly) understand the rationale of keeping this mechanism stateless. I tried turning on `track_cseq_updates` to see if it might change the behaviour, but it does not. Anyway, a mechanism that deliberately elicits 500 responses from the endpoint is going to raise some eyebrows and just looks a bit unprofessional. I'm wondering if there is a better way to go. My questions are: 1. While I understand the reasoning here: "it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept)." Would it be such a problem to use a CSeq value that is (last highest known CSeq observed) + ($RANDOM % LARGE_VALUE)? 2. In the case that `ka-dst` and `ka-src` are both enabled, why is there an inconsistency in the behaviour with respect to the upstream and downstream side (CSeq value of 0 vs. CSeq value of <= CSeq(ACK))? 3. At the risk of inviting some baroque state-keeping that is runtime-dependent, could there be an implementation where the CSeq of genuine in-dialog requests from the UA is modified in-flight by Kamailio, taking advantage of its being in the middle of in-dialog requests, to the appropriate next highest value? I ask this because, if I understood the limited documentation for `track_cseq_updates` correctly, https://kamailio.org/docs/modules/5.3.x/modules/dialog.html#dialog.p.track_… "Enable the callbacks for tracking if CSeq number needs to be updated. It is the case when the INVITE has to be authenticated to downstream provider using uac_auth() from uac module. This is done only for requests in downstream direction. The CSeq difference is stored in $dlg_var(cseq_diff), be sure this variable is not overwritten via config operation." it seems like the door to this method might already be open? Thanks, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

4 years, 10 months

Kamailio stop to process incoming SIP traffic via TCP.

by Kristijan Vrban

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

4 years, 10 months

possible TCP deadlock (tls again?) // pike module not releasing IPs

by Aymeric Moizard

Hi List, History: * In the past, I had deadlock which was, most probably, related to ssl1.1. We have discussed this issue, and a fix is supposed to workaround the issue that was detected. * With latest 5.2.X, I have experienced ONCE a similar behavior with TCP and TLS being mostly stuck. I have not been using this version much, but the fix was supposed to be in the core of kamailio. The status of the server this night: * I'm today running version: kamailio 5.3.1 (x86_64/linux), * Installed on stretch using http://deb.kamailio.org/kamailio53 repository. * This versions use libssl1.1 * A user reported that he can't connect with TCP * An average of 5000 IPs per 10 minutes are being banned by the pike module (could be twice the same) Yesterday/Today: * at the end of the outage, I had 2479 IP in my ipban htable. (which is equivalent to my statistics showing 2 bans/IP every 10 minutes = 5000) * looking at my logs, it appears that most (ALL?) ip being banned... are my regular users. * looking at my logs, I can't understand why pike would block them. This is a graph for statistics on my service for the last 24 hours: https://www.antisip.com/sip-antisip-com-register/status2.html Yesterday, at 22:18:39, kamailio started to BAN some IPs. 52 IPs were banned in a period of 10 minutes. I can confirm this from my logs. My pike configuration is this one: modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 64) modparam("pike", "remove_latency", 4) When detecting the issue, this morning, I typed: $> sudo kamctl stats $> sudo kamcmd htable.dump ipban //FAILURE (answer too large...) $> sudo kamctl trap Then, I started an agent with TCP and it worked...??? Then, a few seconds, may be a minute after: $> sudo kamcmd htable.dump ipban //SUCCESS and shows 2479 banned ip. and... everything is back to normal in a few minutes. I haven't restarted kamailio, and all statistics are as expected, as usual. Thus, it looks that " sudo kamctl trap" has triggered something. I already experienced a similar behavior -when testing my ssl1.1 deadlock last year-. 2 questions: 1/ I beleive my "pike" configuration should not ban users. Is my pike configuration wrong? As an example, pike has banned an IP sending one message/second. I believe my configuration should accept that? 2/ Could there still be a TLS issue with libssl1.1? This is the result of the "kamctl trap": https://sip.antisip.com/kamailio-pike-or-tls-issue-13-12-2019.kamctl-trap Sorry for the long story & hoping to find a long term solution or at least a workaround! Regards Aymeric -- Antisip - http://www.antisip.com

4 years, 10 months

WebRTC ACK Protocol

by Ilie Soltanici

Hello, I am trying to set up a WebRTC2SIP Gateway by using Kamailio and rtpengine. So far, everything is working fine, I'm able to register an extension and make a call, but for some reason, when i'm trying to call a WebRTC extension from any SIP Extension Kamailio is sending INVITE, WebRTC extension is sending back 200 OK, and then Kamailio is trying to send an ACK through UDP protocol, and not through wss, as it's supposed to do. This is how invite is looking: INVITE sip:nl7oe4ss@vjbh7r4im6j7.invalid;transport=wss SIP/2.0 Record-Route: <sip:my-company.net ;transport=udp;ftag=as1789445c;lr=on;nat=yes> Via: SIP/2.0/WSS 123.123.123.123:10443 ;branch=z9hG4bKe655.29d7c135a302f3eb803902d4f5a8da7e.0 Via: SIP/2.0/UDP 192.168.50.237:5060 ;received=192.168.50.237;branch=z9hG4bK7d2e534e;rport=5060 Max-Forwards: 70 From: "WebRTC" <sip:11@my-company.net>;tag=as1789445c To: <sip:15@192.168.50.210:5060> Contact: <sip:11@192.168.50.237:5060> Call-ID: 7fc800de060197fa2315c93763873092(a)my-company.net CSeq: 102 INVITE User-Agent: Proxy Date: Wed, 03 Apr 2019 17:11:41 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Alert-Info: Content-Type: application/sdp Content-Length: 596 Server: SIP Proxy and then WebRTC app is replying with 200 OK: SIP/2.0 200 OK Record-Route: <sip:my-company.net ;transport=udp;ftag=as1789445c;lr=on;nat=yes> Via: SIP/2.0/WSS 123.123.123.123:10443 ;branch=z9hG4bKe655.29d7c135a302f3eb803902d4f5a8da7e.0 Via: SIP/2.0/UDP 192.168.50.237:5060 ;received=192.168.50.237;branch=z9hG4bK7d2e534e;rport=5060 To: <sip:15@192.168.50.210:5060>;tag=dk4fa8ftt6 From: "WebRTC" <sip:11@my-company.net>;tag=as1789445c Call-ID: 7fc800de060197fa2315c93763873092(a)my-company.net CSeq: 102 INVITE Contact: <sip:nl7oe4ss@vjbh7r4im6j7.invalid;transport=wss> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: Proxy-WEBRTC Content-Type: application/sdp Content-Length: 901 and finally, Kamailio is trying to send this ack through UDP protocol: ACK sip:nl7oe4ss@22.22.22.22:57421;transport=wss SIP/2.0 Via: SIP/2.0/UDP 192.168.50.237:5060;branch=z9hG4bK56363ddf;rport Route: <sip:my-company.net;transport=udp;ftag=as1789445c;lr=on;nat=yes> Max-Forwards: 70 From: "WebRTC" <sip:11@my-company.net>;tag=as1789445c To: <sip:15@192.168.50.210:5060>;tag=dk4fa8ftt6 Contact: <sip:11@192.168.50.237:5060> Call-ID: 7fc800de060197fa2315c93763873092(a)my-company.net CSeq: 102 ACK User-Agent: Proxy Content-Length: 0 If i'm trying to force it through TLS, i'm receiving error: get_send_socket2(): protocol/port mismatch (forced tls:123.123.123.123:10443, to udp:22.22.22.22:23317) Can someone point me in the right direction, please? Thank you.

4 years, 10 months

Kamailio when acting as client doesnt send SNI in client hello handshake message

by mahesh b

Hi, Am using Kamailio 5.1.9 version My Setup : client1 -> kamailio server 1 ( IP : 10.211.160.172) ----> kamailio server 2( IP : 10.211.160.176) -> client2 I have a scenario where kamailio server 1 has to initiate an outgoing tls connection to kamailio server 2, i have set the server_name and server_id in the client profile in tls.cfg like below on kamailio server 1 [client:default] verify_certificate = no require_certificate = no server_name = mahesh.client.com [client:10.211.160.172:5061] method = TLSv1+ verify_certificate = yes require_certificate = yes private_key = /root/mahesh_openssl/profile2/btip_172_server_private.key certificate = /root/mahesh_openssl/profile2/btip_172_server_public.crt ca_list = /root/mahesh_openssl/profile2/btip_ca_public.crt cipher_list = RSA verify_depth = 9 server_name = btip.176.com server_id = btip.176.com And in sar.cfg $xavp(tls=>server_name)="btip.176.com"; $xavp(tls=>server_id)="btip.176.com"; $du = "sip:10.211.160.176:5061;transport=tls"; .... t_relay(); What i observe is that , when client hello is sent by 10.211.160.172 to 10.211.160.176, i dont see Extension server_name being sent. Am i missing anything. Please help !

4 years, 10 months

Siremis & freeswitch

by John Tuxies

I have a Debian server running Kamailio and i have all my users regiatering and talking to each other. I do create/remove users from Siremis. I have followed the guide from here: https://www.powerpbx.org/content/kamailio-v5-siremis-v5-debian-v9-mariadb-a… I would like to add freeswitch to the same server and add conference, voicemail, supplementary services for my users. I have given it a try to install freeswitch and tried to configure it accordingly to https://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc But.now the Siremis gui shows a lot of errors and i cannot login any more. Since it is a Virtual machine i reverted it back and it works without freeswitch. How could i integrate freeswitch to my system please?

4 years, 10 months

MSRP proxy

by Sergey Safarov

I want proxy MSRP data on kamailio for SIP call (not websocket). To do this need update connection information for "message" media in SDP. How i can properly do it only for one media (other medias will be proxed using rtpproxy or rtpengine ). Looks as fix_nated_sdp fix for all medias in SDP. Sergey

4 years, 10 months

pv_parse_spec2(): wrong char [)/41] in [$T(reply_reason)] at [15 (5)]

by Denys Pozniak

Hello! Looks like $T(reply_reason) does not work well (although $T_reply_reason is ok). Kamailio script: failure_route[TRUNK_FAILURE] { ... xlog("L_WARN","rm=$rm / $T(reply_reason) \n"); ... } 0(8894) ERROR: tmx [t_var.c:696]: pv_parse_t_name(): unknown PV name reply_reason 0(8894) ERROR: <core> [core/pvapi.c:952]: pv_parse_spec2(): pvar "T" has an invalid name param [reply_reason] 0(8894) ERROR: <core> [core/pvapi.c:1107]: pv_parse_spec2(): wrong char [)/41] in [$T(reply_reason)] at [15 (5)] 0(8894) ERROR: xlog [xlog.c:511]: xdbg_fixup_helper(): wrong format[rm=$rm / $T(reply_reason) https://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables $T(name) - pseudo-variable class to access TM attributes The *name* can be: - reply_reason - reply reason [kamailio]$ kamailio -v version: kamailio 5.2.2 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 18:04:26 Apr 3 2019 with gcc 4.8.5 -- BR, Denys Pozniak

4 years, 10 months

Tweaking TCP settings

by Dovid Bender

Hi, First off please forgive my lack of knowledge on how TCP works. We are using Kamailio 5.0.7 and we have an issue where clients are connecting via TCP and their NAT devices are closing up. Because of this we want to send TCP keep alives every so often. 1) When restarting Kamailio it's sends a RST. Is this Kamailio sending it out or is it linux sending it when the application is killed? The issue we have is if say we need to do a restart 2-3 times (yes we should normally do that) then we end up with 3x registrations in the db (since when using db mode if the connection goes away it won't remove the reg from the db (as per - https://kamailio.org/docs/modules/5.0.x/modules/usrloc.html#usrloc.p.handle… ) 2) I haven testing with the following settings. a. tcp_crlf_ping=yes b. tcp_keepcnt = 3 c. tcp_keepidle = 5 With the above I see the TCP keep alives coming in every 75 seconds. If I tcp_keepintvl = 10 then I see TCP keep alives going out from Kamailio to the phone. As per https://www.kamailio.org/wiki/cookbooks/5.0.x/core#tcp_keepintvl it says "Time interval between keepalive probes, when the previous probe failed". Looking at my captures Kamilio sends out the TCP keep alive and gets it back. Is Kamailio not seeing it? With the above it seems to be working the way I want it but I want to make sure that I am doing it right. 3) For the devs on here how hard would it be to implement handle_lost_tcp for DB-Only? TIA and a happy new year to all. Regards, Dovid

4 years, 10 months

KSR.sdpops.remove_media is not working as expected

by Miteshkumar Thakkar

Hi, I wants to remove media type "image" from SDP. For that I have tried to use KSR.sdpops.remove_media but it is not working. Not working in the sense that there is no effect of that function on SDP. I am using lua. Kindly find more details below. *Kamailio version*: kamailio 5.2.5 (x86_64/linux) 62d35f *SDP to process:* INVITE sip:xxxxxxxxxx@xxxxxxxxx.com:5060 SIP/2.0 Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK-60823-1-0 From: xxxxxxxxxx <sip: xxxxxxxxxx@ xxxxxxxxxx.com:5060>;tag=xxxxx To: xxxxxxxxxx <sip: xxxxxxxxxx@ xxxxxxxxxx.com:5060> Call-ID: 1-60823(a)172.16.19.64 CSeq: 1 INVITE Contact: sip:xx@xxxxxxx:5060 Max-Forwards: 70 Content-Type: application/sdp Content-Length: 337 v=0 o=zt 53655765 2353687637 IN IP4 xxx.xxx.xxx.xxx s=- c=IN IP4 xxx.xxx.xxx.xxx t=0 0 m=image xxxx RTP/AVP udptl t38 a=sendrecv a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:262 a=T38FaxMaxDatagram:176 a=T38FaxUdpEC:t38UDPRedundancy m=audio xxxx RTP/AVP 0 a=rtpmap:0 PCMU/8000 *Code snippet:* KSR.sdpops.remove_media("image") logger.log("info", "SDP:" .. headers.get("$sdp(body)")) *Log snippet:* https://pastebin.com/5JZmQUfq One more thing I would like to mention that if I do not use dialog module then the function KSR.sdpops.remove_media works. But I can not avoid using dialog module. Thanks in advance. Mitesh

4 years, 10 months

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