sr-users

sr-users@lists.kamailio.org

42 participants
37517 discussions

Problem with command kamcmd pkg.stats on Kamailio 4.2.5
by Dao Hai Dang 04 Jun '15

04 Jun '15

Hi, I need help with kamcmd pkg.stats on Kamailio 4.2.5. When I used this command to check kamailio process, I get an entry with no pid and total_size param. I used kamcmd ps and the process error was MI FIFO. Same thing happened when I added snmpstats module, I get process SNMP AgentX with no pid and total_size param. This didn't happen when I use kamailio 4.1.x . Below are logs : [root@localhost ~]# kamcmd pkg.stats { entry: 0 pid: 1532 rank: 0 used: 376224 free: 3718760 real_used: 475544 total_size: 4194304 total_frags: 4 } { entry: 1 pid: 1534 rank: 1 used: 384496 free: 3709368 real_used: 484936 total_size: 4194304 total_frags: 22 } { entry: 2 pid: 1535 rank: -1 used: 384552 free: 3710096 real_used: 484208 total_size: 4194304 total_frags: 8 } { entry: 3 pid: 1536 rank: -1 used: 384552 free: 3710096 real_used: 484208 total_size: 4194304 total_frags: 8 } { entry: 4 pid: 0 rank: 0 used: 393744 free: 3701072 real_used: 493232 total_size: 0 total_frags: 4 } { entry: 5 pid: 1543 rank: -2 used: 383592 free: 3710552 real_used: 483752 total_size: 4194304 total_frags: 8 } { entry: 6 pid: 1544 rank: -4 used: 454392 free: 3640424 real_used: 553880 total_size: 4194304 total_frags: 4 } [root@localhost ~]# kamcmd ps 1532 attendant 1534 udp receiver child=0 sock=10.84.11.116:5060 1535 slow timer 1536 timer 1537 MI FIFO 1543 ctl handler 1544 tcp main process Thanks & Regards, Dao Hai Dang -------------------------------------------------------------------------------- Solutions & Software Development Center | VNPT Technology A member of VietNam Posts & Telecomunications Group Addr : 124 Hoang Quoc Viet, Ha Noi Mobile : (+84 )912 363 579 - Skype : cnoob89 Office : (+84) 438 36 20 94 - ext 1222

2 6

Strange core.tcp_list / tls.list output
by Mikko Lehto 04 Jun '15

04 Jun '15

Hi, I noticed thath command core.tcp_list in kamcmd gives output that does not make sense to me: --- kamcmd> core.tcp_list { id: 1 type: TLS state: CONN_OK timeout: 3599 ref_count: 1 src_ip: 192.168.47.132 src_port: 5061 dst_ip: 10.10.235.9 dst_port: 54769 } { id: 2 type: TLS state: CONN_OK timeout: 3599 ref_count: 1 src_ip: 192.168.47.132 src_port: 32854 dst_ip: 10.10.235.9 dst_port: 5041 } --- In my scenario I am connecting via TLS to host 192.168.47.132:5061. And host 192.168.47.132 is connecting to my proxy host 10.10.235.9:5041. pcap verifies this. Also tls.list gives similar output. Values regarding incoming connection (id=2) makes total sense. It seems that values regarding outgoing connection (id=1) have dst_* values swapped with src_* values. To debug, I placed this logging to tcp_main.c: --- $ git diff tcp_main.c diff --git a/tcp_main.c b/tcp_main.c index 5830c8e..3717cf6 100644 --- a/tcp_main.c +++ b/tcp_main.c @@ -1207,6 +1207,7 @@ again: } from=&my_name; /* update from with the real "from" address */ su2ip_addr(&ip, &my_name); + LM_WARN("after getsockname() my_name=%s server=%s ip=%s\n", su2a(&my_name, sizeof(my_name)), su2a(server, sizeof(*server)), ip_addr2a(&ip)); find_socket: #ifdef USE_TLS if (unlikely(type==PROTO_TLS)) @@ -1223,6 +1224,7 @@ find_socket: else *res_si=sendipv6_tcp; } *res_local_addr=*from; + LM_WARN("before return my_name=%s server=%s ip=%s\n", su2a(&my_name, sizeof(my_name)), su2a(server, sizeof(*server)), ip_addr2a(&ip)); return s; error: if (s!=-1) tcp_safe_close(s); --- This gives following output: WARNING: <core> [tcp_main.c:1210]: tcp_do_connect(): after getsockname() my_name=192.168.47.132:5061 server=192.168.47.132:5061 ip=10.10.235.9 WARNING: <core> [tcp_main.c:1227]: tcp_do_connect(): before return my_name=192.168.47.132:5061 server=192.168.47.132:5061 ip=10.10.235.9 Are tcp endpoint values really wrong way around or did I undertand something wrong about their meaning? I am running Kamailio 4.2.5 (x86_64/linux) 61d84c-dirty from git. -- Mikko Lehto

2 3

Kamailio Contact header read-only
by Ali Taher 04 Jun '15

04 Jun '15

Hello, I'm trying to change contact header in SIP response message by stripping first characters (for testing only) as below : $ct = $(ct{s.strip,25}); But I got below error saying that $ct is read-only: 0(15410) : <core> [cfg.y:3419]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 575, column 5-7: read only pvar in assignment left side ERROR: bad config file (1 errors) The question is how can I change contact header before it's sending of Kamailio? Thanks Ali

2 7

SIP Auth Realm - From domain or Request domain ?
by jay binks 04 Jun '15

04 Jun '15

I have a questions in regards to SIP Auth, and specifically how Asterisk 13 with PJSIP appears to send Invites. It seems that the typical Kamailio config sends the SIP auth challenge with the from domain as the auth realm. however in the case of the Asterisk 13 ( PJSIP ) invite, the from domain is an RFC1918 IP address and I would have to use the domain from the request. What im wanting to know is what the consensus is on where the auth realm comes from. does everyone 100% agree that you send auth using the SIP From header, or is this something that some do Request domain ? What im considering doing is to use the from domain, but if from domain = RFC1918 then use request domain. Im just after everyone's opinion on how to best handle this invite, from a auth_challenge perspective. ( not so much if the Asterisk 13 PJSIP module is doing the right or wrong thing ) INVITE sip:555111222333@sip.mytestdomain.com:5060 SIP/2.0 Via: SIP/2.0/UDP 180.111.222.333:5060;rport;branch=z9hG4bKPjafb111a9-aaaf-4c9e-b456-748514855a06 From: <sip:555111222333@172.18.90.1 >;tag=88317259-052b-4997-bd2e-9c8836e27b47 To: <sip:555111222333@sip.netsip.net.au> Contact: <sip:9d43c8df-6378-4266-89c1-0a0bb0e1d0d1@180.111.222.333:5060> Call-ID: b7da52e2-dfd1-434e-a2c2-b28e1683ce0e -- Sincerely Jay

2 1

Fwd: Kamailio start failed
by Gopalakrishnan N 03 Jun '15

03 Jun '15

Hi, I have added the ASTERISK integration in kamailio.cfg, after adding those, am not able to start kamailio service, its getting failed, attached is the script. Any help would be appreciated. Thank you with regards, Gopalkrishnan N. Mob: +91 99404 91346 VoIP call - sip:saigop@gtalk2voip.com

2 4

Need help to configure rtpporyx
by Mir Jee 03 Jun '15

03 Jun '15

Hi! Please help me to configure rtpproxy on centos + kamailio.

2 1

lookup() to fork execution of routing script?
by Andrey Utkin 03 Jun '15

03 Jun '15

Hi! Currently we have the following logic in our Kamailio routing script. On incoming INVITE, we lookup() the location of called party, then we analyse the updated Request-URI ($ru) regarding callee contact protocol: is it websocket-based or not, to distinguish web-based useragents from classic SIP agents and provide RTP profiles interconnection with rtpengine (RTP/SAVPF for web-based, RTP/AVPF for the rest). After that, we relay the mangled INVITE to callee location(s) with t_relay(). The issue arises when callee has both websocket-based and classic useragents registered simultaneously. According to lookup() manual, it replaces Req-URI with just one contact, and somehow also attach metainformation about additional locations, so that t_relay() forks the call. lookup() does not provide the possibility to fork the execution of routing script, so that we could execute our routing logic described above. But I would love this to be possible, because the only alternative way for calling to multiple locations seems to be the serial forking described in TM module manual. But we don't need serial calling contact-by-contact, waiting for call failures, we need parallel calling to all available user locations. So we need an advice how to go. Is there a way to implement what we need at scripting level, or should this feature be implemented in Kamailio code (or is it already there?). Thanks in advance for any help. -- Andrey Utkin

2 2

Kamailio LCR Multiple choices
by Ali Taher 03 Jun '15

03 Jun '15

Hello, I'm using LCR module to send multiple choices. Everything works fine so far , yet I have a problem that last gateway comes first, then gateways are ordered correctly. Below is correct sorting of gateways: First gateway : 192.168.26.4 Second gateway: 192.168.26.1 Third gateway : 192.168.26.6 Below is Invite response I'm getting, as you can see 192.168.26.6 (last gateway) is included as the first gateway , then 192.168.26.4 (first gateway) comes next. Via: SIP/2.0/UDP 192.168.26.3:37066;branch=z9hG4bK-d8754z-885c37410729cc3b-1---d8754z-;rport= 37066;received=192.168.26.3 To: "9612"<sip:9612@192.168.110.181>;tag=b27e1a1d33761e85846fc98f5f3a7e58.8d8f From: "5000"<sip:5000@192.168.110.181>;tag=aa37be29 CSeq: 1 INVITE Call-ID: NTY0YjVmYzZiNzc3ZDA3ZDA3MmM0OGM1ZDBhZGZhNTM. Contact: <sip:9612@192.168.26.6>, <sip:9612@192.168.26.4>, <sip:9612@192.168.26.1>, <sip:9612@192.168.26.6> Below is routing block I'm using : if (is_method("INVITE")) { if (!load_gws(1, $rU, $fu)) { sl_send_reply("502", "Unable to load Gateways"); exit; } else while(next_gw()) { append_branch(); } sl_send_reply("300","Multiple Choices"); exit; } Appreciate your help. Regards, Ali

2 7

delay on "location" table update
by Al S 03 Jun '15

03 Jun '15

Hi, I was wondering if it's normal for "location" table to be updated almost 10 sec after receiving REGISTER. Thanks,Al

2 1

Potential CNXCC bug
by Jay Patel 02 Jun '15

02 Jun '15

I am trying to use cnxcc for credit control . It seems like dialog and cnxcc modules are getting out of sync. For some reason , I see cnxcc.active_clients gets stuck and they never clear up. Interestingly only calls that gets failure 5xx and 4xx from PSTN gateway gets stuck, all successful calls are cleared . I have made sure , I have setflag(DLG_FLAG) 1st line in my routing logic. If you need my routing script, I can share with you . Am I missing anything obvious? As you can see , "dlg.list" is empty, ( no calls in progress in system.) kamcmd> dlg.list kamcmd> But , two user are stuck ( 1 with 6 calls in progress and another with 2 calls in progress) kamcmd> cnxcc.active_clients client_id:917044056840,number_of_calls:6,concurrent_calls:0,type:1,max_amount:0.000000,consumed_amount:0.000000; client_id:971554578191,number_of_calls:2,concurrent_calls:0,type:1,max_amount:0.000000,consumed_amount:0.000000; Here are the call dumps for both users. kamcmd> cnxcc.check_client s:971554578191 id:0,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:7.690000,global_max_amount:0.00000 id:1,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:7.690000,global_max_amount:0.00000 kamcmd> kamcmd> kamcmd> cnxcc.check_client s:917044056840 id:0,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.00000 id:1,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:2,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:3,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:4,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:5,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.00000 kamcmd>

1 0

Jump to page:

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