E164 rewritting is a definitelly thing that should be implemented. It's on my todo list:) No. of concurrent calls can be calculated from DB and restricted by radius server + db, so I would rather not send it from the gk. But if you need this, you can easily build your own authenticator/acct module that derives from RadAuth/RadAliasAuth/RadAcct and overrides only one method (OnSendPDU) to include any attributes you wish:) ----- Original Message ----- From: "Nir Simionovich" <nirs@m-wise.com> Sent: Wednesday, December 17, 2003 11:10 PM > I've been fiddeling around with Radius lately, and got some really > neat results (Thanks Aivis from DataTechLabs - you rock). In any case, > I've been going about the fields that are being sent from GnuGK to Radius, > and I've been contemplating on the following issues: > > a. E164 re-writing using Radius > Lets examine the information sent from GnuGK to the Radius server, > using the RadAliasAuth module: > > User-Name = "remote-h323id" > User-Password = "remote-h323id" > NAS-IP-Address = GateKeeper.IP.Address > NAS-Identifier = "GateKeeper.h323id" > NAS-Port-Type = Virtual > Service-Type = Login-User > Framed-IP-Address = Originating.IP.Address > Calling-Station-Id = "remote-h323id" > Called-Station-Id = "E164 After re-writes" > h323-conf-id = "h323-conf-id=bla bla" > h323-call-origin = "h323-call-origin=originate" > h323-call-type = "h323-call-type=VoIP" > h323-gw-id = "h323-gw-id=GateKeeper.h323id" > > Now, I was asking my self the following: currently the Radius gets > the final destination number and prefix from GnuGK. Why can't it > simply send in the orignal prefix before re-writing it, then using > a returned Radius-Attribute re-write the number according to a Radius > table. This way, the re-writes can be done using an external SQL server, > thus enabling GnuGK to have LCR. > > b. Concurrent calls per incoming endpoint > Ok, now we know that it is not a GateKeeper's job to perform limitations > on the number of channels each endpoint sends into the GK, however, if > GnuGK is moving to a PBX/Switch functionality, why not add this thing in. > For example, define a parameter on the Radius that says what is the channel > limit, and send in each Radius query the concurrent number of calls from the > querying endpoint. Right now I'm doing something similar to this using an > external mySQL and some serious SQL tricks, but I believe that it should reside > in the GK itself. > > c. Debug level 3.5 :-) > Well, the GnuGK debug interface is one of the best things about GnuGK, you > can debug anything in there. However, it does pose a slight problem, as the > information provided is 'debug trc 3' is somewhat slim, while 'debug trc 4' > generates so much information, one needs have really fast eyes to look at > that dump. Why not introduce a new level which will include the information > from level 3, and simply add the disconnect causes, without all the other > information. I believe this will be very helpfull for many people here, especially > those who deal with WholeSale VoIP setups (like me). > > Well, these are just some thoughts... ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ List: Openh323gk-users@lists.sourceforge.net Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
