On Wed, Feb 8, 2012 at 8:48 AM, Jan Willamowius <jan@xxxxxxxxxxxxxx> wrote: > I agree that that sockets would be very useful. Do you know what it > would take to include the LuaSocket in PTLib ? I'm pretty sure Robert > and Craig are fine with us adding more functionality. I already had to > expand it a bit to get the GnuGk implementation to work. Honestly, no, I don't know what it would take. The easy answer is "you just link it in as a Lua extension". The reality is that this is a C based extension, and ptlib is a C++ project with platform abstractions to be compilable on many different operating systems. That being said, LuaSocket claims to "work well on most UNIX distributions and Windows flavors", so it may not be that big of a deal to link in. > Again, I agree that the current names aren't great. But since they > don't 1:1 represent Q.931 or H.225 items, we shouldn't pretend they > are: The same variables are made available for routing calls based on > ARQ, Setup, LRQ and facilty messages. The current fields are filled > with the closest equivalent in those messages so you don't have to > write specific code for all 4 situations (but you can look at > messageType if you really want to know what you are routing). I see where you are coming from. From the gnugk maintainer perspective, having the Lua variables parallel the gnugk variable names is a good idea. From a gnugk user perspective, they may be a bit foreign. > Secondly, if you split eg. the sourceAddress from a Setup by alias type > into 4 (or more) variables thats going to lead to terrible if/else > cascades in the routing code. That may be true, but we do run into cases today where Q.931 callingParty/calledParty vs h.225 sourceaddress/destinationAddress URL vs H323ID vs dialedDigit decisions must be made. Yes, I agree, it seems silly, but folks can't seem to come to a consensus on one true way to signal. Case-in-point: Try placing a call to the gateways for cisco.com, callway.net, or tandberg.com, and try signaling a Q.931 calledPartyNumber or H.225 destinationAddress dialedDigits. if you signal anything _but_ a H.225 destinationAddress h323Url to their gateways, the reject the call outright. On the other hand, try signaling only an H.225 destinationAddress h323Url to various Video Relay Service providers here in the US, and they'll likewise reject the call outright. Instead, signal the Q.931 calledPartyNumber (and sometimes the H.225 destinationAddress dialedDigits), and you'll have more luck getting through. I guess what I'm trying to say is that those "terrible if/else cascades" are really unavoidable, if you wish to integrate your dialplan with the widest audience. > If you set the destIP="" and destAlias="123" you get local delivery > like RouteToAlias. Excellent! >> 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. > > That shouldn't be too hard. the underlying functionality is already > there from vqueue routing. Until there is something like LuaSocket, it would be a moot feature to add anyway, at least for our use case. > What I don't like about the current implementation are 2 things: > a.) When you look at just the LUA code, its hard to see where the input > and where the output is. Its hidden in imlicitely filled variables. > > b.) The code in GnuGk to fill the inputs and read the outputs is > alraedy quite repetative and would imagine the number of variables only > grows over time. If there were a way to generically access and modify > _all_ fields of the message being routed on that would be a huge stzep > forward. But this isn't only a question of the LUA interface; the whole > routing policy mechanism would have to be rewritten for that. Understood. When we start talking about things like call branching/forking, the routing policy mechanism faces a similar challenge. > Right now, I don't need the LUA stuff for any project. I'm just toying > with it to get a feel for what a good API might look like. Ditto. We can make do with existing mechanisms for now. I'd rather "do it right" with Lua and have it take a bit longer to implement than "do it quick" and have something that doesn't cover the majority of 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/
