I'm trying to use a gnu gatekeeper in my DMZ to allow outside business partners to be able to make Internet video calls and reach all my cameras registered with a separate internal gatekeeper. Both gatekeepers run the 2.5.5 version. Internal Cameras <------------->Internal GW1 -----------DMZ Gatekeeper2 ---------------- Internet<---> Other BP Cameras Here is the problem. Cameras outside the DMZ can register with my DMZ gatekeeper but cannot call anyone inside my LAN. I have one camera on a work station directly connected to the Internet that is registered with my DMZ gatekeeper. This camera can make calls via IP only to cameras inside my have an internal camera (LAN) camera registered to the DMZ gatekeeper and can use h323_id to call the exterior Test camera. This camera can only call other internal cameras using an IP address. Also, I cannot get my DMZ gatekeeper to register with another DMZ gatekeeper at a partners place. I'm relatively new at this VC stuff and need a bit of help. I have attached the gnu.ini files from both gatekeepers. Any help would be greatly appreciated. ======================================================================== ==================================== [Gatekeeper::Main] This is the DMZ GateKeeper Fourtytwo=42 Name=GNUGateKeeper2 TimeToLive=1200 Home=10.x.x.x NetworkInterfaces=10.x.x.x/24;63.x.x.x/24 EndPointIDSuffix=_gk2 ;AlternateGKs=10.x.x.x:1719:false:100:gk1 SendTo:10.x.x.x:1719 SignalCallID=0 StatusTraceLevel=2 TimeStampFormat=MYSQL [RoutedMode] GKRouted=0 H245Routed=1 CallSignalPort=1721 CallSignalHandlerNumber=2 RtpHandlerNumber=2 AcceptNeighborsCalls=1 AcceptUnregisteredCalls=0 RemoveH245AddressOnTunneling=1 RemoveCallonDRQ=0 DropCallsByReleaseComplete=1 SendReleaseCompleteOnDRQ=1 SupportNATedEndpoints=1 ForwardonFacility=0 ShowForwardNumber=1 Q931PortRange=20000-20999 H245PortRange=30000-30999 SetupTimeOut=4000 SignalTimeOut=10000 AlertingTimeOut=60000 TCPKeepAlive=1 TranslateFacility=1 SocketCleanupTimeout=1000 [RoutingPolicy] H323_ID=internal,neighbor,parent,explicit,dns Default=internal,neighbor,parent,explicit,dns [Proxy] Enable=1 InternalNetwork=x.x.x.x/8 T120PortRange=40000-40999 RTPPortRange=1024-65535 ProxyForNAT=1 ProxyForSameNat=0 [RasSrv::GWPrefixes] gk1=351 gk2=353 [RasSrv::RRQFeatures] AcceptEndPointIdentifier=1 AcceptGatewayPrefixes=1 OverwriteEPOnSameAddress=0 [RasSrv::ARQFeatures] ArjReasonRouteCallToSCN=0 ArjReasonRouteCallToGateKeeper=1 CallUnregisteredEndpoints=1 RoundRobinGateways=0 [GKStatus::Auth] rule=password 127.0.0.1=password gkadmin=3d0load3S4CBO3olVdL3zw== [Gatekeeper::Auth] default=allow SQLPasswordAuth=required;RRQ SQLAliasAuth=required;RRQ SQLAuth=required;Setup,SetupUnreg gkadmin=3d0load3S4CBO3olVdL3zw== [Gatekeeper::Acct] SQLAccount=required;start,stop,update FileAcct=sufficient;stop [RasSrv::Neighbors] GK1=GnuGK ccmgr1=CiscoGK [RasSrv::LRQFeatures] NeighborTimeout=2 AcceptForwardedLRQ=0 IncludeDestinationInfoInLCF=1 ForwardResponse=0 ForwardLRQ=depends [NATedEndPoints] [Neighbor::GK1] GateKeeperIdentifier=GK1 Host=10.x.x.x Dynamic=0 SendPrefixes=* AcceptPrefixes=* AcceptForwardedLRQ=1 ForwardResponses=0 ForwardLRQ=depends [Neighbor::ccmgr1] GateKeeperIdentifier=ccmgr1 Host=10.x.x.x Dynamic=0 SendPrefixes=* AcceptPrefixes=* ForwardResponses=0 ForwardLRQ=depends [EP::GK1] GatewayPriority=100 GatewayPrefixes=351 [EP::GK2] GatewayPriority=150 GatewayPrefixes=353 [CallTable] ;GenerateNBCDR=0 ;GenerateUCCDR=1 ;DefaultCallTimeout=7200 ;DefaultCallDurationLimit=0 [EndPoint] ;Register with This Gatekeeper=x.x.x.x Type=Gateway Vendor=Cisco H323ID=ccmgr1 UnRegisterOnReload=0 NATRetryInterval=60 NATKeepAliveInterval=86400 [SimplePasswordAuth] gkadmin=password gnugk=password [password] gkadmin=password End of config ini file for DMZ ======================================================================== ==================================== ======================================================================== ==================================== Config File for Internal gatekeeper. [Gatekeeper::Main] Fourtytwo=42 Name=GNUGateKeeper TimeToLive=1200 Home=x.x.x.10 EndPointIDSuffix=_gk1 ;AlternateGKs=10.x.x.x:1719:false:150:gk2 ;SendTo=63.x.x.x SignalCallID=0 StatusTraceLevel=5 TimeStampFormat=MYSQL [GKStatus::Auth] rule=password 127.0.0.1=password gkadmin=password [LogFile] Rotate=Weekly RotateDay=Sun RotateTime=00:59 [RoutedMode] GKRouted=1 H245Routed=0 CallSignalPort=1721 CallSignalHandlerNumber=2 RtpHandlerNumber=2 AcceptNeighborsCalls=1 AcceptUnregisteredCalls=0 RemoveH245AddressOnTunneling=0 DropCallsByReleaseComplete=0 SendReleaseCompleteOnDRQ=0 SupportNATedEndpoints=1 ForwardonFacility=0 Q931PortRange=20000-20999 H245PortRange=30000-30999 SetupTimeOut=8000 SignalTimeOut=15000 AlertingTimeOut=15000 TCPKeepAlive=1 TranslateFacility=0 SocketCleanupTimeout=1000 [Proxy] Enable=0 InternalNetwork=10.x.x.x/255.x.x.x ProxyForNAT=1 [RoutingPolicy] h323_id=internal,parent,neighbor,explicit,dns,enum Default=internal,parent,neighbor,explicit,dns,enum [RasSrv::RewriteE164] [RasSrv::GWPrefixes] gk1=350,351 gk2=353,9,40 NSRHN=722 (Business Partner Gatekeeper, Nated.) [RasSrv::PermanentEndPoints] 10.x.x.x=gk2,353 10.x.x.x:1719=NSRHN,722 [RasSrv::RRQFeatures] AcceptEndPointIdentifier=1 AcceptGatewayPrefixes=1 OverwriteEPonSameAddress=1 [RasSrv::ARQFeatures] ArjReasonRouteCallToSCN=0 ArjReasonRouteCallToGateKeeper=0 CallUnregisteredEndpoints=1 RoundRobinGateways=0 [Gatekeeper::Auth] default=allow SQLPasswordAuth=required;RRQ SQLAliasAuth=required;RRQ SQLAuth=required;Setup,SetupUnreg gkadmin=password= [Gatekeeper::Acct] SQLAccount=required;start,stop,update FileAcct=sufficient;stop [RasSrv::Neighbors] GK2=GnuGK ccmgr1=CiscoGK NSRHN=Polycom [RasSrv::LRQFeatures] NeighborTimeout=2 AcceptForwardedLRQ=1 IncludeDestinationInfoInLCF=1 ForwardResponse=1 ForwardLRQ=depends [NATedEndPoints] [Neighbor::GK2] GateKeeperIdentifier=GK2 Host=10.x.x.x:1719 Dynamic=0 SendPrefixes=353,9.......,9.... AcceptPrefixes=* ForwardResponses=1 ForwardLRQ=depends [Neighbor::ccmgr1] GateKeeperIdentifier=ccmgr1 Host=10.x.x.x Dynamic=0 SendPrefixes=* AcceptPrefixes=* ForwardResponses=0 ForwardLRQ=depends [Neighbor::NSRHN] GateKeeperIdentifier=NSRHN Host=10.47.234.15:1719 Dynamic=0 SendPrefixes=722 AcceptPrefixes=* ForwardResponses=0 ForwardLRQ=depends [password] gkadmin=password ;[CallTable] ;GenerateNBCDR=TRUE ;GenerateUCCDR=TRUE ;DefaultCallTimeout=7200 ;DefaultCallDurationLimit=0 [SimplePasswordAuth] gkadmin=password gnugk=password End of Config file for internal gatekeeper. ======================================================================== ==================================== -----Original Message----- From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of openh323gk-users-request@xxxxxxxxxxxxxxxxxxxxx Sent: Monday, February 19, 2007 1:16 PM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Openh323gk-users Digest, Vol 9, Issue 22 Send Openh323gk-users mailing list submissions to openh323gk-users@xxxxxxxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/openh323gk-users or, via email, send a message with subject or body 'help' to openh323gk-users-request@xxxxxxxxxxxxxxxxxxxxx You can reach the person managing the list at openh323gk-users-owner@xxxxxxxxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of Openh323gk-users digest..." Today's Topics: 1. Re: Strange behaviour of GnuGk 2.2.5 (Alex Golyshev) 2. Re: Strange behaviour of GnuGk 2.2.5 (Zygmuntowicz Michal) ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 Feb 2007 17:48:40 +0300 From: Alex Golyshev <alex.golyshev@xxxxxxx> Subject: Re: Strange behaviour of GnuGk 2.2.5 To: GNU Gatekeeper Users <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> Message-ID: <45D9B8C8.60403@xxxxxxx> Content-Type: text/plain; charset=UTF-8; format=flowed But, from the other side: there are some cases when the problem is exists, but CPU & memory usage are at the normal level. I noticed another (?) error mesasages in debug: 2007/02/19 10:11:10.070 3 yasocket.cxx(654) Q931d xx.xx.xx.xx:1720 Error(1): Input/output error (12:32) 2007/02/19 10:11:10.070 3 ProxyChannel.cxx(4617) Proxy yy.yy.yy.yy:6306 1 forward blocked 2007/02/19 10:11:10.070 5 ProxyChannel.cxx(611) Q931d Reading from xx. xx.xx.xx:1720 2007/02/19 10:11:10.070 3 yasocket.cxx(654) Q931d xx.xx.xx.xx:1720 Error(0): Interrupted system call (10:9) They are encountered when the load of gk is pretty huge, so I suppose that these errors are also refered to the similar problem. Regards, Alex. Alex Golyshev ?????: >Michal, > >Yes, you are right. TOP said that CPU usage is about 100% > >last pid: 9257; load averages: 1.02, 1.00, 0.78 up 53+13:00:58 15:02:01 >50 processes: 2 running, 48 sleeping CPU states: 73.3% user, 0.0% nice, >26.7% system, 0.0% interrupt, 0.0% idle >Mem: 55M Active, 693M Inact, 180M Wired, 44M Cache, 110M Buf, 16M Free >Swap: 2005M Total, 84K Used, 2005M Free > >Memory is also seems to be exhasted. Is it some memory leak in gnugk? > >Other stats: > >%netstat -s -p tcp >tcp: >13644382 packets sent >8182965 data packets (1054165771 bytes) >28826 data packets (9213821 bytes) retransmitted >7753 data packets unnecessarily retransmitted 0 resends initiated by >MTU discovery >3994884 ack-only packets (1874075 delayed) 0 URG only packets 0 window >probe packets >25261 window update packets >1412446 control packets >16225442 packets received >9619140 acks (for 1051061672 bytes) >714837 duplicate acks >0 acks for unsent data >6876534 packets (706198705 bytes) received in-sequence >12175 completely duplicate packets (655564 bytes) >145 old duplicate packets >1051 packets with some dup. data (69771 bytes duped) >36363 out-of-order packets (11418118 bytes) 0 packets (0 bytes) of data >after window 0 window probes >25536 window update packets >20958 packets received after close >6 discarded for bad checksums >0 discarded for bad header offset fields 0 discarded because packet too >short >484742 connection requests >451499 connection accepts >15180 bad connection attempts >0 listen queue overflows >62 ignored RSTs in the windows >910231 connections established (including accepts) >955108 connections closed (including 7854 drops) 471100 connections >updated cached RTT on close >471438 connections updated cached RTT variance on close >205811 connections updated cached ssthresh on close >663 embryonic connections dropped >9586399 segments updated rtt (of 9156114 attempts) >56844 retransmit timeouts >253 connections dropped by rexmit timeout 0 persist timeouts 0 >connections dropped by persist timeout >502 keepalive timeouts >472 keepalive probes sent >30 connections dropped by keepalive >18391 correct ACK header predictions >4994989 correct data packet header predictions >452456 syncache entries added >2483 retransmitted >2229 dupsyn >0 dropped >451499 completed >0 bucket overflow >0 cache overflow >449 reset >193 stale >0 aborted >0 badack >315 unreach >0 zone failures >0 cookies sent >0 cookies received >1871 SACK recovery episodes >2313 segment rexmits in SACK recovery episodes >2935473 byte rexmits in SACK recovery episodes >16182 SACK options (SACK blocks) received >4508 SACK options (SACK blocks) sent >0 SACK scoreboard overflow > >%netstat -m -p tcp >7/758/765 mbufs in use (current/cache/total) 0/134/134/25600 mbuf >clusters in use (current/cache/total/max) >0/128 mbuf+clusters out of packet secondary zone in use (current/cache) >0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) >0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k >jumbo clusters in use (current/cache/total/max) 1K/457K/459K bytes >allocated to network (current/cache/total) 776457/0/0 requests for >mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo >clusters denied (4k/9k/16k) >0/8/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied >0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile >5040 calls to protocol drain routines > >I'll try to use recent CVS 2.2.6 version. Maybe it will work fine? > >Regards, >Alex. > >Zygmuntowicz Michal ?????: > > > >>Did you try to examine CPU/memory usage with top or other utility? >>One strange thing I notice is that in you log, the timeout happens >>immediatelly after connecting the socket. >> >>----- Original Message ----- >>From: "Alex Golyshev" <alex.golyshev@xxxxxxx> >>Sent: Saturday, February 17, 2007 7:14 PM >> >> >> >> >> >> >>>Hi all. >>> >>>I've found a strange bug (?) in gnugk 2.2.5. After some working time >>>gk starts to drop calls with reason 102 (Recovery from timer expiry). >>>Log tells me that gk can't establish Q931 TCP connection wih remote party: >>> >>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2946) Q931 Connect >>>to xx.xx.xx.xx:1720 from yy.yy.yy.yy:0 successful >>>2007/02/17 18:45:12.290 3 yasocket.cxx(654) Q931d >>>xx.xx.xx.xx:1720 Error(1): Input/output error (12:57) >>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2618) Q931 Timed >>>out waiting for a response to Setup message from xx.xx.xx.xx:1720 >>> >>>So looks like gk gets some bad info from destinaion.. But from that >>>moment many calls to different ip-addresses drop with the same error. >>>I calculated that there was 15% of successful calls to usual value. >>>After restarting gk returns to the normal state: calls are going >>>through with no problem. >>> >>>I'm not sure that it is a gnugk problem, maybe calls drop due to >>>tcp/ip full socket buffers etc. >>> >>>Gnugk 2.2.5, release version with the prefix prioroty patch. Failover >>>is enabled, full proxy mode. >>>OpenH323 1.18.0, PWLib 1.10.0. FreeBSD 6.1-Release. >>> >>>Does anybody have similar problems? >>> >>>Regards, >>>Alex. >>> >>> >>> >>> >>---------------------------------------------------------------------- >>--- Take Surveys. Earn Cash. Influence the Future of IT Join >>SourceForge.net's Techsay panel and you'll get the chance to share >>your opinions on IT & business topics through brief surveys-and earn >>cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV >>DEV _______________________________________________________ >> >>Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx >>Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 >>Unsubscribe: >>http://lists.sourceforge.net/lists/listinfo/openh323gk-users >>Homepage: http://www.gnugk.org/ >> >> >> >> >> >> > > > >----------------------------------------------------------------------- >-- Take Surveys. Earn Cash. Influence the Future of IT Join >SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD >EV _______________________________________________________ > >Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx >Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 >Unsubscribe: >http://lists.sourceforge.net/lists/listinfo/openh323gk-users >Homepage: http://www.gnugk.org/ > ------------------------------ Message: 2 Date: Mon, 19 Feb 2007 15:10:04 +0100 From: "Zygmuntowicz Michal" <m.zygmuntowicz@xxxxxxx> Subject: Re: Strange behaviour of GnuGk 2.2.5 To: "GNU Gatekeeper Users" <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx> Message-ID: <02a401c7542f$a8271c40$0400000a@qgamer> Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original I'd recommend observing GnuGK memory usage growth. There have been some reports about excessive memory consumption. As a temporary solution I can recommend periodic service restart during idle hours. ----- Original Message ----- From: "Alex Golyshev" <alex.golyshev@xxxxxxx> Sent: Sunday, February 18, 2007 4:56 PM > Yes, you are right. TOP said that CPU usage is about 100% > > last pid: 9257; load averages: 1.02, 1.00, 0.78 up 53+13:00:58 15:02:01 > 50 processes: 2 running, 48 sleeping > CPU states: 73.3% user, 0.0% nice, 26.7% system, 0.0% interrupt, 0.0% idle > Mem: 55M Active, 693M Inact, 180M Wired, 44M Cache, 110M Buf, 16M Free > Swap: 2005M Total, 84K Used, 2005M Free > > Memory is also seems to be exhasted. Is it some memory leak in gnugk? > > Other stats: > > %netstat -s -p tcp > tcp: > 13644382 packets sent > 8182965 data packets (1054165771 bytes) > 28826 data packets (9213821 bytes) retransmitted > 7753 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 3994884 ack-only packets (1874075 delayed) > 0 URG only packets > 0 window probe packets > 25261 window update packets > 1412446 control packets > 16225442 packets received > 9619140 acks (for 1051061672 bytes) > 714837 duplicate acks > 0 acks for unsent data > 6876534 packets (706198705 bytes) received in-sequence > 12175 completely duplicate packets (655564 bytes) > 145 old duplicate packets > 1051 packets with some dup. data (69771 bytes duped) > 36363 out-of-order packets (11418118 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 25536 window update packets > 20958 packets received after close > 6 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 484742 connection requests > 451499 connection accepts > 15180 bad connection attempts > 0 listen queue overflows > 62 ignored RSTs in the windows > 910231 connections established (including accepts) > 955108 connections closed (including 7854 drops) > 471100 connections updated cached RTT on close > 471438 connections updated cached RTT variance on close > 205811 connections updated cached ssthresh on close > 663 embryonic connections dropped > 9586399 segments updated rtt (of 9156114 attempts) > 56844 retransmit timeouts > 253 connections dropped by rexmit timeout > 0 persist timeouts > 0 connections dropped by persist timeout > 502 keepalive timeouts > 472 keepalive probes sent > 30 connections dropped by keepalive > 18391 correct ACK header predictions > 4994989 correct data packet header predictions > 452456 syncache entries added > 2483 retransmitted > 2229 dupsyn > 0 dropped > 451499 completed > 0 bucket overflow > 0 cache overflow > 449 reset > 193 stale > 0 aborted > 0 badack > 315 unreach > 0 zone failures > 0 cookies sent > 0 cookies received > 1871 SACK recovery episodes > 2313 segment rexmits in SACK recovery episodes > 2935473 byte rexmits in SACK recovery episodes > 16182 SACK options (SACK blocks) received > 4508 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > > %netstat -m -p tcp > 7/758/765 mbufs in use (current/cache/total) > 0/134/134/25600 mbuf clusters in use (current/cache/total/max) > 0/128 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > 1K/457K/459K bytes allocated to network (current/cache/total) > 776457/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/8/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 5040 calls to protocol drain routines > > I'll try to use recent CVS 2.2.6 version. Maybe it will work fine? > > Regards, > Alex. > > Zygmuntowicz Michal ?????: > >>Did you try to examine CPU/memory usage with top or other utility? >>One strange thing I notice is that in you log, the timeout happens >>immediatelly >>after connecting the socket. >> >>----- Original Message ----- >>From: "Alex Golyshev" <alex.golyshev@xxxxxxx> >>Sent: Saturday, February 17, 2007 7:14 PM >> >> >> >> >>>Hi all. >>> >>>I've found a strange bug (?) in gnugk 2.2.5. After some working time gk >>>starts to drop calls with reason 102 (Recovery from timer expiry). >>>Log tells me that gk can't establish Q931 TCP connection wih remote >>>party: >>> >>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2946) Q931 Connect >>>to xx.xx.xx.xx:1720 from yy.yy.yy.yy:0 successful >>>2007/02/17 18:45:12.290 3 yasocket.cxx(654) Q931d >>>xx.xx.xx.xx:1720 Error(1): Input/output error (12:57) >>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2618) Q931 Timed >>>out waiting for a response to Setup message from xx.xx.xx.xx:1720 >>> >>>So looks like gk gets some bad info from destinaion.. But from that >>>moment many calls to different ip-addresses drop with the same error. >>>I calculated that there was 15% of successful calls to usual value. >>>After restarting gk returns to the normal state: calls are going through >>>with no problem. >>> >>>I'm not sure that it is a gnugk problem, maybe calls drop due to tcp/ip >>>full socket buffers etc. >>> >>>Gnugk 2.2.5, release version with the prefix prioroty patch. Failover is >>>enabled, full proxy mode. >>>OpenH323 1.18.0, PWLib 1.10.0. FreeBSD 6.1-Release. >>> >>>Does anybody have similar problems? >>> >>>Regards, >>>Alex. ------------------------------ ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V ------------------------------ _______________________________________________ Openh323gk-users mailing list Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openh323gk-users End of Openh323gk-users Digest, Vol 9, Issue 22 *********************************************** ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
