Hi Walter, contrary to what you say, I don't see the Cisco MX300 put "61262112650@202.158.196.141:h323_ID" into the destinationInfo. GnuGk would be able to route that with the dns policy. I only see "61262112650" and thats a local number that you can't route. Thats not a bug in GnuGk. Unrelated to your routing issues, I would remove the enum policy and EnableH46023=1 from your config. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan@xxxxxxxxxxxxxx Website: http://www.gnugk.org Support: http://www.willamowius.com/gnugk-support.html Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 archlinux@xxxxxxxxxxx wrote: > Hi Jan, > > After doing more tests, we have additional information (gnugk version 4.1): > > - URI dialling to endpoints not registered on any GK is more or less completely failing when using Polycom PVX software (this is probably the buggy Polycom endpoint you were referring to in your first response?) > > - URI dialling to not registered endpoints works with Polycom Realpresence Desktop (Windows 10 64-Bit) > > - URI dialling to not registered endpoints from Cisco MX300 G2 fails as stated below. > > There is a difference in the ACF: > > - when calling from Polycom Realpresence the unregistered endpoint appears e.g. (this is a publicly accesible test channel) in the destination info field : 61262112650@202.158.196.141:url_ID > (and here I also have a doubt because afaik Polycom syntax would be like IP##H323_alias for example) > > - calling from Cisco MX300, the same field looks like : 61262112650@202.158.196.141:h323_ID > > In the first case (Polycom Realpresence) the call is established successfully then. > In the second case (Cisco MX300) we see then ARJ (calledPartyNotRegistered) for the call. > The callsignaladdress/IP field does not contain an IP address from what I can see in the 2nd case. > > Admission request section: > > admissionRequest { > requestSeqNum = 18747 > callType = pointToPoint <<null>> > callModel = gatekeeperRouted <<null>> > endpointIdentifier = 15 characters { > 0033 0030 0037 0034 0032 0037 0037 0032 30742772 > 0031 0035 005f 0065 006e 0064 0070 15_endp > } > destinationInfo = 1 entries { > [0]=dialedDigits "61262112650" > } > srcInfo = 1 entries { > [0]=dialedDigits "OUR_ALIAS(replaced here)" > } > srcCallSignalAddress = ipAddress { > ip = 4 octets { > 0a c9 42 42 ..BB > } > port = 11113 > } > bandWidth = 38400 > callReferenceValue = 27114 > conferenceID = 16 octets { > 02 b2 1e 18 e0 1b 19 42 14 9c 00 fe c8 60 41 b0 .......B.....`A. > } > activeMC = false > answerCall = false > canMapAlias = true > callIdentifier = { > guid = 16 octets { > 02 b2 1e 18 e0 1b 19 42 14 9b 00 fe c8 60 41 b0 .......B.....`A. > } > } > willSupplyUUIEs = false > } > 2016/05/02 09:32:12.937 5 RasSrv.cxx(286) RAS Sent Successful > 2016/05/02 09:32:12.937 5 job.cxx(388) JOB Job DRQ deleted > 2016/05/02 09:32:12.937 5 job.cxx(378) JOB Worker threads: 16 total - 15 busy, 1 idle > 2016/05/02 09:32:12.937 5 job.cxx(180) JOB Starting Job ARQ at Worker thread 139876072228608 > 2016/05/02 09:32:12.937 1 RasSrv.cxx(393) RAS ARQ Received from OUR_IP_address:1719 > 2016/05/02 09:32:12.938 5 Routing.h(250) ROUTING Checking policy Internal for the request ARQ 18747 > 2016/05/02 09:32:12.938 5 Routing.h(250) ROUTING Checking policy Neighbor for the request ARQ 18747 > 2016/05/02 09:32:12.938 5 Routing.h(250) ROUTING Checking policy ENUM for the request ARQ 18747 > 2016/05/02 09:32:12.938 5 pdns.cxx(705) DNS Query aged "0.5.6.2.1.1.2.6.2.1.6.e164.arpa 35 0" > 2016/05/02 09:32:12.938 5 pdns.cxx(705) DNS Query aged "0.5.6.2.1.1.2.6.2.1.6.e164.org 35 0" > 2016/05/02 09:32:12.938 5 pdns.cxx(722) DNS SRV physical lookup "0.5.6.2.1.1.2.6.2.1.6.e164.org 35 0" > 2016/05/02 09:32:13.018 3 pdns.cxx(734) DNS Query failed: error=-1 > 2016/05/02 09:32:13.018 5 pdns.cxx(722) DNS SRV physical lookup "0.5.6.2.1.1.2.6.2.1.6.e164.arpa 35 0" > 2016/05/02 09:32:13.160 3 pdns.cxx(734) DNS Query failed: error=-1 > 2016/05/02 09:32:13.160 5 Routing.h(250) ROUTING Checking policy SRV for the request ARQ 18747 > 2016/05/02 09:32:13.160 5 Routing.h(250) ROUTING Checking policy DNS for the request ARQ 18747 > 2016/05/02 09:32:13.160 5 Routing.h(250) ROUTING Checking policy Explicit for the request ARQ 18747 > 2016/05/02 09:32:13.161 2 RasSrv.cxx(446) ARJ|10.201.66.66:1719|61262112650:dialedDigits|00417:dialedDigits|false|calledPartyNotRegistered|02-b2-1e-18-e0-1b-19-42-14-9b-00-fe-c8-60-41-b0; > 2016/05/02 09:32:13.161 3 RasSrv.cxx(266) RAS Send to OUR_IP_address:1719 > admissionReject { > requestSeqNum = 18747 > rejectReason = calledPartyNotRegistered <<null>> > } > 2016/05/02 09:32:13.161 5 RasSrv.cxx(286) RAS Sent Successful > 2016/05/02 09:32:13.161 5 job.cxx(388) JOB Job ARQ deleted > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > And our routing policy: > > [RoutedMode] > GKRouted=1 > H245Routed=1 > CallSignalPort=1720 > CallSignalHandlerNumber=10 > RemoveH245AddressOnTunneling=1 > AcceptNeighborsCalls=1 > AcceptUnregisteredCalls=1 > DropCallsByReleaseComplete=1 > SupportNATedEndpoints=1 > RemoveCallOnDRQ=1 > SendReleaseCompleteOnDRQ=1 > SupportCallingNATedEndpoints=1 > TreatUnregisteredNAT=1 > EnableH46018=1 > EnableH46023=1 > > [RoutingPolicy] > default=internal,neighbor,parent,enum,srv,dns,explicit > > [Routing::DNS] > ResolveNonLocalLRQ=1 > > [Routing::SRV] > ResolveNonLocalLRQ=1 > > [Routing::ENUM] > ResolveLRQ=1 > > > Thank you very much for your support. > > Best regards, > Walter > > > > Jan Willamowius <jan@xxxxxxxxxxxxxx> hat am 29. April 2016 um 13:02 geschrieben: > > > > Hi Walter, > > > > I don't think GnuGk 'steals' your destination IP. ;-) > > When GnuGk receives the ARQ, it prints it out as it got it before > > starting any rewrites. > > > > I remember old Polycom endpoints having a bug where the didn't transmit > > the destination IP when they were registered to a gatekeeper, but that > > should long be fixed. > > > > Can you please post the full ARQ and your RoutingPolicy config ? > > > > Did you check if your endpoint moved the IP to the > > destCallSignalAddress field in the ARQ ? > > > > Regards, > > Jan > > > > -- > > Jan Willamowius, Founder of the GNU Gatekeeper Project > > EMail : jan@xxxxxxxxxxxxxx > > Website: http://www.gnugk.org > > Support: http://www.willamowius.com/gnugk-support.html > > > > Relaxed Communications GmbH > > Frahmredder 91 > > 22393 Hamburg > > Geschäftsführer: Jan Willamowius > > HRB 125261 (Amtsgericht Hamburg) > > USt-IdNr: DE286003584 > > > > archlinux@xxxxxxxxxxx wrote: > > > > > Dears, > > > > > > We have an issue with full URI connection strings which we cannot sort out. > > > I checked this forum for similar entries but the posts I found did not really apply to our version/setup or were very old posts from years ago. If this was already dealt with I appreciate that you point me to the right place in this forum. > > > > > > The setup is gnugk 4.1 on Centos 7 self compiled. The binary is working nicely and we can set up and receive calls using E.164 numbers. URI connection strings do also work with our internal endpoints and with endpoints registered on a neighbored external gatekeeper. > > > > > > However, when we dial a full URI string like H323_alias@IP_address to any other system, non-internal, non-neighbored, this just fails with the message "system not registered with the gatekeeper". > > > In the gk log we can see > > > ... > > > admissionRequest { > > > ... > > > [0]=dialedDigits "H323_alias (without @IP address)" > > > > > > and below > > > .... > > > RAS ARQ received from our_IP > > > H460 Loaded Std 9 > > > DNS Query failed: error=-1 > > > ARJ...calledPartyNotRegistered > > > > > > It looks like gk is removing the IP address from a full URI string as in the admission request in the log appears only the H_323 alias and not the full URI string. > > > Is this the expected behavior? Or does it point to a wrong configuration on our side? > > > I thought the expected behavior was to be able to place calls with full URI strings without problems with gk registration. > > > When we remove the gk registration from the endpoint, the URI string does work as expected and calls are established. > > > > > > Any help is highly appreciated. > > > > > > Best regards, > > > Walter > ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________________ 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/
