Re: 1 IP, 2 gnugk instances

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/
  

[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux