[SR-Users] NDB_REDIS password to REDIS remote DB

2015-01-29 Thread Yuriy Gorlichenko
Hello. I try to use NDB_REDIS with remote REDIS DB and can not to connect
because remote DB use password, but Kamailio module have no any variable or
attr of modparam that implenets password for DB.

How I can connect to my REDIS?
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


[SR-Users] Dialog module is crashing after setting track_cseq_updates to 1

2015-01-29 Thread Fernando Aquilino
Hi,

after setting track_cseq_updates to 1 in module dialog (and calling
dlg_manage() from request_route) I'm getting reproducible crashes in both
stable (4.2.2) and dev (4.3.0-dev3, 2015-01-28) releases.

I made the change to cope with CSeq not being incremented when sending
another INVITE with authentication information with by calling
uac_auth()/append_branch()/t_relay(). The SIP trunk on the asterisk server
I'm forwarding the request to requires so and sends me an 401
Unauthorized message after the first INVITE.

Anyone using it would help me with the configuration?

Should I post to the dev list?


Thanks for any help,
Fernando Aquilino



 kamailio.cfg 

modparam(uac,credential,username:domain:password)
modparam(uac,auth_realm_avp,$avp(i:101))
modparam(uac,auth_username_avp,$avp(i:102))
modparam(uac,auth_password_avp,$avp(i:103))
modparam(uac,restore_mode,none)

modparam(dialog, track_cseq_updates, 1)
modparam(dialog, dlg_flag, 4)

...

failure_route[serial] {

if (t_check_status(401|407)) {
if (isflagset(auth_sent)) {
xlog(Authentication failed on SIP Trunk: $ru);

} else {

#realm
$avp(i:101) = asterisk;
#username
$avp(i:102) = user123;
#password
$avp(i:103) = pass123;

if (uac_auth()) {

setflag(auth_sent);
t_on_failure(serial);
append_branch();
t_relay();
}
}
exit;
}


if (!t_next_contacts()) {
exit;
}

t_on_failure(serial);
t_relay();
}




 debug log 

Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog
[dlg_cseq.c:215]: dlg_cseq_msg_sent(): traking cseq updates
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog
[dlg_hash.c:633]: dlg_lookup(): ref dlg 0x7f9eeb4aec20 with 1 - 2
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog
[dlg_hash.c:635]: dlg_lookup(): dialog id=9870 found on entry 2115
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog
[dlg_cseq.c:249]: dlg_cseq_msg_sent(): uac auth request - cseq inc needed
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog
[dlg_var.c:248]: print_lists(): Internal var-list ((nil)):
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog
[dlg_var.c:258]: print_lists(): Dialog var-list (0x7f9eeb4b2f38):
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog
[dlg_var.c:263]: print_lists(): cseq_diff=1 (flags 1)
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9856]: CRITICAL: core
[pass_fd.c:275]: receive_fd(): EOF on 20
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9856]: DEBUG: core
[tcp_main.c:3445]: handle_ser_child(): dead child 10, pid 9838 (shutting
down?)
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9856]: DEBUG: core
[io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0x96cfe0, 20, -1, 0x0)
fd_no=37 called
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9828]: ALERT: core
[main.c:727]: handle_sigs(): child process 9838 exited by a signal 11
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9828]: ALERT: core
[main.c:730]: handle_sigs(): core was not generated
Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9828]: INFO: core
[main.c:742]: handle_sigs(): terminating due to SIGCHLD




 core dump* 

root@kamailio:/etc/kamailio# gdb kamailio core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/sbin/kamailio...Reading symbols from
/usr/lib/debug/.build-id/62/86ce2a5e0241120986e5ec3ed803be5b945076.debug...done.
done.
[New LWP 3077]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `   '.
Program terminated with signal 11, Segmentation fault.
#0  0x7fbe4ba33dae in memcpy (__len=18446744073709551522,
__src=0x7fbe47c9f121, __dest=0x712ada6d) at
/usr/include/x86_64-linux-gnu/bits/string3.h:52
52  return __builtin___memcpy_chk (__dest, __src, __len, __bos0
(__dest));




Re: [SR-Users] Core dump while saving user location in mongo

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

can you give the parameters for usrloc module? Are you using DB_ONLY mode?

Cheers,
Daniel

On 29/01/15 08:55, Mickael Marrache wrote:

 Hi,

  

 When my proxy receives a REGISTER request, it crashes while saving the
 user location in MongoDB.

  

 This is the backtrace from the core dump:

  

 #0  0x003f08e32625 in raise () from /lib64/libc.so.6

 #1  0x003f08e33e05 in abort () from /lib64/libc.so.6

 #2  0x006196f9 in fm_free (qm=0x7f4368bf7010, p=0x210add0,
 file=0x7f4367fd7608 core: db_res.c, func=0x7f4367fd8100
 db_free_columns, line=86) at mem/f_malloc.c:588

 #3  0x7f4367fc37ab in db_free_columns (_r=0x7f4368ca0430) at
 db_res.c:86

 #4  0x7f4367fc479e in db_free_result (_r=0x7f4368ca0430) at
 db_res.c:134

 #5  0x7f4367da37cb in db_mongodb_free_result (_h=0x7f4368c94718,
 _r=0x7f4368ca0430) at mongodb_dbase.c:646

 #6  0x7f4367da5d65 in db_mongodb_query (_h=0x7f4368c94718,
 _k=0x7fffa03d5550, _op=0x0, _v=0x7fffa03d5510, _c=0x7fffa03d5560,
 _n=1, _nc=16, _o=0x7f4365ed2c80, _r=0x7fffa03d5508) at mongodb_dbase.c:783

 #7  0x7f4365cac7d2 in db_load_urecord (_c=0x7f4368c94718,
 _d=0x7f436154a0e8, _aor=0x7fffa03d59d0) at udomain.c:601

 #8  0x7f4365cb1e8e in get_urecord (_d=0x7f436154a0e8,
 _aor=0x7fffa03d59d0, _r=0x7fffa03d5760) at udomain.c:1106

 #9  0x7f4365a75dea in add_contacts (_m=0x7f4368cbdc40,
 _d=0x7f436154a0e8, _a=0x7fffa03d59d0, _mode=1, _use_regid=1) at save.c:832

 #10 0x7f4365a77d32 in save (_m=0x7f4368cbdc40, _d=0x7f436154a0e8,
 _cflags=4, _uri=0x0) at save.c:986

 #11 0x7f4365a606db in w_save2 (_m=0x7f4368cbdc40,
 _d=0x7f436154a0e8 H\240TaC\177, _cflags=0x4 Address 0x4 out of
 bounds) at reg_mod.c:447

 #12 0x0041d489 in do_action (h=0x7fffa03d6180,
 a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1100

 #13 0x00429a7a in run_actions (h=0x7fffa03d6180,
 a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1583

 #14 0x0042a0df in run_actions_safe (h=0x7fffa03d7470,
 a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1648

 #15 0x00540b7c in rval_get_int (h=0x7fffa03d7470,
 msg=0x7f4368cbdc40, i=0x7fffa03d6658, rv=0x7f4368c72830, cache=0x0) at
 rvalue.c:924

 #16 0x00544db4 in rval_expr_eval_int (h=0x7fffa03d7470,
 msg=0x7f4368cbdc40, res=0x7fffa03d6658, rve=0x7f4368c72828) at
 rvalue.c:1918

 #17 0x005451aa in rval_expr_eval_int (h=0x7fffa03d7470,
 msg=0x7f4368cbdc40, res=0x7fffa03d6ae0, rve=0x7f4368c72070) at
 rvalue.c:1926

 #18 0x0041ce4e in do_action (h=0x7fffa03d7470,
 a=0x7f4368c73148, msg=0x7f4368cbdc40) at action.c:1064

 #19 0x00429a7a in run_actions (h=0x7fffa03d7470,
 a=0x7f4368c71cc0, msg=0x7f4368cbdc40) at action.c:1583

 #20 0x00419dea in do_action (h=0x7fffa03d7470,
 a=0x7f4368c3bdb8, msg=0x7f4368cbdc40) at action.c:712

 #21 0x00429a7a in run_actions (h=0x7fffa03d7470,
 a=0x7f4368c33898, msg=0x7f4368cbdc40) at action.c:1583

 #22 0x0042a1a7 in run_top_route (a=0x7f4368c33898,
 msg=0x7f4368cbdc40, c=0x0) at action.c:1669

 #23 0x0050747e in receive_msg (

 buf=0xa6f780 REGISTER sip::5060;transport=tcp
 SIP/2.0\r\nVia: SIP/2.0/UDP
 X;branch=z9hG4bK242c.26de52a75c8675f6757e0958454a0ad5.0;i=1\r\nv:
 SIP/2.0/TCP XX:62051;received=...,

 len=1004, rcv_info=0x7fffa03d7760) at receive.c:216

 #24 0x00606e76 in udp_rcv_loop () at udp_server.c:521

 #25 0x004a5c97 in main_loop () at main.c:1629

 #26 0x004aaf2a in main (argc=13, argv=0x7fffa03d7b78) at
 main.c:2561

  

 I tested multiple times, it occurs everytime.

  

 Let me know if you need more information.

  

 Thanks,

 Mickael



 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dispatcher weight dont work

2015-01-29 Thread Yuriy Gorlichenko
Will, thanks for your answer. I already implemented my own lgorithm without
using dispatcher module. It works better for me. Now I try to implement it
with REDIS for faster results.

2015-01-29 1:35 GMT+03:00 Will Ferrer will.fer...@switchsoft.com:

 Hi Yuri

 I shared your issue with my business partner who works on the configs with
 me. I had remembered he had some similar issue he pinged me about some time
 back.

 His response to your issue follows:

 Looks like he is missing flags 8 and the trailing ; after weight in attrs.
 CREATE TABLE `dispatcher` (
 `id`   `setid` `destination` `flags` `priority` `attrs`  `description`
 1 1 sip:10.0.0.1 8 1 weight=50;
 2 1 sip:10.0.0.2 8 2 weight=50;

 To see if it changes is being used by Kamailio run:
 kamcmd dispatcher.list

 BODY: weight=50  -- this is the raw attrs
 WEIGHT: 50 -- this show that the attribute has been processed.

 {
 NRSETS: 1
 RECORDS: {
 SET: {
 ID: 1
 TARGETS: {
 DEST: {
 URI: sip:10.0.0.1
 FLAGS: AP
 PRIORITY: 1
 ATTRS: {
 BODY: weight=50
 DUID:
 MAXLOAD: 0
 WEIGHT: 50
 }
 }
 DEST: {
 URI: sip:10.0.0.2
 FLAGS: AP
 PRIORITY: 1
 ATTRS: {
 BODY: weight=50
 DUID:
 MAXLOAD: 0
 WEIGHT: 50
 }
 }
 }
 }
 }
 }

 I hope that helps.

 All the best.

 Will

 On Tue, Jan 27, 2015 at 3:12 AM, Yuriy Gorlichenko ovoshl...@gmail.com
 wrote:

 Hello I use dipatcher  algorithm 8 that works with weight. I added  2
 Asterisks and try to call its with my kam.We use 4.3 version.

 Tthis config select needed dst from database with my scenario.

 if(!ds_select_dst($var(setid), 8))

 $var(setid)- is variable for setting setid that i get from database with
 my own scenario. IT does not matter.

 When running asterisk with weight 90 - all calls goes through it. When I
 starting asterisk with weight 10 -calls going through asterisk 90. When I
 shut down asterisk with weight 90 -calls goes through asterisk 10? but when
 i start asterisk weight 90 all calls goes through sterisk 10 until I shut
 down it.

 root@Kamailio:~# kamailio -v
 version: kamailio 4.3.0-dev3 (x86_64/linux) 8cdbe7
 flags: STATS: Off, USE_TCP, USE_TLS, 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: 8cdbe7
 compiled on 01:17:56 Jan 21 2015 with gcc 4.8.2


 id setid   destination  flags priority attrs
 1   2   sip:34.25.123.45:506000  0 weight=10



 2   2   sip:10.0.1.6:506000  0weight=90

 modparam(dispatcher, db_url,DBURL)
 modparam(dispatcher, table_name, dispatcher)
 modparam(dispatcher, setid_col, setid)
 modparam(dispatcher, destination_col, destination)
 modparam(dispatcher, force_dst, 1)
 modparam(dispatcher, flags, 3)
 modparam(dispatcher, dst_avp, $avp(i:271))
 modparam(dispatcher, grp_avp, $avp(i:272))
 modparam(dispatcher, cnt_avp, $avp(i:273))
 modparam(dispatcher, ds_ping_from, sip:proxy@10.0.1.1)
 modparam(dispatcher, ds_ping_interval,15)
 modparam(dispatcher, ds_probing_mode, 1)
 modparam(dispatcher, ds_ping_reply_codes,
 class=2;code=403;code=404;code=484;class=3)
 modparam(tm, reparse_on_dns_failover, 0)


 Thanks

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users 

[SR-Users] Setting dialog variable when BYE is received before accounting

2015-01-29 Thread Mickael Marrache
Hi,

 

Is there a way to set a dialog variable when a BYE is received so that it
can be written in a CDR?

 

I tried as follows but it didn't work:

 

if (loose_route()) {

  ..

  if(is_method(BYE)) {

if(is_direction(downstream)) {

 #Call disconnected by caller

 $dlg_var(dr) = 700;

} else {

#Call disconnected by callee

$dlg_var(dr) = 701;

}

xlog(Setting disconnect reason to $dlg_var(dr)\n);

  }

  ..

  exit;

}

 

The xlog statement prints:

 

ERROR: script: Setting disconnect reason to null

 

The doc states:

 

This pseudo-variable will be available only for subsequential requests after
doing loose_route().

 

Thanks,

Mickael

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Dialog module is crashing after setting track_cseq_updates to 1

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

I pushed a patch in master branch, can you try with latest git? The
issue happened when cseq was before the via.

If reported to work ok, I will backport.

Cheers,
Daniel

On 28/01/15 21:14, Fernando Aquilino wrote:
 Hi,

 after setting track_cseq_updates to 1 in module dialog (and calling
 dlg_manage() from request_route) I'm getting reproducible crashes in
 both stable (4.2.2) and dev (4.3.0-dev3, 2015-01-28) releases.

 I made the change to cope with CSeq not being incremented when sending
 another INVITE with authentication information with by calling
 uac_auth()/append_branch()/t_relay(). The SIP trunk on the asterisk
 server I'm forwarding the request to requires so and sends me an 401
 Unauthorized message after the first INVITE.

 Anyone using it would help me with the configuration?

 Should I post to the dev list?


 Thanks for any help,
 Fernando Aquilino

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Core dump while saving user location in mongo

2015-01-29 Thread Mickael Marrache
The parameters:

 

modparam(usrloc, db_url,
mongodb://DB_MONGO_HOST:DB_MONGO_PORT/DB_MONGO_DBNAME)

modparam(usrloc, db_mode, 3)

modparam(usrloc, use_domain, 0)

modparam(usrloc, timer_interval, 60)

 

Yes, I use DB_ONLY (3) mode.

 

Mickael

 

From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of
Daniel-Constantin Mierla
Sent: Thursday, January 29, 2015 12:23 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Core dump while saving user location in mongo

 

Hello,

can you give the parameters for usrloc module? Are you using DB_ONLY mode?

Cheers,
Daniel

On 29/01/15 08:55, Mickael Marrache wrote:

Hi,

 

When my proxy receives a REGISTER request, it crashes while saving the user
location in MongoDB.

 

This is the backtrace from the core dump:

 

#0  0x003f08e32625 in raise () from /lib64/libc.so.6

#1  0x003f08e33e05 in abort () from /lib64/libc.so.6

#2  0x006196f9 in fm_free (qm=0x7f4368bf7010, p=0x210add0,
file=0x7f4367fd7608 core: db_res.c, func=0x7f4367fd8100
db_free_columns, line=86) at mem/f_malloc.c:588

#3  0x7f4367fc37ab in db_free_columns (_r=0x7f4368ca0430) at db_res.c:86

#4  0x7f4367fc479e in db_free_result (_r=0x7f4368ca0430) at db_res.c:134

#5  0x7f4367da37cb in db_mongodb_free_result (_h=0x7f4368c94718,
_r=0x7f4368ca0430) at mongodb_dbase.c:646

#6  0x7f4367da5d65 in db_mongodb_query (_h=0x7f4368c94718,
_k=0x7fffa03d5550, _op=0x0, _v=0x7fffa03d5510, _c=0x7fffa03d5560, _n=1,
_nc=16, _o=0x7f4365ed2c80, _r=0x7fffa03d5508) at mongodb_dbase.c:783

#7  0x7f4365cac7d2 in db_load_urecord (_c=0x7f4368c94718,
_d=0x7f436154a0e8, _aor=0x7fffa03d59d0) at udomain.c:601

#8  0x7f4365cb1e8e in get_urecord (_d=0x7f436154a0e8,
_aor=0x7fffa03d59d0, _r=0x7fffa03d5760) at udomain.c:1106

#9  0x7f4365a75dea in add_contacts (_m=0x7f4368cbdc40,
_d=0x7f436154a0e8, _a=0x7fffa03d59d0, _mode=1, _use_regid=1) at save.c:832

#10 0x7f4365a77d32 in save (_m=0x7f4368cbdc40, _d=0x7f436154a0e8,
_cflags=4, _uri=0x0) at save.c:986

#11 0x7f4365a606db in w_save2 (_m=0x7f4368cbdc40, _d=0x7f436154a0e8
H\240TaC\177, _cflags=0x4 Address 0x4 out of bounds) at reg_mod.c:447

#12 0x0041d489 in do_action (h=0x7fffa03d6180, a=0x7f4368c71e98,
msg=0x7f4368cbdc40) at action.c:1100

#13 0x00429a7a in run_actions (h=0x7fffa03d6180, a=0x7f4368c71e98,
msg=0x7f4368cbdc40) at action.c:1583

#14 0x0042a0df in run_actions_safe (h=0x7fffa03d7470,
a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1648

#15 0x00540b7c in rval_get_int (h=0x7fffa03d7470,
msg=0x7f4368cbdc40, i=0x7fffa03d6658, rv=0x7f4368c72830, cache=0x0) at
rvalue.c:924

#16 0x00544db4 in rval_expr_eval_int (h=0x7fffa03d7470,
msg=0x7f4368cbdc40, res=0x7fffa03d6658, rve=0x7f4368c72828) at rvalue.c:1918

#17 0x005451aa in rval_expr_eval_int (h=0x7fffa03d7470,
msg=0x7f4368cbdc40, res=0x7fffa03d6ae0, rve=0x7f4368c72070) at rvalue.c:1926

#18 0x0041ce4e in do_action (h=0x7fffa03d7470, a=0x7f4368c73148,
msg=0x7f4368cbdc40) at action.c:1064

#19 0x00429a7a in run_actions (h=0x7fffa03d7470, a=0x7f4368c71cc0,
msg=0x7f4368cbdc40) at action.c:1583

#20 0x00419dea in do_action (h=0x7fffa03d7470, a=0x7f4368c3bdb8,
msg=0x7f4368cbdc40) at action.c:712

#21 0x00429a7a in run_actions (h=0x7fffa03d7470, a=0x7f4368c33898,
msg=0x7f4368cbdc40) at action.c:1583

#22 0x0042a1a7 in run_top_route (a=0x7f4368c33898,
msg=0x7f4368cbdc40, c=0x0) at action.c:1669

#23 0x0050747e in receive_msg (

buf=0xa6f780 REGISTER sip::5060;transport=tcp
SIP/2.0\r\nVia: SIP/2.0/UDP
X;branch=z9hG4bK242c.26de52a75c8675f6757e0958454a0ad5.0;i=1\r\nv:
SIP/2.0/TCP XX:62051;received=...,

len=1004, rcv_info=0x7fffa03d7760) at receive.c:216

#24 0x00606e76 in udp_rcv_loop () at udp_server.c:521

#25 0x004a5c97 in main_loop () at main.c:1629

#26 0x004aaf2a in main (argc=13, argv=0x7fffa03d7b78) at main.c:2561

 

I tested multiple times, it occurs everytime.

 

Let me know if you need more information.

 

Thanks,

Mickael






___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users





-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Core dump while saving user location in mongo

2015-01-29 Thread Daniel-Constantin Mierla
Also, give the error messages from syslog file.

Cheers,
Daniel

On 29/01/15 11:23, Daniel-Constantin Mierla wrote:
 Hello,

 can you give the parameters for usrloc module? Are you using DB_ONLY mode?

 Cheers,
 Daniel

 On 29/01/15 08:55, Mickael Marrache wrote:

 Hi,

  

 When my proxy receives a REGISTER request, it crashes while saving
 the user location in MongoDB.

  

 This is the backtrace from the core dump:

  

 #0  0x003f08e32625 in raise () from /lib64/libc.so.6

 #1  0x003f08e33e05 in abort () from /lib64/libc.so.6

 #2  0x006196f9 in fm_free (qm=0x7f4368bf7010, p=0x210add0,
 file=0x7f4367fd7608 core: db_res.c, func=0x7f4367fd8100
 db_free_columns, line=86) at mem/f_malloc.c:588

 #3  0x7f4367fc37ab in db_free_columns (_r=0x7f4368ca0430) at
 db_res.c:86

 #4  0x7f4367fc479e in db_free_result (_r=0x7f4368ca0430) at
 db_res.c:134

 #5  0x7f4367da37cb in db_mongodb_free_result (_h=0x7f4368c94718,
 _r=0x7f4368ca0430) at mongodb_dbase.c:646

 #6  0x7f4367da5d65 in db_mongodb_query (_h=0x7f4368c94718,
 _k=0x7fffa03d5550, _op=0x0, _v=0x7fffa03d5510, _c=0x7fffa03d5560,
 _n=1, _nc=16, _o=0x7f4365ed2c80, _r=0x7fffa03d5508) at
 mongodb_dbase.c:783

 #7  0x7f4365cac7d2 in db_load_urecord (_c=0x7f4368c94718,
 _d=0x7f436154a0e8, _aor=0x7fffa03d59d0) at udomain.c:601

 #8  0x7f4365cb1e8e in get_urecord (_d=0x7f436154a0e8,
 _aor=0x7fffa03d59d0, _r=0x7fffa03d5760) at udomain.c:1106

 #9  0x7f4365a75dea in add_contacts (_m=0x7f4368cbdc40,
 _d=0x7f436154a0e8, _a=0x7fffa03d59d0, _mode=1, _use_regid=1) at
 save.c:832

 #10 0x7f4365a77d32 in save (_m=0x7f4368cbdc40, _d=0x7f436154a0e8,
 _cflags=4, _uri=0x0) at save.c:986

 #11 0x7f4365a606db in w_save2 (_m=0x7f4368cbdc40,
 _d=0x7f436154a0e8 H\240TaC\177, _cflags=0x4 Address 0x4 out of
 bounds) at reg_mod.c:447

 #12 0x0041d489 in do_action (h=0x7fffa03d6180,
 a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1100

 #13 0x00429a7a in run_actions (h=0x7fffa03d6180,
 a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1583

 #14 0x0042a0df in run_actions_safe (h=0x7fffa03d7470,
 a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1648

 #15 0x00540b7c in rval_get_int (h=0x7fffa03d7470,
 msg=0x7f4368cbdc40, i=0x7fffa03d6658, rv=0x7f4368c72830, cache=0x0)
 at rvalue.c:924

 #16 0x00544db4 in rval_expr_eval_int (h=0x7fffa03d7470,
 msg=0x7f4368cbdc40, res=0x7fffa03d6658, rve=0x7f4368c72828) at
 rvalue.c:1918

 #17 0x005451aa in rval_expr_eval_int (h=0x7fffa03d7470,
 msg=0x7f4368cbdc40, res=0x7fffa03d6ae0, rve=0x7f4368c72070) at
 rvalue.c:1926

 #18 0x0041ce4e in do_action (h=0x7fffa03d7470,
 a=0x7f4368c73148, msg=0x7f4368cbdc40) at action.c:1064

 #19 0x00429a7a in run_actions (h=0x7fffa03d7470,
 a=0x7f4368c71cc0, msg=0x7f4368cbdc40) at action.c:1583

 #20 0x00419dea in do_action (h=0x7fffa03d7470,
 a=0x7f4368c3bdb8, msg=0x7f4368cbdc40) at action.c:712

 #21 0x00429a7a in run_actions (h=0x7fffa03d7470,
 a=0x7f4368c33898, msg=0x7f4368cbdc40) at action.c:1583

 #22 0x0042a1a7 in run_top_route (a=0x7f4368c33898,
 msg=0x7f4368cbdc40, c=0x0) at action.c:1669

 #23 0x0050747e in receive_msg (

 buf=0xa6f780 REGISTER sip::5060;transport=tcp
 SIP/2.0\r\nVia: SIP/2.0/UDP
 X;branch=z9hG4bK242c.26de52a75c8675f6757e0958454a0ad5.0;i=1\r\nv:
 SIP/2.0/TCP XX:62051;received=...,

 len=1004, rcv_info=0x7fffa03d7760) at receive.c:216

 #24 0x00606e76 in udp_rcv_loop () at udp_server.c:521

 #25 0x004a5c97 in main_loop () at main.c:1629

 #26 0x004aaf2a in main (argc=13, argv=0x7fffa03d7b78) at
 main.c:2561

  

 I tested multiple times, it occurs everytime.

  

 Let me know if you need more information.

  

 Thanks,

 Mickael



 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

 -- 
 Daniel-Constantin Mierla
 http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Core dump while saving user location in mongo

2015-01-29 Thread Mickael Marrache
Now, it didn't crash during the REGISTER but during the INVITE:

 

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:705]:
db_mongodb_query(): query to collection [location]

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:726]:
db_mongodb_query(): query filter: { username : m1 }

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:745]:
db_mongodb_query(): columns filter: { contact : 1, expires : 1, q : 1,
callid : 1, cseq : 1, flags :

1, cflags : 1, user_agent : 1, received : 1, path : 1, socket : 1,
methods : 1, last_modified : 1, ruid : 1, instance : 1, reg_id : 1
}

kamailio[32599]: DEBUG: core [db_res.c:118]: db_new_result(): allocate 56
bytes for result set at 0x7f83a32daa48

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:203]:
db_mongodb_get_columns(): 16 columns returned from the query

kamailio[32599]: DEBUG: core [db_res.c:155]: db_allocate_columns():
allocate 128 bytes for result names at 0x7f83a32daf98

kamailio[32599]: DEBUG: core [db_res.c:165]: db_allocate_columns():
allocate 64 bytes for result types at 0x7f83a32daed8

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[0] named: contact

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[0] at
0x7f83a32daab8

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:285]:
db_mongodb_get_columns(): use DB1_STRING result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32daab8)[0]=[contact] (2)

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[1] named: expires

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[1] at
0x7f83a32dab98

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:275]:
db_mongodb_get_columns(): use DB1_DATETIME result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32dab98)[1]=[expires] (9)

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[2] named: q

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[2] at
0x7f83a32dabe0

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:270]:
db_mongodb_get_columns(): use DB1_DOUBLE result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32dabe0)[2]=[q] (1)

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[3] named: callid

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[3] at
0x7f83a32dac70

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:285]:
db_mongodb_get_columns(): use DB1_STRING result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32dac70)[3]=[callid] (2)

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[4] named: cseq

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[4] at
0x7f83a32dac28

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:260]:
db_mongodb_get_columns(): use DB1_INT result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32dac28)[4]=[cseq] (16)

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[5] named: flags

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[5] at
0x7f83a32dab50

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:260]:
db_mongodb_get_columns(): use DB1_INT result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32dab50)[5]=[flags] (16)

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[6] named: cflags

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[6] at
0x7f83a32dae50

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:260]:
db_mongodb_get_columns(): use DB1_INT result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32dae50)[6]=[cflags] (16)

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
db_mongodb_get_columns(): Found a field[7] named: user_agent

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[7] at
0x7f83a32dacb8

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:285]:
db_mongodb_get_columns(): use DB1_STRING result type

kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
db_mongodb_get_columns(): RES_NAMES(0x7f83a32dacb8)[7]=[user_agent] 

Re: [SR-Users] kamailio 4.2.1 core in timer.c:877

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

the tl content looks good, let's see the prev and next items:

p *tl-prev
p *tl-next

Cheers,
Daniel

On 29/01/15 08:49, 张顺通 wrote:
 hi  daniel, look at the following info,thks.

 (gdb) bt full
 #0  0x005fda98 in timer_list_expire (t=1263625687,
 h=0x7fa5e01c19b0, slow_l=0x7fa5e01c3010, slow_mark=325) at timer.c:877
 tl = 0x7fa5e03e77d0
 ret = 0
 #1  0x005fc686 in timer_handler () at timer.c:953
 saved_ticks = 1263625687
 run_slow_timer = 0
 i = 325
 __FUNCTION__ = timer_handler
 #2  0x005fdd4d in timer_main () at timer.c:992
 No locals.
 #3  0x004aa571 in main_loop () at main.c:1700
 i = 12
 pid = 0
 si = 0x0
 si_desc = udp receiver child=11 sock=10.103.252.159:5160
 http://10.103.252.159:5160\000\000\b\000\000\000\000\000\000\000\000\200\024\340\245\177\000\000
 ;\032\000\001\000\000\000(\325\027\340\245\177\000\000
 ;\032\000\377\177\000\000\214\216N\000\000\000\000\000\335\233}{\000\000\000\000(\325\027\340\245\177\000\000\200\032\000\377\177\000\000\000\000\000\000\001\000\000
 nrprocs = 12
 __FUNCTION__ = main_loop
 #4  0x004af166 in main (argc=11, argv=0x7fff001a3e88) at
 main.c:2561
 cfg_stream = 0x19e15e0
 c = -1
 r = 0
 tmp = 0x7fff001a4681 
 tmp_len = 32767
 port = 1719808
 proto = 32680
 options = 0x706ec0
 :f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:
 ret = -1
 seed = 3548653977
 rfd = 4
 debug_save = 0
 debug_flag = 0
 dont_fork_cnt = 0
 n_lst = 0xb
 p = 0x0
 __FUNCTION__ = main


 (gdb) p *tl

 $1 = {next = 0x0, prev = 0x7fa5e01c19b0, expire = 1263625760,
 initial_timeout = 80, data = 0x7fa5e03e7750, f = 0x7fa864720942
 wait_handler, flags = 513, 

   slow_idx = 0}


 2015-01-17 0:40 GMT+08:00 Daniel-Constantin Mierla mico...@gmail.com
 mailto:mico...@gmail.com:

 Can you get the output in gdb for:

 p *tl

 ?

 Cheers,
 Daniel


 On 16/01/15 04:29, 张顺通 wrote:
 I user rtimer module :

 loadmodule rtimer.so
 modparam(rtimer, timer, name=p_route;interval=1;mode=1;)
 modparam(rtimer, exec, timer=p_route;route=P_ROUTE)

 application will coredump in sometimes, and core file in below,
 what's the reason?

 Program terminated with signal 11, Segmentation fault.
 #0  0x005fda98 in timer_list_expire (t=1043586690,
 h=0x7f9ed45ac9b0, slow_l=0x7f9ed45adc80, slow_mark=2316) at
 timer.c:877
 877timer.c: No such file or directory.
 in timer.c
 (gdb) bt full
 #0  0x005fda98 in timer_list_expire (t=1043586690,
 h=0x7f9ed45ac9b0, slow_l=0x7f9ed45adc80, slow_mark=2316) at
 timer.c:877
 tl = 0x7f9ed47f7e98
 ret = 0
 #1  0x005fc686 in timer_handler () at timer.c:953
 saved_ticks = 1043586690
 run_slow_timer = 0
 i = 268
 __FUNCTION__ = timer_handler
 #2  0x005fdd4d in timer_main () at timer.c:992
 No locals.
 #3  0x004aa571 in main_loop () at main.c:1700
 i = 12
 pid = 0
 si = 0x0
 si_desc = udp receiver child=11
 
 sock=10.1.*.*:5160\000\000\b\000\000\000\000\000\000\000\000\060S\324\236\177\000\000\060=#z\001\000\000\000(\205V\324\236\177\000\000\060=#z\377\177\000\000\214\216N\000\000\000\000\000\037t\372D\000\000\000\000(\205V\324\236\177\000\000\220@#z\377\177\000\000\000\000\000\000\001\000\000
 nrprocs = 12
 __FUNCTION__ = main_loop
 #4  0x004af166 in main (argc=11, argv=0x7fff7a234098) at
 main.c:2561
 cfg_stream = 0x1da75e0
 c = -1
 r = 0
 tmp = 0x7fff7a234681 
 tmp_len = 32767
 port = 2049130512 tel:2049130512
 proto = 32673
 options = 0x706ec0
 :f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:
 ret = -1
 seed = 220012340
 rfd = 4
 debug_save = 0
 debug_flag = 0
 dont_fork_cnt = 0
 n_lst = 0xb
 p = 0x0
 __FUNCTION__ = main



 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

 -- 
 Daniel-Constantin Mierla
 http://twitter.com/#!/miconda http://twitter.com/#%21/miconda - 
 http://www.linkedin.com/in/miconda



-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org

Re: [SR-Users] Async module taking down our server

2015-01-29 Thread Brandon Armstead
Why not just kill the call and have billing fix up for minimum duration occur 
during CDR creation?  Does not make sense to delay Hangup just to meet minimum 
duration.

Sent from my iPhone

 On Jan 28, 2015, at 5:37 PM, Will Ferrer will.fer...@switchsoft.com wrote:
 
 Hi Daniel
 
 Yeah I am happy to be able to report the success. Thanks for everything as 
 always!
 
 I hope you are well.
 
 Will
 
 On Wed, Jan 28, 2015 at 5:54 AM, Daniel-Constantin Mierla 
 mico...@gmail.com wrote:
 Hello,
 
 great that it was sorted out and it was not on Kamailio side :-)
 
 Also, glad to hear that async processing did increase capacity to handle 
 more concurrent calls, even it was causing troubles to other applications ...
 
 Cheers,
 Daniel
 
 
 On 28/01/15 05:40, Will Ferrer wrote:
 Hello
 
 I wanted to give an update on this.
 
 My business partner that found the issue and has been monitoring the 
 problem has tracked down the issue. It turns out that the features we 
 implemented using the async module were leading to more calls going on con 
 currently (as they were intended to) and this was causing and issue with 
 voip monitor. So the issue was not with the Async module.
 
 All the best.
 
 Will Ferrer
 
 Switchsoft
 
 On Mon, Jan 19, 2015 at 8:43 PM, Will Ferrer will.fer...@switchsoft.com 
 wrote:
 Hi All
 
 We are trying to use the async module to to delay sending a bye on from 
 one end of the call to the other.
 
 We are using async_route(routename, seconds) to delay the WITHINDLG route. 
 The idea is that in the future we want to be able to have our billing min 
 duration enforced (though currently we are having issues with the dialog 
 module that we are discussing in another thread).
 
 After running this on our deploy servers, the delays before sending on the 
 byes get longer and longer, and then kamailio goes down. Then the receive 
 udp buffer fills up.
 
 We tried it with both 4 and 400 async workers, and it made no difference.
 
 I am including a screen capture of the servers stats when this happens 
 taken from voip monitor.
 
 Here are the relevant parts of the config:
 
 ...
 loadmodule async.so
 ...
 modparam(async, workers, ASYNC_THREADS)
 ...
 request_route {
 ...
 route(DELAYED_BYE_STATIC);
 ...
 route[DELAYED_BYE_STATIC] {
  xlog(L_DEBUG,route DELAYED_BYE_STATIC);
  #!ifdef WITH_DELAYED_BYE_STATIC
  if (is_method(BYE)) {
  xlog(L_DEBUG,route DELAYED_BYE_STATIC, from self \n);
  #if (from_uri == myself) {
  if ((allow_trusted() || allow_source_address())  from_uri == myself) {
  xlog(L_DEBUG,route DELAYED_BYE_STATIC, Bye detected, from self \n);
  send_reply(200, OK);
  xlog(L_DEBUG,route DELAYED_BYE_STATIC, sent 200 about to sleep \n);
  setflag(FLT_ACC); # do accounting ...
  setflag(FLT_ACCFAILED); # ... even if the transaction fails
  if (has_totag()) {
  xlog(L_DEBUG,route DELAYED_BYE_STATIC, sleeping to WITHINDLG_DELAYED 
 \n);
  async_route(WITHINDLG_DELAYED, MIN_DURATION);
  } else {
  xlog(L_DEBUG,route DELAYED_BYE_STATIC, sleeping to WITHINDLG \n);
  async_route(WITHINDLG, MIN_DURATION);
  }
  xlog(L_DEBUG,route DELAYED_BYE_STATIC, slept\n);
  exit;
  }
  }
  #!endif
  return;
 }
 ...
 route[WITHINDLG_DELAYED] {
  xlog(L_DEBUG, route WITHINDLG_DELAYED: triggered \n);
  $avp(was_delayed) = 1;
  route(WITHINDLG);
 }
 ...
 route[WITHINDLG] {
  xlog(L_DEBUG, route WITHINDLG: will -- DLG triggered, request method: 
 $rm \n);
  #!ifdef WITH_DISPATCHER
  if(is_method(BYE|CANCEL)) {
  xlog(L_DEBUG,route WITHINDLG:  cancel or bye detected, request method: 
 $rm \n);
  #!ifdef WITH_DISPATCHER_LOAD_AWARE
  xlog(L_DEBUG,route WITHINDLG: running ds_load_update, request method: 
 $rm \n);
  ds_load_update();
  #dlg_get ($ci,$ft,$tt); 
   #dlg_bye (all);
  #!endif
  }
  #!endif
 
  if (has_totag() || $avp(was_delayed) == 1) {
  xlog(L_DEBUG, route WITHINDLG: will -- DLG has totag or was_delayed: 
 $avp(was_delayed)  \n);
  # sequential request withing a dialog should
  # take the path determined by record-routing
  if (loose_route()) {
  xlog(L_DEBUG, route WITHINDLG: will -- DLG has loose route \n);
  route(DLGURI);
  if (is_method(BYE)) {
  xlog(L_DEBUG,route WITHINDLG: BYE detected);
  setflag(FLT_ACC); # do accounting ...
  setflag(FLT_ACCFAILED); # ... even if the transaction fails
  xlog(L_DEBUG,route WITHINDLG: ACC flag set);
  
  }
  else if ( is_method(ACK) ) {
  # ACK is forwarded statelessy
  route(NATMANAGE);
  }
  else if ( is_method(NOTIFY) ) {
  # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
  record_route();
  }
  xlog(L_DEBUG, route WITHINDLG: will -- DLG RELAY 1\n);
  route(RELAY);
  } else {
  xlog(L_DEBUG, route WITHINDLG: will -- DLG else \n);
  if (is_method(SUBSCRIBE)  uri == myself) {
  # in-dialog subscribe requests
  route(PRESENCE);
  exit;
  }
  if ( is_method(ACK) ) {
  xlog(L_DEBUG, route WITHINDLG: will -- DLG is ack \n);
  if ( t_check_trans() ) {
  xlog(L_DEBUG, route WITHINDLG: will -- DLG t_check_trans \n);
  # no loose-route, 

Re: [SR-Users] NDB_REDIS password to REDIS remote DB

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

it appears that hiredis library does the authentication after connecting
and can be done from config -- that's on a very quick search, not sure
if something has changed with the hiredis api meanwhile:

 - https://github.com/redis/hiredis/issues/56

Cheers,
Daniel

On 29/01/15 17:20, Marc Soda wrote:
 The only way it will work right now is to not use a password:

 modparam(ndb_redis, server,
 name=localredis;addr=localhost;port=6379)

 I've been wanting to look at contributing support at that, but no time...

 On Thu, Jan 29, 2015 at 10:16 AM, Yuriy Gorlichenko
 ovoshl...@gmail.com mailto:ovoshl...@gmail.com wrote:

 Hello. I try to use NDB_REDIS with remote REDIS DB and can not to
 connect because remote DB use password, but Kamailio module have
 no any variable or attr of modparam that implenets password for DB.

 How I can connect to my REDIS?

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
 list
 sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] NDB_REDIS password to REDIS remote DB

2015-01-29 Thread Marc Soda
The only way it will work right now is to not use a password:

modparam(ndb_redis, server, name=localredis;addr=localhost;port=6379)

I've been wanting to look at contributing support at that, but no time...
On Thu, Jan 29, 2015 at 10:16 AM, Yuriy Gorlichenko ovoshl...@gmail.com
wrote:

 Hello. I try to use NDB_REDIS with remote REDIS DB and can not to connect
 because remote DB use password, but Kamailio module have no any variable or
 attr of modparam that implenets password for DB.

 How I can connect to my REDIS?

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] NDB_REDIS password to REDIS remote DB

2015-01-29 Thread Marc Soda
Ah, so you should be able to do something like:

redis_cmd(localredis, AUTH $var(redis_password));

Nice.  I will try that and post my results.

On Thu, Jan 29, 2015 at 1:28 PM, Daniel-Constantin Mierla mico...@gmail.com
 wrote:

  Hello,

 it appears that hiredis library does the authentication after connecting
 and can be done from config -- that's on a very quick search, not sure if
 something has changed with the hiredis api meanwhile:

  - https://github.com/redis/hiredis/issues/56

 Cheers,
 Daniel


 On 29/01/15 17:20, Marc Soda wrote:

 The only way it will work right now is to not use a password:

 modparam(ndb_redis, server, name=localredis;addr=localhost;port=6379
 )

 I've been wanting to look at contributing support at that, but no time...
  On Thu, Jan 29, 2015 at 10:16 AM, Yuriy Gorlichenko ovoshl...@gmail.com
 wrote:

 Hello. I try to use NDB_REDIS with remote REDIS DB and can not to connect
 because remote DB use password, but Kamailio module have no any variable or
 attr of modparam that implenets password for DB.

 How I can connect to my REDIS?

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
 listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


 --
 Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - 
 http://www.linkedin.com/in/miconda


 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Does forking impact max_inv_lifetime?

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

I will have to look at the code in tm module to be able to comment more.
Based on your findings, it seems that it is reset, and shouldn't.

Cheers,
Daniel

On Wed, Jan 28, 2015 at 11:40 PM, Alex Balashov abalas...@evaristesys.com
wrote:

 Hi,

 To return to this topic, it definitely does not appear that
 max_inv_lifetime runs concurrently with the fr_[inv]_timers. The
 documentation suggests that max_inv_lifetime is a transaction-level
 construct that is logically independent of the fr_ timers on any particular
 branch, but that does not appear to be the case.

 I tested with a UAS that sends continuous 183 Session Progress ad
 infinitum. My TM parameters are:

modparam(tm, fr_timer, 3000)# 3 seconds
modparam(tm, fr_inv_timer, 12)   # was: 4.
modparam(tm, fr_inv_timer_avp, $avp(inv_timer))
modparam(tm, max_inv_lifetime, 6)

 Now, one critical aspect of this issue is that I initially set
 $avp(inv_timer) to 10 sec to deal with PDD. This is reset to the default
 120s in an onreply_route using t_reset_fr() once a 18x or 2xx reply is
 received:

 if(t_check_status(1[1-9][0-9]|200))
 t_reset_fr();

 The top of my failure_route looks like this:

 failure_route[ROUTE_OUTBOUND_TRY_FAILURE] {
 if(t_is_canceled()) {
 xlog(L_INFO, [FR-ROUTE-OUTBOUND-TRY-FAILURE:$ci] - 
 Transaction cancelled\n);

 return;
 }

 if(t_is_expired()) {
 xlog(L_INFO, [FR-ROUTE-OUTBOUND-TRY-FAILURE:$ci] - 
 Transaction timed out because max_inv_lifetime
 has been reached; no more attempts will be made\n);

 t_reply(503, Service Unavailable);
 exit;
 }

 if(t_branch_timeout()) {
 xlog(L_INFO, [FR-ROUTE-OUTBOUND-TRY-FAILURE:$ci] - 
 Route attempt timed out\n);
 }

 ...
 }

 So, my expectation would be that even though the successive 183s cause the
 fr_inv_timer to be reset every time and thus never hit, that
 max_inv_lifetime would kick in at 60 seconds and thus kill the transaction.

 Instead, here's what happens:

 [Jan 28 16:24:36] Initial INVITE --
 [Jan 28 16:24:36] -- 100 Trying
 [Jan 28 16:24:38] -- 183 Session Progress
 [Jan 28 16:25:26] -- 183 Session Progress
 [Jan 28 16:26:01] -- 183 Session Progress
 [Jan 28 16:26:03] -- 183 Session Progress
 [Jan 28 16:26:25] -- 183 Session Progress
 [Jan 28 16:26:59] -- 183 Session Progress
 [Jan 28 16:27:31] -- 183 Session Progress
 [Jan 28 16:28:03] -- 183 Session Progress
 [Jan 28 16:28:25] -- 183 Session Progress
 [Jan 28 16:28:59] -- 183 Session Progress
 [Jan 28 16:29:26] -- 183 Session Progress
 [Jan 28 16:29:36] -- max_inv_lifetime finally hits, and branch is
 CANCEL'd by Kamailio, i.e.

 Jan 28 16:29:36 sip /usr/local/sbin/kamailio[5816]: INFO: script:
 [FR-ROUTE-OUTBOUND-TRY-FAILURE:4551-5851-9ab6@x.x.x.x] - Transaction
 timed out because max_inv_lifetime has been reached; no more attempts will
 be made

 That's a full 5 minutes later!

 Furthermore, if I remove the t_reset_fr() call in the onreply_route and
 don't initialise $avp(inv_timer) to 10 sec, everything works like clockwork
 and max_inv_lifetime does kick in after 60 seconds, as expected.

 So, there is definitely some logical connection between the
 fr_[inv]_timers and max_inv_lifetime, although the documentation seems to
 suggest otherwise.

 Any insight would be appreciated!


 --
 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/




-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/micond
http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


[SR-Users] Can kamailio generate a PRACK

2015-01-29 Thread Rahul MathuR
Hello,

I was wondering whether Kamailio (as proxy) can generate a PRACK on its own
( since one of the custom written dialer is not sending PRACK) ?
Is there any way I can achieve this ?



-- 
Warm Regds.
MathuRahul
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Possible memory leak dealing with presence in kamailio

2015-01-29 Thread Nuno Reis
Hi Juha and all.

I understand that and that is what the RFC says. It seems pua module does
that right. Although something is clearly not right in my production
environment because kamailio memory consumption still grows pretty fast.
Kamailio memory usage starts in ~500MB and after ~24H kamailio is using
~3GB. If I disable kamailio from listening on the localhost(127.0.0.1)
where pua is generating the SIP Publishes kamailio just keeps around the
~500MB all the time.
This is a small production environment with 70 extensions with Yealink
phones.
Any ideas on how to chase down this memory leak? Should I open a git issue
for this one?



--

*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nr...@wavecom.pt
WAVECOM-Soluções Rádio, S.A.
Cacia Park | Rua do Progresso, Lote 15
3800-639 AVEIRO | Portugal
T. +351 309 700 225 | F. +351 234 919 191
*GPS
http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88
| www.wavecom.pt http://www.wavecom.pt/** http://www.wavecom.pt/*

[image: Description: Description: WavecomSignature]
http://www.wavecom.pt/pt/wavecom/premios.php

[image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php



On Wed, Jan 21, 2015 at 8:45 PM, Juha Heinanen j...@tutpro.com wrote:

 Nuno Reis writes:

  Here my publisher is Kamailio itself. Can someone elaborate a bit more on
  this issue and maybe we can get to bottom of it?

 when your application issues initial publish request, it does so without
 SIP-If-Match header.  200 ok from presence server then contains an etag
 in SIP-ETag header. when your application refreshes the publish, it must
 place this etag in SIP-If-Match header to prevent presence server from
 creating a new publication.

 for subscribes, your application must place in re-subscribe the
 same event header id param as the previous one had in order for the
 presence server to know that subscribe was not a new subscription.

 -- juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] why do not support tcp:eth1:5062,only support eht1:5062

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

can you give the log messages with debug=3 in your config file?

Cheers,
Daniel

On Thu, Jan 29, 2015 at 8:54 AM, 张顺通 shuntongzh...@gmail.com wrote:

 especially i want to use tls:eth1:5063

 2015-01-29 15:52 GMT+08:00 张顺通 shuntongzh...@gmail.com:

 what can i do to user tcp:eth1:5062

 2014-11-12 10:53 GMT+08:00 张顺通 shuntongzh...@gmail.com:

 why do not support tcp:eth1:5062,only support eht1:5062?
 I need to bind on eth1 only tcp.




 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/micond
http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Core dump while saving user location in mongo

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

I pushed a patch that takes care of initializing the columns array of the
result - it is in the master branch for now.

However, the log messages don't seem to be complete, were you sending all.
The backtrace shows a line which is executed only if an error message is
printed, it is not in the logs you sent.

One thing that I remembered was that usrloc requires parameter
db_insert_null to be set in order to work with mongodb:

-
http://kamailio.org/docs/modules/stable/modules/usrloc.html#usrloc.p.db_insert_null

The crash shouldn't happen and hopefully the patch I pushed catches it. Try
the patch without db_insert_null just to see if there is still a crash or
not.

Cheers,
Daniel

On Thu, Jan 29, 2015 at 11:51 AM, Mickael Marrache 
mickaelmarra...@gmail.com wrote:

 Now, it didn't crash during the REGISTER but during the INVITE:



 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:705]:
 db_mongodb_query(): query to collection [location]

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:726]:
 db_mongodb_query(): query filter: { username : m1 }

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:745]:
 db_mongodb_query(): columns filter: { contact : 1, expires : 1, q :
 1, callid : 1, cseq : 1, flags :

 1, cflags : 1, user_agent : 1, received : 1, path : 1, socket :
 1, methods : 1, last_modified : 1, ruid : 1, instance : 1, reg_id
 : 1 }

 kamailio[32599]: DEBUG: core [db_res.c:118]: db_new_result(): allocate
 56 bytes for result set at 0x7f83a32daa48

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:203]:
 db_mongodb_get_columns(): 16 columns returned from the query

 kamailio[32599]: DEBUG: core [db_res.c:155]: db_allocate_columns():
 allocate 128 bytes for result names at 0x7f83a32daf98

 kamailio[32599]: DEBUG: core [db_res.c:165]: db_allocate_columns():
 allocate 64 bytes for result types at 0x7f83a32daed8

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
 db_mongodb_get_columns(): Found a field[0] named: contact

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
 db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[0] at
 0x7f83a32daab8

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:285]:
 db_mongodb_get_columns(): use DB1_STRING result type

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
 db_mongodb_get_columns(): RES_NAMES(0x7f83a32daab8)[0]=[contact] (2)

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
 db_mongodb_get_columns(): Found a field[1] named: expires

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
 db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[1] at
 0x7f83a32dab98

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:275]:
 db_mongodb_get_columns(): use DB1_DATETIME result type

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
 db_mongodb_get_columns(): RES_NAMES(0x7f83a32dab98)[1]=[expires] (9)

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
 db_mongodb_get_columns(): Found a field[2] named: q

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
 db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[2] at
 0x7f83a32dabe0

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:270]:
 db_mongodb_get_columns(): use DB1_DOUBLE result type

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
 db_mongodb_get_columns(): RES_NAMES(0x7f83a32dabe0)[2]=[q] (1)

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
 db_mongodb_get_columns(): Found a field[3] named: callid

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
 db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[3] at
 0x7f83a32dac70

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:285]:
 db_mongodb_get_columns(): use DB1_STRING result type

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
 db_mongodb_get_columns(): RES_NAMES(0x7f83a32dac70)[3]=[callid] (2)

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
 db_mongodb_get_columns(): Found a field[4] named: cseq

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
 db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[4] at
 0x7f83a32dac28

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:260]:
 db_mongodb_get_columns(): use DB1_INT result type

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
 db_mongodb_get_columns(): RES_NAMES(0x7f83a32dac28)[4]=[cseq] (16)

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
 db_mongodb_get_columns(): Found a field[5] named: flags

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:250]:
 db_mongodb_get_columns(): allocate 16 bytes for RES_NAMES[5] at
 0x7f83a32dab50

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:260]:
 db_mongodb_get_columns(): use DB1_INT result type

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:314]:
 db_mongodb_get_columns(): RES_NAMES(0x7f83a32dab50)[5]=[flags] (16)

 kamailio[32599]: DEBUG: db_mongodb [mongodb_dbase.c:231]:
 db_mongodb_get_columns(): Found a field[6] named: cflags

 

Re: [SR-Users] Possible memory leak dealing with presence in kamailio

2015-01-29 Thread Daniel-Constantin Mierla
Hello,

which memory is increasing? shared or private memory? or is system memory?

Cheers,
Daniel

On Fri, Jan 30, 2015 at 4:24 AM, Nuno Reis nr...@wavecom.pt wrote:

 Hi Juha and all.

 I understand that and that is what the RFC says. It seems pua module does
 that right. Although something is clearly not right in my production
 environment because kamailio memory consumption still grows pretty fast.
 Kamailio memory usage starts in ~500MB and after ~24H kamailio is using
 ~3GB. If I disable kamailio from listening on the localhost(127.0.0.1)
 where pua is generating the SIP Publishes kamailio just keeps around the
 ~500MB all the time.
 This is a small production environment with 70 extensions with Yealink
 phones.
 Any ideas on how to chase down this memory leak? Should I open a git issue
 for this one?



 --

 *Nuno Miguel Reis* | *Unified Communication** Systems*
 M. +351 913907481 | nr...@wavecom.pt
 WAVECOM-Soluções Rádio, S.A.
 Cacia Park | Rua do Progresso, Lote 15
 3800-639 AVEIRO | Portugal
 T. +351 309 700 225 | F. +351 234 919 191
 *GPS
 http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88
 | www.wavecom.pt http://www.wavecom.pt/** http://www.wavecom.pt/*

 [image: Description: Description: WavecomSignature]
 http://www.wavecom.pt/pt/wavecom/premios.php

 [image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php



 On Wed, Jan 21, 2015 at 8:45 PM, Juha Heinanen j...@tutpro.com wrote:

 Nuno Reis writes:

  Here my publisher is Kamailio itself. Can someone elaborate a bit more
 on
  this issue and maybe we can get to bottom of it?

 when your application issues initial publish request, it does so without
 SIP-If-Match header.  200 ok from presence server then contains an etag
 in SIP-ETag header. when your application refreshes the publish, it must
 place this etag in SIP-If-Match header to prevent presence server from
 creating a new publication.

 for subscribes, your application must place in re-subscribe the
 same event header id param as the previous one had in order for the
 presence server to know that subscribe was not a new subscription.

 -- juha





-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/micond
http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users