Re: [Openh323gk-users] calls to neighbors problem
H.323 Gatekeeper for VoIP and videconferencing
Brought to you by:
willamowius
Menu
▾
▴
Re: [Openh323gk-users] calls to neighbors problem
|
From: slesru <sl...@ya...> - 2012-02-16 03:55:04
|
--- On Wed, 2/15/12, Jan Willamowius <ja...@wi...> wrote: > From: Jan Willamowius <ja...@wi...> > Subject: Re: [Openh323gk-users] calls to neighbors problem > To: ope...@li... > Date: Wednesday, February 15, 2012, 11:11 PM > Hi, > > you didn't show your full config. Do you also have > AcceptNonNeighborLCF=1 ? If you don't specifically need it, > you should try to switch it off. > Hello! There is no such option. But, about case sensitivity. P98 is still 2.3.1. Should I try to upgrade it to 3.0.1? Thank you! > Regards, > Jan > > -- > Jan Willamowius, Founder of the GNU Gatekeeper Project > EMail : ja...@wi... > Website: http://www.gnugk.org > Support: http://www.willamowius.com/gnugk-support.html > > > slesru wrote: > > Hello! > > > > I had the same problem with gnugk 2.3, so I tested > 3.0.1 and got the same result. > > > > I have following config for 3.0.1: > > > > [RasSrv::LRQFeatures] > > NeighborTimeout=2 > > SendRetries=5 > > > > [RasSrv::Neighbors] > > > > P98=GnuGk > > NPU1=GnuGK > > > > [Neighbor::P98] > > GatekeeperIdentifier=P98 > > Host=192.168.22.254 > > SendPrefixes=* > > AcceptPrefixes=* > > ForwardLRQ=always > > > > [Neighbor::NPU1] > > GatekeeperIdentifier=NPU1 > > Host=10.1.1.1 > > SendPrefixes=* > > AcceptPrefixes=* > > ForwardLRQ=always > > > > > > One of neighbors , namely NPU1, is down. > > Usually all is OK, but sometimes gatekeeper returns > ARJ. > > > > Here is some debug info for such case: > > > > locationRequest { > > requestSeqNum = 7 > > destinationInfo = 1 entries { > > [0]=dialedDigits "6401" > > } > > nonStandardData = { > > nonStandardIdentifier = > h221NonStandard { > > t35CountryCode = > 138 > > t35Extension = 1 > > manufacturerCode > = 2 > > } > > data = 4 octets { > > 4e 50 55 31 > > > NPU1 > > } > > } > > replyAddress = ipAddress { > > ip = 4 octets { > > 0a 01 01 11 > > > .... > > } > > port = 1719 > > } > > sourceInfo = 1 entries { > > [0]=dialedDigits "6052" > > } > > canMapAlias = false > > gatekeeperIdentifier = 7 > characters { > > 0041 0053 0054 002d 004e > 0053 004b AST-NSK > > } > > callIdentifier = { > > guid = 16 octets > { > > 6f 6f 68 33 32 33 > 63 2d 51 55 54 00 00 00 00 > 22 ooh323c-QUT...." > > } > > } > > canMapSrcAlias = false > > } > > 2012/02/15 12:02:40.125 > 5 > RasSrv.cxx(251) RAS Sent > Successful > > 2012/02/15 12:02:40.125 > 2 > Neighbor.cxx(1162) NB 1 > LRQ(s) re-sent > > 2012/02/15 12:02:40.125 > 4 > RasSrv.cxx(218) RAS > Receiving on 10.1.1.17:1719(U) > > 2012/02/15 12:02:40.125 > 5 > socket.cxx(607) PTLIB > recvmsg returned error 111 > > 2012/02/15 12:02:40.126 > 1 > RasSrv.cxx(169) RAS Read > error 12/111: Connection refused > > 2012/02/15 12:02:41.115 > 2 > RasSrv.cxx(395) > ARJ|10.1.1.17:1720|6401:dialedDigits|6052:dialedDigits|false|calledPartyNotRegistered|6f-6f-68-33-32-33-63-2d-51-55-54-00-00-00-00-22; > > 2012/02/15 12:02:41.115 > 3 > RasSrv.cxx(239) RAS Send > to 10.1.1.17:13030 > > admissionReject { > > requestSeqNum = 12 > > rejectReason = > calledPartyNotRegistered <<null>> > > } > > > > Successeful call: > > > > locationRequest { > > requestSeqNum = 8 > > destinationInfo = 1 entries { > > [0]=dialedDigits "6401" > > } > > nonStandardData = { > > nonStandardIdentifier = > h221NonStandard { > > t35CountryCode = > 138 > > t35Extension = 1 > > manufacturerCode > = 2 > > } > > data = 3 octets { > > 50 39 38 > > > P98 > > } > > } > > replyAddress = ipAddress { > > ip = 4 octets { > > 0a 01 01 11 > > > .... > > } > > port = 1719 > > } > > sourceInfo = 1 entries { > > [0]=dialedDigits "6052" > > } > > canMapAlias = false > > gatekeeperIdentifier = 7 > characters { > > 0041 0053 0054 002d 004e > 0053 004b AST-NSK > > } > > callIdentifier = { > > guid = 16 octets > { > > 6f 6f 68 33 32 33 > 63 2d 51 55 54 00 00 00 00 > 22 ooh323c-QUT...." > > } > > } > > canMapSrcAlias = false > > } > > 2012/02/15 12:02:39.138 > 4 > RasSrv.cxx(218) RAS > Receiving on 10.1.1.17:1719(U) > > 2012/02/15 12:02:39.138 > 5 > socket.cxx(607) PTLIB > recvmsg returned error 111 > > 2012/02/15 12:02:39.138 > 1 > RasSrv.cxx(169) RAS Read > error 12/111: Connection refused > > 2012/02/15 12:02:39.139 > 5 > RasSrv.cxx(251) RAS Sent > Successful > > 2012/02/15 12:02:39.139 > 2 > Neighbor.cxx(1036) NB 2 > LRQ(s) sent > > 2012/02/15 12:02:39.158 > 4 > RasSrv.cxx(218) RAS > Receiving on 10.1.1.17:1719(U) > > 2012/02/15 12:02:39.158 > 2 > RasSrv.cxx(174) RAS Read > from 192.168.22.254:1719 > > 2012/02/15 12:02:39.158 > 3 > RasSrv.cxx(227) RAS > > locationConfirm { > > requestSeqNum = 8 > > callSignalAddress = ipAddress > { > > ip = 4 octets { > > c0 a8 16 fd > > > .... > > } > > port = 1720 > > } > > rasAddress = ipAddress { > > ip = 4 octets { > > c0 a8 16 fe > > > .... > > } > > port = 1719 > > } > > } > > 2012/02/15 12:02:39.158 > 2 > RasSrv.cxx(1509) RAS > Trapped LCF > > 2012/02/15 12:02:39.159 > 5 > Neighbor.cxx(1084) NB > Received LCF message matched pending LRQ for neighbor > P98:192.168.22.254 > > 2012/02/15 12:02:40.124 > 3 > RasSrv.cxx(239) RAS Send > to 10.1.1.1:1719 > > > > There are no channel problems or something other > troubles, > > gatekeeper P98 works OK. > > > > Could you tell me where is problem? > > > > Thank you! > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity > Planning > Cloud computing makes use of virtualization - but cloud > computing > also focuses on allowing computing to be delivered as a > service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________________ > > Posting: mailto:Ope...@li... > 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/ > |