As we discussed earlier, having a single LCR is fairly easy and it is a desired feature - the gatekeeper needs only to read destination information returned from a billing system (which does LCR calculation) - this way you can react on fast changing rates. Having call rerouting feature is also nice, but it raises numerous problems. It's easy to perform this using a dedicated hardware when you have a well designed, professional VoIP network. But when it comes to implement this in the gatekeeper like GnuGk, which is used very often with poor designed residential gateways, it's not so easy (especially when we still have some unsolved issues). >From my experience with call rerouting using various methods, there were always more problems than benefits from it. It usually ended up in obtaining better routes. On the other hand, I can understand that small VoIP providers cannot obtain such good routes at a good price, so the call rerouting feature comes handy. I don't want to say that this feature is not needed - if someone will provide a good implementation for this feature - I would happily commit it to the cvs. But it's not at the top of my priority list - we need first a more flexible and stable code, with some parts (like signalling) improved. Then I can think about call rerouting. Alternatively (this just came to my mind), if someone would like to take care of call rerouting), we could spawn a separate branch in the cvs for this work, and then, when everything is tested and well working, we can merge it with the main source code tree. ----- Original Message ----- From: "david winter" <dwinter@xxxxxxxxxxxxxxxxxx> To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> Sent: Friday, June 25, 2004 5:19 PM Subject: Re: least cost rounting and failed calls. > In response to your personal opinion 2. I dont know if you work in the > international voip termination game, but i do. In this game we might > have up to 30 carriers that change thier international rates on a daily > basis and are constatnly moving from 1st least cost route to a lower > placement least cost route, for thousands of possible calling codes. > Furthermore, these carriers routes into countries are constantly > failing, or filling up. As a provider to my customers I have to try and > complete their call even if my first least cost route doenst work for > whatever reason. Some calls i roll to other routes as long as my margin > is still .001 per minute, but for other programs, like calling cards, i > have to complete the call no matter what, even if i am taking a loss. so > you can see, we need to have many carriers. now if a carrier constantly > fails calls we will open tickets and maybe stop doing busniess with > them, but the need for rolling is paramount. As far as PDD, in the > international game there is a much wider latitude for acceptable PDD. > > Again, i dont know if you ARE involved in this game on a day to day > basis. if you are then i am sure you know all this as well. thanks! > > > PS: I have also noticed an increase in carriers re-mapping thier q931 > codes to prevent thier customers from seeing "network congestion","no > circuit available","unkown failure" to "user busy" or "user alerted, no > answer" in order to prevent them from getting a bad reputation for > having low capacity or poor availability. and since we deal with a lot > of smaller carriers, not just MCI SPRINT etc, they tend to do what they > can to keep our business. > > > David Winter > Senior Network Engineer > Planet-Telecom, Inc. > Tampa FL > (813)901-5182 Office > (813)864-3162 Direct > (813)817-4204 Mobile > (813)881-9762 Fax > ------------------------------------------ > AIM: mobofool > ICQ: 3563403 > MSN: dwinter@xxxxxx > Y!: vt_fool > > > > Michal Zygmuntowicz wrote: > > >To get this working (and included in the cvs) you need: > >1. Make it working with H.245 tunneling enabled/disabled. > >2. Make it working with/without fast start (reopen audio channels, etc). > >3. Make it working in full proxy mode. > >4. Make it working with various hardware platforms (each platform > > usually has some bugs/missing features that prevent call rerouting > > from working as expected). > > > >My personal opinion is: > >1. It's nice to have a simple feature that detects offline gateways > > and enables some blackout timeouts for them - quite simple and very > > useful. > >2. Having call rerouting on no circuits available (or similar error) > > usually means someone should change his provider or SLA. Besides > > it influences PDD and gives bad experience to the user. > >3. Some current issues should be solved before implementing call > > rerouting. > > > >On Fri, 2004-06-25 at 15:28, Pavel Jezek wrote: > > > >>seems to be most popular question, last time ;-) > >>I thing, that currently this feature isn't available in GNUGK 2.0.8 nor 2.2 > >>but maybe, is under development (?) > >>PJ > >> > >>----- Original Message ----- > >>From: Sait KARALAR > >>To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx > >>Sent: Friday, June 25, 2004 2:30 PM > >>Subject: least cost rounting and failed calls. > >> > >>Hi, > >> > >>Can anybody help me about least cost routing and failed calls (due to the > >>network error and/or remote endpoint not respoding and/or endpoint have > >>not enough port to handle call) > >> > >>have a solution ? > >> > >>contact with me at > >>sait at karalar.com > >>please. > >> > >>Current Version: > >>gnugk 2.0.8 (linux binary with mysql, pgsql, radius, no ldap) ------------------------------------------------------- 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/
