I've confirmed that the issue is new in 3.4 by reverting my GnuGk to version 3.3 where the registrations on the child GK show up correctly. I had to modify the config slightly since 3.3 requires adding "[RasSrv::RRQFeatures] EnableAdditiveRegistration=1". Comparing the logs, the difference is in the parent GK's RCF for the 2nd endpoint's RRQ. In 3.4, the parent sends an RCF that contains both endpoints' aliases, while in 3.3 the parent's RCF only has the alias that was in the RRQ forwarded to it by the child GK from the 2nd endpoint. Abes On 03/08/2014 04:03 AM, Jan Willamowius wrote: > Its on by default for registration on the gatekeeper itself. > You have to switch it on in the [Endpoint] section if you want the > child to use it to it's parent. > > I thought your issue is the registration on the child. > > Jan > > > Abes Dabir wrote: >> Hi Jan, >> >> So if additive registrations are enabled by default, is this section of the >> manual out of date? >> >> EnableAdditiveRegistration=1 >> Default: 0 >> >> Based on my understanding of the logs in my original message, and the 2nd >> set I sent out, the endpoints are trying to register properly in terms of >> their aliases and the issue is between the parent and child, specifically >> the parent's registration confirmation for the 2nd endpoint. My knowledge >> of H.323 is limited, so it is possible that I may be missing something. I >> will try another 2 endpoints using a different stack on Monday just in case. >> >> Thanks, >> Abes >> >> >> On Fri, Mar 7, 2014 at 4:31 AM, Jan Willamowius <jan@xxxxxxxxxxxxxx> wrote: >> >>> Hi Abes, >>> >>> its strange that you see issues in the child gatekeeper. >>> >>> When I rewrote the additive registrations support for GnuGk 3.4, I made >>> it active by default, so basically everybody has it enabled and we >>> haven't had a bug report since the 3.4 release... >>> >>> I'd suggest you check your level 5 traces. >>> >>> 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 >>> >>> Abes Dabir wrote: >>>> Hi Simon, >>>> >>>> Thank you for the quick response. Unfortunately it ended up in my spam >>>> folder and took me a few days to notice. >>>> >>>> We are on the same page when it comes to the registration on the parent >>>> GK. My issue is only with registrations on the child GK, and how the >>>> 2nd endpoint registering gets the 1st endpoint's alias added to its >>>> registration. I have level 5 traces from the child GK attached to this >>>> response which I hope will help with the diagnosis. The network for this >>>> trace is slightly different than the one in the original email: >>>> >>>> Details: >>>> ===== >>>> Parent GK (name = MagorH323GK): 10.111.0.1 (internal), (there is a >>>> public interface as well, but it isn't relevant to this problem) >>>> Child GK (name = Onion): 10.111.0.4, 10.0.14.164 (internal) >>>> >>>> Endpoint 1: 2031@10.0.14.51 >>>> Endpoint 2: 1234@10.0.14.52 >>>> >>>> I first had endpoint 2031 register, then endpoint 1234. Here is what the >>>> final registration table looks like on the *_child_* GK: >>>> >>>> >>>> AllRegistrations >>>> RCF|10.0.14.51:1720 >>> |Onion:h323_ID=2031:dialedDigits=h323:2031:h323_ID|terminal|8680_endp >>>> ; >>>> RCF|10.0.14.52:1720 >>> |Onion:h323_ID=2031:dialedDigits=h323:2031:h323_ID=1234:dialedDigits=h323:1234:h323_ID|terminal|8681_endp >>>> ; >>>> Number of Endpoints: 2 >>>> ; >>>> >>>> The 2nd endpoint's registration contains both endpoints' aliases, which >>>> is causing issues. >>>> >>>> Thanks, >>>> Abes >>>> >>>> On 03/03/2014 07:09 PM, Simon Horne wrote: >>>>> Abes >>>>> >>>>> The logic is correct. The parent gk acts as a gateway for the child. >>>>> Aliases of endpoints registered to the child are added to the alias >>> list on >>>>> the parent GK for the child so calls from the outside can be routed to >>> the >>>>> child. >>>>> >>>>> Posting debug traces of the child gatekeeper with respect to the >>>>> registration issue would help diagnose that issue. >>>>> >>>>> Simon >>>>> >>>>> -----Original Message----- >>>>> From: Abes Dabir [mailto:abes.dabir@xxxxxxxxxxxxx] >>>>> Sent: 04 March 2014 06:21 >>>>> To: GNU Gatekeeper Users >>>>> Subject: Additive registrations getting mixed up on >>> child >>>>> GK >>>>> >>>>> Hi, >>>>> >>>>> I'm having issues with additive registrations and I was hoping you >>> could >>>>> help me out by either confirming a bug, or correcting any >>> misconceptions on >>>>> my part. I have a setup with a parent GK, child GK with additive >>>>> registrations turned on, and 2 endpoints behind the child. The 1st >>> endpoint >>>>> registers as I would expect. When the 2nd endpoint registers, its >>>>> registration on the child GK shows up with its alias, as well as that >>> of the >>>>> 1st endpoint: >>>>> >>>>> RCF|192.168.217.23:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h3 >>>>> RCF|23_ID|terminal|6992_endp >>>>> RCF|192.168.217.85:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h3 >>>>> RCF|23_ID=6872:dialedDigits=h323:6872:h323_ID|terminal|6993_endp >>>>> >>>>> I would expect the child GK's registration on the parent to be a >>>>> concatenated list of all the endpoints behind the child, but I would >>> expect >>>>> each endpoint's registration on the child GK to be listed >>> individually. The >>>>> behaviour is the same on versions 3.4 and 3.5. From this point on, I >>> seem to >>>>> be in a bad state and several problems can occur, such as: >>>>> >>>>> - An incoming call doesn't get routed correctly (couldn't reproduce >>> this >>>>> reliably) >>>>> >>>>> - If I restart the 1st endpoint, I keep getting registrations >>> rejections: >>>>> GCF|192.168.217.23|6836|terminal; >>>>> >>> RRJ|192.168.217.23|6836:dialedDigits=h323:6836:h323_ID|terminal|duplicat >>>>> RRJ|eAlias; >>>>> >>>>> - If I then restart the 2nd endpoint as well, I get: >>>>> >>>>> >>> RRJ|10.111.0.12|6872:dialedDigits=h323:6872:h323_ID|unknown|fullRegistra >>>>> RRJ|tionRequired; >>>>> >>> RRJ|10.111.0.12|6836:dialedDigits=h323:6836:h323_ID|unknown|fullRegistra >>>>> RRJ|tionRequired; >>>>> >>>>> >>>>> I've added all further details about my setup and the problem below. >>> If you >>>>> need any additional info, or would me to try different things, I would >>> be >>>>> happy to do so. >>>>> >>>>> Thanks, >>>>> Abes Dabir >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Details: >>>>> ===== >>>>> >>>>> Parent GK (name = MagorH323GK): 10.111.0.1 (internal), (there is a >>> public >>>>> interface as well, but it isn't relevant to this problem) Child GK >>> (name = >>>>> innie2-61): 10.111.0.4, 192.168.217.226 (internal) >>>>> >>>>> Endpoint 1: 6836@192.168.217.23 >>>>> Endpoint 2: 6972@192.168.217.85 >>>>> >>>>> >>>>> Registrations on child GK (name = innie2-61): >>>>> ============================================= >>>>> >>>>> After 6836 registers: >>>>> -------------------------- >>>>> >>>>> AllRegistrations >>>>> RCF|192.168.217.23:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h3 >>>>> RCF|23_ID|terminal|6992_endp >>>>> ; >>>>> Number of Endpoints: 1 >>>>> >>>>> >>>>> After 6872 registers: >>>>> -------------------------- >>>>> >>>>> AllRegistrations >>>>> RCF|192.168.217.23:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h3 >>>>> RCF|23_ID|terminal|6992_endp >>>>> ; >>>>> RCF|192.168.217.85:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h3 >>>>> RCF|23_ID=6872:dialedDigits=h323:6872:h323_ID|terminal|6993_endp >>>>> ; >>>>> Number of Endpoints: 2 >>>>> ; >>>>> >>>>> Registrations on parent GK (name = MagorH323GK): >>>>> ============================================= >>>>> >>>>> AllRegistrations >>>>> RCF|10.111.0.12:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h323_ >>>>> RCF|ID=6872:dialedDigits=h323:6872:h323_ID|gateway,gatekeeper|2330_endp >>>>> ; >>>>> >>>>> Child GK logs for 6872 registering: >>>>> =================================== >>>>> >>>>> The log below on the child GK show the registration request from the >>>>> endpoint (6872) coming into the child GK, the child forwarding the >>> request >>>>> to the parent, the parent responding, and the child forwarding the >>> response >>>>> to the endpoint (containing both 6872 & 6836 !!!). >>>>> >>>>> 2014/03/03 14:32:53.853 2 RasSrv.cxx(175) RAS Read >>>>> from 192.168.217.85:1719 >>>>> 2014/03/03 14:32:53.853 3 RasSrv.cxx(252) RAS >>>>> registrationRequest { >>>>> requestSeqNum = 23320 >>>>> protocolIdentifier = 0.0.8.2250.0.6 >>>>> discoveryComplete = true >>>>> callSignalAddress = 1 entries { >>>>> [0]=ipAddress { >>>>> ip = 4 octets { >>>>> c0 a8 d9 55 ...U >>>>> } >>>>> port = 1720 >>>>> } >>>>> } >>>>> rasAddress = 1 entries { >>>>> [0]=ipAddress { >>>>> ip = 4 octets { >>>>> c0 a8 d9 55 ...U >>>>> } >>>>> port = 1719 >>>>> } >>>>> } >>>>> terminalType = { >>>>> vendor = { >>>>> vendor = { >>>>> t35CountryCode = 9 >>>>> t35Extension = 0 >>>>> manufacturerCode = 61 >>>>> } >>>>> productId = 21 octets { >>>>> 46 72 65 65 53 57 49 54 43 48 20 6d 6f 64 5f 68 >>> FreeSWITCH mod_h >>>>> 33 32 33 00 00 323.. >>>>> } >>>>> 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 34 2e 30 29 00 00 lus >>> v1.24.0).. >>>>> } >>>>> } >>>>> terminal = { >>>>> } >>>>> mc = false >>>>> undefinedNode = false >>>>> } >>>>> terminalAlias = 2 entries { >>>>> [0]=dialedDigits "6872" >>>>> [1]=h323_ID 9 characters { >>>>> 0068 0033 0032 0033 003a 0036 0038 0037 h323:687 >>>>> 0032 2 >>>>> } >>>>> } >>>>> gatekeeperIdentifier = 9 characters { >>>>> 0069 006e 006e 0069 0065 0032 002d 0036 innie2-6 >>>>> 0031 1 >>>>> } >>>>> endpointVendor = { >>>>> vendor = { >>>>> t35CountryCode = 9 >>>>> t35Extension = 0 >>>>> manufacturerCode = 61 >>>>> } >>>>> productId = 21 octets { >>>>> 46 72 65 65 53 57 49 54 43 48 20 6d 6f 64 5f 68 FreeSWITCH >>> mod_h >>>>> 33 32 33 00 00 323.. >>>>> } >>>>> 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 34 2e 30 29 00 00 lus >>> v1.24.0).. >>>>> } >>>>> } >>>>> timeToLive = 30 >>>>> keepAlive = false >>>>> willSupplyUUIEs = true >>>>> maintainConnection = false >>>>> supportsAltGK = <<null>> >>>>> usageReportingCapability = { >>>>> nonStandardUsageTypes = 0 entries { >>>>> } >>>>> startTime = <<null>> >>>>> endTime = <<null>> >>>>> terminationCause = <<null>> >>>>> } >>>>> callCreditCapability = { >>>>> canEnforceDurationLimit = true >>>>> } >>>>> } >>>>> >>>>> >>>>> 2014/03/03 14:32:53.854 3 RasSrv.cxx(264) RAS Send to >>>>> 10.111.0.1:1719 >>>>> registrationRequest { >>>>> requestSeqNum = 6 >>>>> protocolIdentifier = 0.0.8.2250.0.2 >>>>> nonStandardData = { >>>>> nonStandardIdentifier = h221NonStandard { >>>>> t35CountryCode = 138 >>>>> t35Extension = 2 >>>>> manufacturerCode = 2 >>>>> } >>>>> data = 14 octets { >>>>> 49 50 3d 31 30 2e 31 31 31 2e 30 2e 31 32 IP=10.111.0.12 >>>>> } >>>>> } >>>>> discoveryComplete = true >>>>> callSignalAddress = 1 entries { >>>>> [0]=ipAddress { >>>>> ip = 4 octets { >>>>> 0a 6f 00 0c .o.. >>>>> } >>>>> port = 1720 >>>>> } >>>>> } >>>>> rasAddress = 1 entries { >>>>> [0]=ipAddress { >>>>> ip = 4 octets { >>>>> 0a 6f 00 0c .o.. >>>>> } >>>>> port = 1719 >>>>> } >>>>> } >>>>> terminalType = { >>>>> mc = false >>>>> undefinedNode = false >>>>> } >>>>> terminalAlias = 2 entries { >>>>> [0]=dialedDigits "6872" >>>>> [1]=h323_ID 9 characters { >>>>> 0068 0033 0032 0033 003a 0036 0038 0037 h323:687 >>>>> 0032 2 >>>>> } >>>>> } >>>>> gatekeeperIdentifier = 11 characters { >>>>> 004d 0061 0067 006f 0072 0048 0033 0032 MagorH32 >>>>> 0033 0047 004b 3GK >>>>> } >>>>> endpointVendor = { >>>>> vendor = { >>>>> t35CountryCode = 138 >>>>> t35Extension = 0 >>>>> manufacturerCode = 2 >>>>> } >>>>> } >>>>> keepAlive = true >>>>> endpointIdentifier = 9 characters { >>>>> 0032 0033 0033 0030 005f 0065 006e 0064 2330_end >>>>> 0070 p >>>>> } >>>>> willSupplyUUIEs = false >>>>> maintainConnection = false >>>>> additiveRegistration = <<null>> >>>>> supportsAltGK = <<null>> >>>>> supportsAssignedGK = false >>>>> } >>>>> >>>>> 2014/03/03 14:32:53.866 3 RasSrv.cxx(252) RAS >>>>> registrationConfirm { >>>>> requestSeqNum = 6 >>>>> protocolIdentifier = 0.0.8.2250.0.2 >>>>> callSignalAddress = 1 entries { >>>>> [0]=ipAddress { >>>>> ip = 4 octets { >>>>> 0a 6f 00 01 .o.. >>>>> } >>>>> port = 1720 >>>>> } >>>>> } >>>>> terminalAlias = 5 entries { >>>>> [0]=h323_ID 9 characters { >>>>> 0069 006e 006e 0069 0065 0032 002d 0036 innie2-6 >>>>> 0031 1 >>>>> } >>>>> [1]=dialedDigits "6836" >>>>> [2]=h323_ID 9 characters { >>>>> 0068 0033 0032 0033 003a 0036 0038 0033 h323:683 >>>>> 0036 6 >>>>> } >>>>> [3]=dialedDigits "6872" >>>>> [4]=h323_ID 9 characters { >>>>> 0068 0033 0032 0033 003a 0036 0038 0037 h323:687 >>>>> 0032 2 >>>>> } >>>>> } >>>>> gatekeeperIdentifier = 11 characters { >>>>> 004d 0061 0067 006f 0072 0048 0033 0032 MagorH32 >>>>> 0033 0047 004b 3GK >>>>> } >>>>> endpointIdentifier = 9 characters { >>>>> 0032 0033 0033 0030 005f 0065 006e 0064 2330_end >>>>> 0070 p >>>>> } >>>>> timeToLive = 60 >>>>> willRespondToIRR = false >>>>> maintainConnection = false >>>>> supportsAdditiveRegistration = <<null>> >>>>> } >>>>> >>>>> >>>>> 2014/03/03 14:32:53.866 2 RasSrv.cxx(1640) RAS Trapped RCF >>>>> 2014/03/03 14:32:53.867 1 RasTbl.cxx(112) New >>>>> EP|192.168.217.85:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h32 >>>>> EP|3_ID=6872:dialedDigits=h323:6872:h323_ID|terminal|6993_endp >>>>> 2014/03/03 14:32:53.867 2 gkacct.cxx(1034) GKACCT >>>>> Successfully logged event 256 for endpoint 6993_endp >>>>> 2014/03/03 14:32:53.867 2 RasSrv.cxx(422) >>>>> RCF|192.168.217.85:1720 >>> |innie2-61:h323_ID=6836:dialedDigits=h323:6836:h3 >>>>> RCF|23_ID=6872:dialedDigits=h323:6872:h323_ID|terminal|6993_endp >>>>> ; >>>>> 2014/03/03 14:32:53.867 3 RasSrv.cxx(264) RAS Send to >>>>> 192.168.217.85:1719 >>>>> registrationConfirm { >>>>> requestSeqNum = 23320 >>>>> protocolIdentifier = 0.0.8.2250.0.6 >>>>> nonStandardData = { >>>>> nonStandardIdentifier = h221NonStandard { >>>>> t35CountryCode = 138 >>>>> t35Extension = 2 >>>>> manufacturerCode = 2 >>>>> } >>>>> data = 5 octets { >>>>> 4e 6f 4e 41 54 NoNAT >>>>> } >>>>> } >>>>> callSignalAddress = 1 entries { >>>>> [0]=ipAddress { >>>>> ip = 4 octets { >>>>> c0 a8 d9 e2 .... >>>>> } >>>>> port = 1720 >>>>> } >>>>> } >>>>> terminalAlias = 5 entries { >>>>> [0]=h323_ID 9 characters { >>>>> 0069 006e 006e 0069 0065 0032 002d 0036 innie2-6 >>>>> 0031 1 >>>>> } >>>>> [1]=dialedDigits "6836" >>>>> [2]=h323_ID 9 characters { >>>>> 0068 0033 0032 0033 003a 0036 0038 0033 h323:683 >>>>> 0036 6 >>>>> } >>>>> [3]=dialedDigits "6872" >>>>> [4]=h323_ID 9 characters { >>>>> 0068 0033 0032 0033 003a 0036 0038 0037 h323:687 >>>>> 0032 2 >>>>> } >>>>> } >>>>> gatekeeperIdentifier = 9 characters { >>>>> 0069 006e 006e 0069 0065 0032 002d 0036 innie2-6 >>>>> 0031 1 >>>>> } >>>>> endpointIdentifier = 9 characters { >>>>> 0036 0039 0039 0033 005f 0065 006e 0064 6993_end >>>>> 0070 p >>>>> } >>>>> timeToLive = 60 >>>>> willRespondToIRR = false >>>>> maintainConnection = false >>>>> serviceControl = 1 entries { >>>>> [0]={ >>>>> sessionId = 0 >>>>> contents = callCreditServiceControl { >>>>> callStartingPoint = connect <<null>> >>>>> } >>>>> reason = open <<null>> >>>>> } >>>>> } >>>>> supportsAdditiveRegistration = <<null>> >>>>> } >>>>> > ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________________ 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/
