Hello,
can you add a debug message to acc module, compile, reinstall and test
again? Send again the debug messages with parameter debug=4
I am attaching the patch for master branch, should be easy to apply to
3.1 as well.
Cheers,
Daniel
On 9/13/11 11:33 AM, Daniel-Constantin Mierla wrote:
Hello,
On 9/13/11 11:21 AM, Ozren Lapcevic wrote:
Hi,
On Tue, Sep 13, 2011 at 8:46 AM, Daniel-Constantin Mierla
<mico...@gmail.com <mailto:mico...@gmail.com>> wrote:
Hello,
just to be sure, you used flag 2 for missed calls, right? I can
see it set in onreply_route.
Yes, I've used #!define FLT_ACCMISSED 2 and setflag(FLT_ACCMISSED)
for missed calls. I checked the flag in onreply_route and failure
route and they are properly set.
That means the flags are ok now, the issue seems to be in other
place. You don't set any of the accounting flags in request route
block, isn't it? I mean, the first accounting flag (like
accounting answered calls or missed calls) is set in failure
route. If so, the acc does not register itself for a tm callback
that is used for handling accounting events.
Actually, I do set other accounting flags in following routes:
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3
#MAIN ROUTE
if (is_method("INVITE")) setflag(FLT_ACC);
route[WITHINDLG] {
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if
the transaction fails
}
.....
route[LOCATION] {
# only for people who don't have multiple contacts (no serial
forking, not used in reported scenario)
if ( is_method("INVITE") && !(isflagset(FLT_USRPREF)))
setflag(FLT_ACCMISSED);
}
#called only for serial forked calls
failure_route[FAIL_FORK] {
.....
# if second branch set flag
setflag(FLT_ACCMISSED);
t_flush_flags();
....
# if 3rd branch (voicemail) reset flag
resetflag(FLT_ACCMISSED);
t_flush_flags();
....
}
Now that you've mentioned it, I've removed all other setflag()
functions and kept only the ones in FAIL_FORK failure route. There is
still no logging of the second branch.
Try to set acc flag for writing to syslog in route {...}, you can
reset it in failure route or onreply_route. Of course, this as an
workaround for now, I will look for a proper solution in case
this is the problem.
I'm not sure I can implement needed logic this way. I don't want to
account 1st branch. If I set FLT_ACCMISSED flag in route {...} and
reset it in on_reply and failure route, it will be too late, the
missed call will already be accounted. Or, I'm missing something?
It meant setting FLT_ACC (not FLT_ACCMISSED) in main route and reset
it on onreply_route in case you didn't want to account successful
transactions at all. But I see you actually set the acc flag in route
block ... probably I have to dig further in the logs for more details.
So far it looked like an issue if no acc module flags were set in
request route block.
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
diff --git a/modules_k/acc/acc_logic.c b/modules_k/acc/acc_logic.c
index d6e6d53..6cac79d 100644
--- a/modules_k/acc/acc_logic.c
+++ b/modules_k/acc/acc_logic.c
@@ -493,6 +493,8 @@ int acc_api_exec(struct sip_msg *rq, acc_engine_t *eng,
static void tmcb_func( struct cell* t, int type, struct tmcb_params *ps )
{
+ LM_DBG("acc callback called for t(%p) event type %d, reply code %d\n",
+ t, type, ps->code);
if (type&TMCB_RESPONSE_OUT) {
acc_onreply( t, ps->req, ps->rpl, ps->code);
} else if (type&TMCB_E2EACK_IN) {
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
