sr-users February 2013

sr-users@lists.kamailio.org

84 participants
124 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

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

[Kamailio-Users] HA+DRBD setup
by Siddhardha Garige 09 Jul '15

09 Jul '15

Hello all, Just wondering if anyone know any tutorial on setting up HA+DRBD solution for kamailio. Especially creating partitions, DRBD devices and mount points. Thanks in advance, -Sid "May the light be with you." ______________________________________________ Siddhardha Garige www.luminepixels.com

11 24

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error
by vivi 01 Nov '14

01 Nov '14

Hi all.. I have solve the problem . Cheers, vivi From: vivi [mailto:vivi.hilton@gmail.com] Sent: Saturday, June 06, 2009 11:29 PM To: 'users(a)lists.kamailio.org' Subject: /usr/local/sbin/kamdbctl create error Hi all I have specify the wanted db type (DBENGINE=MYSQL) in the /usr/local/etc/kamailio/kamctlrc then I using "/usr/local/sbin/kamdbctl create" to create MySQL database, but I got this error: ERROR: database engine not specified, please setup one in the config script root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim /usr/local/etc/kamailio/kamctlrc root@acer:/usr/local/src/kamailio-1.5.0/sip-server# /usr/local/sbin/kamdbctl create MySQL password for root: INFO: test server charset ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary operator expected INFO: creating database openser ... ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR: Creating core database and grant privileges failed! Cheers, vivi

2 1

kamailio and app_python
by Victor Seva 11 Jun '14

11 Jun '14

Hi, is there any way to return values from a call to python_exec function orther than the default returned integer? Following code generates this error: Oct 1 09:08:23 zskio /usr/sbin/kamailio[21789]: ERROR: app_python [python_support.c:38]: python_exec2: Unhandled exception in the Python code: Oct 1 09:08:23 zskio /usr/sbin/kamailio[21789]: ERROR: app_python [python_support.c:78]: #011RuntimeError: no such function if (!python_exec("get_provider", $(var(clean_uri){s.prefixes}))) { xlog("L_ERR","Can not choose a provider for $rU\n"); sl_send_reply("503","Can not choose a provider for $rU"); exit; } def get_provider(self, msg, param): # snipped code... result = self.util.get_provider(prefixes, position, mode) if result is not None: LM_ERR("mode: %s position: %d result: %s" % (mode, position, result)) # this raises error msg.call_function('rewritehost', result['provider']['ip']) return 1 return -1 I tried to use headers as transport but this simple code does not work: Oct 1 09:45:31 zskio /usr/sbin/kamailio[22303]: ERROR: <script>: No header if (!is_present_hf("X-Test-header")) { xlog("L_ERROR", "No header\n"); } else { xlog("L_INFO", "Header added\n"); } def test_set_header(self, msg): msg.call_function('append_hf', 'X-Test-header: test\r\n') return 1 Thanks in advance.

4 6

Double attempt to record-route
by Juha Heinanen 27 Apr '14

27 Apr '14

I tried to call record_route_preset() in branch route in order to add contact specific RR headers when request is forked to more than one contact. What happened was that I got error message: Sep 26 17:03:47 wheezy2 /usr/sbin/sip-proxy[2436]: ERROR: rr [rr_mod.c:256]: Duble attempt to record-route Is it really so that record routing is not a branch specific thing? Is there a way to solve this problem? -- Juha

3 4

Kamailio stability/timing problem w.r.t. registrations?
by Sotas Development 16 Dec '13

16 Dec '13

Hi, We run Kamailio 3.2.3 (FLAVOUR=ser) on an embedded ARM platform in near- default configuration. In a duration test, we observe that at a certain moment Kamailio seems to start ignoring all (re-)register messages, and eventually expires the existing registrations. We have not been able to reproduce the issue using debug-level logging (-dddd). Info-level logging (-ddd) does reproduce the error, but does not produce any error messages. Configuration: ser-basic.cfg, with the following changes: port=5060 alias=testnet Command line: ser -m 4 -f /etc/ser/ser-basic.cfg -n3 -l udp:eth0 Load: Bursts of 8 (Re-)REGISTER messages that are repeated every 85 seconds. The specified expiration time is 120 seconds. Bursts of 9 (Re-)INVITE messages that are repeated every 45 seconds. Note: With this load it takes roughly 1 hour for the error to occur. Using a more standard 3600 second expiration time Kamailio still stalls, it just takes longer. Does anyone have any idea how to tackle this issue? Kind regards, Michiel Veldkamp

3 14

Kamailio- Redirect message 300 with LCR reroute
by Fatima Chahrour~Vanrise Support 06 Dec '13

06 Dec '13

Dear List, I'd like to get help regarding my case. I have the following script where many thanks to Daniel has helped me in if (is_method("INVITE")) { if (!load_gws(1, $rU, $fu)) { sl_send_reply("502", "Unable To lOad GatEwAyS"); exit;} if(!next_gw()){ sl_send_reply("503", "Unable To fInD a gateWaY"); exit;} while(next_gw()){ km_append_branch(); } sl_send_reply("302","Moved Temporary"); exit; } The problem am facing is that the call is rerouting from the first gateway to the next gateway successfully when I have two gateways. BUT when I have three gateways, and the first two gateways are off, the call is not rerouted to the third gateway. It keeps hitting the seconds gateway and gives request time out at the end Why is that? Thanks in advance, F Chahrour

3 14

kamailioi is not relaying BYE message to UAC
by Arif Hossain 06 Dec '13

06 Dec '13

Hi, We have the following network architecture : UAC1------------------------->kamailio-------------------->VoipSwitch----->PSTN---------->Phone1 (Sip Client) Now UAC1 calls Phone1 and everything is ok. If UAC1 hangs up session is terminated cleanly. But if Phone1 hangs up the BYE message which comes to kamailio and goes back to VoipSwitch instead of relayed to UAC1 . So The session becomes a zombie one, And UAC1 unfortunately gets billed for a session which should be terminated. Following is the Call flow as seen from VoipSwitch : | <kamilio IP> | | | | <VoipSwitch IP> | |134.856 | INVITE SDP | |(7890) ------------------> (5060) | |134.858 | 407 Proxy Authentication Required | |(7890) <------------------ (5060) | |134.902 | ACK | | |(7890) ------------------> (5060) | |135.408 | INVITE SDP | |(7890) ------------------> (5060) | |135.414 | 100 Trying| | |(7890) <------------------ (5060) | |140.121 | 183 Session Progress SDP | |(7890) <------------------ (5060) | |140.184 | RTP (g729) | | |(61868) <------------------ (5136) | |141.295 | RTP (g729) | | |(61868) ------------------> (5136) | |153.701 | 200 OK SDP | |(7890) <------------------ (5060) | |153.713 | RTP (g729) | | |(61868) ------------------> (5136) | |154.126 | ACK | | |(7890) ------------------> (5060) | |159.988 | BYE | | |(7890) <------------------ (5060) | |160.031 | BYE | | |(7890) ------------------> (5060) | |160.478 | BYE | | |(7890) ------------------> (5060) | |161.412 | BYE | | |(7890) ------------------> (5060) | |181.952 | BYE | | |(7890) ------------------> (5060) | |185.687 | BYE | | |(7890) ------------------> (5060) | |188.018 | 408 Request Timeout | |(7890) ------------------> (5060) | Sip Traces : kamailio------>VoipSwitch I'm posting only the offending BYE msg instead of full trace , because of the mail will become difficult to read . If more traces needed, i can post it. The following BYE message is sent by VoipSwitch: BYE sip:ipphone@205.164.40.74 SIP/2.0 Route: <sip:108.166.195.189:7890;lr=on;nat=yes> CSeq: 2 BYE Via: SIP/2.0/UDP 205.164.40.74:5060 From: sip:008801673345531@205.164.40.74;tag=100528120745985872655137 Call-ID: IqBknV19AuxW0jk.8BjuE4hyx93Ws9qS To: "123456" <sip:ipphone@205.164.40.74>;tag=Zopl5lj5YiqyaSR5Le3QnfoR-G0NZAGG Content-Length: 0 Kamailio instead of relaying the message, sends a BYE message towards VoipSwitch: BYE sip:ipphone@205.164.40.74 SIP/2.0 Max-Forwards: 10 CSeq: 2 BYE Via: SIP/2.0/UDP 108.166.195.189:7890;branch=z9hG4bK4b2b.5d893e95.0 Via: SIP/2.0/UDP 205.164.40.74:5060;rport=5060 From: sip:008801673345531@205.164.40.74;tag=100528120745985872655137 Call-ID: IqBknV19AuxW0jk.8BjuE4hyx93Ws9qS To: "123456" <sip:ipphone@205.164.40.74>;tag=Zopl5lj5YiqyaSR5Le3QnfoR-G0NZAGG Content-Length: 0 When the first BYE message comes from VoipSwitch , kamailio does the following : May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:751]: _sdp = 0x831bf10 May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:753]: sdp = 0x83043dc May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:755]: session = 0x8304504 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:632]: method: <BYE> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:ipphone@205.164.40.74> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <BYE> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bk19052612230719933454843>; state=16 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:145]: After parse_msg... May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:186]: preparing to run routing scripts... May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=arILprdVR1srJ76HHlt4BEc3XsyaWcZm May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [76]; uri=[sip:ipphone@205.164.40.74] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body ["ipphone" <sip:ipphone@205.164.40.74>] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found! May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=1905251223419334290936029 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: siputils [checks.c:76]: totag found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:85]: is_preloaded: No May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 13==15 && [205.164.40.74] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 7890 matches port 5060 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 13==15 && [205.164.40.74] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches port 5060 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [forward.c:448]: check_self: host != me May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 15==15 && [108.166.195.189] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 7890 matches port 7890 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:792]: Topmost route URI: 'sip:108.166.195.189:7890;lr=on;nat=yes' is me May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:257]: No next Route HF found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:811]: No next URI found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:983]: params are <;lr=on;nat=yes> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: siputils [checks.c:76]: totag found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=2501 , global msg id=2500 , T on entrance=0xffffffff May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=29177, isACK=0 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:711]: DEBUG: t_lookup_request: no transaction found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_hooks.c:374]: DBG: trans=0xb61626a4, callback type 1, id 0 entered May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [msg_translator.c:204]: check_via_address(205.164.40.74, 205.164.40.74, 0) May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_funcs.c:388]: SER: new transaction fwd'ed May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) May 20 02:26:04 VOS20-108 last message repeated 5 times May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up May 20 02:26:22 VOS20-108 /usr/local/sbin/kamailio[16445]: DEBUG: <core> [udp_server.c:486]: udp_rcv_loop: probing packet received from 180.234.62.230 38722 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_reply.c:1134]: ->>>>>>>>> T_code=0, new_code=408 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_reply.c:1636]: DEBUG: relay_reply: branch=0, save=0, relay=0 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: <core> [msg_translator.c:204]: check_via_address(205.164.40.74, 205.164.40.74, 0) May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: <core> [mem/shm_mem.c:105]: WARNING:vqm_resize: resize(0) called May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb61626a4, callback type 128, id 0 entered May 20 02:26:54 VOS20-108 /usr/local/sbin/kamailio[16451]: WARNING: <core> [timer.c:450]: WARNING: our timer runs faster then real-time (300000 ms / 4800 ticks our time .-> 299923 ms / 4798 ticks real time) OT: How do you guys maintain 80 column mails? i do not use a mail client, use gmail mailbox. -- -aft

5 6

reload to memory is much slower and has problms after upgrade to 3.3.2 and using mem_join=1
by Uri Shacked 05 Dec '13

05 Dec '13

Hi, I am using MTREE and DIALPLAN modules to load lots of info to kamailio. (6 million rows). When kamailio was running with 3.2.1 (no mem_join=1 option), the used size was increasing but the process of loading the data was fast eanough. I upgraded to 3.3.2 and set mem_join=1. Now the loading process take about 10 time longer and sometimes stops kamailio from responding to traffic. Any ideas? Thanks, Uri

3 19

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 February 2013