Thank you so much Muhammad. I have that flag already included in our script. After I sent the last email, I realized that I assumed your use of CDR tool :).
Best of Luck, Ninus. On 5/4/13, Muhammad Shahzad <[email protected]> wrote: > Hi Nick, > > I haven't used Radius with CDRTool so not very sure how the patch effects > OpenSIPS accounting events triggered to Radius. We are using > much sophisticated business logic with integrated VLR and HRL along with > call billing with respect to national and international roaming cases. > Anyhow all you need to do to get failed transactions events in Radius > server, is to set failed_transaction_flag on those transactions, e.g. > > modparam("acc", "aaa_flag", 1) > modparam("acc", "failed_transaction_flag", 3) > > ... > > if ((is_method("INVITE") && !has_totag()) || (is_method("BYE"))) { > setflag(1); > setflag(3); > > }; > > ... > > > Then you should get failed transaction events on Radius regardless of > failure reason, e.g. no-answer (480), cancel (487), busy (486) or even > request timeout (408) and so on. This things works out of the box without > patching Radius and / or OpenSIPS. > > Thank you. > > > On Sat, May 4, 2013 at 3:35 PM, Nick Khamis <[email protected]> wrote: > >> Hello Everyone, >> >> Sorry to chime in however, we are also working on failed route >> accounting using radius. >> My impression was that accounting failed sessions was supported by >> Radius when patching >> the server using CDRTool. Would we still need the above script along >> with the failed packets: >> >> http://cdrtool.ag-projects.com/projects/cdrtool/wiki/Installation_Guide >> >> Kind Regards, >> >> Nick. >> >> On 5/2/13, Muhammad Shahzad <[email protected]> wrote: >> > Something like this, >> > >> > if (t_check_status("408")) { >> > if ( t_local_replied("all") ) { >> > # local timeout with no reply received -> >> fr_timer >> > } else if ( t_local_replied("last") ) { >> > # timeout with replies received -> fr_inv_timer >> > } else { >> > # received timeout >> > }; >> > }; >> > ... >> > >> > Thank you. >> > >> > >> > >> > >> > On Thu, May 2, 2013 at 12:29 PM, [email protected] >> > <[email protected]>wrote: >> > >> >> Hi, >> >> >> >> Thanks Bogdan for your reply. >> >> >> >> Now for my question, I want to keep my STOP event on reply as i have >> >> faced >> >> issues when generating event on request time. The thing is how should >> >> i >> >> cater the fact that the device has gone offline and there is no >> >> response >> >> generated and hence no accounting STOP event. >> >> >> >> Regards, >> >> Qasim >> >> >> >> >> >> On Tue, Apr 30, 2013 at 2:26 PM, Bogdan-Andrei Iancu >> >> <[email protected]>wrote: >> >> >> >>> ** >> >>> Hello, >> >>> >> >>> All accounting triggers (START/STOP or CDR based) are on replies, so >> >>> when >> >>> the transaction is completed. Of course, all transactions are >> terminated >> >>> in >> >>> OpenSIPS - either by received replies, either by a timeout (if no >> reply >> >>> received). >> >>> >> >>> If you want to generate the STOP event at BYE request time (versus >> >>> BYE >> >>> reply time), you can manually do it from script via the acc function >> >>> acc_db_request() (instead of setting the acc flag and letting the acc >> >>> module to generate automatically the event) - the generate event is >> >>> the >> >>> same. See: >> >>> >> >>> http://www.opensips.org/html/docs/modules/1.9.x/acc.html#id294346 >> >>> >> >>> Regards, >> >>> >> >>> Bogdan-Andrei Iancu >> >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >>> >> >>> >> >>> On 04/30/2013 08:00 AM, [email protected] wrote: >> >>> >> >>> I have tried this scenario. Still if the User B is behind a NAT or >> >>> is >> >>> unreachable the opensips generates the BYE with retransmitted BYE's >> >>> and >> >>> the >> >>> dialog is closed but there is no response to BYE received from that >> user >> >>> hence no radius acct request. >> >>> >> >>> Regards, >> >>> Qasim >> >>> >> >>> >> >>> On Mon, Apr 29, 2013 at 8:36 PM, Muhammad Shahzad >> >>> <[email protected]>wrote: >> >>> >> >>>> Per my understanding, accounting event is sent when BYE completes, >> >>>> whether if destination replies with 200 OK or BYE re-transmission >> times >> >>>> out >> >>>> and opensips responds with 408 Request timeout. In each case SIP >> >>>> response >> >>>> code is set appropriately and you should use stop time as accounting >> >>>> end >> >>>> time rather then the time your receive account stop request on >> >>>> radius >> >>>> (they >> >>>> both may differ, e.g. under high load scenarios). >> >>>> >> >>>> Thank you. >> >>>> >> >>>> >> >>>> >> >>>> On Mon, Apr 29, 2013 at 3:27 PM, [email protected] < >> >>>> [email protected]> wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> I wanted to confirm if radius accounting requests are generated on >> >>>>> a >> >>>>> successful transaction or it can be generated on a received BYE >> >>>>> only. >> >>>>> To >> >>>>> elaborate my question you can look at 2 diagrams below. Is first >> >>>>> scenario >> >>>>> correct based on RFC's? My next question is that if scenario A is >> >>>>> correct >> >>>>> then how can we account the call if say user B has gone offline and >> we >> >>>>> do >> >>>>> not receive 200 OK of the BYE sent? >> >>>>> >> >>>>> Can we send a manual accounting request to Radius with >> acc_aaa_request >> >>>>> in accounting module? >> >>>>> >> >>>>> *Scenario A:* >> >>>>> User A OpenSIPs Radius User B >> >>>>> >> >>>>> |-------BYE------->| >> >>>>> | >> >>>>> | >> >>>>> |---------------------BYE-------------------->| >> >>>>> | |-------acct-BYE------->| >> >>>>> >> >>>>> *Scenario B:* >> >>>>> User A OpenSIPs Radius User B >> >>>>> |-------BYE------->| >> >>>>> | | >> >>>>> | >> >>>>> |---------------------BYE-------------------->| >> >>>>> | |<-------------------200 OK >> >>>>> -----------------| >> >>>>> |<----200 OK -----| >> >>>>> | |-------acct-BYE------->| >> >>>>> >> >>>>> >> >>>>> Regards, >> >>>>> Qasim Ayyaz Khan >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Users mailing list >> >>>>> [email protected] >> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Mit freundlichen Grüßen >> >>>> Muhammad Shahzad >> >>>> ----------------------------------- >> >>>> CISCO Rich Media Communication Specialist (CRMCS) >> >>>> CISCO Certified Network Associate (CCNA) >> >>>> Cell: +49 176 99 83 10 85 <%2B49%20176%2099%2083%2010%2085> >> >>>> MSN: [email protected] >> >>>> Email: [email protected] >> >>>> >> >>>> _______________________________________________ >> >>>> Users mailing list >> >>>> [email protected] >> >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>>> >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Users mailing >> >>> [email protected]:// >> lists.opensips.org/cgi-bin/mailman/listinfo/users >> >>> >> >>> >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> [email protected] >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> > >> > >> > -- >> > Mit freundlichen Grüßen >> > Muhammad Shahzad >> > ----------------------------------- >> > CISCO Rich Media Communication Specialist (CRMCS) >> > CISCO Certified Network Associate (CCNA) >> > Cell: +49 176 99 83 10 85 >> > MSN: [email protected] >> > Email: [email protected] >> > >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > > -- > Mit freundlichen Grüßen > Muhammad Shahzad > ----------------------------------- > CISCO Rich Media Communication Specialist (CRMCS) > CISCO Certified Network Associate (CCNA) > Cell: +49 176 99 83 10 85 > MSN: [email protected] > Email: [email protected] > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
