sr-users August 2015

sr-users@lists.kamailio.org

79 participants
123 discussions

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

fix_nated_contact and IPv6
by Sebastian Damm 27 Oct '17

27 Oct '17

Hi, I'm trying to set up a Kamailio (4.1.3) server which converts between IPv6 and IPv4. Everything looks pretty good. Now I have a test client which sends packets via IPv6, but in contact header, SDP etc. there are still IPv4 addresses. (This comes from some converting from v4 to v6 earlier.) Thus, Kamailio tries to do a fix_nated_contact(). But after fixing, the Contact URI is wrong. Example: inbound Contact: <sip:bob@192.168.8.132> outbound Contact: <sip:bob@1234:1234:0:1234:0:0:0:2> The correct way of transforming the Contact URI would be: Contact: <sip:bob@[1234:1234:0:1234:0:0:0:2]> This incorrect Contact URI doesn't hurt first, but when the called party wants to hang up the call, it addresses the URI from Contact header, and Kamailio can't parse the Request URI: Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: pv [pv_core.c:304]: pv_get_ruri_attr(): failed to parse the R-URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: rr [loose.c:934]: loose_route(): failed to parse Request URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: domain [domain.c:140]: is_uri_host_local(): error while parsing R-URI Is this a bug in the nathelper module? Was it never meant to handle IPv6 addresses? Or do I understand something wrong? Best Regards, Sebastian

4 4

NatHelper ignoring force_socket module parameter
by Asgaroth 24 Oct '17

24 Oct '17

Hi All, I have a strange issue, I have set the module parameter for nathelper's force_socket to a specfic ip/port, however, when I perform a sip trace I can see that all locally generated options messages are not sent from the socket defined in the modules parameters. I am not setting $fs anywhere in the script, so I am not over-writing it. Do any of the other module parameters have a bearing on if nathelper uses the force_socket parameter? My current nathelper settings are: modparam("nathelper", "received_avp", "$avp(RECEIVED)") modparam("nathelper", "natping_interval", 20) modparam("nathelper", "natping_processes", 4) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_from", "sip:keepalive@domain.com") modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "sipping_bflag", NAT_BFLAG) modparam("nathelper", "force_socket", "1.2.3.4:5060") I am using kamailio v4.3.1: # kamailio -V version: kamailio 4.3.1 (x86_64/linux) f38e67 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, F_MALLOC, DBG_F_MALLOC, 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: f38e67 compiled on 18:15:23 Jul 20 2015 with gcc 4.4.7 Thanks

2 5

Problem with t_relay() and VPN tunnel
by Carlos Ruiz Diaz 24 Jun '17

24 Jun '17

Hi, I have two SIP servers, *A* and *B*, connected each other though a OPENVPN tunnel. The server *B* needs to t_relay() every SIP message containing the method MESSAGE to the server *A* but these messages never reach destination. I have tested the tunnel connectivity and works fine. I wrote a Perl script (located in *B*) that sends SIP MESSAGES to Kamailio (located in *A*) trying to figure out what is happening but these messages are received by *A* and processed correctly but when *B* does the same from Kamailio, it is never received. Here is the route part of kamailio.cfg in *B*: Observation: ($rU == "1004") result is *true* * if(is_method("MESSAGE")) { if($rU == "1004") { xlog("L_INFO","En 1004"); rewritehost("10.8.0.1"); if (!t_relay()) xlog("L_INFO","MIO Error en t_relay"); t_reply("200", "Ok"); xlog("L_INFO","MIO despues rewrite"); exit; } .....* The perl script that WORKS: *$msg = 'MESSAGE sip:1004@192.168.1.2:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2 From: "2002" <sip:2002@192.168.1.2 <sip%3A2002(a)192.168.1.2>>;tag=1837944796 To: <sip:1004@192.168.1.2 <sip%3A1004(a)192.168.1.2>> Call-ID: 19722852989(a)192.168.1.2 CSeq: 15773 MESSAGE Contact: <sip:2002@**PublicIP-protected**:5060> Max-Forwards: 29 User-Agent: DBL Content-Type: text/plain Content-Length: 34 +595981[protected] hello from kamailio '; use IO::Socket; my $sock = IO::Socket::INET->new( Proto=>'udp', PeerHost=>'192.168.2.102', PeerPort=>'5060'); print "Sending msg $msg\n"; $sock->send($msg) or die "error sending $!\n"; *Please help! Thanks in advance. Carlos.

3 3

Missing accounting events in ACC table
by Muhammad Shahzad 23 May '17

23 May '17

Hi, About 3 weeks ago i upgraded one of my production server with latest stable kamailio version 4.2.1-fad00a. Now i am getting a lot of complaints about missing CDR events in ACC table. I observe following problems, 1. There are only BYE records in acc table, no record for INVITE or ACK. 2. In kamailio logs when ACK is received against 200 OK response for INVITE, i see following errors, -- ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to parse >From uri ERROR: pv [pv_core.c:434]: pv_get_xto_attr(): cannot parse From URI NOTICE: <script>: [udp:<null>@1.0.0.127:5060]: Call from 'you(a)kamailio.org' to 'you(a)kamailio.org' has been hanged up by '<null>' at '1419364717.255484' -- Of course all these errors are bogus, I have checked all headers in ACK (not just FROM header), they all seem perfectly fine and valid. 3. Then the dialog times out, -- WARNING: dialog [dlg_handlers.c:1440]: dlg_ontimeout(): timeout for dlg with CallID '6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9' and tags '1D3ECD34F5731AB845BA3064AC95BB2D' '7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4' -- 4. Any further sequential requests complain about "unable to find dialog", e.g. -- NOTICE: <script>: Sequencial 'BYE' request received from caller ERROR: uac [replace.c:591]: restore_uri(): new URI [] shorter than old URI [ sip:00xxxxxxxxxx@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] -- 5. However the acc record for BYE is written to db and log file, -- NOTICE: acc [acc.c:318]: acc_log_request(): ACC: transaction answered: timestamp=1419364760;method=BYE;from_tag=7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4;to_tag=1D3ECD34F5731AB845BA3064AC95BB2D;call_id=6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9;code=200;reason=OK;src_user=00xxxxxxxxxx;src_domain= sip.domain.com ;src_ip=xx.xx.xx.xx;dst_ouser=+1xxxxxxxxxx;dst_user=1xxxxxxxxxx;dst_domain=yy.yy.yy.yy -- The same config was working fine with older version 4.2.0-97cab8. The kamailio config i am using is pretty much standard, -- #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_DLG 4 ... modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) # log to db modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) modparam("acc", "db_url", "DBURL") ... request_route { # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); # handle requests within SIP dialogs route(WITHINDLG); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); }; exit; }; #### only initial requests (no To tag) #### t_check_trans(); .... # account only INVITEs if (is_method("INVITE")) { setflag(FLT_DLG); # create dialog setflag(FLT_ACC); # do accounting setflag(FLT_ACCFAILED); # ... even if the transaction fails $avp(dlg_timeout) = 60; dlg_manage(); .... } -- Any ideas why its happening? Since it is 3 weeks old so may be problem has already been spotted and fixed by someone else. Otherwise let me know how can i provide more info to help fix this issue. Thank you.

3 11

How to make OutBound calls with kamailio
by sharad tyagi 23 May '17

23 May '17

Hi I am novice to kamailio , I have installed kamailio-4.2.0 and SIREMIS. I have add and registered two IP phones with kamailio these phone able to call each other. How can i make outbound call with that I am using a asterisk server as PSTN Gateway. i am not famalier with kamailio script. Regards Sharad Tyagi SparkTG info Pvt Ltd

4 3

Cannot hear voice with symmetric NAT and STUN
by Khoa Pham 08 Feb '17

08 Feb '17

Hi, I have Kamailio as SIP server and RTP server. Client is PJSIP. I read that STUN is for non-symmetric NAT, and RTP server is for symmetric NAT. Supposed A calls B. If A, B both use symmetric NAT and STUN, they cannot hear each other If A or B use non-symmetric NAT and NOT using STUN, they cannot hear each other. Why is that? I read http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt for Prediction Failure, is that related to this problem ? -- Khoa Pham HCMC University of Science Faculty of Information Technology

8 18

Using the auth_ephemeral module
by Hemanshu Vadehra 17 Jan '17

17 Jan '17

I'm involved in setting up a Kamailio instance and was hoping to make use of the auth_ephemeral module for authentication. But the module documentation doesn't quite make clear how exactly the module is to be employed or the web service set up. Does anyone have a working example? Regards, Hemanshu Vadehra hemanshu.v(a)directi.com

5 8

Kamailio on Mac
by Carlos Ruiz Díaz 04 Aug '16

04 Aug '16

Hi all, I'm switching my development environment from Linux to Mac. Is there any tutorial on how to setup Kamailio on this OS? It may be an Unix flavor, but it's still quite different from Linux :). Thanks, -- Carlos http://caruizdiaz.com http://ngvoice.com +52 55 3048 3303

6 9

t_on_branch_failure never called AND t_relay never fails in a, forked scenario
by Tristan Mahé 03 May '16

03 May '16

Hi fellow kamailio users, I'm playing actually with t_on_branch_failure, in a simultaneous forking scenario ( lookup("location") returns multiple contacts ). Any idea on how to get those "on_branch_failure" working ? Thanks in Advance ! * Test by putting failure_exec_mode: - at 1 => no branch failure being called, never. - at 0 => t_relay does not fail if a single branch answers the transaction, even if all other branches are failing. * Test by moving the t_on_branch_failure("manage_branch_failure"); line before or after the lookup("location") or on a _on_branch route to set it per branch. - The on_route branch are executed, but never the failure one. - tried also with failure_exec_mode = 0 or 1. * Using set_forward_no_connect, I can see in the logs a "Sending to branch X failed" but no failure route being executed. Without it, nothing in the logs indicating that the branch has timeout. * Config extract: # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # 3 by default # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) modparam("tm", "reparse_on_dns_failover", 0) # 1: Allow branches to have a per branch failure route # 0: t_relay should fail if a branch fail modparam("tm", "failure_exec_mode", 1) # Allow locally generated 408 to be forgotten in case a reply is received. #modparam("tm", "faked_reply_prio", 2000) # USER location service route[LOCATION] { t_on_branch_failure("manage_branch_failure"); if (!lookup("location")) { .... } # Let's get back after 2.5s if no 100/Trying received. t_set_fr(0, 2500); # set_forward_no_connect(); #t_on_branch("SET_BRANCH_FAILURE"); route(RELAY); exit; } route[RELAY] { .... if (!t_relay()) { xlog("L_WARN","$rm|$ci|$fu|$tu|RELAY_FAILED"); sl_reply_error(); } exit(); } # set failure route per branch branch_route[SET_BRANCH_FAILURE] { xlog("L_WARN","$rm|$ci|$fu|$tu|SETTING_BrANCH_FAILURE_ROUTE"); t_on_branch_failure("manage_branch_failure"); } # manage failure routing cases per branch event_route[tm:branch-failure:manage_branch_failure] { xlog("L_WARN","$rm|$ci|$fu|$tu[$avp(dest_to)]|MANAGE_BRANCH_FAILURE"); }

3 2

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