[OpenSIPS-Users] OpenSIPs Radius Accounting.
Nick Khamis
symack at gmail.com
Sat May 4 18:31:08 CEST 2013
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 <shaheryarkh at gmail.com> 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 <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
>
More information about the Users
mailing list