i think the interesting part about call re-routing is that it will have to be taken in small steps. from my experience when gnugk tries to set up a call with a remote GW if the GW sends back an ISDN message like release complete before alerting or no circuit/no channel i can imagine that gnugk could re-process this call to another provider with only small delays. i think the larger problem is going to be to determine what additional conditions require re-routing and how to granulate and specify them. i dont imagine that even the radius routing would be able to handle this unless if gnugk would send a second setup request to radius and then radius then sends a second route that is to be considered. this would pass the responsibility to re-route the call from the gnugk to the radius implementation. since there is call id information then it would be up to radius client to identify that it already sent a route and it failed via a second request and either provide another route or just send a reject message back. in the adventure to develop re-routing then we will see the transformation of the gnugk to be then a softswitch. i have participated in the project for about a year now and i have seen great and very important changes and i am proud to have been witness to it, great job michal.. regards ray ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
