Hey Guys,
Got side tracked for a few days but I need to get back to this problem.
I have set the CompareAliasType=0 and I still can't call between two gnugk's.
Here is my gatekeeper.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.216.0/24,10.191.20.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,internal,parent,neighbor
[GkStatus::Auth]
rule=allow
# your.public.ip.addr=allow
;default=forbid
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 )[email protected].
>> 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 [email protected] ???
>>>>
>>>> ..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:[email protected]: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 [email protected].
>>>>>>
>>>>>> ..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 [email protected] 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, [email protected], 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:[email protected]
> 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-d2d-oct
_______________________________________________________
Posting: mailto:[email protected]
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/
