On Tue, Feb 7, 2012 at 5:12 PM, Jan Willamowius <jan@xxxxxxxxxxxxxx> wrote:
> The main idea is that you shouldn’t have to worry about keeping another
> process running to make complex routing decisions or destination
> rewrites. Right now the 'lua' policy can do about the same things the
> 'vqueue' and 'sql' policies can do, just more convenient.
LUA as a domain-specific language is a great idea!
Unfortunately, the LUA implemented by ptlib is pretty basic. Any
chance of including extensions like LuaSocket?
While it is nice to be able to make more complex routing decisions
like this from inside of gnugk, doing so without referencing external
sources can be quite limiting.
A good example of a use-case that I would love to see is the simple
ability to make multiple DNS queries. If LuaSocket were added, there
is at least one dns.lua script I could use to make these lookups.
Similarly, it would be great to be able to connect out to a redis or
memcache server to get and set key/value pairs that persist between
calls. With LuaSocket, that could also be written in the LUA script
itself.
At the moment, based on the Route.cxx, it looks like the script is
passed these fields:
source
calledAlias
calledIP
caller
callingStationId
callID
messageType
clientauthid
While those are definitely based in the legacy of the current gnugk
codebase (not trying to be insulting here, really!), I'm not really
fond of that naming convention. In my head, I think of things in terms
of Wireshark, like this:
Q.931:
displayName
callingPartyNumber
calledPartyNumber
H.225:
sourceAddressIP
sourceAddressDialedDigits
sourceAddressH323Id
sourceAddressH323Url
destinationAddressIP
destinationAddressDialedDigits
destinationAddressH323Id
destinationAddressH323Url
sourceCallSignalAddressIP
destinationCallSignalAddressIP
callIdentifier
clientAuthID
Some additional fields I would like to see: Q.931 displayName (caller
ID), callingURL, calledURL
The script looks like it sets the following values to direct the call:
action
rejectCode
destAlias
destIP
The pseudocode of what happens after the script returns is something like this:
if action == "REJECT" => reject the call, and set ISDN Q.931
result code to rejectCode
if destAlias => H323SetAliasAddress(destAlias)
if destIP => SocketToH225TransportAddr(ip, port)
if destAlias => route.m_destNumber = destAlias
This looks like a REJECT or RouteToGateway kind of function.
Having a RouteToAlias function to deliver calls to locally registered
endpoints is important as well.
It would be great to be able to do things like BindAndRouteToGateway,
but that may be a bit beyond what everyone else really needs gnugk to
do.
> It would also be cool to have this kind of scripting ability for CLI
> rewriting...
That sounds intriguing.
I'm not conceptualizing what you're proposing... have some example use cases?
--
- Ian Blenke <ian@xxxxxxxxxx> http://ian.blenke.com
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
