[SR-Users] selecting memory manager at startup

[Daniel-Constantin Mierla]

Hello,

(cross-posting as it is relevant to user community as well).

I just pushed a bunch of patches to master branch that will allow
selecting the memory manger at kamailio startup, no longer needed to
re-compile sources. There are two new command line parameters:

* -x name: select the memory manager for shm
* -X name: select the memory manager for pkg
* if -x is provided but -X is not provided, then pkg uses same
memory manager as shm
* name can be:
* fm - fast malloc (f_malloc)
* qm - quick malloc (q_malloc)
* default memory manager is fm (what was default so far)

Both f_malloc and q_malloc are now compiled, selecting one or the other
being possible. Other managers expected to be added in the list soon,
especially TLSF, added not that long ago by Camille Oudot. Maybe
reviving Doug Lea malloc (existing in dl_malloc.c) worth a try now that
can be easily used.

The debugging mode for each memory manager is controlled by DB_SR_MEMORY
define via Makefile.defs -- right now it is enabled. All enabled memory
mangers must be compiled either with or without DB_SR_MEMORY (it won't
work to have one memory manger with DB_SR_MEMORY and another one without).

Using system malloc for private (pkg) memory is possible by removing the
define of PKG_MALLOC from Makefile.defs (same as it was before). This is
a mode suitable for troubleshooting using external tools such as
valgrind, because it does inline replacement of pkg_malloc() with
malloc(), so those tools can track the place of allocation. I plan to
add a system malloc custom manager, to allow selecting it with -X
(system malloc won't work for shm management, because it is only for
private memory).

There is no performance impact at runtime, it is only the startup
procedure that replaces the pointers to memory management functions.

Hopefully with the new mechanism will be able to track easier memory
issues -- e.g., qm malloc is better for troubleshooting, using it no
longer requires recompilation, just starting kamailio with -x qm.

Feedback, especially testing, will be very appreciated!

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat


___
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] Authentication issue during registration

[Daniel Tryba]

On Monday 14 September 2015 11:22:10 Austin Einter wrote:
> So my question is, why Kamailio sends 401 repeatedly even if it received
> proper Authorization header.

Log the return code from the *_authenticate function and see why kamailio is 
challenging again (e.g. 
http://kamailio.org/docs/modules/stable/modules/auth_db.html#auth_db.f.www_authenticate
)

___
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] ha1 password authentication without plain text password

[Daniel-Constantin Mierla]

Hello,

On 13/09/15 20:58, Nabeel wrote:
>
> Hi,
>
> My SIP client only uses the 'ha1' password column from the database to
> authenticate users.  It does not require the 'password' column. 
> However, I am not able to register without having the plain text
> password present in the 'password' column in the database.  I need to
> change this behaviour so that user registration will occur using only
> the ha1 encoded password column. How can I make this change?  I tried
> commenting out and changing the 'password_column' attribute in the
> config but could not get it to work.
>

you have to set the password collumn to point to ha1 and then set
calculate_ha1 parameter to 0.

http://kamailio.org/docs/modules/stable/modules/auth_db.html#auth_db.p.calculate_ha1

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat

___
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] Very high load average after upgrade to Kamailio v4.3.2

[M S]

Hi,

Over last weekend i upgraded one of my test servers from Kamailio
v4.3.1-4d1b65 to latest stable release v4.3.2-07690f and now kamailio goes
crazy even with single call (I am using same db and configuration of
course).

As soon as call establishes system load average (as seen in top command)
starts increasing and soon it increases beyond 6.0 and system becomes
completely unresponsive, sip messages are no longer being processed by
kamailio service. Even after call hangup, system remains under high load.
The "htop" indicates that IO Wait time has increased substantially.

Any idea what is causing this? For now i have reverted by to v4.3.1-4d1b65
but can go to v4.3.2-07690f again if you need further info or testing.

Thank you.
___
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] [sr-dev] Very high load average after upgrade to Kamailio v4.3.2

[Daniel-Constantin Mierla]

Hello,

I will review the changes pushed to 4.3.2 vs 4.3.1. Can you send here
the list of modules you are using? The loadmodule lines in kamailio.cfg.

Cheers,
Daniel

On 14/09/15 10:51, M S wrote:
> Hi,
>
> Over last weekend i upgraded one of my test servers from Kamailio
> v4.3.1-4d1b65 to latest stable release v4.3.2-07690f and now kamailio
> goes crazy even with single call (I am using same db and configuration
> of course).
>
> As soon as call establishes system load average (as seen in top
> command) starts increasing and soon it increases beyond 6.0 and system
> becomes completely unresponsive, sip messages are no longer being
> processed by kamailio service. Even after call hangup, system remains
> under high load. The "htop" indicates that IO Wait time has increased
> substantially.
>
> Any idea what is causing this? For now i have reverted by to
> v4.3.1-4d1b65 but can go to v4.3.2-07690f again if you need further
> info or testing.
>
> Thank you.
>
>
> ___
> sr-dev mailing list
> sr-...@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat

___
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] [sr-dev] Very high load average after upgrade to Kamailio v4.3.2

[M S]

Sure, here is the list of module in given order,

--
loadmodule "db_mysql.so"
loadmodule "mi_fifo.so"
loadmodule "mi_datagram.so"
loadmodule "kex.so"
loadmodule "corex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "outbound.so"
loadmodule "rr.so"
loadmodule "path.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "sdpops.so"
loadmodule "textops.so"
loadmodule "textopsx.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "cfg_rpc.so"
loadmodule "mi_rpc.so"
loadmodule "dialog.so"
loadmodule "acc.so"
loadmodule "uac.so"
loadmodule "rtimer.so"
loadmodule "sqlops.so"
loadmodule "ndb_redis.so"
loadmodule "app_perl.so"
loadmodule "permissions.so"
loadmodule "domain.so"
loadmodule "async.so"
loadmodule "stun.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "alias_db.so"
loadmodule "speeddial.so"
loadmodule "presence.so"
loadmodule "presence_mwi.so"
loadmodule "presence_xml.so"
loadmodule "presence_profile.so"
loadmodule "nathelper.so"
loadmodule "rtpengine.so"
loadmodule "tls.so"
loadmodule "htable.so"
loadmodule "pike.so"
loadmodule "xmlrpc.so"
loadmodule "debugger.so"
loadmodule "xhttp.so"
loadmodule "xhttp_rpc.so"
loadmodule "xhttp_pi.so"
loadmodule "xcap_server.so"
loadmodule "pua.so"
loadmodule "pua_mi.so"
loadmodule "rls.so"
loadmodule "cfgutils.so"
loadmodule "htable.so"
loadmodule "msrp.so"
loadmodule "websocket.so"
loadmodule "msilo.so"
loadmodule "siptrace.so"
--

In "top" i see at least 6 kamailio processes using very high cpu (perhaps
these are the 6 child processes involved in that single call processing).

Thank you.



On Mon, Sep 14, 2015 at 11:28 AM, Daniel-Constantin Mierla <
mico...@gmail.com> wrote:

> Hello,
>
> I will review the changes pushed to 4.3.2 vs 4.3.1. Can you send here the
> list of modules you are using? The loadmodule lines in kamailio.cfg.
>
> Cheers,
> Daniel
>
>
> On 14/09/15 10:51, M S wrote:
>
> Hi,
>
> Over last weekend i upgraded one of my test servers from Kamailio
> v4.3.1-4d1b65 to latest stable release v4.3.2-07690f and now kamailio goes
> crazy even with single call (I am using same db and configuration of
> course).
>
> As soon as call establishes system load average (as seen in top command)
> starts increasing and soon it increases beyond 6.0 and system becomes
> completely unresponsive, sip messages are no longer being processed by
> kamailio service. Even after call hangup, system remains under high load.
> The "htop" indicates that IO Wait time has increased substantially.
>
> Any idea what is causing this? For now i have reverted by to v4.3.1-4d1b65
> but can go to v4.3.2-07690f again if you need further info or testing.
>
> Thank you.
>
>
> ___
> sr-dev mailing 
> listsr-...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - 
> http://www.linkedin.com/in/miconda
> Book: SIP Routing With Kamailio - http://www.asipto.com
> Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - 
> http://asipto.com/u/kat
>
>
> ___
> 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] [sr-dev] Very high load average after upgrade to Kamailio v4.3.2

[M S]

OK runtime debugging shows something is wrong with dialog module, all 6
processes are locked in trying to access dialog module when 200 OK is
received for the call. For example, here is the BT of one the processes,

--
#0  0xb77a0424 in __kernel_vsyscall ()
#1  0xb76c140c in sched_yield () from
/lib/i386-linux-gnu/i686/cmov/libc.so.6
#2  0xb5a20206 in get_lock (lock=0xa55058e4) at ../../mem/../fastlock.h:277
#3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11302) at dlg_hash.c:610
#4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa598a2b0) at dlg_hash.c:643
#5  0xb5a14143 in dlg_onreply (t=0xa5989358, type=2, param=0xbff3a0ac) at
dlg_handlers.c:429
#6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5989398, type=2,
trans=0xa5989358, params=0xbff3a0ac) at t_hooks.c:268
#7  0xb5f781a3 in run_trans_callbacks (type=2, trans=0xa5989358,
req=0xa598a308, rpl=0xb68cc6e8, code=200) at t_hooks.c:295
#8  0xb5f84b14 in t_reply_matching (p_msg=0xb68cc6e8, p_branch=0xbff3a5a4)
at t_lookup.c:966
#9  0xb5f868c4 in t_check_msg (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4)
at t_lookup.c:1069
#10 0xb5f871fd in t_check (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4) at
t_lookup.c:
#11 0xb5fc9b4e in reply_received (p_msg=0xb68cc6e8) at t_reply.c:2134
#12 0x080c9142 in do_forward_reply (msg=0xb68cc6e8, mode=0) at forward.c:747
#13 0x080ca61c in forward_reply (msg=0xb68cc6e8) at forward.c:849
#14 0x08138aab in receive_msg (
buf=0x840f6c0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
X.X.X.X;rport=5060;branch=z9hG4bK719e.844788c1e820e6096cb00d2b2f6c613d.0\r\nVia:
SIP/2.0/UDP
192.168.3.10;received=Y.Y.Y.Y;rport=5060;branch=z9hG4bKlzzjpctt\r\nRe"...,
len=1103, rcv_info=0xbff3a93c) at receive.c:255
#15 0x082188d0 in udp_rcv_loop () at udp_server.c:495
#16 0x080dec65 in main_loop () at main.c:1573
#17 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
--

Here is BT of second process,

--
#0  0xb77a0424 in __kernel_vsyscall ()
#1  0xb76c140c in sched_yield () from
/lib/i386-linux-gnu/i686/cmov/libc.so.6
#2  0xb5a20206 in get_lock (lock=0xa55058e4) at ../../mem/../fastlock.h:277
#3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11301) at dlg_hash.c:610
#4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa5985060) at dlg_hash.c:643
#5  0xb5a140c4 in dlg_ontdestroy (t=0xa5985424, type=131072,
param=0xbff3a7ac) at dlg_handlers.c:398
#6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5985464,
type=131072, trans=0xa5985424, params=0xbff3a7ac) at t_hooks.c:268
#7  0xb5f781a3 in run_trans_callbacks (type=131072, trans=0xa5985424,
req=0x0, rpl=0x0, code=0) at t_hooks.c:295
#8  0xb5f3cbbb in free_cell (dead_cell=0xa5985424) at h_table.c:128
#9  0xb5f7cb20 in wait_handler (ti=1848316837, wait_tl=0xa598546c,
data=0xa5985424) at timer.c:648
#10 0x0820d8f8 in timer_list_expire (t=1848316837, h=0xa530e718,
slow_l=0xa530e7ec, slow_mark=6) at timer.c:873
#11 0x0820dcc0 in timer_handler () at timer.c:938
#12 0x0820e0d8 in timer_main () at timer.c:977
#13 0x080df4e0 in main_loop () at main.c:1644
#14 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
--

Does this makes any sense to you? Let me know if you need anything else.

Thank you.



On Mon, Sep 14, 2015 at 11:36 AM, M S  wrote:

> Sure, here is the list of module in given order,
>
> --
> loadmodule "db_mysql.so"
> loadmodule "mi_fifo.so"
> loadmodule "mi_datagram.so"
> loadmodule "kex.so"
> loadmodule "corex.so"
> loadmodule "tm.so"
> loadmodule "tmx.so"
> loadmodule "sl.so"
> loadmodule "outbound.so"
> loadmodule "rr.so"
> loadmodule "path.so"
> loadmodule "pv.so"
> loadmodule "maxfwd.so"
> loadmodule "usrloc.so"
> loadmodule "registrar.so"
> loadmodule "sdpops.so"
> loadmodule "textops.so"
> loadmodule "textopsx.so"
> loadmodule "siputils.so"
> loadmodule "xlog.so"
> loadmodule "sanity.so"
> loadmodule "ctl.so"
> loadmodule "cfg_rpc.so"
> loadmodule "mi_rpc.so"
> loadmodule "dialog.so"
> loadmodule "acc.so"
> loadmodule "uac.so"
> loadmodule "rtimer.so"
> loadmodule "sqlops.so"
> loadmodule "ndb_redis.so"
> loadmodule "app_perl.so"
> loadmodule "permissions.so"
> loadmodule "domain.so"
> loadmodule "async.so"
> loadmodule "stun.so"
> loadmodule "auth.so"
> loadmodule "auth_db.so"
> loadmodule "alias_db.so"
> loadmodule "speeddial.so"
> loadmodule "presence.so"
> loadmodule "presence_mwi.so"
> loadmodule "presence_xml.so"
> loadmodule "presence_profile.so"
> loadmodule "nathelper.so"
> loadmodule "rtpengine.so"
> loadmodule "tls.so"
> loadmodule "htable.so"
> loadmodule "pike.so"
> loadmodule "xmlrpc.so"
> loadmodule "debugger.so"
> loadmodule "xhttp.so"
> loadmodule "xhttp_rpc.so"
> loadmodule "xhttp_pi.so"
> loadmodule "xcap_server.so"
> loadmodule "pua.so"
> loadmodule "pua_mi.so"
> loadmodule "rls.so"
> loadmodule "cfgutils.so"
> loadmodule "htable.so"
> loadmodule "msrp.so"
> loadmodule "websocket.so"
> loadmodule "msilo.so"
> loadmodule "siptrace.so"
> --
>
> In "top" i see at least 6 kamailio processes using very high cpu (perhaps
> these are the 6 child processes involved in t

Re: [SR-Users] [sr-dev] Very high load average after upgrade to Kamailio v4.3.2

[Daniel-Constantin Mierla]

I found a regression when detecting spiraled dialogs with state deleted.
That would be the case when you create a dialog for an INVITE, but you
reply with a negative response code from kamailio and then quickly a new
invite with same callid and from tag arrives.

Can you upgrade to latest version in branch 4.3, try and see if works
fine now?

Cheers,
Daniel

On 14/09/15 11:55, M S wrote:
> OK runtime debugging shows something is wrong with dialog module, all
> 6 processes are locked in trying to access dialog module when 200 OK
> is received for the call. For example, here is the BT of one the
> processes,
>
> --
> #0  0xb77a0424 in __kernel_vsyscall ()
> #1  0xb76c140c in sched_yield () from
> /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #2  0xb5a20206 in get_lock (lock=0xa55058e4) at
> ../../mem/../fastlock.h:277
> #3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11302) at dlg_hash.c:610
> #4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa598a2b0) at dlg_hash.c:643
> #5  0xb5a14143 in dlg_onreply (t=0xa5989358, type=2, param=0xbff3a0ac)
> at dlg_handlers.c:429
> #6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5989398,
> type=2, trans=0xa5989358, params=0xbff3a0ac) at t_hooks.c:268
> #7  0xb5f781a3 in run_trans_callbacks (type=2, trans=0xa5989358,
> req=0xa598a308, rpl=0xb68cc6e8, code=200) at t_hooks.c:295
> #8  0xb5f84b14 in t_reply_matching (p_msg=0xb68cc6e8,
> p_branch=0xbff3a5a4) at t_lookup.c:966
> #9  0xb5f868c4 in t_check_msg (p_msg=0xb68cc6e8,
> param_branch=0xbff3a5a4) at t_lookup.c:1069
> #10 0xb5f871fd in t_check (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4)
> at t_lookup.c:
> #11 0xb5fc9b4e in reply_received (p_msg=0xb68cc6e8) at t_reply.c:2134
> #12 0x080c9142 in do_forward_reply (msg=0xb68cc6e8, mode=0) at
> forward.c:747
> #13 0x080ca61c in forward_reply (msg=0xb68cc6e8) at forward.c:849
> #14 0x08138aab in receive_msg (
> buf=0x840f6c0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> X.X.X.X;rport=5060;branch=z9hG4bK719e.844788c1e820e6096cb00d2b2f6c613d.0\r\nVia:
> SIP/2.0/UDP
> 192.168.3.10;received=Y.Y.Y.Y;rport=5060;branch=z9hG4bKlzzjpctt\r\nRe"...,
> len=1103, rcv_info=0xbff3a93c) at receive.c:255
> #15 0x082188d0 in udp_rcv_loop () at udp_server.c:495
> #16 0x080dec65 in main_loop () at main.c:1573
> #17 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
> --
>
> Here is BT of second process,
>
> --
> #0  0xb77a0424 in __kernel_vsyscall ()
> #1  0xb76c140c in sched_yield () from
> /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #2  0xb5a20206 in get_lock (lock=0xa55058e4) at
> ../../mem/../fastlock.h:277
> #3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11301) at dlg_hash.c:610
> #4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa5985060) at dlg_hash.c:643
> #5  0xb5a140c4 in dlg_ontdestroy (t=0xa5985424, type=131072,
> param=0xbff3a7ac) at dlg_handlers.c:398
> #6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5985464,
> type=131072, trans=0xa5985424, params=0xbff3a7ac) at t_hooks.c:268
> #7  0xb5f781a3 in run_trans_callbacks (type=131072, trans=0xa5985424,
> req=0x0, rpl=0x0, code=0) at t_hooks.c:295
> #8  0xb5f3cbbb in free_cell (dead_cell=0xa5985424) at h_table.c:128
> #9  0xb5f7cb20 in wait_handler (ti=1848316837, wait_tl=0xa598546c,
> data=0xa5985424) at timer.c:648
> #10 0x0820d8f8 in timer_list_expire (t=1848316837, h=0xa530e718,
> slow_l=0xa530e7ec, slow_mark=6) at timer.c:873
> #11 0x0820dcc0 in timer_handler () at timer.c:938
> #12 0x0820e0d8 in timer_main () at timer.c:977
> #13 0x080df4e0 in main_loop () at main.c:1644
> #14 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
> --
>
> Does this makes any sense to you? Let me know if you need anything else.
>
> Thank you.
>
>
>
> On Mon, Sep 14, 2015 at 11:36 AM, M S  > wrote:
>
> Sure, here is the list of module in given order,
>
> --
> loadmodule "db_mysql.so"
> loadmodule "mi_fifo.so"
> loadmodule "mi_datagram.so"
> loadmodule "kex.so"
> loadmodule "corex.so"
> loadmodule "tm.so"
> loadmodule "tmx.so"
> loadmodule "sl.so"
> loadmodule "outbound.so"
> loadmodule "rr.so"
> loadmodule "path.so"
> loadmodule "pv.so"
> loadmodule "maxfwd.so"
> loadmodule "usrloc.so"
> loadmodule "registrar.so"
> loadmodule "sdpops.so"
> loadmodule "textops.so"
> loadmodule "textopsx.so"
> loadmodule "siputils.so"
> loadmodule "xlog.so"
> loadmodule "sanity.so"
> loadmodule "ctl.so"
> loadmodule "cfg_rpc.so"
> loadmodule "mi_rpc.so"
> loadmodule "dialog.so"
> loadmodule "acc.so"
> loadmodule "uac.so"
> loadmodule "rtimer.so"
> loadmodule "sqlops.so"
> loadmodule "ndb_redis.so"
> loadmodule "app_perl.so"
> loadmodule "permissions.so"
> loadmodule "domain.so"
> loadmodule "async.so"
> loadmodule "stun.so"
> loadmodule "auth.so"
> loadmodule "auth_db.so"
> loadmodule "alias_db.so"
> loadmodule "speeddial.so"
> loadmodule "presence.so"
>

Re: [SR-Users] [sr-dev] Very high load average after upgrade to Kamailio v4.3.2

[M S]

OK, let me test it and get back to you.

Thank you.



On Mon, Sep 14, 2015 at 12:18 PM, Daniel-Constantin Mierla <
mico...@gmail.com> wrote:

> I found a regression when detecting spiraled dialogs with state deleted.
> That would be the case when you create a dialog for an INVITE, but you
> reply with a negative response code from kamailio and then quickly a new
> invite with same callid and from tag arrives.
>
> Can you upgrade to latest version in branch 4.3, try and see if works fine
> now?
>
> Cheers,
> Daniel
>
>
> On 14/09/15 11:55, M S wrote:
>
> OK runtime debugging shows something is wrong with dialog module, all 6
> processes are locked in trying to access dialog module when 200 OK is
> received for the call. For example, here is the BT of one the processes,
>
> --
> #0  0xb77a0424 in __kernel_vsyscall ()
> #1  0xb76c140c in sched_yield () from
> /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #2  0xb5a20206 in get_lock (lock=0xa55058e4) at ../../mem/../fastlock.h:277
> #3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11302) at dlg_hash.c:610
> #4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa598a2b0) at dlg_hash.c:643
> #5  0xb5a14143 in dlg_onreply (t=0xa5989358, type=2, param=0xbff3a0ac) at
> dlg_handlers.c:429
> #6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5989398, type=2,
> trans=0xa5989358, params=0xbff3a0ac) at t_hooks.c:268
> #7  0xb5f781a3 in run_trans_callbacks (type=2, trans=0xa5989358,
> req=0xa598a308, rpl=0xb68cc6e8, code=200) at t_hooks.c:295
> #8  0xb5f84b14 in t_reply_matching (p_msg=0xb68cc6e8, p_branch=0xbff3a5a4)
> at t_lookup.c:966
> #9  0xb5f868c4 in t_check_msg (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4)
> at t_lookup.c:1069
> #10 0xb5f871fd in t_check (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4) at
> t_lookup.c:
> #11 0xb5fc9b4e in reply_received (p_msg=0xb68cc6e8) at t_reply.c:2134
> #12 0x080c9142 in do_forward_reply (msg=0xb68cc6e8, mode=0) at
> forward.c:747
> #13 0x080ca61c in forward_reply (msg=0xb68cc6e8) at forward.c:849
> #14 0x08138aab in receive_msg (
> buf=0x840f6c0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> X.X.X.X;rport=5060;branch=z9hG4bK719e.844788c1e820e6096cb00d2b2f6c613d.0\r\nVia:
> SIP/2.0/UDP
> 192.168.3.10;received=Y.Y.Y.Y;rport=5060;branch=z9hG4bKlzzjpctt\r\nRe"...,
> len=1103, rcv_info=0xbff3a93c) at receive.c:255
> #15 0x082188d0 in udp_rcv_loop () at udp_server.c:495
> #16 0x080dec65 in main_loop () at main.c:1573
> #17 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
> --
>
> Here is BT of second process,
>
> --
> #0  0xb77a0424 in __kernel_vsyscall ()
> #1  0xb76c140c in sched_yield () from
> /lib/i386-linux-gnu/i686/cmov/libc.so.6
> #2  0xb5a20206 in get_lock (lock=0xa55058e4) at ../../mem/../fastlock.h:277
> #3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11301) at dlg_hash.c:610
> #4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa5985060) at dlg_hash.c:643
> #5  0xb5a140c4 in dlg_ontdestroy (t=0xa5985424, type=131072,
> param=0xbff3a7ac) at dlg_handlers.c:398
> #6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5985464,
> type=131072, trans=0xa5985424, params=0xbff3a7ac) at t_hooks.c:268
> #7  0xb5f781a3 in run_trans_callbacks (type=131072, trans=0xa5985424,
> req=0x0, rpl=0x0, code=0) at t_hooks.c:295
> #8  0xb5f3cbbb in free_cell (dead_cell=0xa5985424) at h_table.c:128
> #9  0xb5f7cb20 in wait_handler (ti=1848316837, wait_tl=0xa598546c,
> data=0xa5985424) at timer.c:648
> #10 0x0820d8f8 in timer_list_expire (t=1848316837, h=0xa530e718,
> slow_l=0xa530e7ec, slow_mark=6) at timer.c:873
> #11 0x0820dcc0 in timer_handler () at timer.c:938
> #12 0x0820e0d8 in timer_main () at timer.c:977
> #13 0x080df4e0 in main_loop () at main.c:1644
> #14 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
> --
>
> Does this makes any sense to you? Let me know if you need anything else.
>
> Thank you.
>
>
>
> On Mon, Sep 14, 2015 at 11:36 AM, M S  wrote:
>
>> Sure, here is the list of module in given order,
>>
>> --
>> loadmodule "db_mysql.so"
>> loadmodule "mi_fifo.so"
>> loadmodule "mi_datagram.so"
>> loadmodule "kex.so"
>> loadmodule "corex.so"
>> loadmodule "tm.so"
>> loadmodule "tmx.so"
>> loadmodule "sl.so"
>> loadmodule "outbound.so"
>> loadmodule "rr.so"
>> loadmodule "path.so"
>> loadmodule "pv.so"
>> loadmodule "maxfwd.so"
>> loadmodule "usrloc.so"
>> loadmodule "registrar.so"
>> loadmodule "sdpops.so"
>> loadmodule "textops.so"
>> loadmodule "textopsx.so"
>> loadmodule "siputils.so"
>> loadmodule "xlog.so"
>> loadmodule "sanity.so"
>> loadmodule "ctl.so"
>> loadmodule "cfg_rpc.so"
>> loadmodule "mi_rpc.so"
>> loadmodule "dialog.so"
>> loadmodule "acc.so"
>> loadmodule "uac.so"
>> loadmodule "rtimer.so"
>> loadmodule "sqlops.so"
>> loadmodule "ndb_redis.so"
>> loadmodule "app_perl.so"
>> loadmodule "permissions.so"
>> loadmodule "domain.so"
>> loadmodule "async.so"
>> loadmodule "stun.so"
>> loadmodule "auth.so"
>> loadmodule "auth_db.so"
>> loadmodule "alias_db.so"
>> loadmodule "speeddial.so"
>> loadmodule "presence.so"

Re: [SR-Users] Concurrent calls after forked invite

[Daniel-Constantin Mierla]

Hello,

On 11/09/15 19:53, Lukas Hauser wrote:
> Hello,
>
> I have two UACs registered to kamailio v4.0.4 with the same URI.
> (b...@example.com)
> Then a third registered UAC (al...@example.com) sends an invite to
> b...@example.com.
>
> Both bob UACs accept the call and respond with a 200 Ok.
> The statefull proxy now takes the first one and cancels the second one.
> In my case I need both responses to be send back to alice through the
> proxy.
>
> I want the Invite to be forked in parallel (works) and both calls to
> get connected concurrently (does not work).
>
> Is there such a feature in the statefull proxy?
> Can this be done using a stateless proxy?
in stateful mode (tm processing), kamailio sends CANCEL to all the other
active branches when it receives a 200ok. Even there are 200ok requests,
is unlikely to be able to process both at the same time, so one or the
other will cancel the rest of the branches.

Probably you can achieve what you want quite easily in stateless mode.
Use forward() to send out the INVITE, like:

- set r-uri to first destination
- forward()
- set r-uri to second destination
- forward()

I don't recall by heart how via branch is set, however, it should not
matter if the two destinations are different end points.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat


___
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] Adding user to kamailio database

[Priyaranjan Nayak]

Hi All,

I wanted to use kamailio with authorization.
How can I add public identity and private identity to kamailio database
for a user ?

Thanks
Priyaranjan
___
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] Hex to Dec conversion

[Yufei Tao]

Hi,

I want to convert a Hex number string into a Dec number string, e.g. Hex
number "123" into Dec number "291". What is the best way? I didn't find any
transformation for this.

Thank you!
Yufei
___
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] Hex to Dec conversion

[Alex Balashov]

On 09/14/2015 11:37 AM, Yufei Tao wrote:


I want to convert a Hex number string into a Dec number string, e.g. Hex
number "123" into Dec number "291". What is the best way? I didn't find
any transformation for this.


As far as I know, Kamailio has no facility for this. I didn't see one in 
the transformations or the various utility modules, either.


--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
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] Hex to Dec conversion

[Daniel Tryba]

On Monday 14 September 2015 16:37:24 Yufei Tao wrote:
> I want to convert a Hex number string into a Dec number string, e.g. Hex
> number "123" into Dec number "291". What is the best way? I didn't find any
> transformation for this.

If there is indeed no simple buildin function. You can do it: 
-"manually", a loop from right to left, stripping characters and doing the 
powers of 16:
3*16^0+2*16^1+1*16^2

-if you are using something like mysql its conv()
https://dev.mysql.com/doc/refman/5.6/en/mathematical-functions.html#function_conv

-use one of the embedded interpreters app_(lua|perl|python|mono|java)


___
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] Hex to Dec conversion

[Konrad Rozycki]

On 09/14/2015 04:37 PM, Yufei Tao wrote:
Hi,

I want to convert a Hex number string into a Dec number string, e.g. Hex number 
"123" into Dec number "291". What is the best way? I didn't find any 
transformation for this.

Thank you!
Yufei



___
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


Hi Yufei,

Use app_python and python scripts contains somthing like that:


int("0x123", 16)

Greetings

Konrad


--
Konrad Rozycki
Red Embedded

This E-mail and any attachments hereto are strictly confidential and intended 
solely for the addressee. If you are not the intended addressee please notify 
the sender by return and delete the message.

You must not disclose, forward or copy this E-mail or attachments to any third 
party without the prior consent of the sender.

Red Embedded Design, Company Number 06688253 Registered in England: The Wave, 1 
View Croft Road, Shipley, West Yorkshire, BD17 7DU
___
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] [sr-dev] Very high load average after upgrade to Kamailio v4.3.2

[M S]

Hi,

After doing all the test cases, it seems the problem has been resolved in
v4.3.2-3763f6.

Thank you so much for your help in this timely fix.



On Mon, Sep 14, 2015 at 12:52 PM, M S  wrote:

> OK, let me test it and get back to you.
>
> Thank you.
>
>
>
> On Mon, Sep 14, 2015 at 12:18 PM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> I found a regression when detecting spiraled dialogs with state deleted.
>> That would be the case when you create a dialog for an INVITE, but you
>> reply with a negative response code from kamailio and then quickly a new
>> invite with same callid and from tag arrives.
>>
>> Can you upgrade to latest version in branch 4.3, try and see if works
>> fine now?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 14/09/15 11:55, M S wrote:
>>
>> OK runtime debugging shows something is wrong with dialog module, all 6
>> processes are locked in trying to access dialog module when 200 OK is
>> received for the call. For example, here is the BT of one the processes,
>>
>> --
>> #0  0xb77a0424 in __kernel_vsyscall ()
>> #1  0xb76c140c in sched_yield () from
>> /lib/i386-linux-gnu/i686/cmov/libc.so.6
>> #2  0xb5a20206 in get_lock (lock=0xa55058e4) at
>> ../../mem/../fastlock.h:277
>> #3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11302) at dlg_hash.c:610
>> #4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa598a2b0) at dlg_hash.c:643
>> #5  0xb5a14143 in dlg_onreply (t=0xa5989358, type=2, param=0xbff3a0ac) at
>> dlg_handlers.c:429
>> #6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5989398,
>> type=2, trans=0xa5989358, params=0xbff3a0ac) at t_hooks.c:268
>> #7  0xb5f781a3 in run_trans_callbacks (type=2, trans=0xa5989358,
>> req=0xa598a308, rpl=0xb68cc6e8, code=200) at t_hooks.c:295
>> #8  0xb5f84b14 in t_reply_matching (p_msg=0xb68cc6e8,
>> p_branch=0xbff3a5a4) at t_lookup.c:966
>> #9  0xb5f868c4 in t_check_msg (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4)
>> at t_lookup.c:1069
>> #10 0xb5f871fd in t_check (p_msg=0xb68cc6e8, param_branch=0xbff3a5a4) at
>> t_lookup.c:
>> #11 0xb5fc9b4e in reply_received (p_msg=0xb68cc6e8) at t_reply.c:2134
>> #12 0x080c9142 in do_forward_reply (msg=0xb68cc6e8, mode=0) at
>> forward.c:747
>> #13 0x080ca61c in forward_reply (msg=0xb68cc6e8) at forward.c:849
>> #14 0x08138aab in receive_msg (
>> buf=0x840f6c0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
>> X.X.X.X;rport=5060;branch=z9hG4bK719e.844788c1e820e6096cb00d2b2f6c613d.0\r\nVia:
>> SIP/2.0/UDP
>> 192.168.3.10;received=Y.Y.Y.Y;rport=5060;branch=z9hG4bKlzzjpctt\r\nRe"...,
>> len=1103, rcv_info=0xbff3a93c) at receive.c:255
>> #15 0x082188d0 in udp_rcv_loop () at udp_server.c:495
>> #16 0x080dec65 in main_loop () at main.c:1573
>> #17 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
>> --
>>
>> Here is BT of second process,
>>
>> --
>> #0  0xb77a0424 in __kernel_vsyscall ()
>> #1  0xb76c140c in sched_yield () from
>> /lib/i386-linux-gnu/i686/cmov/libc.so.6
>> #2  0xb5a20206 in get_lock (lock=0xa55058e4) at
>> ../../mem/../fastlock.h:277
>> #3  0xb5a25a9f in dlg_lookup (h_entry=2405, h_id=11301) at dlg_hash.c:610
>> #4  0xb5a26446 in dlg_get_by_iuid (diuid=0xa5985060) at dlg_hash.c:643
>> #5  0xb5a140c4 in dlg_ontdestroy (t=0xa5985424, type=131072,
>> param=0xbff3a7ac) at dlg_handlers.c:398
>> #6  0xb5f78092 in run_trans_callbacks_internal (cb_lst=0xa5985464,
>> type=131072, trans=0xa5985424, params=0xbff3a7ac) at t_hooks.c:268
>> #7  0xb5f781a3 in run_trans_callbacks (type=131072, trans=0xa5985424,
>> req=0x0, rpl=0x0, code=0) at t_hooks.c:295
>> #8  0xb5f3cbbb in free_cell (dead_cell=0xa5985424) at h_table.c:128
>> #9  0xb5f7cb20 in wait_handler (ti=1848316837, wait_tl=0xa598546c,
>> data=0xa5985424) at timer.c:648
>> #10 0x0820d8f8 in timer_list_expire (t=1848316837, h=0xa530e718,
>> slow_l=0xa530e7ec, slow_mark=6) at timer.c:873
>> #11 0x0820dcc0 in timer_handler () at timer.c:938
>> #12 0x0820e0d8 in timer_main () at timer.c:977
>> #13 0x080df4e0 in main_loop () at main.c:1644
>> #14 0x080e4c99 in main (argc=13, argv=0xbff3ad44) at main.c:2533
>> --
>>
>> Does this makes any sense to you? Let me know if you need anything else.
>>
>> Thank you.
>>
>>
>>
>> On Mon, Sep 14, 2015 at 11:36 AM, M S  wrote:
>>
>>> Sure, here is the list of module in given order,
>>>
>>> --
>>> loadmodule "db_mysql.so"
>>> loadmodule "mi_fifo.so"
>>> loadmodule "mi_datagram.so"
>>> loadmodule "kex.so"
>>> loadmodule "corex.so"
>>> loadmodule "tm.so"
>>> loadmodule "tmx.so"
>>> loadmodule "sl.so"
>>> loadmodule "outbound.so"
>>> loadmodule "rr.so"
>>> loadmodule "path.so"
>>> loadmodule "pv.so"
>>> loadmodule "maxfwd.so"
>>> loadmodule "usrloc.so"
>>> loadmodule "registrar.so"
>>> loadmodule "sdpops.so"
>>> loadmodule "textops.so"
>>> loadmodule "textopsx.so"
>>> loadmodule "siputils.so"
>>> loadmodule "xlog.so"
>>> loadmodule "sanity.so"
>>> loadmodule "ctl.so"
>>> loadmodule "cfg_rpc.so"
>>> loadmodule "mi_rpc.so"
>>> loadmodule "dialog.so"
>>> loadmodule "acc.so"
>>> loadmodule "uac.so"
>>> loadmodule "rti

Re: [SR-Users] Hex to Dec conversion

[Daniel-Constantin Mierla]

On 14/09/15 18:16, Alex Balashov wrote:
> On 09/14/2015 11:37 AM, Yufei Tao wrote:
>
>> I want to convert a Hex number string into a Dec number string, e.g. Hex
>> number "123" into Dec number "291". What is the best way? I didn't find
>> any transformation for this.
>
> As far as I know, Kamailio has no facility for this. I didn't see one
> in the transformations or the various utility modules, either.
>
Isn't the s.decode.hexa transformation what it actually needed here?

  - http://www.kamailio.org/wiki/cookbooks/4.3.x/transformations#sdecodehexa

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat


___
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] problem with dispatcher load balancing

[Ding Ma]

Hi,

Figured this out. Seems I had made a mistake in the names of AVPs. Changed
the AVP names as the exact names used in the example contained in
dispatcher doc. Dispatcher started to work, I can see even distribution of
loads to 2 Asterisk servers. Will verify if maxload is being enforced or
not, not really an issue even if it is not enforced.

Thanks,

On Thu, Aug 27, 2015 at 9:07 AM, Ding Ma  wrote:

> Hi, Daniel
>
> I just tested the dispatcher in 4.3.1. It showed the same behavior as
> 4.2.3. All the calls are sent to one Asterisk (the last one in the
> dispatcher list), the maxload setting in dispatcher table is ignored.
>
> We use db dispatcher table instead of dispatcher list file, and the
> kamailio.cfg is the same as included in the previous email in this thread.
>
> Hope I didn't make any mistake in kamailio.cfg.
>
> Thanks
>
> On Fri, Jun 12, 2015 at 12:34 AM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Yes, 4.3 should have all fixes in 4.2.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 12/06/15 06:06, Ding Ma wrote:
>>
>> OK, we’ll try to update and report back. Wonder if the latest 4.3 has all
>> the fixes went into the latest 4.2.x. We already have plan to upgrade to
>> 4.3.
>> Thanks.
>>
>> On Jun 10, 2015, at 10:01 AM, Daniel-Constantin Mierla 
>> wrote:
>>
>> It was a fix for maxload during 4.2.x, but don't recall exactly when was
>> backported. Can you upgrade to latest 4.2.x and see the results? Your
>> config file and database don't require any change, only deploy the binaries
>> for latest 4.2.x and restart.
>>
>> If the issue is still there with latest 4.2.x, report here and I will
>> look at it with the first chance.
>>
>> Cheers,
>> Daniel
>>
>> On 10/06/15 16:50, Ding Ma wrote:
>>
>> We're running kamailio 4.2.3. Are there any changes to dispatcher in
>> 4.2.x?
>> Thanks,
>>
>> # kamailio -V
>> version: kamailio 4.2.3 (x86_64/linux) 5596bd
>> 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: 5596bd
>> compiled on 09:32:37 May  6 2015 with gcc 4.4.7
>>
>>
>> On Wed, Jun 10, 2015 at 7:01 AM, Daniel-Constantin Mierla <
>> mico...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> what version of kamailio are you using?
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 09/06/15 20:51, Ding Ma wrote:
>>>
>>> I'm trying to set up kamailio dispatcher to distribute calls to 2
>>> asterisk servers. So far, the failover case seems ok, but I cannot get the
>>> dispatcher to distribute load. All calls are going to the last destination
>>> entry in the dispatcher table even if I have set the maxload attributes.
>>> I'm using algorithm 10 for load distribution. The number of calls sent to
>>> one asterisk is well above the maxload. Hope someone more experienced in
>>> dispatcher can review my config and give me some recommendations. Thanks in
>>> advance.
>>>
>>> Here is the content of dispatcher table in postgresql db.
>>>
>>> select * from dispatcher;
>>>  id | setid |destination | flags | priority |   attrs
>>> | description
>>>
>>> +---++---+--+---+-
>>>   1 | 1 | sip:10.0.1.31:5061 | 0 |0 |
>>> duid=asterisk1;maxload=25 | Asterisk1
>>>   2 | 1 | sip:10.0.1.33:5061 | 0 |0 |
>>> duid=asterisk2;maxload=25 | Asterisk2
>>> (2 rows)
>>>
>>> Here are the dispatcher sections in kamailio.cfg.
>>> # - dispatcher params -
>>> #!ifdef WITH_DISPATCHER
>>> modparam("dispatcher", "db_url", DBASTURL)
>>> modparam("dispatcher", "table_name", "dispatcher")
>>> modparam("dispatcher", "force_dst", 1).
>>> # If flag 2 is set, then failover support is enabled.
>>> modparam("dispatcher", "flags", 3)
>>> # the last address in destination set is used as a final option to send
>>> the request to
>>> modparam("dispatcher", "use_default", 1)
>>> # load balancing fail over
>>> modparam("dispatcher", "dst_avp", "$avp(dsdst)")
>>> modparam("dispatcher", "grp_avp", "$avp(dsgrp)")
>>> modparam("dispatcher", "cnt_avp", "$avp(dscnt)")
>>> modparam("dispatcher", "dstid_avp", "$avp(dsdstid)")
>>> modparam("dispatcher", "attrs_avp", "$avp(dsattrs)")
>>> # PVs for hashing
>>> modparam("dispatcher", "hash_pvar", "$fU@$ci")
>>> # PVs to store results when calling ds_is_from_list
>>> modparam("dispatcher", "setid_pvname", "$var(setid)")
>>> modparam("dispatcher", "attrs_pvname", "$var(attrs)")
>>> # method to probe the gateways
>>> modparam("dispatcher", "ds_ping_method", "OPTIONS")
>>> modparam("dispatcher", "ds_ping_from", "sip:dispatcher@localhost")
>>> modparam("dispatcher

Re: [SR-Users] evapi tcp parsing??

[Jayesh Nambiar]

Hello Daniel,
After further testing with evapi module, I figured that when Netstrings are
used, an event route is invoked individually for each message even if if
multiple netstring messages are received in a single TCP packet. But this
doesn't work effectively when a single proper message is split-up in two
packets. For Example, if a message arrives as:
12:Hello World!, 12:Hello World!, 12:Hello World! in a single packet,
kamailio properly invokes the event route "evapi:message-received" thrice
for every individual proper netstring message.
But if the first packet contains:
12:Hello World!, 12:Hello
And Second Packet contains:
 World!, 12:Hello World!
the event route is invoked only once !!

The above pattern is very much possible while sending and receiving packets
over TCP Socket. Our tests for receiving an approximately 150 byte message
over evapi socket at the rate of roughly 1000cps causes a lot of real
events to be missed because of the above problem. You can never be sure
when TCP will split messages in different chunks.
This definitely looks like a bug which makes it not very reliable at large
scale deployments. Would really appreciate your inputs on this. Thanks;

- Jayesh



On Thu, Sep 10, 2015 at 4:01 PM, Jayesh Nambiar 
wrote:

> Hi Daniel,
> Thanks for the quick response. So if I do not use Netstrings, does
> Kamailio allow me to create a custom logic in the script. For eg. if I
> decide to use newline as a delimiter, can I keep buffering the message
> until I encounter the delimiter from the event route and then execute
> whatever I have to within the script??
>
> Thanks,
>
> - Jayesh
>
> On Thu, Sep 10, 2015 at 1:29 PM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> tcb is stream protocol and several messages can be queued on the pipe at
>> the same time. That is the reason for netstring format, to be able to
>> easily detect the boundaries of each message. If netstring format is
>> enabled and kamailio receives several messages at once, it splits them and
>> for each is executing the event route.
>>
>> If netstring format is not used, the kamailio is executing the event
>> route with the entire content that was read at once from the tcp connection.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 09/09/15 22:01, Jayesh Nambiar wrote:
>>
>> Hello,
>> I'm exploring the evapi module for my kamailio to interface with an
>> external node.js app for third party stuff like AAA, billing engine tasks,
>> notifications and so on. I followed and took some ideas from the rtjson and
>> evapi tutorial found here(
>> 
>> http://kb.asipto.com/kamailio:k43-async-sip-routing-nodejs) to build the
>> node.js app consuming events.
>> When I stress tested the scenario using SIPp and tried sending a lot of
>> events at 300-350cps from Kamailio, I noticed that at times the client is
>> receiving 2-3 events in a single message together although I do
>> event_sync_relay once per SIP message received and have netstrings enabled.
>> I believe this is a typical behavior of TCP and needs to be handled by the
>> client using some kind of Netstring handler. Please correct me if I'm wrong.
>> And hence I'd like to know what particularly needs to be taken care of
>> while writing a client that is listening for events on raw tcp socket and
>> how does kamailio handle this situation while receiving messages over TCP
>> socket?? Does kamailio recognize the end of netstring properly on
>> evapi:message-received and give exactly one message to take care of on
>> every "message-received" event or should that be handled in the script
>> somewhere !!
>> I also referred cgrates client over evapi example which is written in GO,
>> but I couldnt find them handling TCP streams clearly either.
>> I'd really appreciate some expert suggestion here to make an informed
>> decision on using the evapi module for a large scale solution.
>>
>> Thanks,
>>
>> - Jayesh
>>
>>
>>
>>
>> ___
>> 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
>> Book: SIP Routing With Kamailio - http://www.asipto.com
>> Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - 
>> http://asipto.com/u/kat
>>
>>
>> ___
>> 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

[SR-Users] Best practices for troubleshooting deadlocks?

[Alex Balashov]

Hello,

Very occasionally, we encounter what appear to be deadlocks in all UDP 
receiver threads. All Kamailio processes are running, but no SIP 
messages are being processed.


On one of our high-volume installation, this happens extremely 
infrequently -- maybe once every month or two. On these occasions, the 
operator restarts the proxy before we get a chance to go in and figure 
out what's going on.


So, I'm trying to provide the operator with a procedure to execute prior 
to restarting the proxy on these occasions, so that we can see a 
snapshot of where the receiver threads are stuck. As far as I can tell, 
unless Kamailio itself segfaults, there's no specific PID that one can 
attach GDB to in order to get an overhead snapshot of all the child 
processes.


Here's what I came up with:

-
#!/bin/bash

kamcmd -s /tmp/kamailio_ctl ps > thread_log.txt
echo >> thread_log.txt

while read PID;
do
gdb --pid=$PID<>thread_log.txt
set print elements 0
thread apply all bt full
generate-core-file
detach
EOF
done < <(kamcmd -s /tmp/kamailio_ctl ps | grep 'udp receiver' | awk 
'{print $1}')

-

As far as I can tell, this should give me the most ample visibility into 
the state of the threads, with further core dumps to inspect if 
follow-up is needed. Hopefully this will result in some fixes back to 
the project.


However, if there are any other suggestions for information to grab in 
such a scenario, I'm all ears.


Thanks in advance!

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
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] Authentication issue during registration

[Austin Einter]

I took SBC from my test scenario.
Then I found same issue, Kamalio challanges repeatedly.

One of the reason I suspect is, in my case for REGISTER message to uri and
from uri are different.
Can that cause Kamailio to challenge it repeatedly.

Thanks
Austin



On Mon, Sep 14, 2015 at 11:22 AM, Austin Einter 
wrote:

> Hi All
> I have a typical requirement, where I have a forwarding SBC between an
> endpoint and kamailio as shown below.
>
> Endpoint > SBC --> Kamailio
>
> From endpoint I am sending REGISTER request. It reaches SBC. SBC sends the
> REGISTER request to Kamailio, Kamailio challenges it (401), and challenge
> response is received at endpoint through SBC.
>
> Next endpoint adds authorization header and sends REGISTER to SBC, SBC
> forwards it to Kamailio.
>
> Now Kamailio again responds with 401.
>
> When we analysed Kamailio logs, we can see Kamailio log authorization
> response token and response token that was sent by Endpoint are same.
>
> So my question is, why Kamailio sends 401 repeatedly even if it received
> proper Authorization header.
>
> Is it because Kamailio received REGISTER from IP address different from
> endpoint.
>
> Please guide, how can I avoid this issue.
>
> Thanks
> Austin
>
>
>
>
>
>
>
>
___
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