[OpenSIPS-Users] ul_dump brief is not accepted, opensips 3.4
Hi,
1,
looks like ul_dump brief params is not accepted
OS: Ubuntu 22
opensips -V
version: opensips 3.4.0-rc1 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: c64766a85
main.c compiled on with gcc 11
apt policy opensips-cli
opensips-cli:
Installed: 0.1~20230512~161b5ea-1
Candidate: 0.1~20230512~161b5ea-1
Version table:
*** 0.1~20230512~161b5ea-1 500
500 https://apt.opensips.org jammy/cli-nightly amd64 Packages
opensips-cli --version
OpenSIPS CLI 0.2.0
opensips-cli -x mi ul_dump brief
ERROR: command 'ul_dump' returned: -32602: Invalid params (Bad type for
parameter 'brief')
2,
When doing dr_reload through httpd, the load of the HTTPD ps will increase and
other services rely on it like opensips prometheus will stuck and return
nothing until dr_reload is completed
curl -s -X POST -H 'Content-Type: application/json' {server-IP}:/mi
-d'{"jsonrpc": "2.0","id": 1,"method": "dr_reload"}' | json_pp
curl 127.0.0.1:/metrics
Is it possible to increase the worker number of HTTPD ps?
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye
Yes, I've updated to the latest version and can confirm the crash no longer happens. Thanks. -- Regards, William Jin From: Liviu Chircu Sent: Wednesday, 29 September 2021 8:01 PM To: William Jin ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye On 17.09.2021 07:42, William Jin wrote: Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: CRITICAL:core:sig_usr: segfault in process pid: 188225, id: 15 Hi William, Not sure if you noticed the identical thread below (with James Fox, Rob Dyck and Max) but this crash has been fixed in latest 3.2! Cheers, -- Liviu Chircu www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> | www.opensips-solutions.com<http://www.opensips-solutions.com> OpenSIPS eBootcamp 2021 | www.opensips.org/training<http://www.opensips.org/training> ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye
And I just enabled log_level=4 It connects to db (mysql 8.0.26-1debian11) and converting password string to val, then segfault Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f6d33facd80 (tail=140107000235208) MC=0x7f6d33fac560 Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_do_prepared_query: new query=|select password,rpid from subscriber where username=?| Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:re_init_statement: query is , ptr=(nil) Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_do_prepared_query: new statement(0x7f6d33faf978) on connection: (0x7f6d33facd80) 0x7f6d33fac4c8 Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=10; type=254; is_null=0 Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:mysql_raise_event: MySQL status has not changed: connected Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 2 columns in result Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_do_prepared_query: doing to BIND_PARAM out ... Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f6d33fadf68 Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_get_columns: 2 columns returned from the query Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:core:db_allocate_columns: allocate 56 bytes for result columns at 0x7f6d33faf060 Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f6d33faf070)[0]=[password] Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f6d33faf080)[1]=[rpid] Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:core:db_allocate_rows: allocate 80 bytes for result rows and values at 0x7f6d33fb0450 Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: DBG:db_mysql:db_mysql_str2val: converting STRING [my@password] Sep 17 14:33:23 ip-10-20-12-22 /usr/sbin/opensips[188225]: CRITICAL:core:sig_usr: segfault in process pid: 188225, id: 15 -- Regards, William Jin From: Users on behalf of William Jin Sent: Friday, 17 September 2021 2:19 PM To: Liviu Chircu ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye And just further investigation, looks like it's crashed only after I register my test user. (which can register on debian 10 before upgraded to debian 11 using zoiper softphone) And the backtrack also indicate the crash from auth_db?? -- Regards, William Jin From: Users on behalf of William Jin Sent: Friday, 17 September 2021 9:12 AM To: Liviu Chircu ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye Hi Liviu, I attached the backtrace in the init email. I've attached it again. -- Regards, William Jin From: Liviu Chircu Sent: Thursday, 16 September 2021 5:12 PM To: OpenSIPS users mailling list ; William Jin Subject: Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye On 16.09.2021 02:16, William Jin wrote: > Anyone has any chance to look into this? Hi William, There is not enough info to look into anything, really: * how are you reproducing this crash? can you share a basic opensips.cfg that causes it? * are there any useful logs _before_ those "signal 11" logs? * can you obtain a backtrace out of this crash? See this guide [1] for some help here [1]: https://www.opensips.org/Documentation/TroubleShooting-Crash Best, -- Liviu Chircu www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> | www.opensips-solutions.com<http://www.opensips-solutions.com> ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye
And just further investigation, looks like it's crashed only after I register my test user. (which can register on debian 10 before upgraded to debian 11 using zoiper softphone) And the backtrack also indicate the crash from auth_db?? -- Regards, William Jin From: Users on behalf of William Jin Sent: Friday, 17 September 2021 9:12 AM To: Liviu Chircu ; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye Hi Liviu, I attached the backtrace in the init email. I've attached it again. -- Regards, William Jin From: Liviu Chircu Sent: Thursday, 16 September 2021 5:12 PM To: OpenSIPS users mailling list ; William Jin Subject: Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye On 16.09.2021 02:16, William Jin wrote: > Anyone has any chance to look into this? Hi William, There is not enough info to look into anything, really: * how are you reproducing this crash? can you share a basic opensips.cfg that causes it? * are there any useful logs _before_ those "signal 11" logs? * can you obtain a backtrace out of this crash? See this guide [1] for some help here [1]: https://www.opensips.org/Documentation/TroubleShooting-Crash Best, -- Liviu Chircu www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> | www.opensips-solutions.com<http://www.opensips-solutions.com> ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye
Hi Liviu,
I attached the backtrace in the init email.
I've attached it again.
--
Regards,
William Jin
From: Liviu Chircu
Sent: Thursday, 16 September 2021 5:12 PM
To: OpenSIPS users mailling list ; William Jin
Subject: Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye
On 16.09.2021 02:16, William Jin wrote:
> Anyone has any chance to look into this?
Hi William,
There is not enough info to look into anything, really:
* how are you reproducing this crash? can you share a basic
opensips.cfg that causes it?
* are there any useful logs _before_ those "signal 11" logs?
* can you obtain a backtrace out of this crash? See this guide [1] for
some help here
[1]: https://www.opensips.org/Documentation/TroubleShooting-Crash
Best,
--
Liviu Chircu
www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> |
www.opensips-solutions.com<http://www.opensips-solutions.com>
gdb /usr/sbin/opensips /tmp/core
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/opensips...
Reading symbols from
/usr/lib/debug/.build-id/68/43b0716a68e5fab40b5fba966d9bce8d0e224f.debug...
warning: Can't open file /dev/zero (deleted) during file-backed mapping note
processing
[New LWP 10586]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f
/etc/opensips/opensips.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x559ddc5502a0 in memcpy (__len=64, __src=0xaf01ff,
__dest=0x7ffd97072be8) at
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
34return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) bt full
#0 0x559ddc5502a0 in memcpy (__len=64, __src=0xaf01ff,
__dest=0x7ffd97072be8) at
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
No locals.
#1 MD5_memcpy (len=64, input=0xaf01ff , output=0x7ffd97072be8 "\240-\a\227\375\177") at md5.c:329
No locals.
#2 MD5Update (context=0x7ffd97072bd0, input=0xaf01ff , inputLen=127) at md5.c:152
i =
index = 0
partLen = 64
#3 0x7f67bad9a788 in digest_calc_HA1 (crd=0x7ffd97072d60,
sess_key=0x7ffd97072de0) at dauth_calc_md5.c:48
Md5Ctx = {state = {1732584193, 4023233417, 2562383102, 271733878},
count = {1016, 0},
buffer =
"\240-\a\227\375\177\000\000(-\a\227\375\177\000\000\000\305L\321\027`\200P\220-\a\227\375\177\000\000\200\355\003\277g\177\000\000(-\a\227\375\177\000\000\310\344\003\277g\177\000\000(-\a\227\375\177\000"}
HA1 = "(-\a\227\375\177\000\000z\247\244\272g\177\000"
#4 0x7f67bad9476d in auth_calc_HA1 (params=0x7ffd97072d40,
sess_key=0x7ffd97072de0) at api.c:341
digest_calc = 0x7f67bada2800
__FUNCTION__ = "auth_calc_HA1"
#5 0x7f67baa8e936 in get_ha1 (res=0x7ffd97072d28, _ha1=0x7ffd97072de0,
_table=, _domain=0x7ffd97072f88, digest=0x7f67bf040f58) at
authorize.c:169
cprms = {use_hashed = 0, alg = ALG_MD5, creds = {open = 0x7ffd97072d60,
ha1 = 0x7ffd97072d60}, nonce = 0x7f67bf040f98, cnonce = 0x7f67bf040fe0}
vals = {{type = DB_STR, nul = 0, free = 0, val = {int_val = -594864196,
bigint_val = 94136498329532, double_val = 4.6509609844413654e-310, time_val =
94136498329532,
string_val = 0x559ddc8b17bc
"1122334455\",realm=\"sip1.mydomain.com\",nonce=\"KprTqedqhYxO7vVNGoDdw6U2mvUQ1v6Jd7liqtOCO94A\",uri=\"sip:sip1.mydomain.com;transport=UDP\",response=\"46f25ec4472d495ed41f46677a1eb647\",algorithm=MD5"...,
str_val = {
s = 0x559ddc8b17bc
"1122334455\",realm=\"sip1.mydomain.com\",nonce=\"KprTqedqhYxO7vVNGoDdw6U2mvUQ1v6Jd7liqtOCO94A\",uri=\"sip:sip1.mydomain.com;transport=UDP\",response=\"46f25ec4472d495ed41f46677a1eb647\",algorithm=MD5"...,
len = 10}, blob_val = {
s = 0x559ddc8b17bc
"1122334455\",realm=\"sip1.mydomain.com\",nonce=\"KprTqedqhYxO
Re: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye
Anyone has any chance to look into this? -- Regards, William Jin From: Users on behalf of William Jin Sent: Thursday, 9 September 2021 12:32 PM To: users@lists.opensips.org Subject: [OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye We currently upgraded our Debian server from 10(buster) to 11(bullseye), After the upgrade, the Opensips keep crashing with a segfault. Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8700]: CRITICAL:core:sig_usr: segfault in process pid: 8700, id: 16 Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8683]: INFO:core:handle_sigs: child process 8700 exited by a signal 11 Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8683]: INFO:core:handle_sigs: core was generated Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8683]: INFO:core:handle_sigs: terminating due to SIGCHLD We are using the apt repo opensips, tried both stable and nightly version, same result. opensips -V version: opensips 3.2.2 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: dc45f112e main.c compiled on with gcc 10 DBG attached PS: I've replaced my number to 1122334455, domain to sip1.mydomain.com -- Regards, William Jin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensips 3.2.2 Segfault on debian 11 bullseye
We currently upgraded our Debian server from 10(buster) to 11(bullseye),
After the upgrade, the Opensips keep crashing with a segfault.
Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8700]: CRITICAL:core:sig_usr:
segfault in process pid: 8700, id: 16
Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8683]: INFO:core:handle_sigs:
child process 8700 exited by a signal 11
Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8683]: INFO:core:handle_sigs:
core was generated
Sep 9 10:35:04 ip-10-20-12-22 /usr/sbin/opensips[8683]: INFO:core:handle_sigs:
terminating due to SIGCHLD
We are using the apt repo opensips, tried both stable and nightly version,
same result.
opensips -V
version: opensips 3.2.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: dc45f112e
main.c compiled on with gcc 10
DBG attached
PS: I've replaced my number to 1122334455, domain to sip1.mydomain.com
--
Regards,
William Jin
gdb /usr/sbin/opensips /tmp/core
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/opensips...
Reading symbols from
/usr/lib/debug/.build-id/68/43b0716a68e5fab40b5fba966d9bce8d0e224f.debug...
warning: Can't open file /dev/zero (deleted) during file-backed mapping note
processing
[New LWP 10586]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f
/etc/opensips/opensips.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x559ddc5502a0 in memcpy (__len=64, __src=0xaf01ff,
__dest=0x7ffd97072be8) at
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
34return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) bt full
#0 0x559ddc5502a0 in memcpy (__len=64, __src=0xaf01ff,
__dest=0x7ffd97072be8) at
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
No locals.
#1 MD5_memcpy (len=64, input=0xaf01ff , output=0x7ffd97072be8 "\240-\a\227\375\177") at md5.c:329
No locals.
#2 MD5Update (context=0x7ffd97072bd0, input=0xaf01ff , inputLen=127) at md5.c:152
i =
index = 0
partLen = 64
#3 0x7f67bad9a788 in digest_calc_HA1 (crd=0x7ffd97072d60,
sess_key=0x7ffd97072de0) at dauth_calc_md5.c:48
Md5Ctx = {state = {1732584193, 4023233417, 2562383102, 271733878},
count = {1016, 0},
buffer =
"\240-\a\227\375\177\000\000(-\a\227\375\177\000\000\000\305L\321\027`\200P\220-\a\227\375\177\000\000\200\355\003\277g\177\000\000(-\a\227\375\177\000\000\310\344\003\277g\177\000\000(-\a\227\375\177\000"}
HA1 = "(-\a\227\375\177\000\000z\247\244\272g\177\000"
#4 0x7f67bad9476d in auth_calc_HA1 (params=0x7ffd97072d40,
sess_key=0x7ffd97072de0) at api.c:341
digest_calc = 0x7f67bada2800
__FUNCTION__ = "auth_calc_HA1"
#5 0x7f67baa8e936 in get_ha1 (res=0x7ffd97072d28, _ha1=0x7ffd97072de0,
_table=, _domain=0x7ffd97072f88, digest=0x7f67bf040f58) at
authorize.c:169
cprms = {use_hashed = 0, alg = ALG_MD5, creds = {open = 0x7ffd97072d60,
ha1 = 0x7ffd97072d60}, nonce = 0x7f67bf040f98, cnonce = 0x7f67bf040fe0}
vals = {{type = DB_STR, nul = 0, free = 0, val = {int_val = -594864196,
bigint_val = 94136498329532, double_val = 4.6509609844413654e-310, time_val =
94136498329532,
string_val = 0x559ddc8b17bc
"1122334455\",realm=\"sip1.mydomain.com\",nonce=\"KprTqedqhYxO7vVNGoDdw6U2mvUQ1v6Jd7liqtOCO94A\",uri=\"sip:sip1.mydomain.com;transport=UDP\",response=\"46f25ec4472d495ed41f46677a1eb647\",algorithm=MD5"...,
str_val = {
s = 0x559ddc8b17bc
"1122334455\",realm=\"sip1.mydomain.com\",nonce=\"KprTqedqhYxO7vVNGoDdw6U2mvUQ1v6Jd7liqtOCO94A\",uri=\"sip:sip1.mydomain.com;transport=UDP\",respo
Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8
Found some extra error logs that might be related to this. checking how we can
fix this
/usr/sbin/opensips[1983]: ERROR:proto_bin:add_write_chunk: We have reached the
limit of max async postponed chunks
/usr/sbin/opensips[1983]: ERROR:proto_bin:proto_bin_send: failed to send
/usr/sbin/opensips[1983]: ERROR:clusterer:msg_send: send() to 10.2.2.16:5566
for proto bin/7 failed
--
Regards,
William Jin
From: William Jin
Sent: Thursday, 2 July 2020 11:24 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8
Hi,
Thanks for the info.
I have upgraded both nodes to latest 2.4.8, and restarted opensips on both
nodes so it should start from empty.
The error "INFO:usrloc:receive_binary_packets: discarding , ver 1: need ver 2"
is gone.
However, the 2nd node usrloc is still not synced with 1st node(seed), even
manually issue the command opensipsctl fifo ul_cluster_sync.
my config: (on both node)
# - usrloc params -
modparam("usrloc", "cluster_mode", "full-sharing")
modparam("usrloc", "nat_bflag", "NAT")
modparam("usrloc", "location_cluster", 1)
modparam("usrloc", "restart_persistency", "sync-from-cluster")
The clusterer table:
id | cluster_id | node_id |url | state | no_ping_retries |
priority | sip_addr | description | flags
++-++---+-+--+--+-+---
2 | 1 | 2 | bin:10.2.2.16:5566 | 1 | 3 |
50 | | node2 |
1 | 1 | 1 | bin:10.2.2.15:5566 | 1 | 3 |
50 | | node1 | seed
>From node1 log:
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg:
Node [2] is UP
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request:
Received sync request for capability 'dialog-dlg-repl' from node 2, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:send_sync_repl: Sent
all sync packets for capability 'dialog-dlg-repl' to node 2, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request:
Received sync request for capability 'usrloc-contact-repl' from node 2, cluster
1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send: send() to
10.2.2.16:5566 for proto bin/7 failed
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send_retry:
msg_send() to node [2] failed
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start:
Failed to send sync packet
...
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start:
Failed to send sync packet
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl:
Failed to send sync packet, rc=-1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl:
Failed to send sync end message
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg:
Node [2] is UP
Node2 log:
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_internal_msg:
Node [1] is UP
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent
sync request for capability 'dialog-dlg-repl' to node 1, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent
sync request for capability 'usrloc-contact-repl' to node 1, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_sync_packet:
Received all sync packets for capability 'dialog-dlg-repl' in cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:probe_max_sock_buff: using
snd buffer of 512 kb
Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:init_sock_keepalive: TCP
keepalive enabled on socket 184
we have around 30,000 end devices(UDP), and I found the
https://github.com/OpenSIPS/opensips/issues/1976, not sure if it's related
Any idea? Do I need to increase the ping_timeout and give it a try?
--
Regards,
William Jin
From: Users on behalf of Liviu Chircu
Sent: Wednesday, 1 July 2020 4:48 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8
On 01.07.2020 09:39, Liviu Chircu wrote:
> then re-register them manually with the "ul_add" [2] command that and
> some Python scripting logic, for example.
Sorry, I meant bash, not Python. Not that I have anything against
Python, but the former script (basically a simple loop) is much quicker
to write in order to achieve your purpose.
--
Liviu Chircu
www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> |
www.opensips-solutions.com<http://www.opensips-solutions.com>
___
Users mailing list
Users@lists.opensips.org
ht
Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8
Hi,
Thanks for the info.
I have upgraded both nodes to latest 2.4.8, and restarted opensips on both
nodes so it should start from empty.
The error "INFO:usrloc:receive_binary_packets: discarding , ver 1: need ver 2"
is gone.
However, the 2nd node usrloc is still not synced with 1st node(seed), even
manually issue the command opensipsctl fifo ul_cluster_sync.
my config: (on both node)
# - usrloc params -
modparam("usrloc", "cluster_mode", "full-sharing")
modparam("usrloc", "nat_bflag", "NAT")
modparam("usrloc", "location_cluster", 1)
modparam("usrloc", "restart_persistency", "sync-from-cluster")
The clusterer table:
id | cluster_id | node_id |url | state | no_ping_retries |
priority | sip_addr | description | flags
++-++---+-+--+--+-+---
2 | 1 | 2 | bin:10.2.2.16:5566 | 1 | 3 |
50 | | node2 |
1 | 1 | 1 | bin:10.2.2.15:5566 | 1 | 3 |
50 | | node1 | seed
>From node1 log:
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg:
Node [2] is UP
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request:
Received sync request for capability 'dialog-dlg-repl' from node 2, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:send_sync_repl: Sent
all sync packets for capability 'dialog-dlg-repl' to node 2, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request:
Received sync request for capability 'usrloc-contact-repl' from node 2, cluster
1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send: send() to
10.2.2.16:5566 for proto bin/7 failed
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send_retry:
msg_send() to node [2] failed
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start:
Failed to send sync packet
...
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start:
Failed to send sync packet
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl:
Failed to send sync packet, rc=-1
Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl:
Failed to send sync end message
Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg:
Node [2] is UP
Node2 log:
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_internal_msg:
Node [1] is UP
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent
sync request for capability 'dialog-dlg-repl' to node 1, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent
sync request for capability 'usrloc-contact-repl' to node 1, cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_sync_packet:
Received all sync packets for capability 'dialog-dlg-repl' in cluster 1
Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:probe_max_sock_buff: using
snd buffer of 512 kb
Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:init_sock_keepalive: TCP
keepalive enabled on socket 184
we have around 30,000 end devices(UDP), and I found the
https://github.com/OpenSIPS/opensips/issues/1976, not sure if it's related
Any idea? Do I need to increase the ping_timeout and give it a try?
--
Regards,
William Jin
From: Users on behalf of Liviu Chircu
Sent: Wednesday, 1 July 2020 4:48 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8
On 01.07.2020 09:39, Liviu Chircu wrote:
> then re-register them manually with the "ul_add" [2] command that and
> some Python scripting logic, for example.
Sorry, I meant bash, not Python. Not that I have anything against
Python, but the former script (basically a simple loop) is much quicker
to write in order to achieve your purpose.
--
Liviu Chircu
www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> |
www.opensips-solutions.com<http://www.opensips-solutions.com>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8
Hi, We were using opensips 2.4.6 from apt repo, and we upgraded to 2.4.8 today. However, after the upgrade, the usrloc-contact-repl can not be synced between the 2 nodes within 1 cluster. Even we issue the ul_cluster_sync command. opensipsctl fifo clusterer_list_cap Cluster:: 1 Capability:: usrloc-contact-repl State=not synced And we found the below log INFO:usrloc:receive_binary_packets: discarding , ver 1: need ver 2 Is there anything I missed? where should I change the version to 2? -- Regards, William Jin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] question about rtpengine_manage() in failure_route
Hi Razvan,
Many thanks for your advice.
Yes, I can confirm the branch_route did the trick.
--
Regards,
William Jin
From: Users on behalf of Răzvan Crainea
Sent: Wednesday, 10 June 2020 5:59 PM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] question about rtpengine_manage() in failure_route
Hi, William!
Make sure you call rtpengine_manage() in branch route, not in the request
route, otherwise all the changes will be inherited throughout all the branches
further created.
Best regards,
Răzvan
On 6/9/20 7:04 AM, William Jin wrote:
Below is a short config example.
route {
...
setflag(CallFWD);
rtpengine_manage(); #say the first call attempt need rtpengine
t_on_failure("handle_failure");
r_relay();
...
}
failure_route[handle_failure] {
...
if (isflagset(CallFWD)){route(handle_callfwd);}
...
}
route[handle_callfwd]{
...
xlog("L_INFO","RB=$rb(application/sdp)");
if (t_relay()){
xlog("L_INFO","Stateful relay done. RB=$rb(application/sdp)");
}
...
}
Looks like the t_relay in the handle_callfwd will inherit the SDP info that
rtpengine_manage entered in the first attempt.
Also, another interesting fact is that the SDP info is added while the t_relay
is called. Looks like the t_relay is using its data in memory and re-write the
SDP. the $rb(application/sdp) is not changed until the t_relay is called.
How can I, for example, remove the rtpengine related SDP for the second INVITE
generated by the failure_route?
I tried rtpengine_delete() in handle_callfwd or rtpengine_manage() in the
failure_route which suppose to do rtpengine_delete also, but they don't work as
expected.
Thanks in advance.
--
Regards,
William Jin
From: Users
<mailto:users-boun...@lists.opensips.org> on
behalf of William Jin <mailto:willi...@exetel.com.au>
Sent: Tuesday, 9 June 2020 9:09 AM
To: OpenSIPS users mailling list
<mailto:users@lists.opensips.org>
Subject: [OpenSIPS-Users] question about rtpengine_manage() in failure_route
Hi All
May I know how can I rewrite the SDP (rtpengine) in the failure route?
The scenario is we use rtpengine_manage() in the first call attempt, if it
fails, it uses failure_route, however, we want to change the SDP info.
For example, the call's first attempt is to an ipv6 UAC, when failed, we try
ipv4 UAC. We need to change the rtpengine address-family to IP4 so the c= line
can follow with an IPv4 address.
We tried to use rtpengine_manage("address-family=IP4"), but looks like the SDP
still not changed.
Does anyone have any idea about this? Or is there any other way to achieve this?
--
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] question about rtpengine_manage() in failure_route
Below is a short config example.
route {
...
setflag(CallFWD);
rtpengine_manage(); #say the first call attempt need rtpengine
t_on_failure("handle_failure");
r_relay();
...
}
failure_route[handle_failure] {
...
if (isflagset(CallFWD)){route(handle_callfwd);}
...
}
route[handle_callfwd]{
...
xlog("L_INFO","RB=$rb(application/sdp)");
if (t_relay()){
xlog("L_INFO","Stateful relay done. RB=$rb(application/sdp)");
}
...
}
Looks like the t_relay in the handle_callfwd will inherit the SDP info that
rtpengine_manage entered in the first attempt.
Also, another interesting fact is that the SDP info is added while the t_relay
is called. Looks like the t_relay is using its data in memory and re-write the
SDP. the $rb(application/sdp) is not changed until the t_relay is called.
How can I, for example, remove the rtpengine related SDP for the second INVITE
generated by the failure_route?
I tried rtpengine_delete() in handle_callfwd or rtpengine_manage() in the
failure_route which suppose to do rtpengine_delete also, but they don't work as
expected.
Thanks in advance.
--
Regards,
William Jin
________
From: Users on behalf of William Jin
Sent: Tuesday, 9 June 2020 9:09 AM
To: OpenSIPS users mailling list
Subject: [OpenSIPS-Users] question about rtpengine_manage() in failure_route
Hi All
May I know how can I rewrite the SDP (rtpengine) in the failure route?
The scenario is we use rtpengine_manage() in the first call attempt, if it
fails, it uses failure_route, however, we want to change the SDP info.
For example, the call's first attempt is to an ipv6 UAC, when failed, we try
ipv4 UAC. We need to change the rtpengine address-family to IP4 so the c= line
can follow with an IPv4 address.
We tried to use rtpengine_manage("address-family=IP4"), but looks like the SDP
still not changed.
Does anyone have any idea about this? Or is there any other way to achieve this?
--
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] question about rtpengine_manage() in failure_route
Hi All
May I know how can I rewrite the SDP (rtpengine) in the failure route?
The scenario is we use rtpengine_manage() in the first call attempt, if it
fails, it uses failure_route, however, we want to change the SDP info.
For example, the call's first attempt is to an ipv6 UAC, when failed, we try
ipv4 UAC. We need to change the rtpengine address-family to IP4 so the c= line
can follow with an IPv4 address.
We tried to use rtpengine_manage("address-family=IP4"), but looks like the SDP
still not changed.
Does anyone have any idea about this? Or is there any other way to achieve this?
--
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about IP Transit
OK, I think I figured it out myself. Have to use force_send_socket(udp:ipv4 address); -- Regards, William Jin From: Users on behalf of William Jin Sent: Thursday, 4 June 2020 1:35 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Question about IP Transit Hi, Does anyone have any idea? I can send the sip trace if needed. -- Regards, William Jin From: Users on behalf of William Jin Sent: Tuesday, 2 June 2020 2:48 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Question about IP Transit Just additional info: A(v4) => opensips(v4/v6) => B(v6) => C(v6) - also working Does that mean if the B number is V6, I need to send the invite to the v6 IP of the opensips? Then the server should handle the ip transit from v6 to v4 again? -- Regards, William Jin From: Users on behalf of William Jin Sent: Tuesday, 2 June 2020 2:07 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] Question about IP Transit Hi We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian opensips -V version: opensips 2.4.6 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on with gcc 6.3.0 The situation is: Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6 A(v4) <=> opensips(v4<=>v6) <=> B(v6) We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue. A(v4) => opensips(v4/v6) => B(v6) - working A(v4) => opensips(v4/v6) => B(v6) => C(v4) - not working A(v4) => opensips(v4/v6) => B(v4) => C(v4) - working Could you please shed some light on it? -- Regards, William Jin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about IP Transit
Hi, Does anyone have any idea? I can send the sip trace if needed. -- Regards, William Jin From: Users on behalf of William Jin Sent: Tuesday, 2 June 2020 2:48 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Question about IP Transit Just additional info: A(v4) => opensips(v4/v6) => B(v6) => C(v6) - also working Does that mean if the B number is V6, I need to send the invite to the v6 IP of the opensips? Then the server should handle the ip transit from v6 to v4 again? -- Regards, William Jin From: Users on behalf of William Jin Sent: Tuesday, 2 June 2020 2:07 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] Question about IP Transit Hi We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian opensips -V version: opensips 2.4.6 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on with gcc 6.3.0 The situation is: Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6 A(v4) <=> opensips(v4<=>v6) <=> B(v6) We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue. A(v4) => opensips(v4/v6) => B(v6) - working A(v4) => opensips(v4/v6) => B(v6) => C(v4) - not working A(v4) => opensips(v4/v6) => B(v4) => C(v4) - working Could you please shed some light on it? -- Regards, William Jin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about IP Transit
Just additional info: A(v4) => opensips(v4/v6) => B(v6) => C(v6) - also working Does that mean if the B number is V6, I need to send the invite to the v6 IP of the opensips? Then the server should handle the ip transit from v6 to v4 again? -- Regards, William Jin From: Users on behalf of William Jin Sent: Tuesday, 2 June 2020 2:07 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] Question about IP Transit Hi We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian opensips -V version: opensips 2.4.6 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on with gcc 6.3.0 The situation is: Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6 A(v4) <=> opensips(v4<=>v6) <=> B(v6) We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue. A(v4) => opensips(v4/v6) => B(v6) - working A(v4) => opensips(v4/v6) => B(v6) => C(v4) - not working A(v4) => opensips(v4/v6) => B(v4) => C(v4) - working Could you please shed some light on it? -- Regards, William Jin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Question about IP Transit
Hi We are using opensips 2.4.6 at the moment. It's the apt standard(not nightly) repo of debian opensips -V version: opensips 2.4.6 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. main.c compiled on with gcc 6.3.0 The situation is: Our sip server has both IPv4 and IPv6 addresses, it handles IP transit pretty well. Say if there is an incoming call from the gateway A (asterisk IPv4), it can do the IP transit to the destination number registered in IPv6 A(v4) <=> opensips(v4<=>v6) <=> B(v6) We are using $T_fr_inv_timeout to do call forwarding if no answer. The issue here is: when the B has a call forwarding setting and if the destination number, let's say C is v4, then the t_relay() of the INVITE after $T_fr_inv_timeout seconds results in fail with $retcode -6, I checked the doc it says "generic send failed". I am not too sure what does that means. If both B and C are in v4 only env, then it works without any issue. A(v4) => opensips(v4/v6) => B(v6) - working A(v4) => opensips(v4/v6) => B(v6) => C(v4) - not working A(v4) => opensips(v4/v6) => B(v4) => C(v4) - working Could you please shed some light on it? -- Regards, William Jin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
ok, thanks.
I can confirm the nightly build works without any issue.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu
Sent: Tuesday, 28 April 2020 5:19 PM
To: William Jin ; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Similarly, try the nightly build
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/28/20 1:28 AM, William Jin wrote:
Ok, I will try that and let you know the result
And BTW, does the 2.4.7 (release) also has this issue?
--
Regards,
William Jin
From: Bogdan-Andrei Iancu <mailto:bog...@opensips.org>
Sent: Monday, 27 April 2020 7:10 PM
To: William Jin <mailto:willi...@exetel.com.au>;
OpenSIPS users mailling list
<mailto:users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Hi William,
Please use the nightly builds for 3.0 - there is a fix which didn't make it
into the release package.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/25/20 12:12 AM, William Jin wrote:
It's the release.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu <mailto:bog...@opensips.org>
Sent: Friday, 24 April 2020 6:14 PM
To: William Jin <mailto:willi...@exetel.com.au>;
OpenSIPS users mailling list
<mailto:users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
And it is the release or nightly build ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/24/20 1:22 AM, William Jin wrote:
I am using the debian apt repo, not from git.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu <mailto:bog...@opensips.org>
Sent: Thursday, 23 April 2020 6:49 PM
To: OpenSIPS users mailling list
<mailto:users@lists.opensips.org>; William Jin
<mailto:willi...@exetel.com.au>
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Hi William,
What GIT revision of OpenSIPS do you use? (this is exposed by the "opensips -V")
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/23/20 7:04 AM, William Jin wrote:
Hi,
Linux platform: Debian 9 (stretch)
opensips -V
version: opensips 3.0.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on with gcc 6.3.0
related config:
listen = tls:xxx.xxx.xxx.xxx:5061 anycast
TLS
loadmodule "tls_mgm.so"
loadmodule "proto_tls.so"
modparam("tls_mgm", "server_domain", "sip1")
modparam("tls_mgm", "match_ip_address", "[sip1]xx.xx.xx.xx:5061")
modparam("tls_mgm", "match_sip_domain", "[sip1]xxx.xxx.example.com")
modparam("tls_mgm", "verify_cert", "[sip1]1")
modparam("tls_mgm", "require_cert", "[sip1]0")
modparam("tls_mgm", "tls_method", "[sip1]SSLv23")
modparam("tls_mgm", "ciphers_list",
"[sip1]AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA")
modparam("tls_mgm", "certificate",
"[sip1]/etc/opensips/tls/mycerts/selfsignedcert.pem")
modparam("tls_mgm", "private_key",
"[sip1]/etc/opensips/tls/mycerts/unsecuredkey.pem")
opensips-cli -x trap {pid} result attached
Can someone shed some light on it? Thanks.
--
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Ok, I will try that and let you know the result
And BTW, does the 2.4.7 (release) also has this issue?
--
Regards,
William Jin
From: Bogdan-Andrei Iancu
Sent: Monday, 27 April 2020 7:10 PM
To: William Jin ; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Hi William,
Please use the nightly builds for 3.0 - there is a fix which didn't make it
into the release package.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/25/20 12:12 AM, William Jin wrote:
It's the release.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu <mailto:bog...@opensips.org>
Sent: Friday, 24 April 2020 6:14 PM
To: William Jin <mailto:willi...@exetel.com.au>;
OpenSIPS users mailling list
<mailto:users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
And it is the release or nightly build ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/24/20 1:22 AM, William Jin wrote:
I am using the debian apt repo, not from git.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu <mailto:bog...@opensips.org>
Sent: Thursday, 23 April 2020 6:49 PM
To: OpenSIPS users mailling list
<mailto:users@lists.opensips.org>; William Jin
<mailto:willi...@exetel.com.au>
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Hi William,
What GIT revision of OpenSIPS do you use? (this is exposed by the "opensips -V")
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/23/20 7:04 AM, William Jin wrote:
Hi,
Linux platform: Debian 9 (stretch)
opensips -V
version: opensips 3.0.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on with gcc 6.3.0
related config:
listen = tls:xxx.xxx.xxx.xxx:5061 anycast
TLS
loadmodule "tls_mgm.so"
loadmodule "proto_tls.so"
modparam("tls_mgm", "server_domain", "sip1")
modparam("tls_mgm", "match_ip_address", "[sip1]xx.xx.xx.xx:5061")
modparam("tls_mgm", "match_sip_domain", "[sip1]xxx.xxx.example.com")
modparam("tls_mgm", "verify_cert", "[sip1]1")
modparam("tls_mgm", "require_cert", "[sip1]0")
modparam("tls_mgm", "tls_method", "[sip1]SSLv23")
modparam("tls_mgm", "ciphers_list",
"[sip1]AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA")
modparam("tls_mgm", "certificate",
"[sip1]/etc/opensips/tls/mycerts/selfsignedcert.pem")
modparam("tls_mgm", "private_key",
"[sip1]/etc/opensips/tls/mycerts/unsecuredkey.pem")
opensips-cli -x trap {pid} result attached
Can someone shed some light on it? Thanks.
--
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
It's the release.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu
Sent: Friday, 24 April 2020 6:14 PM
To: William Jin ; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
And it is the release or nightly build ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/24/20 1:22 AM, William Jin wrote:
I am using the debian apt repo, not from git.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu <mailto:bog...@opensips.org>
Sent: Thursday, 23 April 2020 6:49 PM
To: OpenSIPS users mailling list
<mailto:users@lists.opensips.org>; William Jin
<mailto:willi...@exetel.com.au>
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Hi William,
What GIT revision of OpenSIPS do you use? (this is exposed by the "opensips -V")
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/23/20 7:04 AM, William Jin wrote:
Hi,
Linux platform: Debian 9 (stretch)
opensips -V
version: opensips 3.0.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on with gcc 6.3.0
related config:
listen = tls:xxx.xxx.xxx.xxx:5061 anycast
TLS
loadmodule "tls_mgm.so"
loadmodule "proto_tls.so"
modparam("tls_mgm", "server_domain", "sip1")
modparam("tls_mgm", "match_ip_address", "[sip1]xx.xx.xx.xx:5061")
modparam("tls_mgm", "match_sip_domain", "[sip1]xxx.xxx.example.com")
modparam("tls_mgm", "verify_cert", "[sip1]1")
modparam("tls_mgm", "require_cert", "[sip1]0")
modparam("tls_mgm", "tls_method", "[sip1]SSLv23")
modparam("tls_mgm", "ciphers_list",
"[sip1]AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA")
modparam("tls_mgm", "certificate",
"[sip1]/etc/opensips/tls/mycerts/selfsignedcert.pem")
modparam("tls_mgm", "private_key",
"[sip1]/etc/opensips/tls/mycerts/unsecuredkey.pem")
opensips-cli -x trap {pid} result attached
Can someone shed some light on it? Thanks.
--
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
I am using the debian apt repo, not from git.
--
Regards,
William Jin
From: Bogdan-Andrei Iancu
Sent: Thursday, 23 April 2020 6:49 PM
To: OpenSIPS users mailling list ; William Jin
Subject: Re: [OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Hi William,
What GIT revision of OpenSIPS do you use? (this is exposed by the "opensips -V")
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/23/20 7:04 AM, William Jin wrote:
Hi,
Linux platform: Debian 9 (stretch)
opensips -V
version: opensips 3.0.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on with gcc 6.3.0
related config:
listen = tls:xxx.xxx.xxx.xxx:5061 anycast
TLS
loadmodule "tls_mgm.so"
loadmodule "proto_tls.so"
modparam("tls_mgm", "server_domain", "sip1")
modparam("tls_mgm", "match_ip_address", "[sip1]xx.xx.xx.xx:5061")
modparam("tls_mgm", "match_sip_domain", "[sip1]xxx.xxx.example.com")
modparam("tls_mgm", "verify_cert", "[sip1]1")
modparam("tls_mgm", "require_cert", "[sip1]0")
modparam("tls_mgm", "tls_method", "[sip1]SSLv23")
modparam("tls_mgm", "ciphers_list",
"[sip1]AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA")
modparam("tls_mgm", "certificate",
"[sip1]/etc/opensips/tls/mycerts/selfsignedcert.pem")
modparam("tls_mgm", "private_key",
"[sip1]/etc/opensips/tls/mycerts/unsecuredkey.pem")
opensips-cli -x trap {pid} result attached
Can someone shed some light on it? Thanks.
--
Regards,
William Jin
___
Users mailing list
Users@lists.opensips.org<mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensips 3.0.2 100% CPU after enable tls?
Hi,
Linux platform: Debian 9 (stretch)
opensips -V
version: opensips 3.0.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on with gcc 6.3.0
related config:
listen = tls:xxx.xxx.xxx.xxx:5061 anycast
TLS
loadmodule "tls_mgm.so"
loadmodule "proto_tls.so"
modparam("tls_mgm", "server_domain", "sip1")
modparam("tls_mgm", "match_ip_address", "[sip1]xx.xx.xx.xx:5061")
modparam("tls_mgm", "match_sip_domain", "[sip1]xxx.xxx.example.com")
modparam("tls_mgm", "verify_cert", "[sip1]1")
modparam("tls_mgm", "require_cert", "[sip1]0")
modparam("tls_mgm", "tls_method", "[sip1]SSLv23")
modparam("tls_mgm", "ciphers_list",
"[sip1]AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA,DES-CBC3-SHA")
modparam("tls_mgm", "certificate",
"[sip1]/etc/opensips/tls/mycerts/selfsignedcert.pem")
modparam("tls_mgm", "private_key",
"[sip1]/etc/opensips/tls/mycerts/unsecuredkey.pem")
opensips-cli -x trap {pid} result attached
Can someone shed some light on it? Thanks.
--
Regards,
William Jin
gdb_opensips_20200423_135258
Description: gdb_opensips_20200423_135258
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensips 2.4.6 crash dns_cache module with CNAME record
Hi,
We are using Opensips 2.4.6(apt repo) on Debian stretch
opensips -V
version: opensips 2.4.6 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC,
FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
main.c compiled on with gcc 6.3.0
We started to use dns_cache module recently.
However, after we add the module, opensips crashes when it stores a particular
dns_cache and we noticed below error
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__naptr] with value [|] ttl = 7200
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__sip._udp._srv] with value [|] ttl = 7200
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__] with value [|] ttl = 7200
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__a] with value [#002] ttl = 1769
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__naptr] with value [|] ttl = 7200
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__sip._udp._srv] with value [|] ttl = 7200
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__] with value [|] ttl = 7200
Dec 4 03:53:17 /usr/sbin/opensips[10788]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache__a] with value [#002] ttl = 60
Dec 4 03:53:24 /usr/sbin/opensips[10789]: INFO:dns_cache:put_dnscache_value:
putting key [dnscache_[CNAME_hostname]_] with value [#012] ttl = 20062
Dec 4 03:53:24 /usr/sbin/opensips[10789]: CRITICAL:core:sig_usr: segfault in
process pid: 10789, id: 6
Dec 4 03:53:24 /usr/sbin/opensips[10854]: CRITICAL:core:handle_worker: dead
child 6 (EOF received), pid 10789
Dec 4 03:53:24 /usr/sbin/opensips[10773]: INFO:core:handle_sigs: child process
10789 exited by a signal 11
To replicate:
==
dns_try_ipv6=yes
...
loadmodule "cachedb_local.so"
loadmodule "dns_cache.so"
...
modparam("dns_cache", "cachedb_url","local://")
modparam("dns_cache", "blacklist_timeout",7200)
Create a hostname with record points to a CNAME without any records (E.g
www.example.com<http://www.example.com> 60 IN CNAME
www.example.net<http://www.example.net>., but do not give any record to
www.example.net<http://www.example.net>)
modparam("proto_hep", "hep_id", "[hep_dst]
www.example.com;transport=udp;version=3<http://www.example.com;transport=udp;version=3>")
#we are using the hostname here in proto_hep, I think it can be triggered
anywhere.
==
>From the log, I believe if the dns query fail, it will store it for
>{blacklist_timeout} seconds.
However, in my case, it can get a CNAME answer, but there is no actual IPv6 IP
associate with it, and it is where opensips crash happens. The ttl = 20062
also looks weird in the log, because I set it up for 60 only.
We also tried to use the cachedb_memcached by setting up a memcache server,
same crash. However, when we tried to use the same settings on a server without
this particular CNAME record, then the issue is gone.
--
Regards,
William Jin
[cid:image001.png@01CF28AB.CA19A270]
Exetel System Adminitrator | Exetel PTY LTD
Web: www.exetel.com.au<http://www.exetel.com.au/>
Main : 0280301000
Direct : 0280301038
Fax : 0280302100
Disclaimer: Hey, we like to 'Get Things Done' but sometimes little things can
go astray. Like emails. This email may contain confidential information. If you
received it accidentally please let the sender know and delete it. No
contractual obligations for pricing or any services will arise until we sign a
formal written contract or formal variation to your existing contract.
Exetel Pty Ltd - PRIVACY POLICY
Exetel respects your privacy, and we will only reveal, discuss, or transact
with the owner of the service(s) via e-mail or telephone once we are satisfied
we have identified the person who is seeking information. If for any reason any
other person(s) wishes to enquire on a service that they are not the owner of,
we will not discuss any matters with them. Exetel's Privacy policy is not
negotiable under any circumstances, except for urgent or vital situations as
described in the relevant Federal legislation (Privacy Act).
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
