Re: AcctUpdateInterval < 10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You can easily modify some specific accounting module
to read and update call duration limit on accounting updates. 
The current implementation just sends accounting updates
and does not wait for an answer.

Cisco-AVPair = "h323-credit-time=32167731" is not the best
way to specify credit time, as there is a special attribute for this
purpose. Although you can customize radius modules and process
your custom attributes (like this), so the gatekeeper can talk
with any billing system, even if it is using some funny attributes.

----- Original Message ----- 
From: "Michael Bannij" <rin@xxxxxxxxxxx>
Sent: Thursday, July 08, 2004 3:36 PM


> I'm new to this mailing list and now I woud like to reply this 
> several-month-old message found in archive:
> 
> > > Each of us knows, that the variant will be
> > > more acceptable, when possible
> > > duration of a call will be calculated BEFORE
> > > Setup will be sent .
> > > Then the need in sending of AcctUpdate
> > > in general disappears.
> > > Certainly there will be other problems: 
> > > 1) It Is necessary to create the table with
> > > codes of destinations (preffixes) and the
> appropriate tariffs 
> > > 2) It Is necessary to have the program module
> > > built - in in gnugk or external, 
> > > which before sending Setup will
> > > calculate CurrentCallDurationLimit 
> > > 3) This module also should solve, whether
> > > there is an opportunity to serve the given call. 
> > > That is whether there are enough money
> > > to conversation of minimally possible duration.
> > > 4) After the end of current call this module must to
> > > calculate the session coast, must sent
> > > this coast to GNUGK, and GNUGK must sent update of
> > > CurrentAmount instead of EndSession
> > > or Stop message  to RADIUS-server.
> 
> > Hello Igor",
> > You"re idea is very good it"s just the same as mine ;~)
> > I didn"t understand why some people would want to use
> > AccUpdate = 1, I thought AcctUpdate is
> > just to live some small record every minute or so,
> > to indicate that the call was in progress
> > and the only use for that record is in case if gk
> > dies while there"re some calls in
> > progress, so that latter it would be possible to track
> > interrupted calls. Myabe I"m not
> > clear in this place...  
> >  In my opinion radius should send something like
> > h323-credit-time and your gk should
> > understand it - the math will be simple - you can use
> > then milliseconds as incriments in you
> > billing;) 
> 
> There are also some drawbacks of using only h323-credit-time 
> only once:
> 
>  - It will take some time to compute that credit time. 
> Espesially in cases dealing with sofisticated tariff plans and 
> you should return result in realtime. And (In some cases that 
> problem even may become unresolvable, for example, when tariff 
> plan is build in such a way, when computed credit time depends 
> on resource (call seconds, MB, number of acts of using 
> per-access-tariffed services). Besides, in reality it 
> friquently happens that you make most of computations in vain - 
> that is, you compute cost for 1 hour phone call while customer 
> is used to issue 1-minute calls.
> 
>  - Other problem lays in non-reentrance of such logic. That is, 
> suppose you have two customers sharing one account. And when 
> both of them going to call at the same time - radius should 
> return credit-time computed keeping in mind that there is more 
> than one customer using the service. Or les suppose a situation 
> when you are making long-time call ant want to add to your 
> account additional money while calling in order to improove of 
> that call length.
> 
> I see no good solution, yet I suppose partial one: break entire 
> h323-credit-time in bits of time we sure we could let consumer 
> speak, "guaranted-time" and recheck that time periodicaly at 
> the middle of "guaranted-time" using status update packets. 
> Also while such updates we still may use h323-credit-time in 
> cases when we could solve computation problem. In general it 
> looks like fetching BLOB from database in parts, or like eating 
> pizza in parts when you can't deal with at once :) 
> 
> Currently I'm looking for such feature, what may gnugk promt in 
> this way?
> 
> Also I have question about correct form of the attribute 
> h323-credit-time: now i have billing system returning it in 
> such form:
>   Cisco-AVPair = "h323-credit-time=32167731"
> while AFAIK gnugk requires
>   h323-credit-time=32167731
> or
>   h323-credit-time="h323-credit-time=32167731"
> Why so many forms of the same thing and what form is most 
> compatible with h323 standard?



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

_______________________________________________________

List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Homepage: http://www.gnugk.org/

[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux