The hardest problem with call rerouting is to maintain H.245 call state (audio channels, MSD state, TCS negotiations, ...). My experience tells me that if you hit a bad route, then the error condition usually occurs at the last switching element on the path. Therefore the gatekeeper does not received ReleaseComplete immediatelly, but first it receives CallProceeding, some Facility messages or even Alterting (although it should not...). This forces call rerouting to track/control/change the complete call state. While it is relatively easy to provide a solution that "works for me" or "usually works", it's hard to build something that can be made available for all users. But I hope we are getting close to the point, when we have current problems solved out and the codebase is flexible enough to take a next step and implement some more advanced features. ----- Original Message ----- From: "Ray Jackman" <gnugklist@xxxxxxxxx> Sent: Saturday, June 26, 2004 1:08 AM > 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/
