RE: LRJ from Cisco Gk

"Freddy Parra" <fparra@xxxxxxxxxx> · Fri, 16 Jul 2004 10:41:31 -0400

Hi,

I 
spoke to one of my providers that had told me recently that Gnugk was 
working fine with his 7200 Cisco Gatekeeper, which I had posted on this 
list as working. Well it turns out that this is not the case, and its 
actually a 7206 Gatekeeper which I have problems with like the 
other Provider Gatekeeper I am having problems with too. I"m actually sending 
traffic to his Cisco Gatekeepers 3640 and 3660 which work fine. He says that he 
has many interpretability problems with Nextone and Gnugk sending to the 
7206 Cisco Gatekeeper. I just like to clarify that mistake. 

Here 
is some info I came across when conducting some test with one of my Provider's 
7206 Cisco Gatekeeper:

I 
got Gnugk to receive back a LCF instead of a LRJ from my 
provider's 7206 Cisco Gatekeeper.What I did was install 
ohphone and registered it with Gnugk with the same gatekeeper 
identifier as Gnugk. This works I don't know why but look at the 
sourceInfo and gatekeeperIdentifier parameters below, 
they must both be gatekeeper identifier id's which my 
provider has set in their Cisco's Gatekeeper. Now if I register the 
terminal with any other id that's not in the providers 
configuration list I get LRJ as is the case with my Cisco since I have it 
set to an H323-id of AS5400MIA.  But this should not matter(or should it?) 
for sourceinfo or does the Cisco gatekeeper look at this sourceinfo also to 
determine access? I guess the bottom line here is whether sourceinfo plays a 
role in determining whether I get back a LCF or a LRJ, which seems to be the 
case here for the 7206 Gatekeeper.

If 
this is the case then I can see two solutions to this 
problem:

1.) 
The provider must add all my gateway endpoint h323-ids in there 
configuration along with my gatekeeper identifier . 
2.) Change the sourceinfo to be the same 
as the Gatekeeper Identifier before forwarding the LRQ to the Provider's 
Gatekeeper, but I'm not sure what impact this will have on other different 
types of Gatekeeper.

I 
could not test this with any of my Cisco's since that would had required me 
to change my Cisco's h323 Id to the gatekeepers identifier and 
currently I am running live traffic on it. 

Ex:

2004/07/15 17:43:16.961 
1             
RasSrv.cxx(1447)  GK      ARQ 
Received
2004/07/15 17:43:16.962 
3             
RasSrv.cxx(2374)  GK      Send to 
xxx.xxx.xxx.xxx:1719
locationRequest {
    requestSeqNum = 
363
    destinationInfo = 1 entries 
{
      [0]=dialedDigits 
"xxxxx#xxxxxxx"
    }
    nonStandardData = 
{
      nonStandardIdentifier = h221NonStandard 
{
        t35CountryCode = 
181
        t35Extension = 
0
        manufacturerCode = 
18
      }
      data 
="" 5 octets {
        67 6e 75 67 
6b                                     
gnugk
      }

}
    replyAddress = ipAddress 
{
      ip =  4 octets 
{
        d8 7f 7f 
e7                                        
....
      }
      port 
= 1719
    }
    sourceInfo = 1 entries 
{
      [0]=h323_ID  11 characters 
{
        004e 0055 004d 0049 004e 0044 
0047 004b   NUMINDGK

0032 0033 
0031                            
231
      }

}
    canMapAlias = TRUE

gatekeeperIdentifier =  11 characters {

004e 0055 004d 0049 004e 0044 0047 004b   
NUMINDGK
      0032 0033 
0031                            
231
    }
    canMapSrcAlias = 
FALSE
  }
2004/07/15 17:43:16.962 
5             
RasSrv.cxx(2388)  GK      Sent 
Successful
2004/07/15 17:43:16.962 
2             
RasSrv.cxx(447)   GK      Send LRQ to 1 
neighbor(s)
2004/07/15 17:43:17.029 
2             
RasSrv.cxx(2434)  GK      Read from 
xxx.xxx.xxx.xxx:1719
2004/07/15 17:43:17.029 
3             
RasSrv.cxx(2447)  GK
locationConfirm {

requestSeqNum = 363
    callSignalAddress = ipAddress 
{
      ip =  4 octets 
{
        xxx xxx xxx xxx                                        
..J.
      }
      port 
= 1720
    }
    rasAddress = ipAddress 
{
      ip =  4 octets 
{
        xxx xxx xxx xxx                                        
..J.
      }
      port 
= 55465
    }
    nonStandardData = 
{
      nonStandardIdentifier = h221NonStandard 
{
        t35CountryCode = 
181
        t35Extension = 
0
 manufacturerCode = 18

}
      data ="" 85 octets 
{
        00 01 40 04 00 69 00 70  00 
32 00 69 00 70 24 00   ..@..i.p.2.i.p$.

6e 00 6f 00 76 00 61 00  67 00 6b 00 32 00 2e 00   
.o.v.a.g.k.2...
        6e 00 6f 00 76 00 
61 00  74 00 65 00 6c 00 2e 00   
n.o.v.a.t.e.l...
        63 00 6f 00 6d 01 
00 01  40 04 00 69 00 70 00 32   c.o.m...@..i.p.2

00 69 00 70 00 ce a9 4a  98 06 b8 00 00 00 00 00   
.i.p...J........
        00 00 00 00 
00                                     
.....
      }

}
    destinationInfo = 1 entries 
{
      [0]=dialedDigits 
"xxxx#xxxxx"
    }
    destinationType = 
{
      gateway = 
{
      }
      mc = 
FALSE
      undefinedNode = 
FALSE
    }
  }
2004/07/15 17:43:17.029 
1             
RasSrv.cxx(2218)  GK      LCF 
Received

Regards,

Freddy

  -----Original Message-----
From: 
  openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx 
  [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of Glen 
  Sykes
Sent: Tuesday, July 13, 2004 5:19 PM
To: 
  openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Subject: RE: 
   LRJ from Cisco Gk

  It has just occured to me that the problem may be in the 
  way that the Cisco CK is handling your zone prefix.

  There are 2 ways that the Cisco GK handles zone prefixes, 
  either with a fixed or variable number of digits that follow the zone prefix 
  definition.

  For example, the zone prefix statement 'zone prefix GNUGK 
  12345*' Would imply that your GNUGK could supply any length of digits in the 
  source E.164 address.

  However, if the Cisco config were 'zone prefix GNUGK 
  12345.....', then this would imply that you could only use E.164 numbers in 
  your zone with a maximum of 10 digits, inclusive of the 12345 zone 
  prefix.

  It's worth checking that your parent or neighbour GK are 
  configured to allow variable length E.164 by use of the * at the end of the 
  configured zone prefix.

  Hope this helps,

  Glen

  From: Freddy Parra [mailto:fparra@xxxxxxxxxx] 

Sent: 13 July 2004 00:36
To: 
  openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Subject: RE: 
   LRJ from Cisco Gk

  Glen,

  I just spoke to 
  one of my providers that uses a Cisco Gatekeeper and which I have no 
  problems with and got the following spec info from him. 

  Cisco Internetwork 
  Operating System Software

  IOS (tm) 7200 
  Software (C7200-IS-M), Version 12.2(15)T5,  RELEASE SOFTWARE 
  (fc1)

  TAC Support: http://www.cisco.com/tac

  Compiled Wed 
  11-Jun-03 19:39 by eaarmas

  Image text-base: 
  0x60008954, data-base: 0x61BF0000

  ROM: System 
  Bootstrap, Version 12.2(4r)B2, RELEASE SOFTWARE (fc2)

  BOOTLDR: 7200 
  Software (C7200-KBOOT-M), Version 12.2(15)T5,  RELEASE SOFTWARE 
  (fc1)

  cisco 7206VXR 
  (NPE400) processor (revision A) with 245760K/16384K bytes of 
  memory.

  Processor board ID 
  29497839

  R7000 CPU at 
  350Mhz, Implementation 39, Rev 3.3, 256KB L2, 4096KB L3 
  Cache

  6 slot VXR 
  midplane, Version 2.7

  I have no problems 
  with this gatekeeper when I set his gatekeeper in 
  Gnugk as a neighbor or as being a parent to 
  my Gnugk. It works great. Now, the other provider that's 
  running a 7206 but with the same IOS version is the one I have problems 
  sending traffic to. I asked the provider that I do not have problems with 
  about their configuration and he stated the 
following:

  They do not configure anything to give you access to our DGK. 
  Only the tech prefix.

      You are the one that make the configuration on 
  your side to send traffic.

      The configuration lines you sent me are used in 
  case I send traffic to you...which is not our 
  case.

  Now I'm not sure how the tech prefix 
  configuration he specified must be configured in his Cisco Gatekeeper. 
  But the fact that I have no problems 
  with a Cisco 7200 Gk but do with 7206 both using same Cisco IOS 
  version makes me think that this might just be a Cisco Gatekeeper 
  configuration issue on the 7206 and not Interpretability problems. 

  Freddy

  -----Original 
  Message-----
From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx 
  [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of Glen 
  Sykes
Sent: Monday, July 12, 2004 5:50 PM
To: 
  openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Subject: RE: 
   LRJ from Cisco Gk

    Hi Freddy,

    I have not managed to get this to work yet 
    either.  I did post something along the lines of what you have put 
    a while ago but no reply.

    I am looking to integrate GNUGK as a child GK to a 
    parent Cisco GK but have not been able to test this yet.

    However I would recommend that the Cisco GK is upgraded 
    to 12.3(7) or (8), for no other reason that it the more recent version 
    supports H.323 version 4.

    Has the GNUGK been tested for interop with Cisco 
    GK's?

    Cheers,

    Glen

    From: Freddy Parra 
    [mailto:fparra@xxxxxxxxxx] 
Sent: 12 July 2004 18:33
To: 
    openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Subject: RE: 
     LRJ from Cisco Gk

    Glen,

    Thanks for your reply. I verified the following configuration with 
    the provider, and they say this is exactly how they have it. 

    But this still does not work, it still gives LRJ and the 
    provider also has problems sending calls to gnugk. Just so that 
    you know they are currently running a Cisco Gatekeeper 
    on a 7206 12.2(15)T5.

    Has anyone gotten a 7206 Cisco gatekeeper to work with gnugk as a 
    neighbor? 

    Freddy

      -----Original Message-----
From: 
      openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx 
      [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of 
      Glen Sykes
Sent: Friday, July 09, 2004 11:58 
      AM
To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Subject: 
      RE:  LRJ from Cisco Gk

      Have you defined the GNUGK as a remote zone in the 
      Cisco Config?

      i.e.

      "zone remote GNUGK domain.com [ip address of 
      GNUGK]"

      also you will need to tell the cisco GK of the zone 
      prefix associated with the GNUGK with the command "zone prefix GNUGK 
      12345*"

      The text in italics indicate the H.323 name of the 
      zone associated with the GNUGK.

      Hope this helps, 

      Glen

      From: Freddy Parra 
      [mailto:fparra@xxxxxxxxxx] 
Sent: 09 July 2004 
      16:35
To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Cc: 
      openh323gk-developer@xxxxxxxxxxxxxxxxxxxxx
Subject: 
       LRJ from Cisco Gk

      Hi,

      I am getting 
      the following LRJ message from a cisco gatekeeper that I have setup 
      in gnugk as a neighbor gk.

      2004/07/08 
      16:29:30.793 1       
      RasSrv.cxx(1413) GK ARQ Received
2004/07/08 
      16:29:30.793 4       
      gkauth.cxx(473) GkAuth default check ok
2004/07/08 
      16:29:30.793 3       
      RasSrv.cxx(2340) GK Send to 
      xxx.xxx.xxx.xxx:1719
      locationRequest {

      requestSeqNum = 563
    destinationInfo = 1 entries 
      {
      [0]=dialedDigits 
      "0723#0115034112222"
    }

      nonStandardData = {

      nonStandardIdentifier = h221NonStandard 
      {
        t35CountryCode = 
      181
        t35Extension = 
      0
        manufacturerCode = 
      18
      }

      data ="" 5 octets {
        67 
      6e 75 67 
      6b                                     
      gnugk
      }

      }
    replyAddress = ipAddress 
      {
      ip =  4 octets 
      {
        xx xx xx xx                                        
      ....
      }

      port = 1719
    }
    sourceInfo = 1 
      entries {
      [0]=h323_ID  9 characters 
      {
        0041 0053 0035 0034 0030 
      0030 004d 0049   
      AS5400MI

      0041                                      
      A
      }

      }
    canMapAlias = TRUE

      gatekeeperIdentifier =  11 characters 
      {
      004e 0055 004d 0049 004e 0044 0047 
      004b   NUMINDGK
      0032 0033 
      0032                            
      232
    }
    canMapSrcAlias = 
      FALSE
  }

2004/07/08 16:29:30.794 5       
      RasSrv.cxx(2354) GK Sent Successful
2004/07/08 
      16:29:30.794 2       
      RasSrv.cxx(447) GK Send LRQ to 1 neighbor(s)
2004/07/08 
      16:29:30.858 2       
      RasSrv.cxx(2400) GK Read from xxx.xxx.xxx.xxx:1719
2004/07/08 
      16:29:30.858 3       RasSrv.cxx 
      locationReject 
      {
    requestSeqNum = 563

      rejectReason = notRegistered <<null>>

      }

      2004/07/08 
      16:29:30.859 3       
      RasSrv.cxx(2340) GK Send to 
      xxx.xxx.xxx.xxx:49799
admissionReject {

      requestSeqNum = 48921
    rejectReason = 
      calledPartyNotRegistered <<null>>

      }

      I know that if 
      your setting up gk to gk communication, there is no registration needed 
      between both gatekeepers. So the reason code doesn't
      make any sense 
      to me. Does anyone have any idea what could be the most 
      likely cause of getting a notRegistered LRJ message from a cisco 
      gatekeeper.
      Thanks. 

      Regards,

      Freddy