Call gen tests

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

 




Hello everybody,

I've been trying to write some simple billing system for gnugk/radius and then I found some strange problems.

first problem I saw, is that strangely at some point gnugk wasn't sending id/h235 pass to my radius - istead it decided to go easier way - it started to send User-Name and User-Password as if I had fixedusername option in config.

My first test was with accounts prepaid - 1500 calls in ~20min gave me 0 errors. gnugk was runing on linux-rh9 and both callgen323 on winxp. However when I added some sort of slow connections/slow database emulation I got tons of problems - barely 50 % of the calls were established. And at some point all the calls were JUST rejected. When I looked inside radiusd -X I found strange thing: In the middle of my test gnugk stopped sending Chap_Pass and started to send User-Password same as User-Name.
I had this config: 
Gk::Auth]
RadAuth=optional;RRQ,ARQ
RadAliasAuth=sufficient;RRQ,ARQ

calling callgen323 was run with -u user -p pass (<- h235 password)



Another issue - I faced a quite difficult problem in building a realiable and efficient billing application that cound support prepaid with gnugk. Most of what I did was really working, but it was kinda a way around different obstacles and just became not reliable and not efficient at the end (with my last test where my sql sometimes dropped connections and wasn't replying instantly and considerable network jitter between endpoints and gk, all my efforts prooved to be useless):))
That's why I want to ask about the way gnugk does radius comunications. There are some people around wishing to build biling for prepaid who whould probably also like to know this information.
The question I have...

If radius received 1st leg access request, then will it receive accounting-start/stop for this user if radius replied access-accept? Actually, acct-start is sent immidiately after access-accept is received by gnugk?
Will radius send acct/stop if it sent acct/start? (meaning there is no way a call could be dropped/rejected without notifying radius)
And a more general question... what should be the right way to control simultaneous use?? Previous 2 questions are directly related to this one in my solution - whether I leave holes in my billing and everything woks nice, or in another way often accounts of users are locked without future possiblity for access. That was the outcome from my test with callgen. Some sort of stored procedures, trigers and transactions in db could simplify my tasks, but still it doesn't become more secure and stable.
Anybody has any ideas??


ps. Does static build work for 207 ?? Couldn't get it compiled properly - some error in BRF or something like that (that what make says it was :)) - without any error codes or unresolved dependencies.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
List: Openh323gk-users@lists.sourceforge.net
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