[SR-Users] Accounting only the 2nd branch of missed serial forked call

Daniel-Constantin Mierla miconda at gmail.com
Tue Sep 13 11:33:01 CEST 2011


Hello,

On 9/13/11 11:21 AM, Ozren Lapcevic wrote:
> Hi,
>
> On Tue, Sep 13, 2011 at 8:46 AM, Daniel-Constantin Mierla 
> <miconda at gmail.com <mailto:miconda at 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110913/566df955/attachment-0001.htm>


More information about the sr-users mailing list