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/
