Hi All,
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...
__________________________________________________________________
Nir Simionovich
IT Manager
m-Wise Ltd.
e-Mail: nirs@m-wise.com
cell: +972-54-482826
-------------------------------------------------------
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/
