S8XXX, CM: Configuring Avaya Communication Manager H.323/LRQ Trunks in a Cisco Multi-Gatekeeper Environment

Doc ID    SOLN119557
Version:    2.0
Status:    Published
Published date:    30 Jan 2014
Created Date:    19 Oct 2007
Author:   
sdoron
 

Details

Communication Manager all versions

Cisco Directory Gate Keeper

Cisco Regional Gatekeeper

 

Problem Clarification

Incoming calls from Cisco are not getting through.
CIsco GK send LRQ (location Requests) but CM does not reply with LCF (Location Confirmed) messages.
Outgoing calls from Communication Manager are working correctly.
This is a typical working call flow:
 
• Call is initiated by the Cisco client
• The Cisco GW will send a RAS message to the Cisco GK.
• The Cisco GK will send an LRQ request to the Cisco DKG.
• The Cisco DGK will forward the LRQ request to Avaya Communication Manager.
• CM will send an LCF back to the Cisco GK. The LCF message includes the CMIP address for call setup.
• The Cisco GK forwards the address of CM to the Cisco GW.
• The Cisco GW then initiates a Q.931 call setup sequence to Avaya Communication Manager.
• Once these call setup sequences are complete, a talk path will exist between Company B and Company A.
 
In a typical Avaya CM to Cisco GK/GW configuration, two Signaling Group/Trunk Group pairs are provisioned.
One Signaling Group has its far-end node name defined as the Cisco GK. This Signaling/Trunk Group is used by CM for LRQ exchanges with the Cisco GK.
In this case CM operates as a GK.
The second Signaling Group is provisioned with the far-end node field left blank. This is to allow CM accept inbound calls from “unknown” locations (e.g. the Cisco GW).
In this case CM operates as a GW.

Cause

running a list trace RAS ip-address x.x.x.x where x.x.x.x is the Cisco GK IP address, we can see CM is receiving LRQ messages from Cisco but it does not reply with LCF messages.

09:24:28   rcv LRQ ext
                   endpt  [10.11.224.44]:1719           >>>> Cisco Directory GK
                   switch [10.106.108.134]:1719     >>>>> CLAN
09:24:34   rcv LRQ ext
                   endpt  [10.11.224.44]:1719
                   switch [10.106.108.134]:1719
09:24:41   rcv LRQ ext
                   endpt  [10.11.224.44]:1719
                   switch [10.106.108.134]:1719
 

On the MST trace, we can clearly see there is probably a mis configuration in CM.
 
This is the denial even message:
13:37:32.619  14 Denial Event Trace (2112 DNY_NO_ROUTE_DEST)
              ProcLRQ() (2112) Send LRJ because we cannot route to the destination.
5  13:37:32.619  81          <-- Dolan RAS Out
 
CM sent out an LRJ but since there is no additional signaling group configured on trunk, it does not know which IP to send it:
5  13:37:32.619  81          <-- Dolan RAS Out    
       From IPAdr:  10.106.108.134   From Port:1719
            To IPAdr:          0.0.0.0     To Port:1719   UID: 0xf001d
RasMessage CHOICE [index = 20]
  locationReject LocationReject SEQUENCE [root fieldcount (not encoded) = 2]
    rejectReason LocationRejectReason CHOICE [index = 14]
      noRouteToDestination NULL [length (not encoded) = 0.0]
 
What it mean is CM received the LRQ from Cisco GK but could not route the call due to missing configuration

Internetworking configuration needs 3 major steps to be done on CM side:

1- One outgoing trunk to the Cisco DGK

2- One incoming trunk to the Cisco regional GK plus one additional signaling group associated to the same trunk (as described below)

3-  inc-call-handling-trmt

Solution

When configuring CM to work with H.323 trunk to Cisco gatekeeper & gateway, the user needs to configure two trunks on CM side to work with LRQ (according to Solution & Interoperability Test Lab Application Notes attached to this KB).
 
First trunk that is listening to port 1719 will receive LRQ (location request) message and will answer with LCF (location confirm) or LRJ (location reject) message. It corresponds to the called number in the LRQ after examining the'inc-call-handling-trmt trunk-group' related to this trunk.
The important field in the 'inc-call-handling-trmt trunk-group' related to this trunk is to have the 'Called Number' configured correctly. The 'Insert' Number can be any station in the system (even one that is only configured but not active) because this trunk will not be used to route the call eventually.
Second trunk that is listening to port 1720 will receive the 'Setup' message and will deal with call routing to the correct destination. It will decide to where to deliver the call according to its 'inc-call-handling-trmt trunk-group' .
 
Configure the 'inc-call-handling-trmt trunk-group' to each trunk separately.
 
Example for getting call (from Cisco gatekeeper/gateway) to number 1234567890 and
routing it to station '5555'
1.First trunk that is listening to port 1719 can be configured as in the example below:
Form SAT :'change inc-call-handling-trmt trunk-group xxx'

Service/       Called    Called                 Del               Insert     Per Call  Night
 Feature         Len      Number                                              CPN/BN    Serv
 tie             10      1234567890              10                5555

(in the 'called number' we can also configure only part of the number like '123456' and in the 'Insert' we can configure any station that is configured in the system,
This action will be good enough to send LCF back to the other side).
2.Second trunk  that is listening to port 1720 can be configures as in the example below:
Form SAT :
Service/       Called    Called                 Del               Insert          Per Call  Night
 Feature         Len      Number                                                CPN/BN    Serv
 tie             10      1234567890              10                5555

(in the 'called number' we can also configure only part of the number like '123456',in the 'Insert' we must configure the real station that we want the call to be
delivered to , in our example its '5555').

Legacy ID

KB01027898

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy