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

Reply via email to