Re: Routing help

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

 



I made the changes to the gatekeeper.ini file in Ottawa, NewYork and Detroit. 

The log below is from the gnugk in Detroit. It's still skipping over the Internal routing and trying to resolve a DNS.
I terminated the gnugk and restarted the process on each server after editing the gatekeeper.ini.

2011/10/04 15:46:57.773	4	    yasocket.cxx(920)	TCPSrv	Accept request on 74.199.95.14:1720
2011/10/04 15:46:57.773	5	         job.cxx(363)	JOB	Worker threads: 6 total - 6 busy, 0 idle
2011/10/04 15:46:57.773	5	         job.cxx(189)	JOB	Starting Job Acceptor at Worker thread 140419354912512
2011/10/04 15:46:57.774	5	ProxyChannel.cxx(684)	Q931s	Reading from 216.13.45.141:20000
2011/10/04 15:46:57.774	3	ProxyChannel.cxx(1023)	Q931s	Received: Setup CRV=22406 from 216.13.45.141:20000
2011/10/04 15:46:57.774	4	ProxyChannel.cxx(966)	Q931	Received: {
  q931pdu = {
    protocolDiscriminator = 8
    callReference = 22406
    from = originator
    messageType = Setup
    IE: Bearer-Capability = {
      88 18 a0 a5                                        ....
    }
    IE: Display = {
      66 72 65 64 6c 61 70 74  6f 70 00                  fredlaptop.
    }
    IE: Calling-Party-Number = {
      81 36 38 37 37                                     .6877
    }
    IE: Called-Party-Number = {
      81 35 35 38 30                                     .5580
    }
    IE: User-User = {
      20 b0 06 00 08 91 4a 00  06 01 01 80 9b aa 22 c0    .....J.......".
      09 00 00 3d 0e 54 65 73  74 20 6d 6f 64 5f 68 33   ...=.Test mod_h3
      32 33 00 00 1d 31 2e 30  61 6c 70 68 61 31 20 28   23...1.0alpha1 (
      48 33 32 33 70 6c 75 73  20 76 31 2e 32 31 2e 30   H323plus v1.21.0
      29 00 00 00 01 40 03 00  35 00 35 00 38 00 30 00   )....@..5.5.8.0.
      50 90 20 46 2f ed e0 11  9f 48 00 90 f5 99 89 f3   P. F/....H......
      00 5d 0f 80 07 00 d8 0d  2d 8d 06 b8 11 00 46 90   .]......-.....F.
      20 46 2f ed e0 11 9f 48  00 90 f5 99 89 f3 01 00    F/....H........
      01 00 13 10 00 31 00 30  00 34 00 39 00 5f 00 65   .....1.0.4.9._.e
      00 6e 00 64 00 70 01 00  01 00 02 80 01 80         .n.d.p........
    }
  }
  h225pdu = {
    h323_uu_pdu = {
      h323_message_body = setup {
        protocolIdentifier = 0.0.8.2250.0.6
        sourceAddress = 1 entries {
          [0]=dialedDigits "6877"
        }
        sourceInfo = {
          vendor = {
            vendor = {
              t35CountryCode = 9
              t35Extension = 0
              manufacturerCode = 61
            }
            productId =  15 octets {
              54 65 73 74 20 6d 6f 64  5f 68 33 32 33 00 00      Test mod_h323..
            }
            versionId =  30 octets {
              31 2e 30 61 6c 70 68 61  31 20 28 48 33 32 33 70   1.0alpha1 (H323p
              6c 75 73 20 76 31 2e 32  31 2e 30 29 00 00         lus v1.21.0)..
            }
          }
          terminal = {
          }
          mc = false
          undefinedNode = false
        }
        destinationAddress = 1 entries {
          [0]=h323_ID  4 characters {
            0035 0035 0038 0030                       5580
          }
        }
        activeMC = false
        conferenceID =  16 octets {
          50 90 20 46 2f ed e0 11  9f 48 00 90 f5 99 89 f3   P. F/....H......
        }
        conferenceGoal = create <<null>>
        callType = pointToPoint <<null>>
        sourceCallSignalAddress = ipAddress {
          ip =  4 octets {
            d8 0d 2d 8d                                        ..-.
          }
          port = 1720
        }
        callIdentifier = {
          guid =  16 octets {
            46 90 20 46 2f ed e0 11  9f 48 00 90 f5 99 89 f3   F. F/....H......
          }
        }
        mediaWaitForConnect = false
        canOverlapSend = false
        endpointIdentifier =  9 characters {
          0031 0030 0034 0039 005f 0065 006e 0064   1049_end
          0070                                      p
        }
        multipleCalls = false
        maintainConnection = false
      }
      h245Tunneling = true
    }
  }
}
2011/10/04 15:46:57.775	4	ProxyChannel.cxx(2017)	Q931s	GWRewrite source for 216.13.45.141:20000: setup H323 ID or E164
2011/10/04 15:46:57.775	5	     Routing.cxx(196)	ROUTING	Checking policy Explicit for request Setup CRV=22406
2011/10/04 15:46:57.775	5	     Routing.cxx(196)	ROUTING	Checking policy Internal for request Setup CRV=22406
2011/10/04 15:46:57.775	5	     Routing.cxx(196)	ROUTING	Checking policy SRV for request Setup CRV=22406
2011/10/04 15:46:57.775	5	     Routing.cxx(196)	ROUTING	Checking policy DNS for request Setup CRV=22406
2011/10/04 15:46:57.775	4	     Routing.cxx(604)	ROUTING	DNS policy resolves to 5580 @ 0.0.21.204:1720
2011/10/04 15:46:57.775	5	     Routing.cxx(202)	ROUTING	Policy DNS applied to the request Setup CRV=22406
2011/10/04 15:46:57.775	4	ProxyChannel.cxx(2411)	Q931s	Unregistered party is not NATed
2011/10/04 15:46:57.775	2	      RasTbl.cxx(3412)	CallTable::Insert(CALL) Call No. 2, total sessions : 1
2011/10/04 15:46:57.775	2	      gkacct.cxx(950)	GKACCT	Successfully logged event 1 for call no. 2
2011/10/04 15:46:57.775	4	ProxyChannel.cxx(4794)	Q931s	Set Called Numbering Plan 1 Type Of Number 0
2011/10/04 15:46:57.775	4	ProxyChannel.cxx(4824)	Q931s	Set Calling Numbering Plan 1 Type Of Number 0
2011/10/04 15:46:57.775	3	ProxyChannel.cxx(2862)	Q931s	Call 2 is NAT type 0
2011/10/04 15:46:57.776	1	ProxyChannel.cxx(870)	Call 2: h245Routed=1 proxy=1
2011/10/04 15:46:57.776	3	ProxyChannel.cxx(887)	GK	Call 2 proxy enabled
2011/10/04 15:46:57.776	4	ProxyChannel.cxx(966)	Q931	Send to 0.0.21.204:1720 {


The new gatekeeper.ini is listed below:

root@Jim-HDP:/var/log/gnugk# cat /etc/gatekeeper.ini 
# Template Proxy GK
#
# WAN: ip dynamic / dial-up
# LAN: IP=192.168.0.1  Network= 192.168.0.0/16
# the gatekeeper is run at the proxy machine
#
# suggested way to run the gatekeeper
# gnugk -rr -l 100 -c /etc/gnugk.ini 


[Gatekeeper::Main]
Fourtytwo=42
Name=MagorH323GK
TimeToLive=100
CompareAliasType=0
# Home=your.public.ip.addr
# TotalBandwidth=128000
#
# each G.723.1 call consume 1280 Bps.


[RoutedMode]
GKRouted=1
H245Routed=1
AcceptUnregisteredCalls=1
AcceptNeighborsCalls=1
CallSignalPort=1720
CallSignalHandlerNumber=1
RemoveH245AddressOnTunneling=1
DropCallsByReleaseComplete=1
SupportNATedEndpoints=1
SupportCallingNATedEndpoints=1
Q931PortRange=20000-20099
H245PortRange=30000-30099
SendReleaseCompleteOnDRQ=1

#[Routing::Explicit]
#10.191.20.0=192.168.216.1

[Proxy]
Enable=1
#InternalNetwork=192.168.216.0/24,10.191.20.0/24
InternalNetwork=192.168.1.0/24
T120PortRange=50000-59999
RTPPortRange=50000-59999
ProxyForNAT=1
ProxyForSameNAT=0
ProxyAlways=1

# [ModeSelection]


[RasSrv::LRQFeatures]
NeighborTimeout=6
ForwardHopCount=8
AlwaysForwardLRQ=1
IncludeDestinationInfoInLCF=1
CiscoGKCompatible=1

[RasSrv::Neighbors]
#
# List of some possible neighbors can be downloaded
# from http://www.cic.ac.id/gkregistration

[RoutingPolicy]
default=explicit,internal,srv,dns,parent,neighbor

[GkStatus::Auth]
rule=allow
# your.public.ip.addr=allow
;default=forbid

..FG..



On 2011-10-04, at 3:35 PM, Jan Willamowius wrote:

> Hi Fred,
> 
> this is your problem: Your destination isn't sent as an E.164.
> 
>>        destinationAddress = 1 entries {
>>          [0]=h323_ID  4 characters {
>>            0035 0035 0038 0030                       5580
>>          }
>>        }
> 
> You are trying to call H323ID "5580", but your endpoint is E164 "5580".
> According to the spec those are 2 different things, even so Tandberg usually
> treats them as the same.
> 
> If you want aliases to match regardless of their type, you can set in
> your config
> 
> [Gatekeeper::Main]
> CompareAliasType=0
> 
> Its still strange that the DNS policy thinks it can resolve it. I'll
> check into that when I rewrite the policy for IPv6 soon.
> 
> Regards,
> Jan
> 
> 
> Fred Gillette wrote:
>> Yup,
>> 
>> 2011/10/04 11:32:38.406	4	    yasocket.cxx(920)	TCPSrv	Accept request on 74.199.95.14:1720
>> 2011/10/04 11:32:38.406	5	         job.cxx(363)	JOB	Worker threads: 6 total - 6 busy, 0 idle
>> 2011/10/04 11:32:38.406	5	         job.cxx(189)	JOB	Starting Job Acceptor at Worker thread 139753991223040
>> 2011/10/04 11:32:38.406	5	ProxyChannel.cxx(684)	Q931s	Reading from 216.13.45.141:20024
>> 2011/10/04 11:32:38.406	3	ProxyChannel.cxx(1023)	Q931s	Received: Setup CRV=22394 from 216.13.45.141:20024
>> 2011/10/04 11:32:38.407	4	ProxyChannel.cxx(966)	Q931	Received: {
>>  q931pdu = {
>>    protocolDiscriminator = 8
>>    callReference = 22394
>>    from = originator
>>    messageType = Setup
>>    IE: Bearer-Capability = {
>>      88 18 a0 a5                                        ....
>>    }
>>    IE: Display = {
>>      66 72 65 64 6c 61 70 74  6f 70 00                  fredlaptop.
>>    }
>>    IE: Calling-Party-Number = {
>>      81 36 38 37 37                                     .6877
>>    }
>>    IE: Called-Party-Number = {
>>      81 35 35 38 30                                     .5580
>>    }
>>    IE: User-User = {
>>      20 b0 06 00 08 91 4a 00  06 01 01 80 9b aa 22 c0    .....J.......".
>>      09 00 00 3d 0e 54 65 73  74 20 6d 6f 64 5f 68 33   ...=.Test mod_h3
>>      32 33 00 00 1d 31 2e 30  61 6c 70 68 61 31 20 28   23...1.0alpha1 (
>>      48 33 32 33 70 6c 75 73  20 76 31 2e 32 31 2e 30   H323plus v1.21.0
>>      29 00 00 00 01 40 03 00  35 00 35 00 38 00 30 00   )....@..5.5.8.0.
>>      ae 4c 6c c2 0b ed e0 11  9f 45 00 90 f5 99 89 f3   .Ll......E......
>>      00 5d 0f 80 07 00 d8 0d  2d 8d 06 b8 11 00 a4 4c   .]......-......L
>>      6c c2 0b ed e0 11 9f 45  00 90 f5 99 89 f3 01 00   l......E........
>>      01 00 13 10 00 31 00 30  00 34 00 39 00 5f 00 65   .....1.0.4.9._.e
>>      00 6e 00 64 00 70 01 00  01 00 02 80 01 80         .n.d.p........
>>    }
>>  }
>>  h225pdu = {
>>    h323_uu_pdu = {
>>      h323_message_body = setup {
>>        protocolIdentifier = 0.0.8.2250.0.6
>>        sourceAddress = 1 entries {
>>          [0]=dialedDigits "6877"
>>        }
>>        sourceInfo = {
>>          vendor = {
>>            vendor = {
>>              t35CountryCode = 9
>>              t35Extension = 0
>>              manufacturerCode = 61
>>            }
>>            productId =  15 octets {
>>              54 65 73 74 20 6d 6f 64  5f 68 33 32 33 00 00      Test mod_h323..
>>            }
>>            versionId =  30 octets {
>>              31 2e 30 61 6c 70 68 61  31 20 28 48 33 32 33 70   1.0alpha1 (H323p
>>              6c 75 73 20 76 31 2e 32  31 2e 30 29 00 00         lus v1.21.0)..
>>            }
>>          }
>>          terminal = {
>>          }
>>          mc = false
>>          undefinedNode = false
>>        }
>>        destinationAddress = 1 entries {
>>          [0]=h323_ID  4 characters {
>>            0035 0035 0038 0030                       5580
>>          }
>>        }
>>        activeMC = false
>>        conferenceID =  16 octets {
>>          ae 4c 6c c2 0b ed e0 11  9f 45 00 90 f5 99 89 f3   .Ll......E......
>>        }
>>        conferenceGoal = create <<null>>
>>        callType = pointToPoint <<null>>
>>        sourceCallSignalAddress = ipAddress {
>>          ip =  4 octets {
>>            d8 0d 2d 8d                                        ..-.
>>          }
>>          port = 1720
>>        }
>>        callIdentifier = {
>>          guid =  16 octets {
>>            a4 4c 6c c2 0b ed e0 11  9f 45 00 90 f5 99 89 f3   .Ll......E......
>>          }
>>        }
>>        mediaWaitForConnect = false
>>        canOverlapSend = false
>>        endpointIdentifier =  9 characters {
>>          0031 0030 0034 0039 005f 0065 006e 0064   1049_end
>>          0070                                      p
>>        }
>>        multipleCalls = false
>>        maintainConnection = false
>>      }
>>      h245Tunneling = true
>>    }
>>  }
>> }
>> 2011/10/04 11:32:38.407	4	ProxyChannel.cxx(2017)	Q931s	GWRewrite source for 216.13.45.141:20024: setup H323 ID or E164
>> 2011/10/04 11:32:38.407	5	     Routing.cxx(196)	ROUTING	Checking policy Explicit for request Setup CRV=22394
>> 2011/10/04 11:32:38.407	5	     Routing.cxx(196)	ROUTING	Checking policy Internal for request Setup CRV=22394
>> 2011/10/04 11:32:38.407	5	     Routing.cxx(196)	ROUTING	Checking policy SRV for request Setup CRV=22394
>> 2011/10/04 11:32:38.407	5	     Routing.cxx(196)	ROUTING	Checking policy DNS for request Setup CRV=22394
>> 2011/10/04 11:32:38.408	4	     Routing.cxx(604)	ROUTING	DNS policy resolves to 5580 @ 0.0.21.204:1720
>> 2011/10/04 11:32:38.408	5	     Routing.cxx(202)	ROUTING	Policy DNS applied to the request Setup CRV=22394
>> 2011/10/04 11:32:38.408	4	ProxyChannel.cxx(2411)	Q931s	Unregistered party is not NATed
>> 2011/10/04 11:32:38.408	2	      RasTbl.cxx(3412)	CallTable::Insert(CALL) Call No. 9, total sessions : 1
>> 2011/10/04 11:32:38.408	2	      gkacct.cxx(950)	GKACCT	Successfully logged event 1 for call no. 9
>> 2011/10/04 11:32:38.408	4	ProxyChannel.cxx(4794)	Q931s	Set Called Numbering Plan 1 Type Of Number 0
>> 2011/10/04 11:32:38.408	4	ProxyChannel.cxx(4824)	Q931s	Set Calling Numbering Plan 1 Type Of Number 0
>> 2011/10/04 11:32:38.408	3	ProxyChannel.cxx(2862)	Q931s	Call 9 is NAT type 0
>> 2011/10/04 11:32:38.408	1	ProxyChannel.cxx(870)	Call 9: h245Routed=1 proxy=1
>> 2011/10/04 11:32:38.408	3	ProxyChannel.cxx(887)	GK	Call 9 proxy enabled
>> 2011/10/04 11:32:38.409	4	ProxyChannel.cxx(966)	Q931	Send to 0.0.21.204:1720 {
>> 
>> On 2011-10-04, at 11:21 AM, Jan Willamowius wrote:
>> 
>>> Can you post the Setup or ARQ that is triggering the routing process ?
>>> Then we can see which fields GnuGk tries to route on.
>>> 
>>> Regards,
>>> Jan
>>> 
>>> Fred Gillette wrote:
>>>> The plot thickens...
>>>> 
>>>> The packets are arriving at the remote gnugk but it is rejecting the incoming call. It seems that it is resolving the call to a mysterious IP address.
>>>> 
>>>> 2011/10/04 10:49:55.159 4       ProxyChannel.cxx(2017)  Q931s   GWRewrite source for 216.13.45.141:20023: setup H323 ID or E164
>>>> 2011/10/04 10:49:55.160 5            Routing.cxx(196)   ROUTING Checking policy Explicit for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 5            Routing.cxx(196)   ROUTING Checking policy Internal for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 5            Routing.cxx(196)   ROUTING Checking policy SRV for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 5            Routing.cxx(196)   ROUTING Checking policy DNS for request Setup CRV=22393
>>>> 2011/10/04 10:49:55.160 4            Routing.cxx(604)   ROUTING DNS policy resolves to 5580 @ 0.0.21.204:1720
>>>> 2011/10/04 10:49:55.160 5            Routing.cxx(202)   ROUTING Policy DNS applied to the request Setup CRV=22393
>>>> 
>>>> Here is the registration data from the console.
>>>> 
>>>> AllRegistrations
>>>> RCF|192.168.1.197:1720|5580:dialedDigits|terminal|6738_endp
>>>> Number of Endpoints: 1
>>>> 
>>>> Why would the gnugk resolve 5580 to 5580@0.0.21.204 ???
>>>> 
>>>> ..FG..
>>>> 
>>>> On 2011-10-04, at 8:36 AM, Jan Willamowius wrote:
>>>> 
>>>>> You are looking at the status port which only shows a small number of
>>>>> events. I meant you should create a GnuGk trace:
>>>>> gnugk -c <your config> -ttttt -o trace.log
>>>>> 
>>>>> After the call, trace.log will contain a lot more useful hints what
>>>>> GnuGk received and what it did with it.
>>>>> You can also enable such a trace from the status port with "setlog
>>>>> trace.log" and "debug trc 5", but the command line variant is usually
>>>>> easier.
>>>>> 
>>>>> Regards,
>>>>> Jan
>>>>> 
>>>>> Fred Gillette wrote:
>>>>>> I seem to be only able to set a trace level of 2. See below...
>>>>>> 
>>>>>> root@HDPassport1:~# telnet 192.168.217.79 7000
>>>>>> Trying 192.168.217.79...
>>>>>> Connected to 192.168.217.79.
>>>>>> Escape character is '^]'.
>>>>>> Version:
>>>>>> Gatekeeper(GNU) Version(2.3.4) Ext(pthreads=1,radius=1,mysql=1,pgsql=0,firebird=0,odbc=1,sqlite=1,large_fdset=0,crypto/ssl=1,h46018=0,h46023=1) H323Plus(1.21.0) PTLib(2.6.7) Build(Jul 14 2011, 15:16:35) Sys(Linux x86_64 2.6.32-26-generic)
>>>>>> Startup: Mon, 03 Oct 2011 08:23:32 -0400   Running: 0 days 23:36:58
>>>>>> ;
>>>>>> trace 5
>>>>>> Syntax Error: trace 0|1|2|"min"|"max"
>>>>>> trace max
>>>>>> Output trace level is 2
>>>>>> ACF|192.168.217.53:1720|1049_endp|22388|h323:5580@74.199.95.14:url_ID|6877:dialedDigits|false|ce-ea-1b-4a-ee-ec-e0-11-9f-44-00-90-f5-99-89-f3;
>>>>>> DCF|192.168.217.53|1049_endp|22388|normalDrop|ce-ea-1b-4a-ee-ec-e0-11-9f-44-00-90-f5-99-89-f3;
>>>>>> 
>>>>>> I'm trying to call 5580@74.199.95.14.
>>>>>> 
>>>>>> ..FG..
>>>>>> 
>>>>>> On 2011-10-03, at 7:36 PM, Jan Willamowius wrote:
>>>>>> 
>>>>>>> You should do a level 5 trace for that call to see which policy GnuGk
>>>>>>> chooses to route the call and which IP it tries to forward the Setup to.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Jan
>>>>>>> 
>>>>>>> ajgillette98 wrote:
>>>>>>>> 
>>>>>>>> I added the suggested entries in my gatekeeper.ini, but there seems to me no
>>>>>>>> difference.
>>>>>>>> If I try to call an H.323 endpoint external to my gnugk with an ip address
>>>>>>>> everything works. 
>>>>>>>> If I try to call with an extension and an IP the gnugk does not relay the
>>>>>>>> setup message. 
>>>>>>>> 
>>>>>>>> I did a wireshark trace and saw the admission request, followed by the
>>>>>>>> admission confirm.
>>>>>>>> Then the setup followed by a release complete. When I dig into the release
>>>>>>>> complete I get
>>>>>>>> a cause value of "No route to destination (3)".
>>>>>>>> 
>>>>>>>> If I try calling by IP without the extension the messages go out the public
>>>>>>>> NIC of the gnugk
>>>>>>>> but the far end does not know which endpoint I want to call.
>>>>>>>> 
>>>>>>>> ..FG..
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Willamowius wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> if you want GnuGk to resolve DNS names eg. in URLs, you should include
>>>>>>>>> the dns and srv policy in your config. I usually suggest this:
>>>>>>>>> 
>>>>>>>>> [RoutingPolicy]
>>>>>>>>> default=explicit,internal,srv,dns,internal,parent,neighbor 
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Jan
>>>>>>>>> 
>>>>>>>>> ajgillette98 wrote:
>>>>>>>>>> 
>>>>>>>>>> Hey Guys,
>>>>>>>>>> I have gnugk working great for calls to devices on the Internet but
>>>>>>>>>> when
>>>>>>>>>> I call gnugk to gnugk I get "calledPartyNotRegistered". I suspect that I
>>>>>>>>>> don't understand some aspect of routing? This seems to only happen when I
>>>>>>>>>> am
>>>>>>>>>> trying to call a URL xxxx@x.x.x.x if I call an ip address everything is
>>>>>>>>>> fine. 
>>>>>>>>>> 
>>>>>>>>>> My gatekeeper.ini file has the following:
>>>>>>>>>> 
>>>>>>>>>> [RoutedMode]
>>>>>>>>>> GKRouted=1
>>>>>>>>>> H245Routed=1
>>>>>>>>>> AcceptUnregisteredCalls=1
>>>>>>>>>> AcceptNeighborsCalls=1
>>>>>>>>>> CallSignalPort=1720
>>>>>>>>>> CallSignalHandlerNumber=1
>>>>>>>>>> RemoveH245AddressOnTunneling=1
>>>>>>>>>> DropCallsByReleaseComplete=1
>>>>>>>>>> SupportNATedEndpoints=1
>>>>>>>>>> SupportCallingNATedEndpoints=1
>>>>>>>>>> Q931PortRange=20000-20099
>>>>>>>>>> H245PortRange=30000-30099
>>>>>>>>>> SendReleaseCompleteOnDRQ=1
>>>>>>>>>> 
>>>>>>>>>> [Proxy]
>>>>>>>>>> Enable=1
>>>>>>>>>> InternalNetwork=192.168.216.0/24,10.191.20.0/24
>>>>>>>>>> T120PortRange=50000-59999
>>>>>>>>>> RTPPortRange=50000-59999
>>>>>>>>>> ProxyForNAT=1
>>>>>>>>>> ProxyForSameNAT=0
>>>>>>>>>> ProxyAlways=1
>>>>>>>>>> 
>>>>>>>>>> [RoutingPolicy]
>>>>>>>>>> default=explicit,internal
> 
> -- 
> Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________________
> 
> Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
> Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
> Homepage: http://www.gnugk.org/


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/


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

  Powered by Linux