[SR-Users] Accounting only the 2nd branch of missed serial forked call
Ozren Lapcevic
ozren.lapcevic at gmail.com
Tue Sep 27 12:32:02 CEST 2011
Just tested with v3.2 and acc_prepare_flag and accounting works fine now!
Thanks,
Ozren
On Tue, Sep 27, 2011 at 8:21 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> Hello,
>
> the mail is quite long and has lot of inner references that makes it not
> that easy to follow, better focus only on what is wrong.
>
> I see lot of OKs, but I don't get it if you tried with v3.2.0. If still
> does not work, send the debug messages.
>
> You can always use acc_db_request(...) just to record a missed call
> whenever you want, but the other way with flags should work as well, after
> latest enhancement, maybe it needs some tuning if not there yet. Previously
> there was no callback to tm registered for failure event if the missed call
> flag was not set in main route block.
>
> Cheers,
> Daniel
>
>
> On 9/26/11 3:17 PM, Ozren Lapcevic wrote:
>
> 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
>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> 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/20110927/01855c0c/attachment-0001.htm>
More information about the sr-users
mailing list