[SR-Users] Accounting only the 2nd branch of missed serial forked call
Ozren Lapcevic
ozren.lapcevic at gmail.com
Mon Sep 26 15:17:29 CEST 2011
Hi,
sorry if I haven't been clear in the last mail(s). I'll try to recap.
I have a call with 3 branches that are serially forked. branch 1 and 2 can
be PSTN number or SIP URI. branch 3 is voicemail. I do not want to account
1st branch if call is missed, only the 2nd one.
Here are the snippets from the configuration file that I'm using since I've
started this thread. I've bolded parts where acc related flags are set.
route { ....
route(WITHINDLG); ....
if ( is_method("INVITE") ) { ...
*setflag(FLT_ACC); # [1]*
#check for user defined forking priorities and timers
route(FORK);
}
route(LOCATION);
route(RELAY);
}
#check for user defined forking priorities and timers
route[FORK]{ ...
# user has multiple contacts, do serial forking
setflag(FLT_USRPREF); ....
# overwrite request URI with highest priority contact
if ($avp(prio1) =~ "^sip:00") $ru = $avp(prio1) + "@host";
else $ru = $avp(prio1); ....
}
route[RELAY] {
if (is_method("INVITE")) {
t_on_reply("REPLY_ONE");
t_on_failure("FAIL_ONE");
#if users have priorities set, use FAIL_FORK failure route
if ( isflagset(FLT_USRPREF) ) t_on_failure("FAIL_FORK");
}
if (!t_relay()) sl_reply_error();
exit;
}
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
*setflag(FLT_ACC);* *# [2]*
*setflag(FLT_ACCFAILED);* *# [3]*
}
route(RELAY);
} ....} }
# USER location service
route[LOCATION] {
if ($ru =~ "^sip:00") xlog("L_INFO","SKIP lookup...");
else {
if (!lookup("location")) {
switch ($rc) {
case -1:
case -3:
t_newtran();
t_reply("404", "Not Found");
exit;
case -2:
sl_send_reply("405", "Method Not
Allowed");
exit;
}
}
}
# when routing via usrloc, log the missed calls also, but only if
user doesn't have prios set
if ( is_method("INVITE") && !(isflagset(FLT_USRPREF))) {
*setflag(FLT_ACCMISSED);* *# [4] - not used in serial
forking scenario
* }
}
# Failure route for forked calls
failure_route[FAIL_FORK] { ...
# handle 2nd branch
if ( ($avp(prio) == 2) && ( isflagset(FLT_USRPREF) )) {
t_on_failure("FAIL_FORK");
if ($avp(prio2) =~ "^sip:00") $ru = $avp(prio2) +
"@host"; # tel number
else {
$ru = $avp(prio2); # sip uri
route(LOCATION);
}
*setflag(FLT_ACCMISSED); # [5]*
}
# 3rd branch is voicemail
else {
$ru = $(avp(uuid));
rewritehostport("host:port");
append_hf("P-App-Name: voicemail\r\n");
append_hf("P-App-Param:
Email-Address=$avp(email)\r\n");
}
route(RELAY);
if (t_is_canceled()) {
exit;
}
}
With code above I'm testing following scenarios, where oz at abc.hr calls
pero at abc.hr. Due to pero at abc.hr settings and priorities set, 1st branch is
PSTN number, 2nd branch is sip:pero at abc.hr and 3rd branch is voicemail:
1. pero doesn't answer 1st branch and 2nd branch, voicemail activates. There
are no logs in missed_calls. I want to have a single log in missed_calls for
this case.
2. pero doesn't answer 1st branch, declines call at 2nd branch (486 Busy),
voicemail activates. There are no logs in missed_calls. I want to have a
single log in missed_calls for this case.
3. pero doesn't answer 1st branch, 2nd branch rings, oz cancels call,
voicemail doesn't activate. There is a single log in missed_calls (487).
This is ok, as expected.
4. 1st branch rings, oz cancels call. There is a single log in missed_calls
(487). This is also ok.
Logs in acc table exist and are good for all 4 cases - all of them are
related to established call to voicemail server.
Previously, I've tested several variations of config file above:
Variation 1: remove [1], [2] and [3]. (look for bolded lines above). In this
variation, only [5] is related to acc flags and is set in failure route.
When testing 4 scenarios above, there are no logs in acc and acc_missed
table. This is probably related to your comment that acc does not register
itself for a tm callback that is used for handling accounting events if
there are no flags defined in request route block.
Variation 2: [1], [2], [3] are used again, but 3rd branch is removed, there
is no voicemail. Lets go through 4 scenarios again:
1. pero doesn't answer 1st branch and 2nd branch. There is a single log in
missed_calls (408) - OK.
2. pero doesn't answer 1st branch, declines call at 2nd branch (486 Busy).
There is a single log in missed_calls (486) - OK.
3. pero doesn't answer 1st branch, 2nd branch rings, oz cancels call. There
is a single log in missed_calls (487) - OK.
4. 1st branch rings, oz cancels call. There is a single log in missed_calls
(487) - OK.
There are no logs in acc table. This is OK because no calls have been
established. Everything works as expected here! However, I need the
voicemail, I can't replace it for accounting.
Variation 3: [1], [2], [3] are used, as well as voicemail. [5] is removed
from failure route. Instead, in failure route setflag(FL_2NDBRANCH) is set
when 2nd branch is processed. In RELAY route following line is added: if (
isflagset(FL_2NDBRANCH) ) setflag(FLT_ACCMISSED). Results are the same as
for original configuration.
On Mon, Sep 26, 2011 at 12:06 PM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:
> Hello,
>
>
> On 9/26/11 11:44 AM, Ozren Lapcevic wrote:
>
>
> On Sat, Sep 24, 2011 at 9:11 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> just to refresh in case you mentioned already, do you set acc missed call
>> flag in request route block?
>>
>
>
> No. I'm setting setflag(FLT_ACCMISSED) in failure route for serially forked
> calls.
>
> ok, so that caused not to register to TM for a callback on failure events
> when the transaction for respective INVITE was created.
>
>
> (Also, I'm setting setflag(FLT_ACC); in main route for INVITES. I'm setting
> setflag(FLT_ACC) and setflag(FLT_ACCFAILED) in WITHINDLG route for loose
> routed BYEs.)
>
> This is different that what we looked after.
>
>
> Previously, before starting this thread, and before any of your patches,
> I've tried setting FLT_ACCMISSED in LOCATION route and in RELAY route, but
> didn't help with properly accounting only the 2nd branch.
>
>
> Because it caused the first branch also to be recorded to missed calls.
>
By that, I meant Variation 3.
> I found another issue that if this flag is no set in request route, the
>> callback to tm that is used for accounting missed calls is not registered.
>> Can you try with 3.2.0 (git master branch at this moment) and set the
>> acc_prepare_flag parameter, plus the flag itself for invites?
>>
>
>
> I've installed new Kamailio with instructions from:
> http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-devel-from-git.
> However, default kamailio config file and kamctl file both show 3.1 version.
> How can I check whether I have 3.2 version installed?
>
> Do:
>
> /usr/local/sbin/kamailio -V
>
> The config file kamailio.cfg is not overwritten if already exists, to
> prevent mistakenly loss (no backup).
>
Ok, I have good version installed. I'll test it and report results.
Cheers
Ozren
> acc_prepare_flag should be set in main route, e.g. in the same place as
> FLT_ACC for INVITES?
>
> Yes, it has to be set in request route {...} block.
>
> Cheers,
> Daniel
>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.com
> Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110926/ed392edf/attachment-0001.htm>
More information about the sr-users
mailing list