[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=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: 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 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=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: 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=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-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=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: 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-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=detail&atid=1086410&aid=3610690&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: 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=detail&atid=1086410&aid=3610690&group_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=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: 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
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: 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 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: 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=, 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 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
