When running 2 instances of the gnugk (different .ini files), do I only
have to differ the CallSignalPort? running a netstat -an i see that
ports 1718 and 1719 are also listening on the home IP.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 Abano, Fernando A. (ePerformax) wrote: I have found the problem, and it was not related to gnugk but to sqlbill (I am using the latest CVS). Here's that part of the radius log. I modified c_voipcall.sql from: tariffdesc TEXT NOT NULL DEFAULT '', To: tariffdesc TEXT NULL DEFAULT '', And the update went in successfully, and the call was placed. I do not know if I missed anything during my setup of the billing, or if there is indeed a bug in the postgresql.conf (which does not provide for the tariffdesc value during the insert of the start/stop) Fri Jul 30 02:39:39 2004 : Error: rlm_sql (sql): Couldn't update SQL accounting for START packet - ERROR: null value in column "tariffdesc" violates not-null constraint Fri Jul 30 02:39:39 2004 : Error: rlm_sql (sql): failed after re-connect Fri Jul 30 02:39:39 2004 : Error: rlm_sql (sql): Couldn't update SQLaccounting START record - ERROR: function throwex() does not exist Fri Jul 30 02:39:41 2004 : Error: Dropping packet from client ECPI-GK-INTERNAL:54961 - ID: 26 due to dead request 1 Fri Jul 30 02:39:43 2004 : Error: rlm_sql: Stop packet with zero session length. (user '00026b01086f', nas '203.104.94.205') Fri Jul 30 02:39:43 2004 : Error: rlm_sql (sql): failed after re-connect Fri Jul 30 02:39:43 2004 : Error: rlm_sql: Couldn't insert SQL accounting STOP record - ERROR: null value in column "tariffdesc" violates not-null constraint F -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Stewart Nelson Sent: Sunday, August 01, 2004 3:06 PM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Help Hi Fernando,I was set ProxyForNAT=1 since the start but it does not help.Sorry, I don't know what might be wrong. We have sites where ProxyForNAT works quite well, and other sites with Cisco ATA186 EPs behind various NATs, including Linksys BEFSR41 (ProxyForNAT not needed). See if it works when your EP behind the Linksys is in DMZ (try with ProxyForNAT on, and also with it off). If not, you will have to troubleshoot what is going wrong. First, is the problem related to NAT? Can you test the EP that is behind the Linksys on a public IP? If that works, it should not be hard to use a tool such as Ethereal (on both sides of the NAT if necessary) to track what packets are present, if they have correct addresses and port numbers, etc. The trace functions built into gnugk, and those that your EPs might have, may also be useful.Would you know if there is some kind of development that handles encapsulation of these packets so that they reach their destination EPs whether the EP is NATed or not? Am very new to this, but wouldn't it be nice if there is some kind of functionality that has an ability to preserve the packets even if they are inside a firewall.This is a complex issue, because H.323 has IP addresses and port numbers in both H.225 and H.245 . With simple networks, it usually works fine to put an endpoint in the DMZ of a NAT, or to configure the NAT so that the call signaling, H.245, and media packets are forwarded to the EP. There are also NATs that have an application gateway for H.323 . For more complex systems, e.g. multiple EPs behind the same NAT, you can put another GK behind the NAT, around the NAT, or have it function as the NAT. I don't know what to recommend in your case, because it appears to me that it should work as you have it set up. Maybe someone else on the list will recognize your problem; otherwise you'll have to debug it. If all else fails, use SIP ;) --Stewart ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/ ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/ |