[OpenSIPS-Users] OpenSIPs Radius Accounting.

Muhammad Shahzad shaheryarkh at gmail.com
Sat May 4 17:56:51 CEST 2013


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 <symack at gmail.com> 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 <shaheryarkh at gmail.com> 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, qasimakhan at gmail.com
> > <qasimakhan at gmail.com>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
> >> <bogdan at opensips.org>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, qasimakhan at gmail.com 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
> >>> <shaheryarkh at gmail.com>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, qasimakhan at gmail.com <
> >>>> qasimakhan at gmail.com> 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
> >>>>> Users at lists.opensips.org
> >>>>> 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: shari_786pk at hotmail.com
> >>>> Email: shaheryarkh at googlemail.com
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> Users at lists.opensips.org
> >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Users mailing
> >>> listUsers at lists.opensips.orghttp://
> lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org
> >> 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: shari_786pk at hotmail.com
> > Email: shaheryarkh at googlemail.com
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> 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: shari_786pk at hotmail.com
Email: shaheryarkh at googlemail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130504/477e23aa/attachment-0001.htm>


More information about the Users mailing list