[SR-Users] Accounting only the 2nd branch of missed serial forked call
Daniel-Constantin Mierla
miconda at gmail.com
Tue Sep 27 16:53:26 CEST 2011
Hello,
On 9/27/11 12:32 PM, Ozren Lapcevic wrote:
> Just tested with v3.2 and acc_prepare_flag and accounting works fine now!
great, thanks for reporting back.
Not sure if this should be backported to 3.1 branch, thinking of how it
was so far designed the acc -- I am actually not that much convinced for
backporting since more or less similar functionality can be done using
acc_db_request(...) in failure_route and version 3.2 is on the corner,
but also this backport would introduce a new parameter to acc module ...
I will give more thought until the next minor release to 3.1 branch.
Cheers,
Daniel
>
> Thanks,
> Ozren
>
>
> On Tue, Sep 27, 2011 at 8:21 AM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto: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
>> <mailto:oz at abc.hr> calls pero at abc.hr <mailto:pero at abc.hr>. Due to
>> pero at abc.hr <mailto:pero at abc.hr> settings and priorities set, 1st
>> branch is PSTN number, 2nd branch is sip:pero at abc.hr
>> <mailto:sip%3Apero 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 <mailto: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 <mailto: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/kat
>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>> http://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/kat http://linkedin.com/in/miconda --
> http://twitter.com/miconda
>
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110927/2cedabcb/attachment-0001.htm>
More information about the sr-users
mailing list