sr-users April 2013

sr-users@lists.kamailio.org

94 participants
133 discussions

loose_route received parameter question
by Juha Heinanen 08 Apr '13

08 Apr '13

in my test, proxy p2 receives initial request from proxy p1, that has this kind of R-URI and Route header: INVITE sip:47089231@192.98.102.10:41073;transport=tcp SIP/2.0. Route: <sip:192.98.102.20:5070;transport=tcp;lr;received='sip:192.98.102.10:49127;transport=tcp'> route header is result of calling lookup in p1 on record: AOR:: jh(a)test.fi Contact:: sip:47089231@192.98.102.10:41073;transport=tcp Q=0.5 Expires:: 114 Callid:: 0ed240f3-dc79-4d65-93ef-3e92d178a892 Cseq:: 12 User-agent:: sipsimple 0.34.0 Received:: sip:192.98.102.10:49127;transport=tcp Path:: <sip:192.98.102.20:5070;transport=tcp;lr;received='sip:192.98.102.10:49127;transport=tcp'> i would expect that loose_route() would set $du to received parameter value, but it does not, because i get to syslog: Apr 8 12:44:54 wheezy1 /usr/sbin/sip-proxy[5723]: INFO: Trying to relay to du <<null>> or ru <sip:47089231@192.98.102.10:41073;transport=tcp> how can i tell p2 to set $du to received uri? do i need to add another route header in p1 that contains received uri? -- juha

2 2

pkg mem problems. Leaking?
by Jon Bonilla 08 Apr '13

08 Apr '13

Hi all I have two different kamailio servers running in a single machine. The first one is a sl proxy and the second one acts as stateful proxy/registrar. From time to time the stateless one goes out of pkg mem. It has 8MB (also tried with 16 in another setup). The sl proxy listens the public interface for external connections and the loopback interface for conecting to the stateful proxy. As I have seen since I installed a mem debug kamailio 3.3.2 version there 6 days ago, the internal socket children have grown on mem usage while the external ones remain more or less stable. As example one uf the external udp receivers uses less than 1MB while one of the internal ones uses almost 6MB. I'm attaching the mem dump of one of those internal udp receiver processes via "ngcp-sercmd lb cfg.set_now_int core mem_dump_pkg 25437" command. I see several tens of thousands of lines like these ones: N address=0x7fd1207383c0 frag=0x7fd120738390 size=56 used=1 alloc'd from <core>: parser/parse_param.c: parse_params(539) start check=f0f0f0f0, end check= c0c0c0c0, abcdefed I have no idea about how to continue debugging this. I'm pasting some more info regarding the process list, mem status and kamailio version/flags. Thanks sp1:~# ngcp-sercmd lb ps 25416 attendant 25429 udp receiver child=0 sock=77.77.77.77:5060 25430 udp receiver child=1 sock=77.77.77.77:5060 25431 udp receiver child=2 sock=77.77.77.77:5060 25432 udp receiver child=3 sock=77.77.77.77:5060 25433 udp receiver child=4 sock=77.77.77.77:5060 25434 udp receiver child=5 sock=77.77.77.77:5060 25435 udp receiver child=6 sock=77.77.77.77:5060 25436 udp receiver child=7 sock=77.77.77.77:5060 25437 udp receiver child=0 sock=127.0.0.1:5060 25438 udp receiver child=1 sock=127.0.0.1:5060 25439 udp receiver child=2 sock=127.0.0.1:5060 25440 udp receiver child=3 sock=127.0.0.1:5060 25441 udp receiver child=4 sock=127.0.0.1:5060 25442 udp receiver child=5 sock=127.0.0.1:5060 25443 udp receiver child=6 sock=127.0.0.1:5060 25444 udp receiver child=7 sock=127.0.0.1:5060 25445 slow timer 25446 timer 25447 ctl handler 25448 MI FIFO 25449 tcp receiver (generic) child=0 25450 tcp receiver (generic) child=1 25451 tcp receiver (generic) child=2 25452 tcp receiver (generic) child=3 25453 tcp receiver (generic) child=4 25454 tcp receiver (generic) child=5 25455 tcp receiver (generic) child=6 25456 tcp receiver (generic) child=7 25457 tcp receiver (tcp:127.0.0.1:5060) child=8 25458 tcp receiver (tcp:127.0.0.1:5060) child=9 25459 tcp main process sp1:~# ngcp-sercmd lb pkg.stats { entry: 0 pid: 25416 rank: 0 used: 901136 free: 15417544 real_used: 1359672 } { entry: 1 pid: 25429 rank: 1 used: 909360 free: 15408648 real_used: 1368568 } { entry: 2 pid: 25430 rank: 2 used: 909400 free: 15408608 real_used: 1368608 } { entry: 3 pid: 25431 rank: 3 used: 909352 free: 15408656 real_used: 1368560 } { entry: 4 pid: 25432 rank: 4 used: 909344 free: 15408664 real_used: 1368552 } { entry: 5 pid: 25433 rank: 5 used: 909392 free: 15408712 real_used: 1368504 } { entry: 6 pid: 25434 rank: 6 used: 909344 free: 15408664 real_used: 1368552 } { entry: 7 pid: 25435 rank: 7 used: 909344 free: 15408664 real_used: 1368552 } { entry: 8 pid: 25436 rank: 8 used: 909352 free: 15408656 real_used: 1368560 } { entry: 9 pid: 25437 rank: 9 used: 5884872 free: 2480784 real_used: 14296432 } { entry: 10 pid: 25438 rank: 10 used: 5935272 free: 2359728 real_used: 14417488 } { entry: 11 pid: 25439 rank: 11 used: 5971616 free: 2305912 real_used: 14471304 } { entry: 12 pid: 25440 rank: 12 used: 5821672 free: 2522672 real_used: 14254544 } { entry: 13 pid: 25441 rank: 13 used: 5945584 free: 2310056 real_used: 14467160 } { entry: 14 pid: 25442 rank: 14 used: 5868760 free: 2495264 real_used: 14281952 } { entry: 15 pid: 25443 rank: 15 used: 5903672 free: 2457952 real_used: 14319264 } { entry: 16 pid: 25444 rank: 16 used: 5899208 free: 2453872 real_used: 14323344 } { entry: 17 pid: 25445 rank: -1 used: 983944 free: 15409512 real_used: 2267696 } { entry: 18 pid: 25446 rank: -1 used: 909168 free: 15409512 real_used: 1367704 } { entry: 19 pid: 25447 rank: -2 used: 983664 free: 15407912 real_used: 2267032 } { entry: 20 pid: 0 rank: 0 used: 918424 free: 15400064 real_used: 1377152 } { entry: 21 pid: 25449 rank: 17 used: 989192 free: 15329200 real_used: 1448016 } { entry: 22 pid: 25450 rank: 18 used: 989192 free: 15329200 real_used: 1448016 } { entry: 23 pid: 25451 rank: 19 used: 989192 free: 15329200 real_used: 1448016 } { entry: 24 pid: 25452 rank: 20 used: 989192 free: 15329200 real_used: 1448016 } { entry: 25 pid: 25453 rank: 21 used: 989192 free: 15329200 real_used: 1448016 } { entry: 26 pid: 25454 rank: 22 used: 989192 free: 15329200 real_used: 1448016 } { entry: 27 pid: 25455 rank: 23 used: 989192 free: 15329200 real_used: 1448016 } { entry: 28 pid: 25456 rank: 24 used: 989192 free: 15329200 real_used: 1448016 } { entry: 29 pid: 25457 rank: 25 used: 989192 free: 15329200 real_used: 1448016 } { entry: 30 pid: 25458 rank: 26 used: 989192 free: 15329200 real_used: 1448016 } { entry: 31 pid: 25459 rank: -4 used: 983240 free: 15334096 real_used: 2266992 } sp1:~# kamailio -V version: kamailio 3.3.2 (x86_64/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_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 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 13:08:06 Oct 31 2012 with gcc 4.4.5

3 3

usrloc + multimaster replication
by Alex Balashov 08 Apr '13

08 Apr '13

I know I'm revisiting a problem that has been discussed in multiple threads from various angles, so I might be rightly accused of laziness in neglecting to research them all. All the same: I have proxy1 and proxy2 writing to database A and database B, respectively. Database A and database B are active-active masters, synchronised via some replication system attached to the underlying DB technology. The 'location' table is also replicated this way. We know that 'usrloc' doesn't work so well with this: one instance of Kamailio will periodically delete the other's contacts, even if they have a nonlocal SIP domain. Is there any db_mode that can be used (other than 0/purely in-memory) to make this work right? Or is that the essential problem that p_usrloc is written to solve? Thanks, -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

4 12

problem with core forward function
by Juha Heinanen 08 Apr '13

08 Apr '13

now that the send function issue got resolved, i tried core forward function. core cookbook tells: forward Forward the SIP request to the given destination in stateless mode. This has the format of [proto:]host[:port]. Host can be an IP or hostname; supported protocols are UDP, TCP and TLS. (For TLS, you need to compile the TLS support into core). If proto or port are not specified, NAPTR and SRV lookups will be used to determine them (if possible). If destination parameter is missing, the forward will be done based on RURI. Example of usage: forward("10.0.0.10:5060"); #or forward(); i then went i tried forward("tcp:192.98.102.20:5070"); but got errors from that line: Apr 7 13:52:10 siika /usr/sbin/sip-proxy[22923]: : <core> [proxy.c:278]: ERROR: mk_proxy: could not resolve hostname: "tcp:192.98.102.20:5070" Apr 7 13:52:10 siika /usr/sbin/sip-proxy[22923]: ERROR: <core> [route.c:1214]: fixing failed (code=-478) at cfg:/etc/sip-proxy/sip-proxy.cfg:1584 i also tried with forward_tcp("192.98.102.20:5070"); but it didn't help either: Apr 7 13:54:24 siika /usr/sbin/sip-proxy[23056]: : <core> [proxy.c:278]: ERROR: mk_proxy: could not resolve hostname: "192.98.102.20:5070" Apr 7 13:54:24 siika /usr/sbin/sip-proxy[23056]: ERROR: <core> [route.c:1214]: fixing failed (code=-478) at cfg:/etc/sip-proxy/sip-proxy.cfg:1584 how should core cookbook be fixed this time? -- juha

2 2

expired record not removed from location table
by Juha Heinanen 08 Apr '13

08 Apr '13

i have seen emails about expired records not removed from database, but i could not find the thread. i'm not sure if it is related, but today i noticed too that there is an old record in my location table which has expired couple of hours ago. the record does not show up with ul_dump command, so it has been removed from memory. usrloc db_mode=1. what could cause the record not be removed? is it a bug in cleaner process? i have usrloc timer_procs=2. -- juha

2 3

textops warning
by Juha Heinanen 07 Apr '13

07 Apr '13

i don't remember seeing this before: Apr 7 19:09:57 siika /usr/sbin/sip-proxy[8734]: WARNING: textops [textops.c:1816]: free function has not been defined for spve what should i do about it? -- juha

1 1

looks like send core function does not exist
by Juha Heinanen 07 Apr '13

07 Apr '13

i removed corex from loaded modules and added string argument to send: send("192.98.102.20:5070"); that gave error: 0(15695) ERROR: <core> [cfg.y:3415]: cfg. parser: failed to find command send 0(15695) : <core> [cfg.y:3554]: parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 1578, column 34: unknown command, missing loadmodule? according to core cookbook: send Send the original SIP message to a specific destination in stateless mode. No changes are applied to received message, no Via header is added. Host can be an IP or hostname. Used protocol: UDP Parameter is mandatory and has string format. Example of usage: send("10.10.10.10:5070"); does anyone know what is going on? -- juha

2 2

Re: [SR-Users] sip_trace unable to capture after next_branches()
by Ramaseshi reddy kolli 06 Apr '13

06 Apr '13

Hi, I have tried by setting flag only but still no luck,Here is the configuration i am using. # sip trace modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "db_url", "") modparam("siptrace", "duplicate_uri", "sip:homer.com:9060") modparam("siptrace", "duplicate_with_hep", 1) modparam("siptrace", "trace_flag", 22) modparam("siptrace", "trace_on", 1) #HEPv2 == timestamp will be included to HEP header modparam("siptrace", "hep_version", 2) setflag(22); if (!t_relay()) { xlog("L_ERR", "CALL $ci - Relay error\n"); sl_reply_error(); exit; } Thanks Ram

2 1

forward to pseudo var destination
by Juha Heinanen 06 Apr '13

06 Apr '13

looks like forward core function does not accept pseudo var argument. then i found this: I just committed a patch that allow using send() without any parameter: * http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=8e4db80… if that commit is still valid, it is not reflected by core cookbook: send Send the original SIP message to a specific destination in stateless mode. No changes are applied to received message, no Via header is added. Host can be an IP or hostname. Used protocol: UDP Parameter is mandatory and has string format. Example of usage: send("10.10.10.10:5070"); so which way this is? -- juha

2 2

Changing Domain in To URI
by qmail＠polarismail.com 06 Apr '13

06 Apr '13

Sorry if I repeat myself - I just subscribed properly to the list: > if you don't need to change it back for replies and next requests, try: > > $td = "xyz.com"; > > IIRC, that is available on 3.2.x. If not, either you upgrade or use > replace functions from textops. > > Cheers, > Daniel Thank you for replying. We tried the direct assignment of $td="xyz.com" but the variable doesn't change. We are doing an xlog print right after and an ngrep and we confirmed that the domain part of the URI doesn't change. I also tried a subst() and it's the same problem. I read on the online documentation that the variable is read-only and I figured it can't be changed through these methods. That's why I tried uac_replace_to(). To sum it up, is that variable read-only or not ?

3 5

← Newer
1
...
8
9
10
11
12
13
14
Older →

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