sr-users December 2016

sr-users@lists.kamailio.org

71 participants
101 discussions

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

Parallel Forking with Different Call-Id
by SamyGo 24 Feb '17

24 Feb '17

Hi, I've a very strange scenario to work on which requires me to parallel fork the call to the same Destination provider. The only problem here is that they think that the second INVITE with different branch tag is a re-transmission and hence only take one call forward. I do not have to modify any R-URI or any headers, hence just 'append_branch() before t_relay() is in the code. ... $ru = "sip:" + $rU + "@" + $avp(carrier_ip) + ":" + $avp(carrier_port); append_branch(); route(RELAY); ... *Question:* Is there anyway possible I can change the CallID of the forked INVITEs ? I have tried using Topoh module, but it still puts the same CallID before sending out. Different from the A-leg but the Sent out INVITEs have same Call-ID value. In other weird scenario, I've also tried branching, and looping call within Kamailio before sending out to carrier hoping that Kamailio would treat the two different calls and Topoh would change the Call-ID on both INVITEs before sending out.. ... if(is_present_hf("X-FORKED")) { $ru = "sip:" + $rU + "@" + $avp(carrier_ip) + ":" + $avp(carrier_port); route(RELAY); }else { append_hf("X-FORKED: 1\r\n"); append_branch(); route(RELAY); } ... Still I get same Call-ID on outgoing branched call. I could branch out one INVITE to a MediaServer, say FreeSWITCH/Asterisk but again I don't want to have that component bottleneck the throughput. That could be my very last option. Looking for some ideas. Regards, Sammy

3 6

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

(no subject)
by jay binks 24 Jan '17

24 Jan '17

Hi Guys, Im using a keepalived solution between 2 kamailio boxes, with net.ipv4.ip_nonlocal_bind =1 . On the "non master" I pretty much constantly get these logs in syslog. What Im looking for is a way to suppress these because they are expected in my configuration. is there any way to tell kamailio to not log this... ( or at least, not at CRIT and ERROR ) *Jun 25 10:32:53 lb2 /usr/sbin/kamailio[24869]: ERROR: tm [../../forward.h:208]: msg_send(): udp_send failed* *Jun 25 10:32:53 lb2 /usr/sbin/kamailio[24869]: ERROR: <core> [udp_server.c:576]: udp_send(): sendto(sock,0x7fc0732d5ab0,380,0,xxx.xxx.xxx.xxx:5060,16): Invalid argument(22)* *Jun 25 10:32:53 lb2 /usr/sbin/kamailio[24869]: CRITICAL: <core> [udp_server.c:581]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net* -- Sincerely Jay

4 9

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

why a register error?
by Olvera, Victor 09 Jan '17

09 Jan '17

As I attempt to use X-lite I get a 504 error. On the CSCFs I get the following: pcscf 0(2066) INFO: <script>: [REGISTER] from [sip:bob@epc.mnc001.mcc001.3gppnetwork.org] to [sip:bob@epc.mnc001.mcc001.3gppnetwork.org] 0(2066) ERROR: <script>: REGISTER (sip:bob@epc.mnc001.mcc001.3gppnetwork.org (192.168.56.1:55880) to sip:bob@epc.mnc001.mcc001.3gppnetwork.org, 81563ZDg1Y2MwZDExYWJiYWJjNDZmNzY0ZWEwYjE1ODNkYmM) icscf 11(2150) INFO: cdp [receiver.c:932]: peer_connect(): peer_connect(): Peer hss.epc.mnc001.mcc001.3gppnetwork.org<http://mcc001.3gppnetwork.org>:3868 connected 0(2138) INFO: <script>: [REGISTER] from [sip:bob@epc.mnc001.mcc001.3gppnetwork.org] to [sip:bob@epc.mnc001.mcc001.3gppnetwork.org] 0(2138) ERROR: <script>: REGISTER (sip:bob@epc.mnc001.mcc001.3gppnetwork.org (192.168.56.76:4060) to sip:bob@epc.mnc001.mcc001.3gppnetwork.org, 81563ZDg1Y2MwZDExYWJiYWJjNDZmNzY0ZWEwYjE1ODNkYmM) 0(2138) INFO: ims_icscf [cxdx_uar.c:71]: create_uaa_return_code(): created AVP successfully : [uaa_return_code] 6(2145) INFO: ims_icscf [cxdx_avp.c:137]: cxdx_get_avp(): cxdx_get_server_name: Failed finding avp 6(2145) INFO: ims_icscf [cxdx_avp.c:137]: cxdx_get_avp(): cxdx_get_result_code: Failed finding avp 6(2145) INFO: ims_icscf [cxdx_uar.c:71]: create_uaa_return_code(): created AVP successfully : [uaa_return_code] 0 scscf 11(2047) WARNING: cdp [receiver.c:864]: peer_connect(): peer_connect(): Trying to connect to 192.168.56.78 port 3868 11(2047) INFO: cdp [receiver.c:932]: peer_connect(): peer_connect(): Peer hss.epc.mnc001.mcc001.3gppnetwork.org<http://mcc001.3gppnetwork.org>:3868 connected 9(2045) ERROR: cdp [peerstatemachine.c:635]: I_Snd_CER(): I_Snd_CER(): Error on finding local host address > Socket operation on non-socket Great regards, Victor Olvera victor.olvera(a)verizonwireless.com<mailto:victor.olvera@verizonwireless.com> mobile # 001-214-923-9405

2 1

VERY IMPORTANT: deciding when to remove the MI code
by Daniel-Constantin Mierla 06 Jan '17

06 Jan '17

Hello, we started discussing about removing MI (so called management interface) for very long time, more or less since 2008. The RPC should remain the control interface, given its better structure for commands, parameters, etc ... MI is custom protocol using a line-oriented communication via fifo or socket file with kamailio (e.g., implemented mi_fifo and mi_datagram modules). RPC is the alternative, a more standardized concept, with better structured format. I think it's time to set a clear roadmap for doing the removal. Overall, it will be easier to maintain the code, right now being duplicated code for doing the same operation over MI or RPC, and MI shows its limitations (or complexity to deal with) for advanced needs (see the discussions about how to provide multi-line value parameters over MI). So, I want to know if there are many relying on MI directly and they still want to keep it, what would be the expected duration they need for upgrading their tools to work with RPC interface, other relevant aspects people have in favour of mi vs rpc. I am even willing to do the removal in time befire freezing the 5.0 branch. We will ensure a clean start of 5.x series. The main concern from my point of view is kamctl -- but I think we can preserve the compatibility for kamctl commands and parameters (so command line execution of kamctl will be the same), but the output might be different. That's because it should be easy to updated it to communicate with jsonrpc-s module, but then it will get json-formatted results. To summarize, two big questions to answer: a) Are you ok to remove the MI code/commands? b) If yes to a), are you ok to be done for v5.0? Not providing feedback will be considered as 'yes' for both questions, so **speak up if you want MI to be kept or delay it removal**. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

6 30

presentity tabla, faster update when drop TCP/TLS connection
by João Resende 05 Jan '17

05 Jan '17

I'm testing kamailio with a SIP client with presence support, when I get a connection drop from a client (i.e when the client lost the access to the Internet connection) I do not receive the change in the status to offline immediately, I just received when the timeout from the presentity database finishes. Exists a way to define this? or it is a bug? or should be a new feature? I know that I'm able to change the expiry parameter from the presentity table, but that increases my battery consumption and the data exchange, the same happens if I reduce the publish interval on the client side.

3 9

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