For something like acd does the h323-redirect-number=18005551234 h323-redirect-number=CUST_REPR_05 values would fit. In case if you need something like one number and many representatives, then we put a permanent endpoint CUST_REPR, and a call goes to it, on admission request, radius that knows what repr is busy on not tels that the call should go to h323-redirect-number=CUST_REPR_05 gnugk understands this request and redirects it. If CUST_REPR_05 by some reason sends ARJ then gnugk sends admission-request to radius again while caller is on hold.. Radius then keeps a hash for this particular group and knows who's talking. That's alredy beyond the scope of gnugk, and we don't need to wory about that :)) When CUST_REPR_05 registers to gk, on addmission request radius puts a mark for itself that CUST_REPR_05 is supposed to be available, when CUST_REPR_05 is in a call, radius also marks it as in a call. That's possibly something someone would need in a real life. Second possible situation, for example we have a database of prefixes, and gateways. When radius receives a request on ARQ it checks the contents of Called-Station-Id, retrives somehow the record for the gateway based on the dialed digits, calculates all prices, authorizes and authenticates the user, ... and then depending of what one needs radius to tell gnugk, radius sends h323-redirect-ip-address=1.22.33.44. Which should be trated as a permanent endpoit's ip. The call is then routed to calledId@xxxxxxxxxx, or if the radius responce also contains h323-redirect-number then the called number is rewritten to the new number. This is particulary useful for lagre companies where they maintain a long list of destination gateways where every terminating party has its own sick rules on rewriting dialed e164. Very useful - all you need is to modify a record in the database and voalia, you do not need to restart, or send hup to gnugk... You don't even need to know that gnugk is somewhere sitting in your office. That's very similar to what I modified in my gnugk. With all this gnugk becomes even simplified, not complicated. I've heard cisco also uses some sort of scripting language to control all the logic on their equipment? :))) hehe, just joking. It's not difficult to add perl module (tcl, python, ruby) to gnugk to do all that, but in this case it becomes decentralized. Solution... radius. The last question... How do I make radius do all that? There are many solutions, the easiest and probably the most unflexible is to use external script in radius. For more advanced tasks persisetnt perl is very suitable (I use it and happy with it). It's all only my opinions etc, hopefully it will be a startpoint to your new ideas on how to improve gnugk. > In general, it would be good to agree on which attributes (and how) should be used > for call routing. Good idea is to use standard attributes, like the ones mentioned (h323-redirect-xxx). > > ----- Original Message ----- > From: "P. P." <block111@xxxxxxx> > Sent: Monday, March 01, 2004 11:32 PM > > > > > Alexandre Aractingi <aaractingi@xxxxxxxxxxxxxx> wrote: > > > >Le lun 01/03/2004 Ю 13:42, Zygmuntowicz Michal a Иcrit : > > > >> These are virtual queues and RoutingRequest messages. You can > > > >> take a look at the ACD application how it is done. > > > > > > > >Ok, I see what you mean. But it\'s not possible (yet) to always let an > > > >external app make the routing decisions (on "regular" calls), right? > > > > Hello, > > I wrote some simple billing applicaation and from there it appeared to be very easy to control everything I needed to control. All > sorts of routing logic is just not simple to control through some configuration (some people might have crazy ideas, and they'll > always be asking "..how to do this and that?..") > > That's why I think it's a good decision to move this logic to radius. Everything is controlled from a compiled perl script - all > types of database handling etc are possible as well, just the way with usual perl script. So, I really think it's a very good > decision to go radius way :)) > > Maybe interested people post their suggestions, so that someone could implement it. > > In my opinion all is needed is proper handling of h323-gw-id, h323-redirect-ip-address, Cisco-Gateway-Id, h323-redirect-number. > With all above mentioned complexity reduces greatly as all the complex stuff is easy to manage through perl scripts. > > It's only my opinion... > > I could contribute on that, but I'm very unfamiliar with the way gnugk works, and all its internals - I broke all my bones while > trying to add simple stuff I needed :) And as I checked, 2.2 version differs considerably from 2.0.7 > > > > > If calling endpoints are registered with the gatekeeper and support > > > canMapAlias feature, it is possible to configure a virtual queue > > > to intercept all calls and make routing decisions. This technique > > > does not suit all situations, but, if used smartly, can be quite powerful. > > > > > > Soon we will have a similar, but a bit more advanced way > > > to make routing decision through RADIUS. > > > > > > Regards, > > > Michal > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id56&alloc_id438&opюick > _______________________________________________ > List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > Archive: http://sourceforge.net/mailarchive/forum.php?forum_id 49 > Homepage: http://www.gnugk.org/ > ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
