In my experience, rerouting does not help all that much. I use an ITSP that has very sophisticated rerouting. They do *not* proxy the media stream. In general, that's a good thing, because a media proxy adds significant delay and jitter to the call. If I'm calling Hong Kong from Japan, and the proxy is on the US east coast, that's bad. Also, proxy takes lots of bandwidth, which ultimately means higher prices. Unfortunately, if the media stream is not proxied, then the H.245 needs to get renegotiated on most reroutes. Many gateways don't handle this properly, especially if the codec changes. Also, there is no way for the provider to detect lack of incoming audio, or severe packet loss. Many rerouting decisions are triggered by timeouts. If these are conservative, the PDD is so long, that my users generally hang up before the call goes through. If they are short, you often have a situation where the called phone is ringing, or even answered, from the first attempt, and the second try just gets a busy. So a call that would have been fine without rerouting is blocked, and you have an annoyed callee as well :( When my users call Paris, they expect to hear a European ring tone, and usually do. When the ITSP reroutes through a UK carrier, who supplies a UK ringing tone during Alerting, then the user thinks that he must have dialed incorrectly and hangs up. IMHO, it would be better to do a good job tracking which routes are having problems, so that subsequent callers can avoid them. --Stewart ----- Original Message ----- From: "Zygmuntowicz Michal" <m.zygmuntowicz@xxxxxxx> To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> Sent: Saturday, June 26, 2004 2:13 AM Subject: Re: least cost rounting and failed calls. > 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 ------------------------------------------------------- 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/
