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 <mico...@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 o...@abc.hr calls > p...@abc.hr. Due to p...@abc.hr settings and priorities set, 1st branch is > PSTN number, 2nd branch is sip:p...@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 < > mico...@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 < >> mico...@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-us...@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 > >
_______________________________________________ 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