[OpenSIPS-Devel] [ opensips-Bugs-3612653 ] B2b_logic bridge no ack SDP
Bugs item #3612653, was opened at 2013-05-04 15:53 Message generated for change (Comment added) made by soulof87 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612653group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 7 Private: No Submitted By: tito cumpen (soulof87) Assigned to: Nobody/Anonymous (nobody) Summary: B2b_logic bridge no ack SDP Initial Comment: B2b_logic module fails to send the 200 ok SDP from param 2 to param 1 in ack SDP. as was done in 1.7.2. Please advise if this is a or a change in functionality. Below is a diagram of the none working 1.9 Conv.| Time| 166.78.110.228| | | | 166.78.236.169| 0|5.258027 | INVITE| |SIP From: sip:nurse@166.78.236.169 To:sip:patient@166.78.236.16 | |(5060) -- (5060) | 0|5.260412 | 100 Giving a try |SIP Status | |(5060) -- (5060) | 0|16.888258| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 0|17.887802| 180 Ringing |SIP Status | |(5060) -- (5060) | 0|19.232125| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|19.232396| INVITE SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP From: sip:patient@166.78.236.169 To:sip:nurse@166.78.236.16 | |(5060) -- (5060) | 1|19.239251| 100 Giving a try |SIP Status | |(5060) -- (5060) | 1|19.446797| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 1|19.522588| 180 Ringing |SIP Status | |(5060) -- (5060) | - 0|20.547695| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|20.730180| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 0|20.730440| ACK | |SIP Request | |(5060) -- (5060) | - 1|20.730469| ACK | |SIP Request | |(5060) -- (5060) | - 0|21.046693| BYE | |SIP Request | |(5060) -- (5060) | - 1|21.046955| BYE | |SIP Request | |(5060) -- (5060) | 1|21.328808| 200 OK| |SIP Status | |(5060) -- (5060) | - 0|21.328988| 200 OK| |SIP Status | |(5060) -- (5060) | Here is the one that is currently working using the same scenario file. notice the differences in with the utilization of ack sdp. Conv.| Time| 166.78.237.54 | | | | 166.78.236.169| 0|31.699153| INVITE| |SIP From: sip:nurse@166.78.236.169 To:sip:patient@166.78.236.16 | |(5060) -- (5060) | 0|31.703241| 100 Giving a try |SIP Status | |(5060) -- (5060) | 0|41.924874| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 0|51.984304| 180 Ringing |SIP Status | |(5060) -- (5060) | 0|51.986846| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|51.987036| INVITE SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP From: sip:patient@166.78.236.169
[OpenSIPS-Devel] [ opensips-Bugs-3611852 ] General protection in dialog module
Bugs item #3611852, was opened at 2013-04-25 10:55 Message generated for change (Comment added) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611852group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Vladut-Stefan Paiu (vladut-paiu) Summary: General protection in dialog module Initial Comment: I have seen this across a few systems, seems like a bad pointer. Kernel Message opensips[18810] general protection ip:7fa541fdcc2d sp:7fff44fff870 error:0 in dialog.so[7fa541faf000+55000] Based on the kernel message and an objdump of dialog.so it seems this is in the get_dlg_by_val() function. Working on a core dump + full bt. -- Comment By: Ryan Bullock (rrb3942) Date: 2013-05-08 12:36 Message: No update on this. Haven't seen it again since I reported it. Just waiting for it to happen to get a core dump. -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-05-07 03:03 Message: Hi Ryan, Any updates with this ? Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611852group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3611850 ] Segfault on shutdown in db_mysql
Bugs item #3611850, was opened at 2013-04-25 10:46 Message generated for change (Comment added) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Vladut-Stefan Paiu (vladut-paiu) Summary: Segfault on shutdown in db_mysql Initial Comment: I am seeing a segfault on shutdown in the db_mysql module. My guess is that is is related to a flush to db on shutdown somewhere, we are using bulk inserts so that may be related. Kernel message: opensips[18804]: segfault at 0 ip 7fa545fb0089 sp 7fff45002280 error 6 in db_mysql.so[7fa545fa3000+11000] Going off the kernel message and an objdump of db_mysql.so, seems to be in the db_mysql_val2bind() function. I am working on getting a full core + back trace. -- Comment By: Ryan Bullock (rrb3942) Date: 2013-05-08 12:46 Message: Hey vlad this was a shutdown down after a crash, so the crash in a different process may be the cause. Although it would be nice if it didn't cause another segfault (and another core) when that happens. If you have a patch to get more debug information I can get that into place for when the next crash happens. -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-05-07 03:18 Message: Hello Ryan, I see this is related to the query buffering part. Is this for a normal shutdown, or for a shutdown after a crash ? Seems that somehow ( very oddly ) the prepared statement was not properly allocated.. Can you replicate this somehow ? If yes, I'd like to send you a patch that would print some extra debugging. Best Regards, Vlad -- Comment By: Ryan Bullock (rrb3942) Date: 2013-05-02 12:48 Message: Backtrace attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612928 ] General protection in ratelimit module
Bugs item #3612928, was opened at 2013-05-08 12:50 Message generated for change (Tracker Item Submitted) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612928group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Nobody/Anonymous (nobody) Summary: General protection in ratelimit module Initial Comment: Showing a GP in the ratelimit timer. Happens infrequently. Backtrace is attached. Working on a memory dump as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612928group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612777 ] do_routing: 'W' flag ignored
Bugs item #3612777, was opened at 2013-05-06 12:02 Message generated for change (Tracker Item Submitted) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612777group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) Assigned to: Nobody/Anonymous (nobody) Summary: do_routing: 'W' flag ignored Initial Comment: The 'W' weight flag is ignored while calling do_routing. If in the dr_rules, under gwlist we provision actual gateways with weight, the weight flag is taken into consideration while routing. If in the dr_rules, under gwlist we use a carrier (marked with '#') and if the carrier has multiple gateways configured with weigh (gwlist field on dr_cariers table), the weight flag is ignored for those gateways. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612777group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612653 ] B2b_logic bridge no ack SDP
Bugs item #3612653, was opened at 2013-05-04 15:53 Message generated for change (Tracker Item Submitted) made by soulof87 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612653group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: tito cumpen (soulof87) Assigned to: Nobody/Anonymous (nobody) Summary: B2b_logic bridge no ack SDP Initial Comment: B2b_logic module fails to send the 200 ok SDP from param 2 to param 1 in ack SDP. as was done in 1.7.2. Please advise if this is a or a change in functionality. Below is a diagram of the none working 1.9 Conv.| Time| 166.78.110.228| | | | 166.78.236.169| 0|5.258027 | INVITE| |SIP From: sip:nurse@166.78.236.169 To:sip:patient@166.78.236.16 | |(5060) -- (5060) | 0|5.260412 | 100 Giving a try |SIP Status | |(5060) -- (5060) | 0|16.888258| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 0|17.887802| 180 Ringing |SIP Status | |(5060) -- (5060) | 0|19.232125| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|19.232396| INVITE SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP From: sip:patient@166.78.236.169 To:sip:nurse@166.78.236.16 | |(5060) -- (5060) | 1|19.239251| 100 Giving a try |SIP Status | |(5060) -- (5060) | 1|19.446797| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 1|19.522588| 180 Ringing |SIP Status | |(5060) -- (5060) | - 0|20.547695| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|20.730180| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 0|20.730440| ACK | |SIP Request | |(5060) -- (5060) | - 1|20.730469| ACK | |SIP Request | |(5060) -- (5060) | - 0|21.046693| BYE | |SIP Request | |(5060) -- (5060) | - 1|21.046955| BYE | |SIP Request | |(5060) -- (5060) | 1|21.328808| 200 OK| |SIP Status | |(5060) -- (5060) | - 0|21.328988| 200 OK| |SIP Status | |(5060) -- (5060) | Here is the one that is currently working using the same scenario file. notice the differences in with the utilization of ack sdp. Conv.| Time| 166.78.237.54 | | | | 166.78.236.169| 0|31.699153| INVITE| |SIP From: sip:nurse@166.78.236.169 To:sip:patient@166.78.236.16 | |(5060) -- (5060) | 0|31.703241| 100 Giving a try |SIP Status | |(5060) -- (5060) | 0|41.924874| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 0|51.984304| 180 Ringing |SIP Status | |(5060) -- (5060) | 0|51.986846| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|51.987036| INVITE SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP From: sip:patient@166.78.236.169
[OpenSIPS-Devel] [ opensips-Bugs-3612653 ] B2b_logic bridge no ack SDP
Bugs item #3612653, was opened at 2013-05-04 15:53 Message generated for change (Settings changed) made by soulof87 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612653group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 7 Private: No Submitted By: tito cumpen (soulof87) Assigned to: Nobody/Anonymous (nobody) Summary: B2b_logic bridge no ack SDP Initial Comment: B2b_logic module fails to send the 200 ok SDP from param 2 to param 1 in ack SDP. as was done in 1.7.2. Please advise if this is a or a change in functionality. Below is a diagram of the none working 1.9 Conv.| Time| 166.78.110.228| | | | 166.78.236.169| 0|5.258027 | INVITE| |SIP From: sip:nurse@166.78.236.169 To:sip:patient@166.78.236.16 | |(5060) -- (5060) | 0|5.260412 | 100 Giving a try |SIP Status | |(5060) -- (5060) | 0|16.888258| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 0|17.887802| 180 Ringing |SIP Status | |(5060) -- (5060) | 0|19.232125| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|19.232396| INVITE SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP From: sip:patient@166.78.236.169 To:sip:nurse@166.78.236.16 | |(5060) -- (5060) | 1|19.239251| 100 Giving a try |SIP Status | |(5060) -- (5060) | 1|19.446797| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 1|19.522588| 180 Ringing |SIP Status | |(5060) -- (5060) | - 0|20.547695| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|20.730180| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 0|20.730440| ACK | |SIP Request | |(5060) -- (5060) | - 1|20.730469| ACK | |SIP Request | |(5060) -- (5060) | - 0|21.046693| BYE | |SIP Request | |(5060) -- (5060) | - 1|21.046955| BYE | |SIP Request | |(5060) -- (5060) | 1|21.328808| 200 OK| |SIP Status | |(5060) -- (5060) | - 0|21.328988| 200 OK| |SIP Status | |(5060) -- (5060) | Here is the one that is currently working using the same scenario file. notice the differences in with the utilization of ack sdp. Conv.| Time| 166.78.237.54 | | | | 166.78.236.169| 0|31.699153| INVITE| |SIP From: sip:nurse@166.78.236.169 To:sip:patient@166.78.236.16 | |(5060) -- (5060) | 0|31.703241| 100 Giving a try |SIP Status | |(5060) -- (5060) | 0|41.924874| 101 Dialog Establishement |SIP Status | |(5060) -- (5060) | 0|51.984304| 180 Ringing |SIP Status | |(5060) -- (5060) | 0|51.986846| 200 OK SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP Status | |(5060) -- (5060) | - 1|51.987036| INVITE SDP (SILKRTPType-121 SILKRTPType-120 sp...RTPType-111 ) |SIP From: sip:patient@166.78.236.169
[OpenSIPS-Devel] [ opensips-Bugs-3612046 ] opensips crashing when excuting b2b_logic extern script
Bugs item #3612046, was opened at 2013-04-27 15:55
Message generated for change (Comment added) made by soulof87
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612046group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.9.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: tito cumpen (soulof87)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashing when excuting b2b_logic extern script
Initial Comment:
Opensips is crashing 1 execute a fifo command like so opensipsctl fifo
b2b_trigger_scenario 3pcc sip:nurse@ip sip:patient@ip. Attached is the
scenario file. The Ip addresses have replaced with IP. i am using the latest
1.9 stable release acquired via svn
Heres the entire backtrace
(gdb) bt full
#0 get_local_contact (sock=0x0, contact=0x7fff1c16eb98) at
../presence/utils_func.h:84
buf = '\000' repeats 1023 times
proto = value optimized out
proto_len = value optimized out
#1 0x7fbbeabb3d21 in process_bridge_action (msg=0x0, curr_entity=value
optimized out, tuple=0x7fbbe8e31b30, bridge_node=0x954830) at logic.c:2501
from_uri = {s = 0x7fbbe8e3d267 sip:patient@ip, len = 26}
to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24}
from_dname = value optimized out
bridge_entities = {0x7fbbe8e3d0e8, 0x7fbbe8e3d1c0, 0x0}
entity = value optimized out
old_entity = value optimized out
e = value optimized out
count = value optimized out
index = value optimized out
attr = {s = 0x0, len = 7}
entity_dest = {s = 0x7fbbe8e3d080 sip:patient@ip, len = 26}
clientid_node = value optimized out
dest_node = value optimized out
client_node = value optimized out
lft_node = value optimized out
node = value optimized out
provmedia_uri = {s = 0x0, len = 0}
ci = {method = {s = 0x7fbbeabced40 INVITE, len = 6}, from_uri = {s =
0x7fbbe8e3d267 sip:patient@ip, len = 26}, from_dname = {s = 0x0,
len = 0}, req_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len =
0}, to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24},
to_dname = {s = 0x0, len = 0}, extra_headers = 0x0, body = 0x0,
from_tag = 0x0, local_contact = {s = 0x7fbbeadd6880 , len = 0}, cseq = 0,
send_sock = 0x0}
client_id = value optimized out
fdname_content = 0x0
from_dname = {s = 0x0, len = 0}
value_node = value optimized out
value_content = value optimized out
req_data = {et = 8287936, b2b_key = 0x943fb0, method = 0x7fbbee525860,
extra_headers = 0x7fbbee1fec1a, body = 0x7fbbedfa2960, dlginfo = 0x4240b0,
no_cb = 40}
__FUNCTION__ = process_bridge_action
#2 0x7fbbeaba4d53 in b2bl_bridge_extern (scenario_name=value optimized
out, args=value optimized out, cbf=0, cb_param=0x0) at b2b_logic.c:1067
scenario_struct = 0x7fbbedfa2960
hash_index = 935
tuple = 0x7fbbe8e31b30
b2bl_key = value optimized out
state = value optimized out
xml_node = value optimized out
attr = value optimized out
__FUNCTION__ = b2bl_bridge_extern
#3 0x7fbbeaba530d in mi_trigger_scenario (cmd=value optimized out,
param=value optimized out) at b2b_logic.c:1114
node = value optimized out
args = {0x7fbbedfae6a0, 0x7fbbedfae700, 0x0, 0x0, 0x0}
i = value optimized out
scenario_name = {s = 0x7fbbedfaf138 3pccsip:nurse@IPsip:patient@IP\n,
len = 4}
__FUNCTION__ = mi_trigger_scenario
#4 0x7fbbed0ef3c5 in run_mi_cmd (fifo_stream=0x949950) at ../../mi/mi.h:109
ret = value optimized out
#5 mi_fifo_server (fifo_stream=0x949950) at fifo_fnc.c:490
mi_cmd = value optimized out
mi_rpl = value optimized out
hdl = 0x0
---Type return to continue, or q return to quit---
line_len = 45
file_sep = value optimized out
command = value optimized out
file = value optimized out
f = 0x7fbbedface90
reply_stream = 0x943d70
__FUNCTION__ = mi_fifo_server
#6 0x7fbbed0f1977 in fifo_process (rank=value optimized out) at
mi_fifo.c:213
fifo_stream = 0x949950
__FUNCTION__ = fifo_process
#7 0x004a17ec in start_module_procs () at sr_module.c:585
m = value optimized out
n = value optimized out
l = value optimized out
x = value optimized out
__FUNCTION__ = start_module_procs
#8 0x00432ec1 in main_loop (argc=value optimized out, argv=value
optimized out) at main.c:707
i = value optimized out
pid = value optimized out
si = value optimized out
startup_done = 0x0
chd_rank = 0
rc = value optimized out
load_p = 0x0
#9 main
[OpenSIPS-Devel] [ opensips-Bugs-3612563 ] OpenSIPS fails to parse MIME types containing numbers
Bugs item #3612563, was opened at 2013-05-03 05:14 Message generated for change (Tracker Item Submitted) made by vfm-barracuda You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612563group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Víctor Fernández Martínez (vfm-barracuda) Assigned to: Nobody/Anonymous (nobody) Summary: OpenSIPS fails to parse MIME types containing numbers Initial Comment: Microsoft Lync uses several custom MIME types for its communication with the server. When OpenSIPS is used as a SIP proxy between the Lync client and the Lync server, the following error can be seen in the logs: DBG:core:decode_mime_type: Decoding MIME type for:[application/vnd-microsoft-roaming-provisioning-v2+xml] ERROR:core:decode_mime_type: parse error near in [application/vnd-microsoft-roaming-provisioning-v2+xml] char[50][2] offset =48 DBG:core:set_err_info: ec: 1, el: 3, ei: 'error parsing CT-TYPE header' This happens always in OpenSIPS 1.8.2. After taking a look at the source code, it is evident that decode_mime_type() doesn't accept digits (0-9) as valid characters in MIME types. This could easily be fixed by replacing the definition of is_mime_char() in parse_content.c with the following: #define is_mime_char(_c_) \ (isalnum((int)_c_) || (_c_)=='-' || (_c_)=='+' || (_c_)=='.') -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612563group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-3212664 ] registrant: add MI/script commands to control registration
Feature Requests item #3212664, was opened at 2011-03-14 23:05 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3212664group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Closed Priority: 3 Private: No Submitted By: Paul Wise (pabs3) Assigned to: Ovidiu Sas (osas) Summary: registrant: add MI/script commands to control registration Initial Comment: Please add MI and script commands to control the list of registrations in the registrant module. The following commands would be useful: add: register a new registration and add it to the database remove: de-register a registration and remove it from the database update: re-register a registration and update database information dbsync: trigger a reload of the database, de-register of missing registrations and register of new registrations -- Comment By: Ovidiu Sas (osas) Date: 2013-05-03 08:08 Message: This is implemented in trunk via the new reg_reload mi command: http://www.opensips.org/html/docs/modules/devel/uac_registrant#id250484 Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3212664group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612046 ] opensips crashing when excuting b2b_logic extern script
Bugs item #3612046, was opened at 2013-04-27 15:55
Message generated for change (Comment added) made by osas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612046group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.9.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: tito cumpen (soulof87)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashing when excuting b2b_logic extern script
Initial Comment:
Opensips is crashing 1 execute a fifo command like so opensipsctl fifo
b2b_trigger_scenario 3pcc sip:nurse@ip sip:patient@ip. Attached is the
scenario file. The Ip addresses have replaced with IP. i am using the latest
1.9 stable release acquired via svn
Heres the entire backtrace
(gdb) bt full
#0 get_local_contact (sock=0x0, contact=0x7fff1c16eb98) at
../presence/utils_func.h:84
buf = '\000' repeats 1023 times
proto = value optimized out
proto_len = value optimized out
#1 0x7fbbeabb3d21 in process_bridge_action (msg=0x0, curr_entity=value
optimized out, tuple=0x7fbbe8e31b30, bridge_node=0x954830) at logic.c:2501
from_uri = {s = 0x7fbbe8e3d267 sip:patient@ip, len = 26}
to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24}
from_dname = value optimized out
bridge_entities = {0x7fbbe8e3d0e8, 0x7fbbe8e3d1c0, 0x0}
entity = value optimized out
old_entity = value optimized out
e = value optimized out
count = value optimized out
index = value optimized out
attr = {s = 0x0, len = 7}
entity_dest = {s = 0x7fbbe8e3d080 sip:patient@ip, len = 26}
clientid_node = value optimized out
dest_node = value optimized out
client_node = value optimized out
lft_node = value optimized out
node = value optimized out
provmedia_uri = {s = 0x0, len = 0}
ci = {method = {s = 0x7fbbeabced40 INVITE, len = 6}, from_uri = {s =
0x7fbbe8e3d267 sip:patient@ip, len = 26}, from_dname = {s = 0x0,
len = 0}, req_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len =
0}, to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24},
to_dname = {s = 0x0, len = 0}, extra_headers = 0x0, body = 0x0,
from_tag = 0x0, local_contact = {s = 0x7fbbeadd6880 , len = 0}, cseq = 0,
send_sock = 0x0}
client_id = value optimized out
fdname_content = 0x0
from_dname = {s = 0x0, len = 0}
value_node = value optimized out
value_content = value optimized out
req_data = {et = 8287936, b2b_key = 0x943fb0, method = 0x7fbbee525860,
extra_headers = 0x7fbbee1fec1a, body = 0x7fbbedfa2960, dlginfo = 0x4240b0,
no_cb = 40}
__FUNCTION__ = process_bridge_action
#2 0x7fbbeaba4d53 in b2bl_bridge_extern (scenario_name=value optimized
out, args=value optimized out, cbf=0, cb_param=0x0) at b2b_logic.c:1067
scenario_struct = 0x7fbbedfa2960
hash_index = 935
tuple = 0x7fbbe8e31b30
b2bl_key = value optimized out
state = value optimized out
xml_node = value optimized out
attr = value optimized out
__FUNCTION__ = b2bl_bridge_extern
#3 0x7fbbeaba530d in mi_trigger_scenario (cmd=value optimized out,
param=value optimized out) at b2b_logic.c:1114
node = value optimized out
args = {0x7fbbedfae6a0, 0x7fbbedfae700, 0x0, 0x0, 0x0}
i = value optimized out
scenario_name = {s = 0x7fbbedfaf138 3pccsip:nurse@IPsip:patient@IP\n,
len = 4}
__FUNCTION__ = mi_trigger_scenario
#4 0x7fbbed0ef3c5 in run_mi_cmd (fifo_stream=0x949950) at ../../mi/mi.h:109
ret = value optimized out
#5 mi_fifo_server (fifo_stream=0x949950) at fifo_fnc.c:490
mi_cmd = value optimized out
mi_rpl = value optimized out
hdl = 0x0
---Type return to continue, or q return to quit---
line_len = 45
file_sep = value optimized out
command = value optimized out
file = value optimized out
f = 0x7fbbedface90
reply_stream = 0x943d70
__FUNCTION__ = mi_fifo_server
#6 0x7fbbed0f1977 in fifo_process (rank=value optimized out) at
mi_fifo.c:213
fifo_stream = 0x949950
__FUNCTION__ = fifo_process
#7 0x004a17ec in start_module_procs () at sr_module.c:585
m = value optimized out
n = value optimized out
l = value optimized out
x = value optimized out
__FUNCTION__ = start_module_procs
#8 0x00432ec1 in main_loop (argc=value optimized out, argv=value
optimized out) at main.c:707
i = value optimized out
pid = value optimized out
si = value optimized out
startup_done = 0x0
chd_rank = 0
rc = value optimized out
load_p = 0x0
#9 main
[OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy causes system freeze
Bugs item #3611677, was opened at 2013-04-23 14:10 Message generated for change (Comment added) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611677group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 7 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Offiline RTP Proxy causes system freeze Initial Comment: I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise. The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage). Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected. -- Comment By: Digipigeon (digipigeon) Date: 2013-05-02 03:57 Message: I have updated my code in an attempt to circumvent the issue to include: modparam(rtpproxy, rtpproxy_disable_tout, -1) My observations on the above modification are as follows: 1. CPU regularly runs ah a higher value than before modification. 2. The CPU still reaches 100% utilisation which then causes kernal packet drops (SIP, just because of high load). 3. The 100% CPU usage (through my limited observations) does not appear last as long in locked up state. Further to this I can observe that multiple RTP servers fail successively, however the chance that 5 RTP servers go offline at the time is unlikely, however I am considering that the successive fails of multiple rtp servers could be a effect of the high CPU utilisation then causing packet drops rather than multiple. However in addition this, I have setup a ICMP ping as well as a V ping via UDP in the control channel, both with return negligible packet loss. -- Comment By: Digipigeon (digipigeon) Date: 2013-04-24 10:40 Message: Well this happened sooner than I was expecting, I managed to run the commands on the processes that were taking up the CPU usage, however I cant gurentee that I was able to run the script before the process completed its high usage. Please see files, Dump 1 and Dump 2 -- Comment By: Digipigeon (digipigeon) Date: 2013-04-24 03:40 Message: Hi Răzvan, Thank you, I will make a note of this, however it is my aim not to let my system enter this state again and I have only been able to replicate with live traffic, so I am not sure when I will have the opportunity to run this again. I will keep you updated though. Kind Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-24 03:31 Message: Hi! When opensips is in 100% CPU usage, can you run the following command: gdb $OPENSIPS $PID -batch --eval-command=bt full Note you have to replace $OPENSIPS with OpenSIPS' executable path and $PID with the value of the pid that holds the CPU in 100%. Best regards, Răzvan -- Comment By: Digipigeon (digipigeon) Date: 2013-04-24 03:25 Message: Hello Răzvan, I would make the same assumption, which is expected, however I don't know why this would lead to 100% CPU usage, surely probing only involved sending and waiting for a udp packet. I am using 32 processes on an 8 core machine. I am not using rtpproxy_disable_tout parameter. I have not tried to disable via MI command. Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-24 00:41 Message: Hello! My assumption is that OpenSIPS is trying to probe the other RTPProxy servers without any success. That's probably why the CPU goes that high. How many OpenSIPS processes are you using? Are you using the rtpproxy_disable_tout [1] parameter? If yes, what value are you setting? Have you tried to permanently disable via MI commands [2 ]the RTPProxy servers that failed? [1] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id250074 [2] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy#id293384 Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611677group_id=232389
[OpenSIPS-Devel] [ opensips-Bugs-3611850 ] Segfault on shutdown in db_mysql
Bugs item #3611850, was opened at 2013-04-25 10:46 Message generated for change (Comment added) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault on shutdown in db_mysql Initial Comment: I am seeing a segfault on shutdown in the db_mysql module. My guess is that is is related to a flush to db on shutdown somewhere, we are using bulk inserts so that may be related. Kernel message: opensips[18804]: segfault at 0 ip 7fa545fb0089 sp 7fff45002280 error 6 in db_mysql.so[7fa545fa3000+11000] Going off the kernel message and an objdump of db_mysql.so, seems to be in the db_mysql_val2bind() function. I am working on getting a full core + back trace. -- Comment By: Ryan Bullock (rrb3942) Date: 2013-05-02 12:48 Message: Backtrace attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612267 ] opensips segfault in drouting module
Bugs item #3612267, was opened at 2013-04-30 04:49 Message generated for change (Comment added) made by r0nald11 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612267group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Nobody/Anonymous (nobody) Summary: opensips segfault in drouting module Initial Comment: Just saw a crash on a production server, running opensips 1.8 rev #9969 -ish, bt full attached. The IP address in the strcmp seems odd, having an extra 4 at the beginning. -- Comment By: Ronald Cepres (r0nald11) Date: 2013-05-01 12:00 Message: I think this is a duplicate report. Please see: http://sourceforge.net/tracker/?func=detailaid=3610045group_id=232389atid=1086410 Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612267group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612267 ] opensips segfault in drouting module
Bugs item #3612267, was opened at 2013-04-30 04:49 Message generated for change (Tracker Item Submitted) made by kisskaroly You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612267group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Nobody/Anonymous (nobody) Summary: opensips segfault in drouting module Initial Comment: Just saw a crash on a production server, running opensips 1.8 rev #9969 -ish, bt full attached. The IP address in the strcmp seems odd, having an extra 4 at the beginning. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612267group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612046 ] opensips crashing when excuting b2b_logic extern script
Bugs item #3612046, was opened at 2013-04-27 15:55
Message generated for change (Comment added) made by soulof87
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612046group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.9.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: tito cumpen (soulof87)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashing when excuting b2b_logic extern script
Initial Comment:
Opensips is crashing 1 execute a fifo command like so opensipsctl fifo
b2b_trigger_scenario 3pcc sip:nurse@ip sip:patient@ip. Attached is the
scenario file. The Ip addresses have replaced with IP. i am using the latest
1.9 stable release acquired via svn
Heres the entire backtrace
(gdb) bt full
#0 get_local_contact (sock=0x0, contact=0x7fff1c16eb98) at
../presence/utils_func.h:84
buf = '\000' repeats 1023 times
proto = value optimized out
proto_len = value optimized out
#1 0x7fbbeabb3d21 in process_bridge_action (msg=0x0, curr_entity=value
optimized out, tuple=0x7fbbe8e31b30, bridge_node=0x954830) at logic.c:2501
from_uri = {s = 0x7fbbe8e3d267 sip:patient@ip, len = 26}
to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24}
from_dname = value optimized out
bridge_entities = {0x7fbbe8e3d0e8, 0x7fbbe8e3d1c0, 0x0}
entity = value optimized out
old_entity = value optimized out
e = value optimized out
count = value optimized out
index = value optimized out
attr = {s = 0x0, len = 7}
entity_dest = {s = 0x7fbbe8e3d080 sip:patient@ip, len = 26}
clientid_node = value optimized out
dest_node = value optimized out
client_node = value optimized out
lft_node = value optimized out
node = value optimized out
provmedia_uri = {s = 0x0, len = 0}
ci = {method = {s = 0x7fbbeabced40 INVITE, len = 6}, from_uri = {s =
0x7fbbe8e3d267 sip:patient@ip, len = 26}, from_dname = {s = 0x0,
len = 0}, req_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len =
0}, to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24},
to_dname = {s = 0x0, len = 0}, extra_headers = 0x0, body = 0x0,
from_tag = 0x0, local_contact = {s = 0x7fbbeadd6880 , len = 0}, cseq = 0,
send_sock = 0x0}
client_id = value optimized out
fdname_content = 0x0
from_dname = {s = 0x0, len = 0}
value_node = value optimized out
value_content = value optimized out
req_data = {et = 8287936, b2b_key = 0x943fb0, method = 0x7fbbee525860,
extra_headers = 0x7fbbee1fec1a, body = 0x7fbbedfa2960, dlginfo = 0x4240b0,
no_cb = 40}
__FUNCTION__ = process_bridge_action
#2 0x7fbbeaba4d53 in b2bl_bridge_extern (scenario_name=value optimized
out, args=value optimized out, cbf=0, cb_param=0x0) at b2b_logic.c:1067
scenario_struct = 0x7fbbedfa2960
hash_index = 935
tuple = 0x7fbbe8e31b30
b2bl_key = value optimized out
state = value optimized out
xml_node = value optimized out
attr = value optimized out
__FUNCTION__ = b2bl_bridge_extern
#3 0x7fbbeaba530d in mi_trigger_scenario (cmd=value optimized out,
param=value optimized out) at b2b_logic.c:1114
node = value optimized out
args = {0x7fbbedfae6a0, 0x7fbbedfae700, 0x0, 0x0, 0x0}
i = value optimized out
scenario_name = {s = 0x7fbbedfaf138 3pccsip:nurse@IPsip:patient@IP\n,
len = 4}
__FUNCTION__ = mi_trigger_scenario
#4 0x7fbbed0ef3c5 in run_mi_cmd (fifo_stream=0x949950) at ../../mi/mi.h:109
ret = value optimized out
#5 mi_fifo_server (fifo_stream=0x949950) at fifo_fnc.c:490
mi_cmd = value optimized out
mi_rpl = value optimized out
hdl = 0x0
---Type return to continue, or q return to quit---
line_len = 45
file_sep = value optimized out
command = value optimized out
file = value optimized out
f = 0x7fbbedface90
reply_stream = 0x943d70
__FUNCTION__ = mi_fifo_server
#6 0x7fbbed0f1977 in fifo_process (rank=value optimized out) at
mi_fifo.c:213
fifo_stream = 0x949950
__FUNCTION__ = fifo_process
#7 0x004a17ec in start_module_procs () at sr_module.c:585
m = value optimized out
n = value optimized out
l = value optimized out
x = value optimized out
__FUNCTION__ = start_module_procs
#8 0x00432ec1 in main_loop (argc=value optimized out, argv=value
optimized out) at main.c:707
i = value optimized out
pid = value optimized out
si = value optimized out
startup_done = 0x0
chd_rank = 0
rc = value optimized out
load_p = 0x0
#9 main
[OpenSIPS-Devel] [ opensips-Bugs-3612046 ] opensips crashing when excuting b2b_logic extern script
Bugs item #3612046, was opened at 2013-04-27 15:55
Message generated for change (Comment added) made by osas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612046group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.9.x
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: tito cumpen (soulof87)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashing when excuting b2b_logic extern script
Initial Comment:
Opensips is crashing 1 execute a fifo command like so opensipsctl fifo
b2b_trigger_scenario 3pcc sip:nurse@ip sip:patient@ip. Attached is the
scenario file. The Ip addresses have replaced with IP. i am using the latest
1.9 stable release acquired via svn
Heres the entire backtrace
(gdb) bt full
#0 get_local_contact (sock=0x0, contact=0x7fff1c16eb98) at
../presence/utils_func.h:84
buf = '\000' repeats 1023 times
proto = value optimized out
proto_len = value optimized out
#1 0x7fbbeabb3d21 in process_bridge_action (msg=0x0, curr_entity=value
optimized out, tuple=0x7fbbe8e31b30, bridge_node=0x954830) at logic.c:2501
from_uri = {s = 0x7fbbe8e3d267 sip:patient@ip, len = 26}
to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24}
from_dname = value optimized out
bridge_entities = {0x7fbbe8e3d0e8, 0x7fbbe8e3d1c0, 0x0}
entity = value optimized out
old_entity = value optimized out
e = value optimized out
count = value optimized out
index = value optimized out
attr = {s = 0x0, len = 7}
entity_dest = {s = 0x7fbbe8e3d080 sip:patient@ip, len = 26}
clientid_node = value optimized out
dest_node = value optimized out
client_node = value optimized out
lft_node = value optimized out
node = value optimized out
provmedia_uri = {s = 0x0, len = 0}
ci = {method = {s = 0x7fbbeabced40 INVITE, len = 6}, from_uri = {s =
0x7fbbe8e3d267 sip:patient@ip, len = 26}, from_dname = {s = 0x0,
len = 0}, req_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len =
0}, to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24},
to_dname = {s = 0x0, len = 0}, extra_headers = 0x0, body = 0x0,
from_tag = 0x0, local_contact = {s = 0x7fbbeadd6880 , len = 0}, cseq = 0,
send_sock = 0x0}
client_id = value optimized out
fdname_content = 0x0
from_dname = {s = 0x0, len = 0}
value_node = value optimized out
value_content = value optimized out
req_data = {et = 8287936, b2b_key = 0x943fb0, method = 0x7fbbee525860,
extra_headers = 0x7fbbee1fec1a, body = 0x7fbbedfa2960, dlginfo = 0x4240b0,
no_cb = 40}
__FUNCTION__ = process_bridge_action
#2 0x7fbbeaba4d53 in b2bl_bridge_extern (scenario_name=value optimized
out, args=value optimized out, cbf=0, cb_param=0x0) at b2b_logic.c:1067
scenario_struct = 0x7fbbedfa2960
hash_index = 935
tuple = 0x7fbbe8e31b30
b2bl_key = value optimized out
state = value optimized out
xml_node = value optimized out
attr = value optimized out
__FUNCTION__ = b2bl_bridge_extern
#3 0x7fbbeaba530d in mi_trigger_scenario (cmd=value optimized out,
param=value optimized out) at b2b_logic.c:1114
node = value optimized out
args = {0x7fbbedfae6a0, 0x7fbbedfae700, 0x0, 0x0, 0x0}
i = value optimized out
scenario_name = {s = 0x7fbbedfaf138 3pccsip:nurse@IPsip:patient@IP\n,
len = 4}
__FUNCTION__ = mi_trigger_scenario
#4 0x7fbbed0ef3c5 in run_mi_cmd (fifo_stream=0x949950) at ../../mi/mi.h:109
ret = value optimized out
#5 mi_fifo_server (fifo_stream=0x949950) at fifo_fnc.c:490
mi_cmd = value optimized out
mi_rpl = value optimized out
hdl = 0x0
---Type return to continue, or q return to quit---
line_len = 45
file_sep = value optimized out
command = value optimized out
file = value optimized out
f = 0x7fbbedface90
reply_stream = 0x943d70
__FUNCTION__ = mi_fifo_server
#6 0x7fbbed0f1977 in fifo_process (rank=value optimized out) at
mi_fifo.c:213
fifo_stream = 0x949950
__FUNCTION__ = fifo_process
#7 0x004a17ec in start_module_procs () at sr_module.c:585
m = value optimized out
n = value optimized out
l = value optimized out
x = value optimized out
__FUNCTION__ = start_module_procs
#8 0x00432ec1 in main_loop (argc=value optimized out, argv=value
optimized out) at main.c:707
i = value optimized out
pid = value optimized out
si = value optimized out
startup_done = 0x0
chd_rank = 0
rc = value optimized out
load_p = 0x0
#9 main
[OpenSIPS-Devel] [ opensips-Bugs-3612192 ] db_mysql: Commands out of sync
Bugs item #3612192, was opened at 2013-04-29 06:52 Message generated for change (Tracker Item Submitted) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612192group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql: Commands out of sync Initial Comment: Opensips started to throw out this errors: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014) ERROR:usrloc:db_update_ucontact: updating database failed ERROR:usrloc:update_ucontact: failed to update database It is only one single process that is constantly throwing out this error. All other process are able to use the db. There was another process that had a similar issue, but it cleared out. That process had a different error: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014) ERROR:auth_db:get_ha1: failed to query database It seems that on a query, the system is able to recover, but on an insert, the system fails to recover, This is on latest 1.9 svn: svnrevision: 2:9980M Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612192group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612192 ] db_mysql: Commands out of sync
Bugs item #3612192, was opened at 2013-04-29 06:52 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612192group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ovidiu Sas (osas) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql: Commands out of sync Initial Comment: Opensips started to throw out this errors: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014) ERROR:usrloc:db_update_ucontact: updating database failed ERROR:usrloc:update_ucontact: failed to update database It is only one single process that is constantly throwing out this error. All other process are able to use the db. There was another process that had a similar issue, but it cleared out. That process had a different error: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_store_result() failed: Commands out of sync; you can't run this command now (2014) ERROR:auth_db:get_ha1: failed to query database It seems that on a query, the system is able to recover, but on an insert, the system fails to recover, This is on latest 1.9 svn: svnrevision: 2:9980M Regards, Ovidiu Sas -- Comment By: Ovidiu Sas (osas) Date: 2013-04-29 07:44 Message: Here are some updates: After aprox 6h1/2, the process with issues recovered while processing a request different then REGISTER: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x2ae4584ea8c0 INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0x2ae458566b98) 0x2ae4584ea8c0 INFO:db_mysql:connect_with_retry: re-connected successful for 0x2ae4584ea8c0 Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612192group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3612046 ] opensips crashing when excuting b2b_logic extern script
Bugs item #3612046, was opened at 2013-04-27 15:55
Message generated for change (Tracker Item Submitted) made by soulof87
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3612046group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tito cumpen (soulof87)
Assigned to: Nobody/Anonymous (nobody)
Summary: opensips crashing when excuting b2b_logic extern script
Initial Comment:
Opensips is crashing 1 execute a fifo command like so opensipsctl fifo
b2b_trigger_scenario 3pcc sip:nurse@ip sip:patient@ip. Attached is the
scenario file. The Ip addresses have replaced with IP. i am using the latest
1.9 stable release acquired via svn
Heres the entire backtrace
(gdb) bt full
#0 get_local_contact (sock=0x0, contact=0x7fff1c16eb98) at
../presence/utils_func.h:84
buf = '\000' repeats 1023 times
proto = value optimized out
proto_len = value optimized out
#1 0x7fbbeabb3d21 in process_bridge_action (msg=0x0, curr_entity=value
optimized out, tuple=0x7fbbe8e31b30, bridge_node=0x954830) at logic.c:2501
from_uri = {s = 0x7fbbe8e3d267 sip:patient@ip, len = 26}
to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24}
from_dname = value optimized out
bridge_entities = {0x7fbbe8e3d0e8, 0x7fbbe8e3d1c0, 0x0}
entity = value optimized out
old_entity = value optimized out
e = value optimized out
count = value optimized out
index = value optimized out
attr = {s = 0x0, len = 7}
entity_dest = {s = 0x7fbbe8e3d080 sip:patient@ip, len = 26}
clientid_node = value optimized out
dest_node = value optimized out
client_node = value optimized out
lft_node = value optimized out
node = value optimized out
provmedia_uri = {s = 0x0, len = 0}
ci = {method = {s = 0x7fbbeabced40 INVITE, len = 6}, from_uri = {s =
0x7fbbe8e3d267 sip:patient@ip, len = 26}, from_dname = {s = 0x0,
len = 0}, req_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len =
0}, to_uri = {s = 0x7fbbe8e3d18f sip:nurse@ip, len = 24},
to_dname = {s = 0x0, len = 0}, extra_headers = 0x0, body = 0x0,
from_tag = 0x0, local_contact = {s = 0x7fbbeadd6880 , len = 0}, cseq = 0,
send_sock = 0x0}
client_id = value optimized out
fdname_content = 0x0
from_dname = {s = 0x0, len = 0}
value_node = value optimized out
value_content = value optimized out
req_data = {et = 8287936, b2b_key = 0x943fb0, method = 0x7fbbee525860,
extra_headers = 0x7fbbee1fec1a, body = 0x7fbbedfa2960, dlginfo = 0x4240b0,
no_cb = 40}
__FUNCTION__ = process_bridge_action
#2 0x7fbbeaba4d53 in b2bl_bridge_extern (scenario_name=value optimized
out, args=value optimized out, cbf=0, cb_param=0x0) at b2b_logic.c:1067
scenario_struct = 0x7fbbedfa2960
hash_index = 935
tuple = 0x7fbbe8e31b30
b2bl_key = value optimized out
state = value optimized out
xml_node = value optimized out
attr = value optimized out
__FUNCTION__ = b2bl_bridge_extern
#3 0x7fbbeaba530d in mi_trigger_scenario (cmd=value optimized out,
param=value optimized out) at b2b_logic.c:1114
node = value optimized out
args = {0x7fbbedfae6a0, 0x7fbbedfae700, 0x0, 0x0, 0x0}
i = value optimized out
scenario_name = {s = 0x7fbbedfaf138 3pccsip:nurse@IPsip:patient@IP\n,
len = 4}
__FUNCTION__ = mi_trigger_scenario
#4 0x7fbbed0ef3c5 in run_mi_cmd (fifo_stream=0x949950) at ../../mi/mi.h:109
ret = value optimized out
#5 mi_fifo_server (fifo_stream=0x949950) at fifo_fnc.c:490
mi_cmd = value optimized out
mi_rpl = value optimized out
hdl = 0x0
---Type return to continue, or q return to quit---
line_len = 45
file_sep = value optimized out
command = value optimized out
file = value optimized out
f = 0x7fbbedface90
reply_stream = 0x943d70
__FUNCTION__ = mi_fifo_server
#6 0x7fbbed0f1977 in fifo_process (rank=value optimized out) at
mi_fifo.c:213
fifo_stream = 0x949950
__FUNCTION__ = fifo_process
#7 0x004a17ec in start_module_procs () at sr_module.c:585
m = value optimized out
n = value optimized out
l = value optimized out
x = value optimized out
__FUNCTION__ = start_module_procs
#8 0x00432ec1 in main_loop (argc=value optimized out, argv=value
optimized out) at main.c:707
i = value optimized out
pid = value optimized out
si = value optimized out
startup_done = 0x0
chd_rank = 0
rc = value optimized out
load_p = 0x0
#9
[OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: failed to accept: rejected by client
Bugs item #3581600, was opened at 2012-10-29 04:56 Message generated for change (Comment added) made by chris-secusmart You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3581600group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dragos Oancea (dragosoancea) Assigned to: Nobody/Anonymous (nobody) Summary: TLS: failed to accept: rejected by client Initial Comment: Hi There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months. Sometimes I get a lot of messages like this in the logs: ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake. But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again. Regards, Dragos PS: Vlad, thx for fixing bug #3570495. It does not crash anymore. -- Comment By: Christian Lahme (chris-secusmart) Date: 2013-04-26 02:16 Message: Okay, lets get back to the Bug again. We have got a fix from Bogdan, which stops the crashes. But now there is another behavior. The client doesn't send a TCP FIN to release the connection. Therefor the server awaits with his worker thread another handshake and doesn't close the connection or freeing up the working thread. That means in fact, that an attacker may send a few TCP SYN-Flood attacks to the server, not finishing the connection, and the server will wait for further action till TCP-Timeout. If your connecting clients are behind a NAT-Firewall, you'll need idleing TCP/TLS connections with long TCP timeouts. The server will need to close this connection after a client rejected message. And he will need to free his working thread. -- Comment By: saghul (saghul) Date: 2012-11-08 06:15 Message: Hi Dragos, FWIW, we have also seen this when running the sip2sip.info service and had to turn it off because even if it doesn't crash, if a single client sends bogus data the proxy just stops working (on TLS) as you described. -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-11-08 05:53 Message: anyone else experiencing this bad DoS ? I only have TLS phones, and some of them are under development, so a single TLS phone that goes crazy and cannot perform the SSL handshake for some reason can put down the whole SIP proxy. -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-11-06 08:48 Message: some info from /proc (not sure if it helps) : http://pastebin.com/KULvTY8x -- Comment By: Dragos Oancea (dragosoancea) Date: 2012-11-06 06:21 Message: Hi Some more info: After opening 10 ssl connections and sending junk instead of an SSL handshake, things start to go wrong. A legitimate TLS client (already REGISTERed) would try to send an INVITE. This is what opensips shows in the logs instead of just relay-ing the INVITE : Nov 6 15:05:10 [25062] DBG:core:send2child: to tcp child 0 0(25030), 0x7f39127846c0 Nov 6 15:05:10 [25030] DBG:core:handle_io: received n=8 con=0x7f39127846c0, fd=27 Nov 6 15:05:10 [25030] DBG:core:io_watch_add: io_watch_add(0x74a0a0, 27, 2, 0x7f39127846c0), fd_no=1 Nov 6 15:05:10 [25030] DBG:core:tls_update_fd: New fd is 27 Nov 6 15:05:10 [25030] ERROR:core:_tls_read: TLS connection to 80.187.x.x:39337 read failed Nov 6 15:05:10 [25030] ERROR:core:_tls_read: TLS read error: 1 Nov 6 15:05:10 [25030] ERROR:core:tls_print_errstack: TLS errstack: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Nov 6 15:05:10 [25030] ERROR:core:tcp_read_req: failed to read Nov 6 15:05:10 [25030] DBG:core:io_watch_del: io_watch_del (0x74a0a0, 27, -1, 0x10) fd_no=2 called Nov 6 15:05:10 [25030] DBG:core:release_tcpconn: releasing con 0x7f39127846c0, state -2, fd=27, id=1343 Nov 6 15:05:10 [25030] DBG:core:release_tcpconn: extra_data 0x7f39127f0010 Nov 6 15:05:10 [25062] DBG:core:handle_tcp_child: reader response= 7f39127846c0, -2 from 0 Nov 6 15:05:10 [25062] DBG:core:tcpconn_destroy: destroying connection 0x7f39127846c0, flags 0002 Nov 6 15:05:10 [25062] DBG:core:tls_close: closing TLS connection Nov 6 15:05:10 [25062] DBG:core:tls_update_fd: New fd is 83 Nov 6 15:05:10
[OpenSIPS-Devel] [ opensips-Bugs-3611850 ] Segfault on shutdown in db_mysql
Bugs item #3611850, was opened at 2013-04-25 10:46 Message generated for change (Tracker Item Submitted) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault on shutdown in db_mysql Initial Comment: I am seeing a segfault on shutdown in the db_mysql module. My guess is that is is related to a flush to db on shutdown somewhere, we are using bulk inserts so that may be related. Kernel message: opensips[18804]: segfault at 0 ip 7fa545fb0089 sp 7fff45002280 error 6 in db_mysql.so[7fa545fa3000+11000] Going off the kernel message and an objdump of db_mysql.so, seems to be in the db_mysql_val2bind() function. I am working on getting a full core + back trace. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3611850 ] Segfault on shutdown in db_mysql
Bugs item #3611850, was opened at 2013-04-25 10:46 Message generated for change (Settings changed) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault on shutdown in db_mysql Initial Comment: I am seeing a segfault on shutdown in the db_mysql module. My guess is that is is related to a flush to db on shutdown somewhere, we are using bulk inserts so that may be related. Kernel message: opensips[18804]: segfault at 0 ip 7fa545fb0089 sp 7fff45002280 error 6 in db_mysql.so[7fa545fa3000+11000] Going off the kernel message and an objdump of db_mysql.so, seems to be in the db_mysql_val2bind() function. I am working on getting a full core + back trace. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611850group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3611852 ] General protection in dialog module
Bugs item #3611852, was opened at 2013-04-25 10:55 Message generated for change (Tracker Item Submitted) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611852group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Nobody/Anonymous (nobody) Summary: General protection in dialog module Initial Comment: I have seen this across a few systems, seems like a bad pointer. Kernel Message opensips[18810] general protection ip:7fa541fdcc2d sp:7fff44fff870 error:0 in dialog.so[7fa541faf000+55000] Based on the kernel message and an objdump of dialog.so it seems this is in the get_dlg_by_val() function. Working on a core dump + full bt. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611852group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI - Missing CDR
Bugs item #3610750, was opened at 2013-04-13 06:51 Message generated for change (Comment added) made by razvancrainea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610750group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: ACC + CDR + EVI - Missing CDR Initial Comment: Hello, I have my ACC mod config as follows: modparam(acc, early_media, 0) #modparam(acc, report_ack, 1) modparam(acc, report_cancels, 1) modparam(acc, detect_direction, 0) /* account triggers (flags) */ modparam(acc, failed_transaction_flag, 3) #modparam(acc, log_flag, 1) #modparam(acc, log_missed_flag, 2) /* uncomment the following lines to enable DB accounting also */ modparam(acc, db_flag, 1) modparam(acc, db_missed_flag, 2) modparam(acc, db_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, db_extra_bye, release_reason=$DLG_dir) modparam(acc, cdr_flag, 1) modparam(acc, evi_flag, 1) modparam(acc, evi_missed_flag, 1) modparam(acc, evi_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, evi_extra_bye, release_reason=$DLG_dir) Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again. I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc. Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-23 02:18 Message: Hi, Jonathan! According to my tests, the previous bug has been fixed. Can you confirm if you still have this issue? Best regards, Răzvan -- Comment By: Digipigeon (digipigeon) Date: 2013-04-16 06:02 Message: Hello Răzvan All the evi_ flags when commented out made it work, when the evi_ flags were present it failed. The behaviour that I am expecting and current experience is a line in the acc table (mysql), containing the duration of the call (amongst all the other data in that tuple). (CDR Accounting) I understand that this only happens for DB backend, however if evi_ mod params exist then the db does not log this correctly. Kind Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-15 00:31 Message: Hi, Jonathan! Can you tell me what are the flags you were removing in order to make it work? Also, what is the behavior you are expecting? Old accounting (INVITE + BYE) or CDR accounting (INVITE with duration)? This only happens for DB backend? Best regards, Răzvan
[OpenSIPS-Devel] [ opensips-Bugs-3611677 ] Offiline RTP Proxy causes system freeze
Bugs item #3611677, was opened at 2013-04-23 14:10 Message generated for change (Tracker Item Submitted) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611677group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Nobody/Anonymous (nobody) Summary: Offiline RTP Proxy causes system freeze Initial Comment: I have a setup running multiple RTP Proxy instances, when multiple rtp proxies fail, CPU utilisation approaches 100%, this does not usually happen with 1 or 2 failures, but when 4+ fail (this can even be 4 instances on an 8 core/instance machine), the issues arrise. The severity of this event happening has caused the system to stop responding for short periods, observations notice intermittent periods of no logging information and substantial packet drops (due to high CPU usage). Once RTP Proxy instances that have failed come back online, CPU utilisation drops right down and everything functions as expected. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611677group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3611397 ] CACHEDB_COUCHBASE - Error reporting and reconnects
Patches item #3611397, was opened at 2013-04-19 12:31 Message generated for change (Comment added) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3611397group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Vladut-Stefan Paiu (vladut-paiu) Summary: CACHEDB_COUCHBASE - Error reporting and reconnects Initial Comment: This patch updates the CACHEDB_COUCHBASE module. It adds better error reporting and handling as well as automatic reconnects for certain error codes. Errors: Removed calls to lcb_get_last_error. Since we have callbacks set this is unnecessary and we can go off the last_error variable. Moved error log messages to the callback only, to reduce noise in the logs. (Perhaps debug messages would be appropriate in the get, set, remove, and arithmetic methods?) Return codes: For both the get and remove methods I have made changes so that Non-existent keys return -1 and all other failures return -2. Since couchbase can be used as a primary data-store it is very important to distinguish between no data and other failures at the script level, as the data may not be available elsewhere. This involved a change to the cachedb_fetch(), cachedb_counter_fetch(), and cachedb_remove() methods in cachedb.c to pass through the return code of the underlying drivers method. Compatibility with the other cachedb_* modules should be verified. Reconnects: The libcouchbase library does a pretty good job of handling reconnects itself, there are however a few scenarios where it will get into a state where it will not reconnect. When one of these errors are detected we created a new handle and destroy the old one. This list of errors may need review. Because of this we also support starting opensips without successfully connecting to couchbase, and are able to connect to it later once the service becomes available. We will still fail to start on certain connection errors that are deemed fatal. Again this list of errors may need review. Documentation: I updated the documentation to include an example of multiple hosts in the connection string. I have tested the following works: modparam(cachedb_couchbase, cachedb_url,couchbase:test://192.168.122.192;192.168.122.77/somebucket) If 192.168.122.192 is not available it will still connect to the cluster via 192.168.122.77. I wrote this patch against 1.9, but I think it should apply against trunk just fine. It would be nice if this could be applied to 1.9 as well, however the changes for return codes may pose an issue there. Happy to answer any questions! -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-22 03:32 Message: Hi Ryan, Thanks for the patch. I have committed the cachedb_couchbase part of it on trunk and 1.9 as well . I've left out the propagation of the return code to script, since that could have broken some other cachedb_* modules. I'll go through each of the modules that use the interface, and make sure all modules respect the return codes convention. Thanks again for the patch. Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3611397group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-3602824 ] multi-server support for couchbase
Feature Requests item #3602824, was opened at 2013-01-31 08:34 Message generated for change (Comment added) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3602824group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Priority: 5 Private: No Submitted By: Kneeo (kneeo) Assigned to: Nobody/Anonymous (nobody) Summary: multi-server support for couchbase Initial Comment: I'd like to request that multi-server entry point support for couchbase clusters be added to the library. One should be able to define an array of servers per bucket so that if one server goes down opensips will connect to the next server in the array and so on. This will allow opensips to automatically failover and discover the cb cluster if a server goes down. lib C man page for couchbase explains how this works: https://github.com/couchbase/libcouchbase/blob/master/man/man3couchbase/lcb_create.3couchbase.txt#L53 -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-22 03:39 Message: Hello, The CouchBase driver now supports multiple servers. See [1] for the doc on the cachedb_url param. Basicaly, you can put multiple HOST:PORT combos sepparated by ';'. Credits to Ryan Bullock. [1] http://www.opensips.org/html/docs/modules/devel/cachedb_couchbase#id249096 Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3602824group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-3602824 ] multi-server support for couchbase
Feature Requests item #3602824, was opened at 2013-01-31 08:34 Message generated for change (Settings changed) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3602824group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Closed Priority: 5 Private: No Submitted By: Kneeo (kneeo) Assigned to: Nobody/Anonymous (nobody) Summary: multi-server support for couchbase Initial Comment: I'd like to request that multi-server entry point support for couchbase clusters be added to the library. One should be able to define an array of servers per bucket so that if one server goes down opensips will connect to the next server in the array and so on. This will allow opensips to automatically failover and discover the cb cluster if a server goes down. lib C man page for couchbase explains how this works: https://github.com/couchbase/libcouchbase/blob/master/man/man3couchbase/lcb_create.3couchbase.txt#L53 -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-22 03:39 Message: Hello, The CouchBase driver now supports multiple servers. See [1] for the doc on the cachedb_url param. Basicaly, you can put multiple HOST:PORT combos sepparated by ';'. Credits to Ryan Bullock. [1] http://www.opensips.org/html/docs/modules/devel/cachedb_couchbase#id249096 Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3602824group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3601037 ] MI_HTTP
Bugs item #3601037, was opened at 2013-01-15 15:02 Message generated for change (Settings changed) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3601037group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Ovidiu Sas (osas) Summary: MI_HTTP Initial Comment: There appears to be an issue where the http connection hangs, I have experienced the problem on the latest revision, 9561. I believe that this change is reacently introduced as the previous version which was working fine was when ticket 3590411 was closed on 2012-11-27. -- Comment By: Digipigeon (digipigeon) Date: 2013-04-20 14:42 Message: Hello ovidiu, I have just revisited this, I moved from http since experiencing these issues. I have just re-enabled and there does not appear to be a problem any more. Thanks for your time. Kind Regards Jonathan -- Comment By: Ovidiu Sas (osas) Date: 2013-04-19 20:45 Message: Any updates on this one? -- Comment By: Ovidiu Sas (osas) Date: 2013-01-15 16:47 Message: Hello Jonathan, The fix for the memory leak is this one: http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/mi_http/http_fnc.c?r1=9459r2=9458pathrev=9459 And this is the only one that was applied. You could reverse the fix and test the latest revision without the fix. Do you see any errors in the logs? When this is happening, does opensips recovers itself from it? How do you detect this hung? When the hung happens, it happens for all scripts (you mentioned that there are several scripts pooling the profiles)? How often (per script) do you pull the profile values? -ovidiu -- Comment By: Digipigeon (digipigeon) Date: 2013-01-15 16:35 Message: Hello Ovidiu, When the fix was applied to ticket 3590411 - Everything was working at this point, at some point after this there must have been an error introduced. Connections would have been less than 10 at this point in time. Command used: profile_get_values It was connected via script that has been stable and is still stable on non-upgraded versions, this runs through a curl type connection from php. We probably process 10,000 requests per node per day. Regards Jonathan -- Comment By: Ovidiu Sas (osas) Date: 2013-01-15 16:23 Message: The fix for 3590411 could not introduce an http connection hang. Please provide more details about the hang: - which mi commands did you use? - how many simultaneous connections do you have? - do you connect via a browser or do you have a script that connects to opensips? - how often do you run mi commands over mi_http interface? Thanks, Ovidiu -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3601037group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by razvancrainea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-19 02:09 Message: Hi, Jonathan! Have you managed to test this? I will mark this as fixed and come back to it if you encounter any problems. Best regards, Răzvan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-16 09:26 Message: Hi, Jonathan! Thanks to Brett, I was able to see how this bug behaves in a real environment. I have attached a new patch that was taken from a fresh 1.9 checkout. It includes both some new changes to the event_rabbitmq modules and the previous ones. Please apply this one and let me know if works with it. Best regards, Răzvan -- Comment By: brettnem () Date: 2013-04-15 10:50 Message: I'm having this exact same bug with the attached patch. Crash happens when I load the box up to 300cps. Rabbit called with raise_event in an event route. Low cps doesn't seem to hit, or maybe I'm just not letting it run fast enough. -- Comment By: Digipigeon (digipigeon) Date: 2013-04-09 13:16 Message: Hello, Unfortunately this did not solve the issue, it crashed again: last informative log line: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting BT FULL: (gdb) bt full #0 0x7f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7f76aaf1a990, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7f77025b7597 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7f7708dc7850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-18 07:31 Message: Kiss, Following our chat on IRC, see the new patch (Final fix with change in limit) that hopefully solve all the issues. Regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-17 10:26 Message: Kiss, indeed, the update logic was not fully correct - I tried a simpler approach (which should work) - the version 2 patch is here, against SVN (so remove any prev patch). Please have it tested and let me know what's the result :) Thanks and regards, Bogdan -- Comment By: Kiss Karoly (kisskaroly) Date: 2013-04-16 05:41 Message: With this patch, the original problem is solved, however still not working as expected. The problem is, that when max allowed regs is 2 and there are two contacts registered, at the first refresh by one of the contacts, the other contact is deleted. I would expect it not to delete any contacts, when I allow 2 and have 2. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-15 09:39 Message: Hi Kiss, Attached is a patch that should solve the problem - at least it solved it in my tests :). Please apply it and give it a try - ignore the really verbose debug messages :D. Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:46 Message: Hi Kiss, I managed to reproduce the scenario - I'm working on a fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3611397 ] CACHEDB_COUCHBASE - Error reporting and reconnects
Patches item #3611397, was opened at 2013-04-19 12:31 Message generated for change (Tracker Item Submitted) made by rrb3942 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3611397group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Nobody/Anonymous (nobody) Summary: CACHEDB_COUCHBASE - Error reporting and reconnects Initial Comment: This patch updates the CACHEDB_COUCHBASE module. It adds better error reporting and handling as well as automatic reconnects for certain error codes. Errors: Removed calls to lcb_get_last_error. Since we have callbacks set this is unnecessary and we can go off the last_error variable. Moved error log messages to the callback only, to reduce noise in the logs. (Perhaps debug messages would be appropriate in the get, set, remove, and arithmetic methods?) Return codes: For both the get and remove methods I have made changes so that Non-existent keys return -1 and all other failures return -2. Since couchbase can be used as a primary data-store it is very important to distinguish between no data and other failures at the script level, as the data may not be available elsewhere. This involved a change to the cachedb_fetch(), cachedb_counter_fetch(), and cachedb_remove() methods in cachedb.c to pass through the return code of the underlying drivers method. Compatibility with the other cachedb_* modules should be verified. Reconnects: The libcouchbase library does a pretty good job of handling reconnects itself, there are however a few scenarios where it will get into a state where it will not reconnect. When one of these errors are detected we created a new handle and destroy the old one. This list of errors may need review. Because of this we also support starting opensips without successfully connecting to couchbase, and are able to connect to it later once the service becomes available. We will still fail to start on certain connection errors that are deemed fatal. Again this list of errors may need review. Documentation: I updated the documentation to include an example of multiple hosts in the connection string. I have tested the following works: modparam(cachedb_couchbase, cachedb_url,couchbase:test://192.168.122.192;192.168.122.77/somebucket) If 192.168.122.192 is not available it will still connect to the cluster via 192.168.122.77. I wrote this patch against 1.9, but I think it should apply against trunk just fine. It would be nice if this could be applied to 1.9 as well, however the changes for return codes may pose an issue there. Happy to answer any questions! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3611397group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3601037 ] MI_HTTP
Bugs item #3601037, was opened at 2013-01-15 15:02 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3601037group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Ovidiu Sas (osas) Summary: MI_HTTP Initial Comment: There appears to be an issue where the http connection hangs, I have experienced the problem on the latest revision, 9561. I believe that this change is reacently introduced as the previous version which was working fine was when ticket 3590411 was closed on 2012-11-27. -- Comment By: Ovidiu Sas (osas) Date: 2013-04-19 20:45 Message: Any updates on this one? -- Comment By: Ovidiu Sas (osas) Date: 2013-01-15 16:47 Message: Hello Jonathan, The fix for the memory leak is this one: http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.8/modules/mi_http/http_fnc.c?r1=9459r2=9458pathrev=9459 And this is the only one that was applied. You could reverse the fix and test the latest revision without the fix. Do you see any errors in the logs? When this is happening, does opensips recovers itself from it? How do you detect this hung? When the hung happens, it happens for all scripts (you mentioned that there are several scripts pooling the profiles)? How often (per script) do you pull the profile values? -ovidiu -- Comment By: Digipigeon (digipigeon) Date: 2013-01-15 16:35 Message: Hello Ovidiu, When the fix was applied to ticket 3590411 - Everything was working at this point, at some point after this there must have been an error introduced. Connections would have been less than 10 at this point in time. Command used: profile_get_values It was connected via script that has been stable and is still stable on non-upgraded versions, this runs through a curl type connection from php. We probably process 10,000 requests per node per day. Regards Jonathan -- Comment By: Ovidiu Sas (osas) Date: 2013-01-15 16:23 Message: The fix for 3590411 could not introduce an http connection hang. Please provide more details about the hang: - which mi commands did you use? - how many simultaneous connections do you have? - do you connect via a browser or do you have a script that connects to opensips? - how often do you run mi commands over mi_http interface? Thanks, Ovidiu -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3601037group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-18 07:31 Message: Kiss, Following our chat on IRC, see the new patch (Final fix with change in limit) that hopefully solve all the issues. Regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-17 10:26 Message: Kiss, indeed, the update logic was not fully correct - I tried a simpler approach (which should work) - the version 2 patch is here, against SVN (so remove any prev patch). Please have it tested and let me know what's the result :) Thanks and regards, Bogdan -- Comment By: Kiss Karoly (kisskaroly) Date: 2013-04-16 05:41 Message: With this patch, the original problem is solved, however still not working as expected. The problem is, that when max allowed regs is 2 and there are two contacts registered, at the first refresh by one of the contacts, the other contact is deleted. I would expect it not to delete any contacts, when I allow 2 and have 2. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-15 09:39 Message: Hi Kiss, Attached is a patch that should solve the problem - at least it solved it in my tests :). Please apply it and give it a try - ignore the really verbose debug messages :D. Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:46 Message: Hi Kiss, I managed to reproduce the scenario - I'm working on a fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3611297 ] B2BUA bridging in prepaid demo doesn't work.
Bugs item #3611297, was opened at 2013-04-18 12:21 Message generated for change (Tracker Item Submitted) made by rumb80 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611297group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Renat (rumb80) Assigned to: Nobody/Anonymous (nobody) Summary: B2BUA bridging in prepaid demo doesn't work. Initial Comment: B2BUA bridging in prepaid demo doesn't work in 1.9, but work as expected in 1.8.2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3611297group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-3611300 ] Get b2bl_key_avp working again in b2b_logic
Feature Requests item #3611300, was opened at 2013-04-18 13:09 Message generated for change (Tracker Item Submitted) made by rumb80 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3611300group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Renat (rumb80) Assigned to: Nobody/Anonymous (nobody) Summary: Get b2bl_key_avp working again in b2b_logic Initial Comment: Hi guys, i really need b2bl_key_avp working in 1.8.2 or 1.9 to implement some weird scenario with B2BUA. Any suggestions how to get it back? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3611300group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-17 10:26 Message: Kiss, indeed, the update logic was not fully correct - I tried a simpler approach (which should work) - the version 2 patch is here, against SVN (so remove any prev patch). Please have it tested and let me know what's the result :) Thanks and regards, Bogdan -- Comment By: Kiss Karoly (kisskaroly) Date: 2013-04-16 05:41 Message: With this patch, the original problem is solved, however still not working as expected. The problem is, that when max allowed regs is 2 and there are two contacts registered, at the first refresh by one of the contacts, the other contact is deleted. I would expect it not to delete any contacts, when I allow 2 and have 2. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-15 09:39 Message: Hi Kiss, Attached is a patch that should solve the problem - at least it solved it in my tests :). Please apply it and give it a try - ignore the really verbose debug messages :D. Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:46 Message: Hi Kiss, I managed to reproduce the scenario - I'm working on a fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3607052 ] Load balancer - corrupt data when loading table
Bugs item #3607052, was opened at 2013-03-06 07:08 Message generated for change (Comment added) made by umautone You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3607052group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Umberto Mautone (umautone) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Load balancer - corrupt data when loading table Initial Comment: Tested on 1.9.x Data table: id | group_id | dst_uri | resources | probe_mode +--+---+---+ 19 |1 | sip:192.168.1.5 | pstn=100 | 0 20 |1 | sip:192.168.1.8 | pstn=100 | 0 21 |2 | sip:192.168.1.100 | pstn=2500 | 0 I added this line in lb_db_load_data() to log the actual table fields being loaded: LM_ERR(Fields: %d %d %s %s\n, id, group, uri, resource); The first row loads correctly but subsequent rows seem to lose a pointer alignment somewhere: Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 19 1 sip:192.168.1.5 pstn=100 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 20 1 sip:192.168.1.8 ¥Ý9w#177 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value! Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string ¥Ý9w#177 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 - skipping Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 21 2 sip:192.168.1.100 192.168.1.5 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value! Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string 192.168.1.5 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 - skipping Also tested in 1.8.2 and the problem is not present. The bug seems to be only in the 1.9.x branch. -- Comment By: Umberto Mautone (umautone) Date: 2013-04-17 11:25 Message: This bug as tested is happening on CentOS 6.x and Ubuntu 12.xx. The only common component between the two is PostgreSQL. -- Comment By: Umberto Mautone (umautone) Date: 2013-04-05 14:04 Message: Sorry for taking so long. This is using PostgreSQL 9.2 with unixODBC on a 64 bit box. Here is the output with debug=4 on startup: === Apr 5 16:57:24 localhost opensips: WARNING:core:warn: warning in config file /usr//etc/opensips/opensips.cfg, line 44, column 13-16: tls support not compiled in Apr 5 16:57:24 localhost opensips: INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Apr 5 16:57:24 localhost opensips[13284]: NOTICE:core:main: version: opensips 1.9.0-notls (x86_64/linux) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:main: using 32 Mb shared memory Apr 5 16:57:24 localhost opensips[13284]: INFO:core:main: using 2 Mb private memory per process Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_THRESHOLD(0) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_SHM_THRESHOLD(1) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_PKG_THRESHOLD(2) Apr 5 16:57:24 localhost opensips[13284]: NOTICE:signaling:mod_init: initializing module ... Apr 5 16:57:24 localhost opensips[13284]: INFO:sl:mod_init: Initializing StateLess engine Apr 5 16:57:24 localhost opensips[13284]: INFO:tm:mod_init: TM - initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:rr:mod_init: rr - initializing Apr 5 16:57:24 localhost opensips[13284]: INFO:maxfwd:mod_init: initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:mod_init: initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:dialog:mod_init: Dialog module - initializing Apr 5 16:57:24 localhost opensips[13284]: INFO:load_balancer:mod_init: Load-Balancer module - initializing Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:parse_resources_list: resource must has value! Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string HÿóÇ*#177 Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:lb_db_load_data: failed to add destination 3 - skipping Apr 5 16:57:24 localhost opensips[13284]: ERROR:core:parse_uri: bad uri, state
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Comment added) made by kisskaroly You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- Comment By: Kiss Karoly (kisskaroly) Date: 2013-04-16 05:41 Message: With this patch, the original problem is solved, however still not working as expected. The problem is, that when max allowed regs is 2 and there are two contacts registered, at the first refresh by one of the contacts, the other contact is deleted. I would expect it not to delete any contacts, when I allow 2 and have 2. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-15 09:39 Message: Hi Kiss, Attached is a patch that should solve the problem - at least it solved it in my tests :). Please apply it and give it a try - ignore the really verbose debug messages :D. Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:46 Message: Hi Kiss, I managed to reproduce the scenario - I'm working on a fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI - Missing CDR
Bugs item #3610750, was opened at 2013-04-13 06:51 Message generated for change (Comment added) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610750group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: ACC + CDR + EVI - Missing CDR Initial Comment: Hello, I have my ACC mod config as follows: modparam(acc, early_media, 0) #modparam(acc, report_ack, 1) modparam(acc, report_cancels, 1) modparam(acc, detect_direction, 0) /* account triggers (flags) */ modparam(acc, failed_transaction_flag, 3) #modparam(acc, log_flag, 1) #modparam(acc, log_missed_flag, 2) /* uncomment the following lines to enable DB accounting also */ modparam(acc, db_flag, 1) modparam(acc, db_missed_flag, 2) modparam(acc, db_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, db_extra_bye, release_reason=$DLG_dir) modparam(acc, cdr_flag, 1) modparam(acc, evi_flag, 1) modparam(acc, evi_missed_flag, 1) modparam(acc, evi_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, evi_extra_bye, release_reason=$DLG_dir) Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again. I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc. Regards Jonathan -- Comment By: Digipigeon (digipigeon) Date: 2013-04-16 06:02 Message: Hello Răzvan All the evi_ flags when commented out made it work, when the evi_ flags were present it failed. The behaviour that I am expecting and current experience is a line in the acc table (mysql), containing the duration of the call (amongst all the other data in that tuple). (CDR Accounting) I understand that this only happens for DB backend, however if evi_ mod params exist then the db does not log this correctly. Kind Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-15 00:31 Message: Hi, Jonathan! Can you tell me what are the flags you were removing in order to make it work? Also, what is the behavior you are expecting? Old accounting (INVITE + BYE) or CDR accounting (INVITE with duration)? This only happens for DB backend? Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610750group_id=232389 ___ Devel mailing list Devel@lists.opensips.org
[OpenSIPS-Devel] [ opensips-Bugs-3610776 ] while loop through $branch doesn't show first branch
Bugs item #3610776, was opened at 2013-04-13 15:03
Message generated for change (Comment added) made by a719719
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610776group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: while loop through $branch doesn't show first branch
Initial Comment:
I try to xlog the URI's of all branches:
if (!lookup(location)) {
switch ($retcode) {
case -1:
case -3:
sl_send_reply(404, Not Found);
exit;
case -2:
sl_send_reply(405, Not Found);
exit;
};
};
$var(i) = 0;
while($(branch(uri)[$var(i)])!=NULL) {
xlog(- branch $var(i): $(branch(uri)[$var(i)]));
$var(i) = $var(i) + 1;
};
3 phones are registered. All receive an Invite. No problem there.
But this code prints:
OpenSips[6832]: DBG:registrar:lookup: found a complete match
OpenSips[6832]: DBG:registrar:lookup: setting as ruri
sip:testaccount@4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: DBG:registrar:lookup: looking for branches
OpenSips[6832]: DBG:registrar:lookup: setting branch
sip:testaccount@4.4.4.4:18349
OpenSips[6832]: DBG:registrar:lookup: setting branch
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
OpenSips[6832]: - branch 0: sip:testaccount@4.4.4.4:18349
OpenSips[6832]: - branch 1:
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
I would expect the output to be:
OpenSips[6832]: - branch 0:
sip:testaccount@4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: - branch 1: sip:testaccount@4.4.4.4:18349
OpenSips[6832]: - branch 2:
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
I'm not completely sure but isn't every contact a branch, so the first one
(sip:testaccount@4.4.4.4:30626;rin..) also?
I use 1.8.2 svn9916.
--
Comment By: a719719 (a719719)
Date: 2013-04-16 08:38
Message:
Ok, i understand. Thanks.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:53
Message:
Hi,
There is a misunderstanding here - the branch is an additional
destination, aside the mandatory one hold by RURI. So RURI is keeping first
destination, branch 0 the second destination, branch 1 the third
destination, a.s. o
So you should also print the RURI before the branches.
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610776group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by razvancrainea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-16 09:26 Message: Hi, Jonathan! Thanks to Brett, I was able to see how this bug behaves in a real environment. I have attached a new patch that was taken from a fresh 1.9 checkout. It includes both some new changes to the event_rabbitmq modules and the previous ones. Please apply this one and let me know if works with it. Best regards, Răzvan -- Comment By: brettnem () Date: 2013-04-15 10:50 Message: I'm having this exact same bug with the attached patch. Crash happens when I load the box up to 300cps. Rabbit called with raise_event in an event route. Low cps doesn't seem to hit, or maybe I'm just not letting it run fast enough. -- Comment By: Digipigeon (digipigeon) Date: 2013-04-09 13:16 Message: Hello, Unfortunately this did not solve the issue, it crashed again: last informative log line: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting BT FULL: (gdb) bt full #0 0x7f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7f76aaf1a990, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7f77025b7597 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7f7708dc7850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out
[OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI - Missing CDR
Bugs item #3610750, was opened at 2013-04-13 06:51 Message generated for change (Comment added) made by razvancrainea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610750group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: ACC + CDR + EVI - Missing CDR Initial Comment: Hello, I have my ACC mod config as follows: modparam(acc, early_media, 0) #modparam(acc, report_ack, 1) modparam(acc, report_cancels, 1) modparam(acc, detect_direction, 0) /* account triggers (flags) */ modparam(acc, failed_transaction_flag, 3) #modparam(acc, log_flag, 1) #modparam(acc, log_missed_flag, 2) /* uncomment the following lines to enable DB accounting also */ modparam(acc, db_flag, 1) modparam(acc, db_missed_flag, 2) modparam(acc, db_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, db_extra_bye, release_reason=$DLG_dir) modparam(acc, cdr_flag, 1) modparam(acc, evi_flag, 1) modparam(acc, evi_missed_flag, 1) modparam(acc, evi_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, evi_extra_bye, release_reason=$DLG_dir) Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again. I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc. Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-15 00:31 Message: Hi, Jonathan! Can you tell me what are the flags you were removing in order to make it work? Also, what is the behavior you are expecting? Old accounting (INVITE + BYE) or CDR accounting (INVITE with duration)? This only happens for DB backend? Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610750group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-15 09:39 Message: Hi Kiss, Attached is a patch that should solve the problem - at least it solved it in my tests :). Please apply it and give it a try - ignore the really verbose debug messages :D. Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:46 Message: Hi Kiss, I managed to reproduce the scenario - I'm working on a fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-15 09:39 Message: Hi Kiss, Attached is a patch that should solve the problem - at least it solved it in my tests :). Please apply it and give it a try - ignore the really verbose debug messages :D. Thanks and regards, Bogdan -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:46 Message: Hi Kiss, I managed to reproduce the scenario - I'm working on a fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610690 ] lookup can only be called once
Bugs item #3610690, was opened at 2013-04-12 09:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610690group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: lookup can only be called once
Initial Comment:
If you have several contacts for the same user, and if you call lookup twice,
then each request will be sent one time to the contact with the highest
priority and twice to all other contacts.
If you call it three times, then t_relay will relay the same request three
times to all contacts (except the first one).
Most probably opensips maintains an internal linked list with all branches and
that list is not reset by lookup.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:50
Message:
Hi,
This is not a bug, but rather a misusage of the lookup() function - the
function is all the time uploading the contacts for the AOR from RURI.
There is no intention (by design) to remove the existing branches -
actually I know cases where the script is relying on this behaviour.
If you call the lookup twice and you want no connection between the 2,
simply purge all existing branches before doing the second lookup :
while ( remove_branch(0) ) {xlog(removing branch);}
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610690group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610776 ] while loop through $branch doesn't show first branch
Bugs item #3610776, was opened at 2013-04-13 15:03
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610776group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: while loop through $branch doesn't show first branch
Initial Comment:
I try to xlog the URI's of all branches:
if (!lookup(location)) {
switch ($retcode) {
case -1:
case -3:
sl_send_reply(404, Not Found);
exit;
case -2:
sl_send_reply(405, Not Found);
exit;
};
};
$var(i) = 0;
while($(branch(uri)[$var(i)])!=NULL) {
xlog(- branch $var(i): $(branch(uri)[$var(i)]));
$var(i) = $var(i) + 1;
};
3 phones are registered. All receive an Invite. No problem there.
But this code prints:
OpenSips[6832]: DBG:registrar:lookup: found a complete match
OpenSips[6832]: DBG:registrar:lookup: setting as ruri
sip:testaccount@4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: DBG:registrar:lookup: looking for branches
OpenSips[6832]: DBG:registrar:lookup: setting branch
sip:testaccount@4.4.4.4:18349
OpenSips[6832]: DBG:registrar:lookup: setting branch
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
OpenSips[6832]: - branch 0: sip:testaccount@4.4.4.4:18349
OpenSips[6832]: - branch 1:
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
I would expect the output to be:
OpenSips[6832]: - branch 0:
sip:testaccount@4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: - branch 1: sip:testaccount@4.4.4.4:18349
OpenSips[6832]: - branch 2:
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
I'm not completely sure but isn't every contact a branch, so the first one
(sip:testaccount@4.4.4.4:30626;rin..) also?
I use 1.8.2 svn9916.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-15 09:53
Message:
Hi,
There is a misunderstanding here - the branch is an additional
destination, aside the mandatory one hold by RURI. So RURI is keeping first
destination, branch 0 the second destination, branch 1 the third
destination, a.s. o
So you should also print the RURI before the branches.
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610776group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: https://www.google.com/accounts () Date: 2013-04-15 10:50 Message: I'm having this exact same bug with the attached patch. Crash happens when I load the box up to 300cps. Rabbit called with raise_event in an event route. Low cps doesn't seem to hit, or maybe I'm just not letting it run fast enough. -- Comment By: Digipigeon (digipigeon) Date: 2013-04-09 13:16 Message: Hello, Unfortunately this did not solve the issue, it crashed again: last informative log line: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting BT FULL: (gdb) bt full #0 0x7f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7f76aaf1a990, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7f77025b7597 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7f7708dc7850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff64ee8f81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 129474967 rfd = -2118547680 __FUNCTION__ = main Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-09 09:07
[OpenSIPS-Devel] [ opensips-Bugs-3610750 ] ACC + CDR + EVI - Missing CDR
Bugs item #3610750, was opened at 2013-04-13 06:51 Message generated for change (Tracker Item Submitted) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610750group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Nobody/Anonymous (nobody) Summary: ACC + CDR + EVI - Missing CDR Initial Comment: Hello, I have my ACC mod config as follows: modparam(acc, early_media, 0) #modparam(acc, report_ack, 1) modparam(acc, report_cancels, 1) modparam(acc, detect_direction, 0) /* account triggers (flags) */ modparam(acc, failed_transaction_flag, 3) #modparam(acc, log_flag, 1) #modparam(acc, log_missed_flag, 2) /* uncomment the following lines to enable DB accounting also */ modparam(acc, db_flag, 1) modparam(acc, db_missed_flag, 2) modparam(acc, db_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, db_extra_bye, release_reason=$DLG_dir) modparam(acc, cdr_flag, 1) modparam(acc, evi_flag, 1) modparam(acc, evi_missed_flag, 1) modparam(acc, evi_extra, from_uri=$fu; to_uri=$avp(cdr_to_uri); username=$Au; source_ip=$avp(orig_ip); gw_id=$avp(gw_id); account_id=$avp(account_id); user_agent=$hdr(user-agent); contact=$hdr(contact); event=$hdr(event); group_id=$avp(group_id); prefix=$avp(prefix); name=$avp(destination_name); tariff_id=$avp(tariff_id); pdd_in=$avp(pdd_in); pdd_out=$avp(pdd_out); lrn_number=$avp(lrn_number) ) #Extra data modparam(acc, evi_extra_bye, release_reason=$DLG_dir) Due to issue 3610016, I have NOT at present got the rabbitmq module enabled and I am NOT subscribing to any events in the startup route, however the evi configuration was setup as above as I did not feel it necessary to remove it while 3610016 was been worked on. I only noticed later on my pilot machine that CDR was not been recorded correctly, as soon as I removed all of the flags relating to acc, evi, everything worked as normal again. I was able to see various BYE messages, but not the INVITE messages which recorded the duration, etc. Regards Jonathan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610750group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609399 ] onreply_route nat_uac_test(1) ignores RFC1918 Contact
Bugs item #3609399, was opened at 2013-03-28 16:24
Message generated for change (Comment added) made by a719719
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609399group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: onreply_route nat_uac_test(1) ignores RFC1918 Contact
Initial Comment:
I have in the onreply_route route this check:
if (nat_uac_test(1))
{
fix_nated_contact();
}
But this Contact header remains untouched:
SIP/2.0 200 OK
...
CONTACT: sip:PBX.network.local:5060;transport=Tcp;maddr=172.16.1.1
...
If i remove the nat_uac_test(1) check and just execute fix_nated_contact()
the Contact header is changed:
CONTACT: sip:1.2.3.4:5060;transport=Tcp
So i think the nat_uac_test(1) check doesn't detect the RFC1918 Contact
header. I use 1.8.2 svn9916.
--
Comment By: a719719 (a719719)
Date: 2013-04-13 11:57
Message:
I can't reproduce it myself so it will take while before i can post the
debug logging.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 09:22
Message:
Hi,
Could you attached the opensips log (in debug 4) corresponding to the reply
processing?
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609399group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610776 ] while loop through $branch doesn't show first branch
Bugs item #3610776, was opened at 2013-04-13 15:03
Message generated for change (Tracker Item Submitted) made by a719719
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610776group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Nobody/Anonymous (nobody)
Summary: while loop through $branch doesn't show first branch
Initial Comment:
I try to xlog the URI's of all branches:
if (!lookup(location)) {
switch ($retcode) {
case -1:
case -3:
sl_send_reply(404, Not Found);
exit;
case -2:
sl_send_reply(405, Not Found);
exit;
};
};
$var(i) = 0;
while($(branch(uri)[$var(i)])!=NULL) {
xlog(- branch $var(i): $(branch(uri)[$var(i)]));
$var(i) = $var(i) + 1;
};
3 phones are registered. All receive an Invite. No problem there.
But this code prints:
OpenSips[6832]: DBG:registrar:lookup: found a complete match
OpenSips[6832]: DBG:registrar:lookup: setting as ruri
sip:testaccount@4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: DBG:registrar:lookup: looking for branches
OpenSips[6832]: DBG:registrar:lookup: setting branch
sip:testaccount@4.4.4.4:18349
OpenSips[6832]: DBG:registrar:lookup: setting branch
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
OpenSips[6832]: - branch 0: sip:testaccount@4.4.4.4:18349
OpenSips[6832]: - branch 1:
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
I would expect the output to be:
OpenSips[6832]: - branch 0:
sip:testaccount@4.4.4.4:30626;rinstance=30ffadee5f56a3d2;transport=UDP
OpenSips[6832]: - branch 1: sip:testaccount@4.4.4.4:18349
OpenSips[6832]: - branch 2:
sip:testaccount@8.8.8.8:61002;rinstance=106001d34f5d2212;transport=UDP
I'm not completely sure but isn't every contact a branch, so the first one
(sip:testaccount@4.4.4.4:30626;rin..) also?
I use 1.8.2 svn9916.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610776group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Tracker Item Submitted) made by kisskaroly You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Nobody/Anonymous (nobody) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610690 ] lookup can only be called once
Bugs item #3610690, was opened at 2013-04-12 09:02 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610690group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: lookup can only be called once Initial Comment: If you have several contacts for the same user, and if you call lookup twice, then each request will be sent one time to the contact with the highest priority and twice to all other contacts. If you call it three times, then t_relay will relay the same request three times to all contacts (except the first one). Most probably opensips maintains an internal linked list with all branches and that list is not reset by lookup. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610690group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on use_next_gw/get_gw_by_id
Bugs item #3610045, was opened at 2013-04-04 15:31 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ronald Cepres (r0nald11) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id Initial Comment: Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings. I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash. I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 09:33 Message: Hi Ronald, Is there a way to reproduce this bug (like starting from a certain set of gw/carriers, etc) ? your details on the setup are not really clear for me. Do you still have the core file? could I ask you to extract more info from there ? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on use_next_gw/get_gw_by_id
Bugs item #3610045, was opened at 2013-04-04 15:31 Message generated for change (Comment added) made by r0nald11 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ronald Cepres (r0nald11) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id Initial Comment: Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings. I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash. I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz -- Comment By: Ronald Cepres (r0nald11) Date: 2013-04-12 10:00 Message: Hi Bogdan, Thanks for the reply. For the destinations during that call, we have 6 carriers setup such as: #C1,#C2,#C3,#C4,#C5,#C6. The crash happened when selecting the next gateway from C1 to C2. C1 has gateways C1G1,C1G2,C1G3,C1G4,C1G5,C1G6, where C1G3 and C1G4 are disabled via MI. C2 has only gateway C2G1. The call failed for C1G1,C1G2,C1G6,C1G5 (in order and weighted). The crash happened during the transition from C1G5 to C2G1. I still have the core file. What specific info would you like to extract? -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 09:33 Message: Hi Ronald, Is there a way to reproduce this bug (like starting from a certain set of gw/carriers, etc) ? your details on the setup are not really clear for me. Do you still have the core file? could I ask you to extract more info from there ? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610662 ] REGISTRAR save with force flag and limited contacts broken
Bugs item #3610662, was opened at 2013-04-12 01:32 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.8.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kiss Karoly (kisskaroly) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: REGISTRAR save with force flag and limited contacts broken Initial Comment: When using save in registrar module with f and cXX flags set, the number of contacts can exceed the XX value. Consider the following scenario: 3 devices registering with the same SIP account and XX above is set to 2, with f flag set. In this case we should be seeing two contacts saved, and the third should randomly overwrite one of the two contacts because of the force flag. What I see instead is that when the third device registers, one of the contacts is correctly overwritten, however when the device whos contact was overwritten, reregisters, it's contact is incorrectly added to the list of contacts, thus exceeding the limit of maximum allowed contacts. The cXX flag in my case is specified as a parameter to the save command in script. Tested with opensips 1.8.2 svn rev 9438. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:46 Message: Hi Kiss, I managed to reproduce the scenario - I'm working on a fix. Thanks and regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610662group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on use_next_gw/get_gw_by_id
Bugs item #3610045, was opened at 2013-04-04 15:31 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ronald Cepres (r0nald11) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id Initial Comment: Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings. I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash. I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 10:53 Message: Hi Ronald, So , when calling use_next_gw, the C2G1 should be next in the line. In frame 1, print *id, gw, *gw and gw-id . Also, in script (if you can reproduce it), do a print_avp(); before the use_next_gw(). Thanks and regards, Bogdan -- Comment By: Ronald Cepres (r0nald11) Date: 2013-04-12 10:00 Message: Hi Bogdan, Thanks for the reply. For the destinations during that call, we have 6 carriers setup such as: #C1,#C2,#C3,#C4,#C5,#C6. The crash happened when selecting the next gateway from C1 to C2. C1 has gateways C1G1,C1G2,C1G3,C1G4,C1G5,C1G6, where C1G3 and C1G4 are disabled via MI. C2 has only gateway C2G1. The call failed for C1G1,C1G2,C1G6,C1G5 (in order and weighted). The crash happened during the transition from C1G5 to C2G1. I still have the core file. What specific info would you like to extract? -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-12 09:33 Message: Hi Ronald, Is there a way to reproduce this bug (like starting from a certain set of gw/carriers, etc) ? your details on the setup are not really clear for me. Do you still have the core file? could I ask you to extract more info from there ? Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3606098 ] SIPMSGOPS: text reason for sip_msg_validate()
Patches item #3606098, was opened at 2013-02-26 10:25 Message generated for change (Comment added) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606098group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: SIPMSGOPS: text reason for sip_msg_validate() Initial Comment: This patch adds second parameter for sip_msg_validate with resulting pvar returning error text. -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-12 10:53 Message: Hi Nick, Combined both approaches ( left in the reason phrase, and also added different return codes for each failure reason ). Thanks for the patch. Best Regards, Vlad -- Comment By: Nick Altmann (nikbyte) Date: 2013-04-11 04:13 Message: This patch based on Bogdan's idea to make pv-variable. (Opensips mailing list, Feb 26). -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-10 10:53 Message: Hi Nick, Wouldn't it be better to extend the list of return codes for the sip_msg_validate() function to cover all the errors possible ( internal or SIP msg related ), instead of pushing this text message reason ? Guess that would be a more flexible approach, that would allow the script writer to easily check for the occurred errors. Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606098group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3607239 ] SIPMSGOPS: add stream_delete_except function
Patches item #3607239, was opened at 2013-03-07 12:28 Message generated for change (Comment added) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3607239group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Vladut-Stefan Paiu (vladut-paiu) Summary: SIPMSGOPS: add stream_delete_except function Initial Comment: Adds stream_delete_except() function to sipmsgops module. Allows for removing all streams from SDP that do not match the regex passed to the function. Example: #Permit only audio and fax streams stream_delete_except(audio|image); -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-11 03:45 Message: Hi Ryan, Thanks for the patch. Wasn't able to test yet, but doesn't seem the patch will work as expected, as it will always remove just the first occurrence, and then stop when it'll reach that stream again, because of the lmp-len == 0 condition. I'll rework the patch a little and apply it on trunk. Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3607239group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608659 ] Incorrect profile values resulting from set_dlg_profile
Bugs item #3608659, was opened at 2013-03-20 18:54 Message generated for change (Comment added) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608659group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chen-Che Huang (csmicrox) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect profile values resulting from set_dlg_profile Initial Comment: I set two dialog profiles to keep track of the numbers of ongoing dialogs served by the two RTP proxies in my environment (modparam(dialog, profiles_with_value, S1R1 ; S1R2)). I find that the number may go wrong (stays the same even when new dialogs are set to the profile) when such log messages are shown DBG:dialog:link_dlg_profile: Entered here with hash = 8. Specifically, when several new INVITE requests are processed simutaneously and have the same hash=n, the profile value will keep the same. Please help me address this problem. I'm very grateful to the help. PS. The attached file is the part of my config script associated with this issue. Many thanks and best regards, Chen-Che -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-11 03:52 Message: Hi csmicrox, Not sure if I understand your issue here. First of all, when the BYE comes in to close a call, that respective dialog will be automatically removed from all the profiles it was inserted in. Secondly, If you are testing with SIPP, after a certain amount of time, you will reach a constant number of ongoing dialogs ( for example if you have 100CPS and 30seconds call duration, after 30 seconds you will reach 3 concurrent calls, which you will maintain until the end of your SIPP test). Thus, you dialog profile's size will also reach a maximum, and stay there. Best Regards, Vlad -- Comment By: Chen-Che Huang (csmicrox) Date: 2013-03-21 23:24 Message: Let me be more clear. When the profile value keeps the same for new dialogs set to the profile, the profile value will decrease on termination of existing dialogs. However, in the next round, several new dialogs set to the profile happen to have the same hashed value and then the profile value becomes unchanged again (not increase). Kind wishes, Chen-Che -- Comment By: Chen-Che Huang (csmicrox) Date: 2013-03-21 19:54 Message: Hi Răzvan, Thanks for your reply. I am sorry that I was not being clear enough. In my test, I use SIPp to generate 100 calls/second in a round (each round: INVITE-ACK-BYE requests). When receiving each INVITE request sent from SIPp, the server calls create_dialog() and then call set_dlg_profile(). After several rounds, I find that several dialogs suddently have the same hash values (DBG:dialog:link_dlg_profile: Entered here with hash = n) and then the profile value stays the same. Afterwards, the profile value never increases (always have the same hashed value) even when new dialogs are set to the profile. This does not affect the termination of existing dialogs. Many thanks for your help. Yours sincerely, Chen-Che -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-03-21 02:26 Message: Hi, Chen-Che! When adding a dialog in a profile, it stays there as long as the dialog is active. Are you sure that during your tests, none of the previously created dialogs are ended/expired? Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608659group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3606098 ] SIPMSGOPS: text reason for sip_msg_validate()
Patches item #3606098, was opened at 2013-02-26 10:25 Message generated for change (Comment added) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606098group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: SIPMSGOPS: text reason for sip_msg_validate() Initial Comment: This patch adds second parameter for sip_msg_validate with resulting pvar returning error text. -- Comment By: Nick Altmann (nikbyte) Date: 2013-04-11 04:13 Message: This patch based on Bogdan's idea to make pv-variable. (Opensips mailing list, Feb 26). -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-10 10:53 Message: Hi Nick, Wouldn't it be better to extend the list of return codes for the sip_msg_validate() function to cover all the errors possible ( internal or SIP msg related ), instead of pushing this text message reason ? Guess that would be a more flexible approach, that would allow the script writer to easily check for the occurred errors. Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606098group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608659 ] Incorrect profile values resulting from set_dlg_profile
Bugs item #3608659, was opened at 2013-03-20 18:54 Message generated for change (Comment added) made by csmicrox You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608659group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chen-Che Huang (csmicrox) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect profile values resulting from set_dlg_profile Initial Comment: I set two dialog profiles to keep track of the numbers of ongoing dialogs served by the two RTP proxies in my environment (modparam(dialog, profiles_with_value, S1R1 ; S1R2)). I find that the number may go wrong (stays the same even when new dialogs are set to the profile) when such log messages are shown DBG:dialog:link_dlg_profile: Entered here with hash = 8. Specifically, when several new INVITE requests are processed simutaneously and have the same hash=n, the profile value will keep the same. Please help me address this problem. I'm very grateful to the help. PS. The attached file is the part of my config script associated with this issue. Many thanks and best regards, Chen-Che -- Comment By: Chen-Che Huang (csmicrox) Date: 2013-04-11 20:29 Message: Hi Vlad, Thanks for your reply. I ought to be more clear by describing one of my test results. I used SIPp to generate 100 calls in each round. That is, in each round, only 100 calls are generated and these calls have video transmissions relaying by an RTP proxy. You can think that each round is 1-minute-long and 100 INVITEs are generated at the first second of a round (minute). The SIP proxy server prints out the profile value (before calling rtpproxy_offer) when receiving an INVITE. In round 1, the output profile values associated with the RTP proxy are 0, 1, 2, 3, ..., 99, as expected. In round 2, the output profile values associated with the RTP proxy are 0, 1, 2, 3, ..., 99, as expected. . . . In round x, the output profile values associated with the RTP proxy are 0, 1, 2, 3, , 90, ..., 90. (rather than 0, 1, 2, 3, , 90, ..., 99). With log_level=9, I find the profile size suddenly stays fixed and never increases. As such, the profile values stay 90. With high CPS (more than 100), it is very easy for me to reproduce this result. If I remain not clear enough, please feel free to let me know. Thanks for your kind help. Best regards, Chen-Che -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-11 03:52 Message: Hi csmicrox, Not sure if I understand your issue here. First of all, when the BYE comes in to close a call, that respective dialog will be automatically removed from all the profiles it was inserted in. Secondly, If you are testing with SIPP, after a certain amount of time, you will reach a constant number of ongoing dialogs ( for example if you have 100CPS and 30seconds call duration, after 30 seconds you will reach 3 concurrent calls, which you will maintain until the end of your SIPP test). Thus, you dialog profile's size will also reach a maximum, and stay there. Best Regards, Vlad -- Comment By: Chen-Che Huang (csmicrox) Date: 2013-03-21 23:24 Message: Let me be more clear. When the profile value keeps the same for new dialogs set to the profile, the profile value will decrease on termination of existing dialogs. However, in the next round, several new dialogs set to the profile happen to have the same hashed value and then the profile value becomes unchanged again (not increase). Kind wishes, Chen-Che -- Comment By: Chen-Che Huang (csmicrox) Date: 2013-03-21 19:54 Message: Hi Răzvan, Thanks for your reply. I am sorry that I was not being clear enough. In my test, I use SIPp to generate 100 calls/second in a round (each round: INVITE-ACK-BYE requests). When receiving each INVITE request sent from SIPp, the server calls create_dialog() and then call set_dlg_profile(). After several rounds, I find that several dialogs suddently have the same hash values (DBG:dialog:link_dlg_profile: Entered here with hash = n) and then the profile value stays the same. Afterwards, the profile value never increases (always have the same hashed value) even when new dialogs are set to the profile. This does not affect the termination of existing dialogs. Many thanks for your help. Yours sincerely, Chen-Che -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-03-21 02:26 Message: Hi, Chen-Che! When adding a dialog in a profile, it stays
[OpenSIPS-Devel] [ opensips-Patches-3606324 ] Add {s.encode.int} transformation
Patches item #3606324, was opened at 2013-02-27 23:57
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606324group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.x
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Add {s.encode.int} transformation
Initial Comment:
This patch adds the {s.encode.int} transformation to convert a 4-byte or 8-byte
binary data into an unsigned integer. An example of this feature's use would be
to convert IP addresses directly to unsigned integers to be used as dynamic
group ID values by the load balancer or dispatcher. The patch utilizes
ntohl() on the converted value to correctly manage endian.
$var(ip) = $(Ri{ip.pton}{s.encode.int});
The patch applies to 1.9.0-tls
--
Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-10 10:39
Message:
Hello,
I understand your issue, but perhaps you can re-use some of the existing
modules for doing that.
You could, for example, use the permissions module, and store your OpenSIPS
listening IPs in the dababase, and have the appropriate load-balancing
group for each IP in the attrs field.
Then for a request, you'd just call
check_address(0,$Ri,$Rp,$proto,$avp(lb_group)) and this will
populate the attrs field ( the LB group in our case ) in the $avp(lb_group)
pvar.
This seems cleaner, without the need to have the actual LB group be some
hardcoded number that represents the ip.pton value of the actual IP, and
also has the advantage of more flexibility in the case where you would want
to differentiate between two interface with same IP but different ports (
eg: 127.0.0.1:5060 and 127.0.0.1:5070 )
For the moment, marking the current patch as invalid.
Best Regards,
Vlad
--
Comment By: Umberto Mautone (umautone)
Date: 2013-04-08 11:14
Message:
Yeah, I just noticed I had said 4-byte or 8-byte. My head was somewhere
else that day. Is there a PV_VAL_* entity to handle unsigned integers? I've
got to think about the 16 byte conversion.
The idea behind this patch is to reference the group_id field in the load
balancer table according to the receiving IP when a proxy is set up to
listen on multiple IPs without hard coding the actual IPs in the script.
For example:
$var(ip) = $(Ri{ip.pton}{s.encode.int});
...
if( !load_balance($(var(ip){s.int}),pstn, 1) ) {
..
This would reference the appropriate group of endpoints in the load
balancer table that belong to the proxy's receiving IP.
--
Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-08 10:08
Message:
Hello,
First of all, not sure I understand why you are treating either 4-byte or
8-byte binary data ? If the purpose is to use the output of ip.pton, then
that returns either 4 or 16 bytes, depending on the IP type ( v4 vs v6 ).
Am I missing something here ?
Also, is the purpose of the function to return the value as an integer (
because I see the PV_VAL_INT being set ) ? If so, it will be a little bit
funky, since for IPV4, you might end up with overflows due to the fact that
the IPv4 address is 32 bits, while the pvar structures in the OpenSIPS code
use integers, thus only 31 bits for the actual number ( 1 bit for the sign
).
The situation for IPv6 would be even worse then.
Probably we'd need to re-work this patch, or change the approach entirely
for this to work for IPv4 and IPv6 as well.
Best Regards,
Vlad
--
Comment By: Umberto Mautone (umautone)
Date: 2013-04-07 04:03
Message:
Just following up on this patch to see if there are any objections to its
inclusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606324group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3606098 ] SIPMSGOPS: text reason for sip_msg_validate()
Patches item #3606098, was opened at 2013-02-26 10:25 Message generated for change (Comment added) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606098group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: SIPMSGOPS: text reason for sip_msg_validate() Initial Comment: This patch adds second parameter for sip_msg_validate with resulting pvar returning error text. -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-10 10:53 Message: Hi Nick, Wouldn't it be better to extend the list of return codes for the sip_msg_validate() function to cover all the errors possible ( internal or SIP msg related ), instead of pushing this text message reason ? Guess that would be a more flexible approach, that would allow the script writer to easily check for the occurred errors. Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606098group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3606029 ] add timeout option for db_http module
Patches item #3606029, was opened at 2013-02-26 00:34 Message generated for change (Comment added) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606029group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Guillaume Bour (gbour) Assigned to: Ovidiu Sas (osas) Summary: add timeout option for db_http module Initial Comment: This patch allows to set a timeout (in milliseconds) for db_http queries. Timeout is set globally, as a module option: modparam(db_http, timeout, 5000) Default timeout is set to 30 seconds. This patch applies to 1.8 branch -- Comment By: Vladut-Stefan Paiu (vladut-paiu) Date: 2013-04-10 11:02 Message: Hello Guillaume, Thanks for the patch. Applied on OpenSIPS trunk ( also updated README ). Best Regards, Vlad -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606029group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3607239 ] SIPMSGOPS: add stream_delete_except function
Patches item #3607239, was opened at 2013-03-07 12:28 Message generated for change (Settings changed) made by vladut-paiu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3607239group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) Assigned to: Vladut-Stefan Paiu (vladut-paiu) Summary: SIPMSGOPS: add stream_delete_except function Initial Comment: Adds stream_delete_except() function to sipmsgops module. Allows for removing all streams from SDP that do not match the regex passed to the function. Example: #Permit only audio and fax streams stream_delete_except(audio|image); -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086412aid=3607239group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by razvancrainea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-09 09:07 Message: Hi, Jonathan! I have found a small bug in the rabbitmq module. I have attached a patch here, can you please run it and see if this fixes your bug? Best regards, Răzvan -- Comment By: Digipigeon (digipigeon) Date: 2013-04-08 13:01 Message: I can confirm 4 full days of uptime without rabbitmq module enabled. No Crashes, 99% sure that is the cause of it. -- Comment By: Digipigeon (digipigeon) Date: 2013-04-04 07:28 Message: Hi, The problem does not happen at start-up. I haven't noticed any other errors apart from what I have wrote. Those two messages were from the same run, they were output just before opensips crashed. At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without any crashes or error messages. Previously the crash happened within the first 15 minutes, so I believe that it is stable, but I will update if this instance crashes. Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-04 07:21 Message: Hi! Does this happen at startup or later, at runtime? Do you see any errors before opensips displays the Critical warning? Also, can you confirm that the two Critical messages are from different runs. Finally, please confirm that after removing the rabbitmq you are able to run your platform normally. Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Digipigeon (digipigeon) Date: 2013-04-09 13:16 Message: Hello, Unfortunately this did not solve the issue, it crashed again: last informative log line: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting BT FULL: (gdb) bt full #0 0x7f770cdc5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7f770cdc8b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7f76aaf1a990, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7f77025b7597 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7f7708dc7850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff64ee8f81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 129474967 rfd = -2118547680 __FUNCTION__ = main Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-09 09:07 Message: Hi, Jonathan! I have found a small bug in the rabbitmq module. I have attached a patch here, can you please run it and see if this fixes your bug? Best regards, Răzvan -- Comment By: Digipigeon (digipigeon) Date: 2013-04-08 13:01 Message: I can confirm 4 full days of uptime without rabbitmq module
[OpenSIPS-Devel] [ opensips-Patches-3606324 ] Add {s.encode.int} transformation
Patches item #3606324, was opened at 2013-02-27 23:57
Message generated for change (Comment added) made by vladut-paiu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606324group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Vladut-Stefan Paiu (vladut-paiu)
Summary: Add {s.encode.int} transformation
Initial Comment:
This patch adds the {s.encode.int} transformation to convert a 4-byte or 8-byte
binary data into an unsigned integer. An example of this feature's use would be
to convert IP addresses directly to unsigned integers to be used as dynamic
group ID values by the load balancer or dispatcher. The patch utilizes
ntohl() on the converted value to correctly manage endian.
$var(ip) = $(Ri{ip.pton}{s.encode.int});
The patch applies to 1.9.0-tls
--
Comment By: Vladut-Stefan Paiu (vladut-paiu)
Date: 2013-04-08 10:08
Message:
Hello,
First of all, not sure I understand why you are treating either 4-byte or
8-byte binary data ? If the purpose is to use the output of ip.pton, then
that returns either 4 or 16 bytes, depending on the IP type ( v4 vs v6 ).
Am I missing something here ?
Also, is the purpose of the function to return the value as an integer (
because I see the PV_VAL_INT being set ) ? If so, it will be a little bit
funky, since for IPV4, you might end up with overflows due to the fact that
the IPv4 address is 32 bits, while the pvar structures in the OpenSIPS code
use integers, thus only 31 bits for the actual number ( 1 bit for the sign
).
The situation for IPv6 would be even worse then.
Probably we'd need to re-work this patch, or change the approach entirely
for this to work for IPv4 and IPv6 as well.
Best Regards,
Vlad
--
Comment By: Umberto Mautone (umautone)
Date: 2013-04-07 04:03
Message:
Just following up on this patch to see if there are any objections to its
inclusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606324group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Digipigeon (digipigeon) Date: 2013-04-08 13:01 Message: I can confirm 4 full days of uptime without rabbitmq module enabled. No Crashes, 99% sure that is the cause of it. -- Comment By: Digipigeon (digipigeon) Date: 2013-04-04 07:28 Message: Hi, The problem does not happen at start-up. I haven't noticed any other errors apart from what I have wrote. Those two messages were from the same run, they were output just before opensips crashed. At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without any crashes or error messages. Previously the crash happened within the first 15 minutes, so I believe that it is stable, but I will update if this instance crashes. Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-04 07:21 Message: Hi! Does this happen at startup or later, at runtime? Do you see any errors before opensips displays the Critical warning? Also, can you confirm that the two Critical messages are from different runs. Finally, please confirm that after removing the rabbitmq you are able to run your platform normally. Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3606324 ] Add {s.encode.int} transformation
Patches item #3606324, was opened at 2013-02-27 23:57
Message generated for change (Comment added) made by umautone
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606324group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Umberto Mautone (umautone)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Add {s.encode.int} transformation
Initial Comment:
This patch adds the {s.encode.int} transformation to convert a 4-byte or 8-byte
binary data into an unsigned integer. An example of this feature's use would be
to convert IP addresses directly to unsigned integers to be used as dynamic
group ID values by the load balancer or dispatcher. The patch utilizes
ntohl() on the converted value to correctly manage endian.
$var(ip) = $(Ri{ip.pton}{s.encode.int});
The patch applies to 1.9.0-tls
--
Comment By: Umberto Mautone (umautone)
Date: 2013-04-07 04:03
Message:
Just following up on this patch to see if there are any objections to its
inclusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3606324group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3607052 ] Load balancer - corrupt data when loading table
Bugs item #3607052, was opened at 2013-03-06 07:08 Message generated for change (Comment added) made by umautone You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3607052group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Umberto Mautone (umautone) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Load balancer - corrupt data when loading table Initial Comment: Tested on 1.9.x Data table: id | group_id | dst_uri | resources | probe_mode +--+---+---+ 19 |1 | sip:192.168.1.5 | pstn=100 | 0 20 |1 | sip:192.168.1.8 | pstn=100 | 0 21 |2 | sip:192.168.1.100 | pstn=2500 | 0 I added this line in lb_db_load_data() to log the actual table fields being loaded: LM_ERR(Fields: %d %d %s %s\n, id, group, uri, resource); The first row loads correctly but subsequent rows seem to lose a pointer alignment somewhere: Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 19 1 sip:192.168.1.5 pstn=100 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 20 1 sip:192.168.1.8 ¥Ý9w#177 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value! Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string ¥Ý9w#177 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 - skipping Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 21 2 sip:192.168.1.100 192.168.1.5 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value! Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string 192.168.1.5 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 - skipping Also tested in 1.8.2 and the problem is not present. The bug seems to be only in the 1.9.x branch. -- Comment By: Umberto Mautone (umautone) Date: 2013-04-05 14:04 Message: Sorry for taking so long. This is using PostgreSQL 9.2 with unixODBC on a 64 bit box. Here is the output with debug=4 on startup: === Apr 5 16:57:24 localhost opensips: WARNING:core:warn: warning in config file /usr//etc/opensips/opensips.cfg, line 44, column 13-16: tls support not compiled in Apr 5 16:57:24 localhost opensips: INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Apr 5 16:57:24 localhost opensips[13284]: NOTICE:core:main: version: opensips 1.9.0-notls (x86_64/linux) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:main: using 32 Mb shared memory Apr 5 16:57:24 localhost opensips[13284]: INFO:core:main: using 2 Mb private memory per process Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_THRESHOLD(0) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_SHM_THRESHOLD(1) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_PKG_THRESHOLD(2) Apr 5 16:57:24 localhost opensips[13284]: NOTICE:signaling:mod_init: initializing module ... Apr 5 16:57:24 localhost opensips[13284]: INFO:sl:mod_init: Initializing StateLess engine Apr 5 16:57:24 localhost opensips[13284]: INFO:tm:mod_init: TM - initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:rr:mod_init: rr - initializing Apr 5 16:57:24 localhost opensips[13284]: INFO:maxfwd:mod_init: initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:mod_init: initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:dialog:mod_init: Dialog module - initializing Apr 5 16:57:24 localhost opensips[13284]: INFO:load_balancer:mod_init: Load-Balancer module - initializing Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:parse_resources_list: resource must has value! Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string HÿóÇ*#177 Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:lb_db_load_data: failed to add destination 3 - skipping Apr 5 16:57:24 localhost opensips[13284]: ERROR:core:parse_uri: bad uri, state 0 parsed: 72.0 (4) / 1.2.3.179 (12) Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:add_lb_dsturi: bad uri [1.2.3.179] for destination Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:lb_db_load_data: failed to add destination 3 -
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Tracker Item Submitted) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Nobody/Anonymous (nobody) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by razvancrainea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-04 07:21 Message: Hi! Does this happen at startup or later, at runtime? Do you see any errors before opensips displays the Critical warning? Also, can you confirm that the two Critical messages are from different runs. Finally, please confirm that after removing the rabbitmq you are able to run your platform normally. Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Digipigeon (digipigeon) Date: 2013-04-04 07:28 Message: Hi, The problem does not happen at start-up. I haven't noticed any other errors apart from what I have wrote. Those two messages were from the same run, they were output just before opensips crashed. At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without any crashes or error messages. Previously the crash happened within the first 15 minutes, so I believe that it is stable, but I will update if this instance crashes. Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-04 07:21 Message: Hi! Does this happen at startup or later, at runtime? Do you see any errors before opensips displays the Critical warning? Also, can you confirm that the two Critical messages are from different runs. Finally, please confirm that after removing the rabbitmq you are able to run your platform normally. Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on use_next_gw/get_gw_by_id
Bugs item #3610045, was opened at 2013-04-04 15:31 Message generated for change (Tracker Item Submitted) made by r0nald11 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ronald Cepres (r0nald11) Assigned to: Nobody/Anonymous (nobody) Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id Initial Comment: Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings. I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash. I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609238 ] Memory leak
Bugs item #3609238, was opened at 2013-03-27 00:02
Message generated for change (Comment added) made by nikbyte
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Memory leak
Initial Comment:
After adding
if (($tU !~ ') ($td !~ ') ($ct !~ ')) {
avp_db_query(DELETE FROM location WHERE username='$tU' and
domain='$td' and contact='$ct.fields(uri)' and path like '%sip:$si:$sp;%');
}
for REGISTER call to scenario, I've get shmem memory leak about 250 Mb in 4
hours on system with about 30k regs.
My suspicions is on $ct.fields(url). But I don't know exactly.
--
Comment By: Nick Altmann (nikbyte)
Date: 2013-04-03 02:46
Message:
The leak is in snmp_stats module. When it's disabled, no leak.
Also process with it eats 100% CPU.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:46
Message:
1) please enable the memory debugging in order to get a mem dump (set
memlog=6 and memdump=1 - in this order).
2) try cornering the leak - run the query but without any variables
inside; add them one by one ; see when the leak appears.
Thanks and regards,
Bogdan
--
Comment By: Nick Altmann (nikbyte)
Date: 2013-03-27 03:11
Message:
I'm really sure.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:10
Message:
Hi Nick,
are you sure the leak is in SHM mem ? as non of the parsing (variables) or
db ops are using the shm mem - they are using pkg.
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Bugs item #3608168, was opened at 2013-03-15 06:13 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: LoadBalancer bug Initial Comment: $avp(res) = aaa; load_balance(1,$avp(res)) - works $avp(res) = bbb; load_balance(1,$avp(res)) - works $avp(res) = aaa;bbb; load_balance(1,$avp(res)) - no lines -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-03 02:53 Message: Talking to Nick, we agreed this is not a bug, but rather a need for some new functionality. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-01 10:07 Message: Hi Nick, I don't think your fix is correct - the dst_bitmap mask tells which destinations should be used. And it is built as a logical and between all the dst_bitmap masks for the used resources. Each resource has its own dst_bitmap mask with the destinations that offer that resource - so you need to and the the bitmaps for the requests destinations in order to get the only destinations offering all requested resources. Maybe your provisioning is not right - could you post your lb table ? Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2013-04-01 07:54 Message: The problem in bitmap logic when more than one resource. We need do logic or, not logic and. Patch included. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609238 ] Memory leak
Bugs item #3609238, was opened at 2013-03-27 00:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Memory leak
Initial Comment:
After adding
if (($tU !~ ') ($td !~ ') ($ct !~ ')) {
avp_db_query(DELETE FROM location WHERE username='$tU' and
domain='$td' and contact='$ct.fields(uri)' and path like '%sip:$si:$sp;%');
}
for REGISTER call to scenario, I've get shmem memory leak about 250 Mb in 4
hours on system with about 30k regs.
My suspicions is on $ct.fields(url). But I don't know exactly.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-03 04:21
Message:
Nick, thanks for the update - any way of reproducing this ? Do you also
have a mem dump to see the leaked chunks ? Is the 100% usage triggered by a
certain SNMP val ?
Regards,
Bogdan
--
Comment By: Nick Altmann (nikbyte)
Date: 2013-04-03 02:46
Message:
The leak is in snmp_stats module. When it's disabled, no leak.
Also process with it eats 100% CPU.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:46
Message:
1) please enable the memory debugging in order to get a mem dump (set
memlog=6 and memdump=1 - in this order).
2) try cornering the leak - run the query but without any variables
inside; add them one by one ; see when the leak appears.
Thanks and regards,
Bogdan
--
Comment By: Nick Altmann (nikbyte)
Date: 2013-03-27 03:11
Message:
I'm really sure.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:10
Message:
Hi Nick,
are you sure the leak is in SHM mem ? as non of the parsing (variables) or
db ops are using the shm mem - they are using pkg.
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Bugs item #3608168, was opened at 2013-03-15 06:13 Message generated for change (Comment added) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: LoadBalancer bug Initial Comment: $avp(res) = aaa; load_balance(1,$avp(res)) - works $avp(res) = bbb; load_balance(1,$avp(res)) - works $avp(res) = aaa;bbb; load_balance(1,$avp(res)) - no lines -- Comment By: Nick Altmann (nikbyte) Date: 2013-04-01 07:54 Message: The problem in bitmap logic when more than one resource. We need do logic or, not logic and. Patch included. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609399 ] onreply_route nat_uac_test(1) ignores RFC1918 Contact
Bugs item #3609399, was opened at 2013-03-28 16:24
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609399group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: onreply_route nat_uac_test(1) ignores RFC1918 Contact
Initial Comment:
I have in the onreply_route route this check:
if (nat_uac_test(1))
{
fix_nated_contact();
}
But this Contact header remains untouched:
SIP/2.0 200 OK
...
CONTACT: sip:PBX.network.local:5060;transport=Tcp;maddr=172.16.1.1
...
If i remove the nat_uac_test(1) check and just execute fix_nated_contact()
the Contact header is changed:
CONTACT: sip:1.2.3.4:5060;transport=Tcp
So i think the nat_uac_test(1) check doesn't detect the RFC1918 Contact
header. I use 1.8.2 svn9916.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-04-01 09:22
Message:
Hi,
Could you attached the opensips log (in debug 4) corresponding to the reply
processing?
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609399group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608474 ] Doc field in XCAP table is too small
Bugs item #3608474, was opened at 2013-03-19 06:22 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608474group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: saghul (saghul) Assigned to: saghul (saghul) Summary: Doc field in XCAP table is too small Initial Comment: Currently it's defined as of type 'binary', which is translated to a BLOB type for the MySQL backend. I ran into cases in which the document didn't fit. I suggest we make that a LONGBLOB. AFAIS there is no 'longbinary' type of field, so it would need to be defined for each DB backend. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-01 09:26 Message: Hi Saul, feel free to make the necessary changes. Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608474group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires decrementing
Bugs item #3609028, was opened at 2013-03-25 09:06 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Ovidiu Sas (osas) Summary: uac_registrant expires decrementing Initial Comment: Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry expires= keeps decreasing from the value in the database (240). It eventually reaches 1 and then contact errors appear in the log. the other registrant expires also starts to decrease at this point. -- Comment By: Paul (dipegang) Date: 2013-03-29 22:42 Message: expires= is no longer decrementing but the message below appears in the log every few days. Mar 30 00:58:13 sip /usr/sbin/opensips[17527]: CRITICAL:core:timer_ticker: timer handler uac_reg_check lasted (214 us) for more than timer tick (100 us) - potential timer shifting The messages relating to the REGISTER/200ok have not re-appeared. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:59 Message: I pushed a fix in trunk for avoiding altering the initial expires. Please test it and let me know how it works. Also, if you can provide me some traces related to the REGISTER/200ok, it would help. You can send the trace privately to me or post them here after you obfuscate all the sensitive data. Regards, Ovidiu Sas -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:57 Message: Please put your comments in the 'Comments' section so other can search and find if looking for similar issues. You were saying: I'm registering to a service provider's two proxies. The registrations are successful and I am receiving incoming calls. However, opensisps has been operating normally for about a week until various messages started to appear in the log. Doing some checking, I noticed that the expires=xxx from the reg_list MI command was displaying expires=1. I restarted opensips and it was now returning expires=240 as the correct value. Over time it started to decrement again as seen from the MI reg_list output. The real domain names have been masked. Opensips CP reg_list command: begins at expires=240 and decrementing until it eventually gets to 1. -- Comment By: Paul (dipegang) Date: 2013-03-25 18:49 Message: Uploaded file with more information. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-25 13:21 Message: Hello, Can you provide more details about what are you trying to achieve? Also, if there are errors in the log, please paste them here. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608210 ] Registrar max_expires not working
Bugs item #3608210, was opened at 2013-03-15 13:32 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608210group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Registrar max_expires not working Initial Comment: Opensips 1.9.0 max_expires is not working when set in the module parameters for all UA's. To force the setting, the exported save function has to be used with parameters. Secondly, compilation errors on fedora 13 using gcc 4.4.5 . Some were not present in compiling opensips 1.8.2. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-01 09:30 Message: Hi Paul, So what you are saying is that using the max_expire as flag in save() works, but setting it as module param does not ? Regards, Bogdan -- Comment By: Paul (dipegang) Date: 2013-03-29 22:53 Message: Specifically, max_expires parameter has no effect on CSIP Simple android mobile app. Android application sets register timeout at 900 secs on request. However, using the registrar save command with options, forces the site setting. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608210group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Bugs item #3608168, was opened at 2013-03-15 06:13 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: LoadBalancer bug Initial Comment: $avp(res) = aaa; load_balance(1,$avp(res)) - works $avp(res) = bbb; load_balance(1,$avp(res)) - works $avp(res) = aaa;bbb; load_balance(1,$avp(res)) - no lines -- Comment By: Nick Altmann (nikbyte) Date: 2013-04-01 07:54 Message: The problem in bitmap logic when more than one resource. We need do logic or, not logic and. Patch included. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608168 ] LoadBalancer bug
Bugs item #3608168, was opened at 2013-03-15 06:13 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: LoadBalancer bug Initial Comment: $avp(res) = aaa; load_balance(1,$avp(res)) - works $avp(res) = bbb; load_balance(1,$avp(res)) - works $avp(res) = aaa;bbb; load_balance(1,$avp(res)) - no lines -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-01 10:07 Message: Hi Nick, I don't think your fix is correct - the dst_bitmap mask tells which destinations should be used. And it is built as a logical and between all the dst_bitmap masks for the used resources. Each resource has its own dst_bitmap mask with the destinations that offer that resource - so you need to and the the bitmaps for the requests destinations in order to get the only destinations offering all requested resources. Maybe your provisioning is not right - could you post your lb table ? Regards, Bogdan -- Comment By: Nick Altmann (nikbyte) Date: 2013-04-01 07:54 Message: The problem in bitmap logic when more than one resource. We need do logic or, not logic and. Patch included. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608168group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3607603 ] SIPMSGOPS: sip_msg_validate
Bugs item #3607603, was opened at 2013-03-11 01:30 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3607603group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Razvan Crainea (razvancrainea) Summary: SIPMSGOPS: sip_msg_validate Initial Comment: Why sip_msg_validate passes Contact: in REGISTER like this? Contact: sip:user@domain:10501:20367;rinstance=86d960eb37116caa -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-01 10:09 Message: So adding a new flag to force Contact URI validation ?? -- Comment By: Nick Altmann (nikbyte) Date: 2013-03-14 09:39 Message: It's not valid. There are two times set port - 10501 and 20367. After lookup opensips can't send INVITE. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-03-14 09:37 Message: Nick, That is a valid Contact header. What it shouldn't be passed ? Regards, Bogdan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-03-11 07:59 Message: Hi, Nick! The validate function only if the Contact header has o proper format. However, it doesn't try to parse the URI. Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3607603group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3609533 ] String Transformations: Add s.index and s.rindex
Patches item #3609533, was opened at 2013-03-29 21:54
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3609533group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Razvan Crainea (razvancrainea)
Summary: String Transformations: Add s.index and s.rindex
Initial Comment:
This patch adds the s.index and s.rindex transformations. These transformations
can be used to find the first or last occurrence of a string in another string,
returning its
index (beginning at 0) or -1 if it is not found. They also optionally take an
index parameter which is explained more below.
Examples:
s.index transformation
Searches for one string within another starting at the beginning of the first
string. Returns starting index of the string found or -1 if not found.
The optional index specifies the offset to begin the search at in the string.
Negative offsets are supported and will wrap.
$var(strtosearch) = 'onetwothreeone';
$var(str) = 'one';
#Search the string starting at 0 index
$(var(strtosearch){s.index, $var(str)}) #will return 0
$(var(strtosearch){s.index, $var(str), 0}) #Same as above
$(var(strtosearch){s.index, $var(str), 3}) #returns 11
#Negative offset
$(var(strtosearch){s.index, $var(str), -11}) #Same as above
#Negative wrapping offset
$(var(strtosearch){s.index, $var(str), -25}) #Same as above
#Test for existence of string in another
if ($(var(strtosearch){s.index, $var(str)}) =0) {
xlog(found $var(sstr) in $var(strtosearch));
do some stuff
}
#Case insensitive match
$var(str) = 'ONE';
$(var(strtosearch){s.index, $var(str)}) #will return -1
$(var(strtosearch){s.toupper}{s.index, $var(str)}) #will return 0
r.index transformation
Searches for one string within another starting at the end of the first string.
Returns starting index of the string found or -1 if not found.
The optional index specifies an offset to start the search before, e.g the
start of the found string will be before the supplied offset. Negative offsets
are supported and will wrap.
$(var(strtosearch){s.rindex, $var(str)}) #will return 11
$(var(strtosearch){s.rindex, $var(str), -3}) #will return 11
$(var(strtosearch){s.rindex, $var(str), 11}) #will return 11
$(var(strtosearch){s.rindex, $var(str), -4}) #will return 0
These transformations should be helpful for general string manipulation in
conjunction with the s.substr transformation.
They also provide a mechanism for searching a string that does not rely on
regular expressions.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3609533group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires decrementing
Bugs item #3609028, was opened at 2013-03-25 09:06 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Ovidiu Sas (osas) Summary: uac_registrant expires decrementing Initial Comment: Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry expires= keeps decreasing from the value in the database (240). It eventually reaches 1 and then contact errors appear in the log. the other registrant expires also starts to decrease at this point. -- Comment By: Ovidiu Sas (osas) Date: 2013-04-01 10:55 Message: It seems that you are having some DNS issues. Try to use IPs instead of FQDNs in registrar's URI and see if the issue is still present. Regards, Ovidiu Sas -- Comment By: Paul (dipegang) Date: 2013-03-29 22:42 Message: expires= is no longer decrementing but the message below appears in the log every few days. Mar 30 00:58:13 sip /usr/sbin/opensips[17527]: CRITICAL:core:timer_ticker: timer handler uac_reg_check lasted (214 us) for more than timer tick (100 us) - potential timer shifting The messages relating to the REGISTER/200ok have not re-appeared. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:59 Message: I pushed a fix in trunk for avoiding altering the initial expires. Please test it and let me know how it works. Also, if you can provide me some traces related to the REGISTER/200ok, it would help. You can send the trace privately to me or post them here after you obfuscate all the sensitive data. Regards, Ovidiu Sas -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:57 Message: Please put your comments in the 'Comments' section so other can search and find if looking for similar issues. You were saying: I'm registering to a service provider's two proxies. The registrations are successful and I am receiving incoming calls. However, opensisps has been operating normally for about a week until various messages started to appear in the log. Doing some checking, I noticed that the expires=xxx from the reg_list MI command was displaying expires=1. I restarted opensips and it was now returning expires=240 as the correct value. Over time it started to decrement again as seen from the MI reg_list output. The real domain names have been masked. Opensips CP reg_list command: begins at expires=240 and decrementing until it eventually gets to 1. -- Comment By: Paul (dipegang) Date: 2013-03-25 18:49 Message: Uploaded file with more information. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-25 13:21 Message: Hello, Can you provide more details about what are you trying to achieve? Also, if there are errors in the log, please paste them here. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608210 ] Registrar max_expires not working
Bugs item #3608210, was opened at 2013-03-15 13:32 Message generated for change (Comment added) made by dipegang You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608210group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Registrar max_expires not working Initial Comment: Opensips 1.9.0 max_expires is not working when set in the module parameters for all UA's. To force the setting, the exported save function has to be used with parameters. Secondly, compilation errors on fedora 13 using gcc 4.4.5 . Some were not present in compiling opensips 1.8.2. -- Comment By: Paul (dipegang) Date: 2013-04-01 21:12 Message: Hi Bogdan, To answer your question, yes. The module parameter works for the other UA's except CSIP Simple on android. On a previous occasion, the said mod param was also not forcing the setting for the Yealink hard phones, but it is now; not sure why the inconsistency. In all cases, the exported save function with arguments forces the max_expires for all UA's. Not critical, but reporting due to observation. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2013-04-01 09:30 Message: Hi Paul, So what you are saying is that using the max_expire as flag in save() works, but setting it as module param does not ? Regards, Bogdan -- Comment By: Paul (dipegang) Date: 2013-03-29 22:53 Message: Specifically, max_expires parameter has no effect on CSIP Simple android mobile app. Android application sets register timeout at 900 secs on request. However, using the registrar save command with options, forces the site setting. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608210group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3609533 ] String Transformations: Add s.index and s.rindex
Patches item #3609533, was opened at 2013-03-29 21:54
Message generated for change (Tracker Item Submitted) made by rrb3942
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3609533group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Bullock (rrb3942)
Assigned to: Nobody/Anonymous (nobody)
Summary: String Transformations: Add s.index and s.rindex
Initial Comment:
This patch adds the s.index and s.rindex transformations. These transformations
can be used to find the first or last occurrence of a string in another string,
returning its
index (beginning at 0) or -1 if it is not found. They also optionally take an
index parameter which is explained more below.
Examples:
s.index transformation
Searches for one string within another starting at the beginning of the first
string. Returns starting index of the string found or -1 if not found.
The optional index specifies the offset to begin the search at in the string.
Negative offsets are supported and will wrap.
$var(strtosearch) = 'onetwothreeone';
$var(str) = 'one';
#Search the string starting at 0 index
$(var(strtosearch){s.index, $var(str)}) #will return 0
$(var(strtosearch){s.index, $var(str), 0}) #Same as above
$(var(strtosearch){s.index, $var(str), 3}) #returns 11
#Negative offset
$(var(strtosearch){s.index, $var(str), -11}) #Same as above
#Negative wrapping offset
$(var(strtosearch){s.index, $var(str), -25}) #Same as above
#Test for existence of string in another
if ($(var(strtosearch){s.index, $var(str)}) =0) {
xlog(found $var(sstr) in $var(strtosearch));
do some stuff
}
#Case insensitive match
$var(str) = 'ONE';
$(var(strtosearch){s.index, $var(str)}) #will return -1
$(var(strtosearch){s.toupper}{s.index, $var(str)}) #will return 0
r.index transformation
Searches for one string within another starting at the end of the first string.
Returns starting index of the string found or -1 if not found.
The optional index specifies an offset to start the search before, e.g the
start of the found string will be before the supplied offset. Negative offsets
are supported and will wrap.
$(var(strtosearch){s.rindex, $var(str)}) #will return 11
$(var(strtosearch){s.rindex, $var(str), -3}) #will return 11
$(var(strtosearch){s.rindex, $var(str), 11}) #will return 11
$(var(strtosearch){s.rindex, $var(str), -4}) #will return 0
These transformations should be helpful for general string manipulation in
conjunction with the s.substr transformation.
They also provide a mechanism for searching a string that does not rely on
regular expressions.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086412aid=3609533group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires decrementing
Bugs item #3609028, was opened at 2013-03-25 09:06 Message generated for change (Comment added) made by dipegang You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Nobody/Anonymous (nobody) Summary: uac_registrant expires decrementing Initial Comment: Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry expires= keeps decreasing from the value in the database (240). It eventually reaches 1 and then contact errors appear in the log. the other registrant expires also starts to decrease at this point. -- Comment By: Paul (dipegang) Date: 2013-03-29 22:42 Message: expires= is no longer decrementing but the message below appears in the log every few days. Mar 30 00:58:13 sip /usr/sbin/opensips[17527]: CRITICAL:core:timer_ticker: timer handler uac_reg_check lasted (214 us) for more than timer tick (100 us) - potential timer shifting The messages relating to the REGISTER/200ok have not re-appeared. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:59 Message: I pushed a fix in trunk for avoiding altering the initial expires. Please test it and let me know how it works. Also, if you can provide me some traces related to the REGISTER/200ok, it would help. You can send the trace privately to me or post them here after you obfuscate all the sensitive data. Regards, Ovidiu Sas -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:57 Message: Please put your comments in the 'Comments' section so other can search and find if looking for similar issues. You were saying: I'm registering to a service provider's two proxies. The registrations are successful and I am receiving incoming calls. However, opensisps has been operating normally for about a week until various messages started to appear in the log. Doing some checking, I noticed that the expires=xxx from the reg_list MI command was displaying expires=1. I restarted opensips and it was now returning expires=240 as the correct value. Over time it started to decrement again as seen from the MI reg_list output. The real domain names have been masked. Opensips CP reg_list command: begins at expires=240 and decrementing until it eventually gets to 1. -- Comment By: Paul (dipegang) Date: 2013-03-25 18:49 Message: Uploaded file with more information. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-25 13:21 Message: Hello, Can you provide more details about what are you trying to achieve? Also, if there are errors in the log, please paste them here. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3608210 ] Registrar max_expires not working
Bugs item #3608210, was opened at 2013-03-15 13:32 Message generated for change (Comment added) made by dipegang You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608210group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Nobody/Anonymous (nobody) Summary: Registrar max_expires not working Initial Comment: Opensips 1.9.0 max_expires is not working when set in the module parameters for all UA's. To force the setting, the exported save function has to be used with parameters. Secondly, compilation errors on fedora 13 using gcc 4.4.5 . Some were not present in compiling opensips 1.8.2. -- Comment By: Paul (dipegang) Date: 2013-03-29 22:53 Message: Specifically, max_expires parameter has no effect on CSIP Simple android mobile app. Android application sets register timeout at 900 secs on request. However, using the registrar save command with options, forces the site setting. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3608210group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609399 ] onreply_route nat_uac_test(1) ignores RFC1918 Contact
Bugs item #3609399, was opened at 2013-03-28 16:24
Message generated for change (Tracker Item Submitted) made by a719719
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609399group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: a719719 (a719719)
Assigned to: Nobody/Anonymous (nobody)
Summary: onreply_route nat_uac_test(1) ignores RFC1918 Contact
Initial Comment:
I have in the onreply_route route this check:
if (nat_uac_test(1))
{
fix_nated_contact();
}
But this Contact header remains untouched:
SIP/2.0 200 OK
...
CONTACT: sip:PBX.network.local:5060;transport=Tcp;maddr=172.16.1.1
...
If i remove the nat_uac_test(1) check and just execute fix_nated_contact()
the Contact header is changed:
CONTACT: sip:1.2.3.4:5060;transport=Tcp
So i think the nat_uac_test(1) check doesn't detect the RFC1918 Contact
header. I use 1.8.2 svn9916.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609399group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609238 ] Memory leak
Bugs item #3609238, was opened at 2013-03-27 00:02
Message generated for change (Tracker Item Submitted) made by nikbyte
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak
Initial Comment:
After adding
if (($tU !~ ') ($td !~ ') ($ct !~ ')) {
avp_db_query(DELETE FROM location WHERE username='$tU' and
domain='$td' and contact='$ct.fields(uri)' and path like '%sip:$si:$sp;%');
}
for REGISTER call to scenario, I've get shmem memory leak about 250 Mb in 4
hours on system with about 30k regs.
My suspicions is on $ct.fields(url). But I don't know exactly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609238 ] Memory leak
Bugs item #3609238, was opened at 2013-03-27 00:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Memory leak
Initial Comment:
After adding
if (($tU !~ ') ($td !~ ') ($ct !~ ')) {
avp_db_query(DELETE FROM location WHERE username='$tU' and
domain='$td' and contact='$ct.fields(uri)' and path like '%sip:$si:$sp;%');
}
for REGISTER call to scenario, I've get shmem memory leak about 250 Mb in 4
hours on system with about 30k regs.
My suspicions is on $ct.fields(url). But I don't know exactly.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:10
Message:
Hi Nick,
are you sure the leak is in SHM mem ? as non of the parsing (variables) or
db ops are using the shm mem - they are using pkg.
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609238 ] Memory leak
Bugs item #3609238, was opened at 2013-03-27 00:02
Message generated for change (Comment added) made by nikbyte
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.9.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nick Altmann (nikbyte)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Memory leak
Initial Comment:
After adding
if (($tU !~ ') ($td !~ ') ($ct !~ ')) {
avp_db_query(DELETE FROM location WHERE username='$tU' and
domain='$td' and contact='$ct.fields(uri)' and path like '%sip:$si:$sp;%');
}
for REGISTER call to scenario, I've get shmem memory leak about 250 Mb in 4
hours on system with about 30k regs.
My suspicions is on $ct.fields(url). But I don't know exactly.
--
Comment By: Nick Altmann (nikbyte)
Date: 2013-03-27 03:11
Message:
I'm really sure.
--
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-03-27 03:10
Message:
Hi Nick,
are you sure the leak is in SHM mem ? as non of the parsing (variables) or
db ops are using the shm mem - they are using pkg.
Regards,
Bogdan
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609238group_id=232389
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires decrementing
Bugs item #3609028, was opened at 2013-03-25 09:06 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Nobody/Anonymous (nobody) Summary: uac_registrant expires decrementing Initial Comment: Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry expires= keeps decreasing from the value in the database (240). It eventually reaches 1 and then contact errors appear in the log. the other registrant expires also starts to decrease at this point. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:57 Message: Please put your comments in the 'Comments' section so other can search and find if looking for similar issues. You were saying: I'm registering to a service provider's two proxies. The registrations are successful and I am receiving incoming calls. However, opensisps has been operating normally for about a week until various messages started to appear in the log. Doing some checking, I noticed that the expires=xxx from the reg_list MI command was displaying expires=1. I restarted opensips and it was now returning expires=240 as the correct value. Over time it started to decrement again as seen from the MI reg_list output. The real domain names have been masked. Opensips CP reg_list command: begins at expires=240 and decrementing until it eventually gets to 1. -- Comment By: Paul (dipegang) Date: 2013-03-25 18:49 Message: Uploaded file with more information. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-25 13:21 Message: Hello, Can you provide more details about what are you trying to achieve? Also, if there are errors in the log, please paste them here. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3609028 ] uac_registrant expires decrementing
Bugs item #3609028, was opened at 2013-03-25 09:06 Message generated for change (Comment added) made by osas You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul (dipegang) Assigned to: Nobody/Anonymous (nobody) Summary: uac_registrant expires decrementing Initial Comment: Two outgoing registrations with identical parameters. When viewed with Opensips CP , over time , the second entry expires= keeps decreasing from the value in the database (240). It eventually reaches 1 and then contact errors appear in the log. the other registrant expires also starts to decrease at this point. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:59 Message: I pushed a fix in trunk for avoiding altering the initial expires. Please test it and let me know how it works. Also, if you can provide me some traces related to the REGISTER/200ok, it would help. You can send the trace privately to me or post them here after you obfuscate all the sensitive data. Regards, Ovidiu Sas -- Comment By: Ovidiu Sas (osas) Date: 2013-03-26 07:57 Message: Please put your comments in the 'Comments' section so other can search and find if looking for similar issues. You were saying: I'm registering to a service provider's two proxies. The registrations are successful and I am receiving incoming calls. However, opensisps has been operating normally for about a week until various messages started to appear in the log. Doing some checking, I noticed that the expires=xxx from the reg_list MI command was displaying expires=1. I restarted opensips and it was now returning expires=240 as the correct value. Over time it started to decrement again as seen from the MI reg_list output. The real domain names have been masked. Opensips CP reg_list command: begins at expires=240 and decrementing until it eventually gets to 1. -- Comment By: Paul (dipegang) Date: 2013-03-25 18:49 Message: Uploaded file with more information. -- Comment By: Ovidiu Sas (osas) Date: 2013-03-25 13:21 Message: Hello, Can you provide more details about what are you trying to achieve? Also, if there are errors in the log, please paste them here. Regards, Ovidiu Sas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3609028group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
