RE: Help

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

 




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