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/
