[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=detail&atid=1086410&aid=3610662&group_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=detail&atid=1086410&aid=3610662&group_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=detail&atid=1086410&aid=3610750&group_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=detail&atid=1086410&aid=3610750&group_id=232389
___
Devel mailing li
[OpenSIPS-Devel] member call register
hello, could someone provide how do I let people log into OpenSIPS only registered in mysql? I've done web searches and scripts that meeting never work'm still novated OpenSIPS passes as if someone has some good sites also would be grateful. Thank you. ___ 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 a719719
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3610776&group_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
OpenSips[6832]: DBG:registrar:lookup: looking for branches
OpenSips[6832]: DBG:registrar:lookup: setting branch
OpenSips[6832]: DBG:registrar:lookup: setting branch
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=detail&atid=1086410&aid=3610776&group_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=detail&atid=1086410&aid=3610016&group_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=, p=0x7fac0be20d80, file=, func=, line=) at mem/q_malloc.c:450 f = size = __FUNCTION__ = "qm_free" #3 0x7fac63049bb7 in rmq_process (rank=) at rabbitmq_send.c:323 __FUNCTION__ = "rmq_process" #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = l = x = __FUNCTION__ = "start_module_procs" #5 0x00414edc in main_loop () at main.c:818 i = pid = si = startup_done = 0x0 chd_rank = 0 rc = load_p = 0x0 #6 main (argc=, argv=) at main.c:1557 cfg_log_stderr = cfg_stream = c = r = tmp = 0x7fff847dcf81 "" tmp_len = port = proto = 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=, p=0x7f76aaf1a990, file=, func=, line=) at mem/q_malloc.c:450 f = size = __FUNCTION__ = "qm_free" #3 0x7f77025b7597 in rmq_process (rank=) at rabbitmq_send.c:323 __FUNCTION__ = "rmq_process" #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7f7708dc7850 n = l = x = __FUNCTION__ = "start_module_procs" #5 0x00414edc in main_loop () at main.c:818 i = pid = si = startup_done = 0x0 chd_rank = 0 rc = load_p = 0x0 #6 main (argc=, argv=) at main.c:1557 cfg_log_stderr = cfg_stream = c = r = tmp = 0x7fff64ee8f81 "" tmp_len = port = proto = 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
