Re: Problem with LRQ and LCF (GK 2.2.3-2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've got the following three scenarios. In all of them the GK don't know each other and need to ask DGK in due to establish calls between them.
 
All GKs are configured to accept calls originated only from neighbors:
 
AcceptNeighborsCalls=1
AcceptUnregisteredCalls=0
 
Scenario  A work pretty well. Clients registered on A2 and A3 can establish  calls  one another with no problem.

A)

A-1) DirectoryGK (DGK):  gnugk 2.0.9 or gnugk 2.2.3 or CISCO
A-2) GK gnugk 2.0.9
A-3) GK gnugk 2.0.9
 
On scenarios B and C it does not work.
 
I've already alternated the option "[RasSrv::Neighbors] / CiscoCompatible" to "0" and "1" on gnugk 2.0.9, and the option "[RasSrv::Neighbors] / Type" to "CiscoGK" and "GnuGK" on gnugk 2.2.3, but them keep not working.
I've noticed that LRQ and LCF are performed, but the GK which sends LCF refuses the SETUP and the call are not established.
 
B)
B-1) DirectoryGK (DGK):  gnugk 2.0.9 or gnugk 2.2.3 or CISCO
B-2) GK gnugk 2.2.3
B-3) GK gnugk 2.0.9
 
C)
C-1) DirectoryGK (DGK):  gnugk 2.0.9 or gnugk 2.2.3 or CISCO
C-2) GK gnugk 2.2.3
C-3) GK gnugk 2.2.3
 
Someone knows how can I configure scenarios B and C to work like scenario A does?
 
Regards,
 
P. Anderson
 
On 9/15/05, Zygmuntowicz Michal <m.zygmuntowicz@xxxxxxx> wrote:
If all gatekeepers forward the nonStandardData field
sent by the LRQ originator and this field is received in LCF,
no IP checking is performed (LCF is accepted).
Also (when all gatekeepers are 2.2.3), if neighbor type
is set to Cisco and LCF contains the correct nonStandardData
field (accordingly to Cisco specs), the LCF is also accepted.

----- Original Message -----
From: "Andcop2005 Andcop2005" <andcop2005@xxxxxxxxx>
Sent: Wednesday, September 14, 2005 4:33 PM


> When will be possible?
>  I have a lot of GNUGK (gatekeepers) with 1 CISCO (directory GK). And
> sometimes, I have new GK in my scenario.
>  I could write all the neighbors in GKs, but this is not reasonable.
>  Are there another way to trust GK neighbors?
>  This feature was implementation in version 2.0.9 and earlier ones. Is this
> difficult to be reimplemented? Because I am wondering to do that so my
> problem. It´s related to "h221NonStandard", isn´t it?
>  I am thinking about to compare the version 2.0.9 code to new one (2.2.3-2)
> to looking for what need to made. Do you think this reasonable?
>  On 9/14/05, Zygmuntowicz Michal < m.zygmuntowicz@xxxxxxx> wrote:
>>
>> The problem is that GK1 does not know anything
>> about GK2 and the reply is received from GK2.
>> The current implementation ignores such LCF.
>> In future versions, this scenario will be possible.
>> Also, this setup may work when all 3 gatekeepers
>> are GnuGK.
>>
>> ----- Original Message -----
>> From: "Andcop2005 Andcop2005" < andcop2005@xxxxxxxxx>
>> Sent: Tuesday, September 13, 2005 7:06 PM
>>
>>
>> I have problem with GK 2.0.9, GK 2.2.3-2 and CISCO (directory GK).
>>
>>
>> user 1 <----> GK 1 <~~~~~~~~~> GK 2 <--> user 2
>> |
>> |
>> Directory GK (CISCO)
>>
>> GK 1: version 2.2.3
>> GK 2: Version 2.0.9
>> Directory GK: CISCO
>>
>>
>> When user 1 want to call user 2 there are these steps:
>> 1 - user 1 sent messgae to GK 1
>> 2 - GK 1 sent LRQ to Directory GK
>> 3 - Directory GK sent to GK 2 after show prefix E.164 (destination E164)
>> in
>> Directory GK
>> 4 - GK 2 sent LCF to GK 1
>> 5 - After GK 1 don´t make call with GK 2
>>
>> In GK 2.2.3 I put this configuration:
>> [RasSrv::Neighbors]
>> GK1=CiscoGK
>>
>> [Neighbor::GK1]
>> GatekeeperIdentifier=CACHOEIRO
>> Host= 192.168.168.161 <http://192.168.168.161> <http://192.168.168.161/>
>> SendPrefixes=*
>> AcceptPrefixes=*
>> Dynamic=1
>> AcceptForwardedLRQ=1
>> ForwardResponse=1
>>
>> [RasSrv::ARQFeatures]
>> ArjReasonRouteCallToSCN=1
>> ArjReasonRouteCallToGatekeeper=0
>> RoundRobinGateways=1
>> ;;NeighborTimeout=1
>>
>> [RasSrv::LRQFeatures]
>> ;IncludeDestinationInfoinLCF=0
>> IncludeDestinationInfoinLCF=1
>> AcceptForwardedLRQ=1
>> CiscoGKCompatible=1
>>
>>
>> Does someone know what is wrong?
>>
>> Look my log:
>> 2005/09/13 12:31:12.624 4 RasSrv.cxx(211) RAS Receiving on 10.0.0.228:1719 <http://10.0.0.228:1719>
>> (U)
>> 2005/09/13 12:31:12.627 2 RasSrv.cxx(173) RAS Read from
>> 10.0.0.197:4879 < http://10.0.0.197:4879><http://10.0.0.197:4879/>
>> 2005/09/13 12:31:12.631 3 RasSrv.cxx(219) RAS
>> admissionRequest {
>> requestSeqNum = 10725
>> callType = pointToPoint <<null>>
>> endpointIdentifier = 9 characters {
>> 0031 0033 0030 0039 005f 0065 006e 0064 1309_end
>> 0070 p
>> }
>> destinationInfo = 1 entries {
>> [0]=dialedDigits "0212563191"
>> }
>> srcInfo = 2 entries {
>> [0]=h323_ID 6 characters {
>> 0074 0065 0073 0074 0065 0031 teste1
>> }
>> [1]=dialedDigits "11000091"
>> }
>> bandWidth = 200000
>> callReferenceValue = 8035
>> conferenceID = 16 octets {
>> a0 19 0a 3e e7 f3 18 10 8f 6f 00 40 a7 08 3c fa ...>.....o.@..<.
>> }
>> activeMC = FALSE
>> answerCall = FALSE
>> canMapAlias = TRUE
>> callIdentifier = {
>> guid = 16 octets {
>> a0 19 0a 3e e7 f3 18 10 8f 6e 00 40 a7 08 3c fa ...>.....n.@..<.
>> }
>> }
>> gatekeeperIdentifier = 9 characters {
>> 0043 0041 0043 0048 004f 0045 0049 0052 CACHOEIR
>> 004f O
>> }
>> tokens = 1 entries {
>> [0]={
>> tokenOID = 1.2.840.113548.10.1.2.1
>> timeStamp = 1126625849
>> challenge = 16 octets {
>> ec 63 9e 25 7b ba a3 9c 1d f4 e0 53 0e 12 c1 5c .c.%{......S...\
>> }
>> random = 178
>> generalID = 7 characters {
>> 0074 0065 0073 0074 0065 0031 0000 teste1
>> }
>> }
>> }
>> willSupplyUUIEs = TRUE
>> }
>> 2005/09/13 12:31:12.632 1 RasSrv.cxx(343) RAS ARQ Received
>> 2005/09/13 12:31:12.633 2 Toolkit.cxx(457) RewritePString: 0212563191 to
>> 55212563191
>> 2005/09/13 12:31:12.633 4 gkauth.cxx(2115) GKAUTH PrefixAuth rule matched
>> and accepted destination prefix 'ALL' for alias '55212563191'
>> 2005/09/13 12:31:12.634 3 gkauth.cxx(1005) GKAUTH PrefixAuth ARQ check ok
>> 2005/09/13 12:31:12.634 3 RasSrv.cxx(1948) GK ARQ will request bandwith of
>> 200000
>> 2005/09/13 12:31:12.638 3 RasSrv.cxx(231) RAS Send to 192.168.168.161:1719<http://192.168.168.161:1719 >
>> <http://192.168.168.161:1719/>
>> locationRequest {
>> requestSeqNum = 1
>> destinationInfo = 1 entries {
>> [0]=dialedDigits "55212563191"
>> }
>> nonStandardData = {
>> nonStandardIdentifier = h221NonStandard {
>> t35CountryCode = 181
>> t35Extension = 0
>> manufacturerCode = 18
>> }
>> data = "" octets {
>> 82 03 90 11 00 a0 19 0a 3e e7 f3 18 10 8f 6e 00 ........>.....n.
>> 40 a7 08 3c fa 15 02 40 05 00 74 00 65 00 73 00 @..< ...@..t.e.s.
>> 74 00 65 00 31 03 80 44 33 33 c4 t.e.1..D33.
>> }
>> }
>> replyAddress = ipAddress {
>> ip = 4 octets {
>> 92 a4 f7 e4 ....
>> }
>> port = 1719
>> }
>> sourceInfo = 1 entries {
>> [0]=h323_ID 9 characters {
>> 0043 0041 0043 0048 004f 0045 0049 0052 CACHOEIR
>> 004f O
>> }
>> }
>> canMapAlias = TRUE
>> canMapSrcAlias = FALSE
>> }
>> 2005/09/13 12:31:12.640 2 Neighbor.cxx(722) NB 1 LRQ(s) sent
>> 2005/09/13 12:31:12.676 4 RasSrv.cxx(211) RAS Receiving on 10.0.0.228:1719<http://10.0.0.228:1719 >
>> (U)
>> 2005/09/13 12:31:12.679 2 RasSrv.cxx(173) RAS Read from
>> 10.0.0.240:1719 <http://10.0.0.240:1719>< http://10.0.0.240:1719/>
>> 2005/09/13 12:31:12.683 3 RasSrv.cxx(219) RAS
>> locationConfirm {
>> requestSeqNum = 1
>> callSignalAddress = ipAddress {
>> ip = 4 octets {
>> 92 a4 f7 f0 ....
>> }
>> port = 1720
>> }
>> rasAddress = ipAddress {
>> ip = 4 octets {
>> 92 a4 f7 f0 ....
>> }
>> port = 1719
>> }
>> supportedProtocols = 1 entries {
>> [0]=voice {
>> supportedPrefixes = 4 entries {
>> [0]={
>> prefix = dialedDigits "3873"
>> }
>> [1]={
>> prefix = dialedDigits "2598"
>> }
>> [2]={
>> prefix = dialedDigits "2562"
>> }
>> [3]={
>> prefix = dialedDigits "021"
>> }
>> }
>> }
>> }
>> }
>> 2005/09/13 12:31:12.684 2 RasSrv.cxx(1255) RAS Trapped LCF
>> 2005/09/13 12:31:12.684 1 Neighbor.cxx(787) RAS Unknown reply LCF
>> 2005/09/13 12:31:12.685 4 RasSrv.cxx(211) RAS Receiving on 10.0.0.228:1719<http://10.0.0.228:1719>
>> (U)
>> 2005/09/13 12:31: 12.688 2 RasSrv.cxx(173) RAS Read from
>> 192.168.168.161:1719 <http://192.168.168.161:1719><
>> http://192.168.168.161:1719/>
>> 2005/09/13 12:31:12.688 3 RasSrv.cxx(219) RAS
>> requestInProgress {
>> requestSeqNum = 1
>> delay = 6000
>> }
>> 2005/09/13 12:31: 12.689 2 RasSrv.cxx(1255) RAS Trapped RIP
>> 2005/09/13 12:31:15.623 4 RasSrv.cxx(211) RAS Receiving on 10.0.0.228:1719<http://10.0.0.228:1719 >
>> (U)
>> 2005/09/13 12:31:15.626 2 RasSrv.cxx(173) RAS Read from
>> 10.0.0.197:4879 <http://10.0.0.197:4879 ><http://10.0.0.197:4879/>
>> 2005/09/13 12:31:15.629 3 RasSrv.cxx(219) RAS



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id…49
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/


[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux