Ah, I see what you mean now, and as to why there was probably some confusion. See, I am doing direct Q931 Setup message from my gateways to my gatekeepers, no RAS for the initial call leg. When the call hits the gatekeeper, if the prefix matches my neighbor policy, then Gnugk creates a LRQ message and forwards that to the provider. If a LRJ comes back from the provider, Gnugk does not forward back to my gateway a LRJ or an ARJ message, it forwards instead a Q931 release complete message that I specified/changed in the source code. This way we can reroute the call when the call is sent back from the Cisco's to our DMS, since we re-route on specific codes. I have it this way because I need more freedom on my gateways, I don't want my gateways to be register to any specific gatekeepers. Otherwise all the traffic on all of my dozen of gateways would report all the call information to the gatekeepers. This can be a good thing or a bad thing depending on how your network is design or how many calls one is looking to process per server or how much management one wants the gatekeeper to deal with. For example, we have 5850 Cisco boxes with thousands of calls, some of the routes are direct routes to other gateways etc, and if I had these gateway register to my gatekeepers then all the calls regardless of where they are being routed would have to report all this information to my gatekeeper as ARQ messages. This eats up more ports and resources, and Gnugk is still a work in progress so I can't take such a huge risk and have Gnugk manage everything. Also if for some reason the Gatekeeper goes down then all routes that are set on the Gateways regardless of whether they are going directly to other gateways or using RAS would be rejected. I'm not saying this is the case for everyone, but this the case for us and how we choose to do it. Freddy -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Ray Jackman Sent: Tuesday, March 01, 2005 9:52 AM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Configuring Reject / Disconnect Cause For example, I have providers that return back > LRJ messages when they are at full capacity or not able to complete the > call for which ever reason. Most of these LRJ messages come back with > release code undefine. Which hit the part of the code where no route to > destination is set to the release code of authData.m_rejectReason = > request.GetRejectReason();. This returns a different type of release code > that we cannot re-route on. I'm not saying this is the case for everyone, > but its a specific case for us. very cleaver. good job. i dont use LRQ's to process routes that way so i have not directly seen this problem yet. i just thought that gnugk would send LRQ and if destination was found then call would go thru and if no destination was found as in LRJ then gnugk would respond with "no route to host" which my customers are able to re-route on. thanks for pointing out this situation. regards ray ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/ ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&opÌk _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49 Homepage: http://www.gnugk.org/
