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/
