Cisco BTS 10200 Softswitch H.323 Guide, Release 6.0.4

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco BTS 10200 Softswitch H.323 Guide, Release 6.0.4

Chapter Title

Chapter 5 - Troubleshooting

Results

Updated:
May 13, 2012

Chapter: Chapter 5 - Troubleshooting


Troubleshooting

Revised: May 14, 2012, OL-24999-02

This chapter provides examples of possible problems you might encounter while working with H.323, and recommended solutions.

•Outgoing Trunk Group Is Out of Service

•Outgoing H.323 Gateway Is Out of Service

•H.323 Gateway Fails to Register with GK (Invalid Alias)

•Outgoing H.323 Gateway Unregistered with GK and Needs to Use RAS

•Stable Calls Are Dropped When CA Switches Over

•No Matching Dial Plan Found on Incoming H.323 Trunk Group

•Configuration at Softswitch or Gatekeeper Has Placed Routing into a Loop

•Outgoing H.323 Calls Routed to Incorrect Endpoint When Using RAS

•Outgoing H.323 Calls Routed to Incorrect Endpoint When Using Direct Signaling

•RAS Still Used When Outgoing H.323 Call Is Provisioned to Use Direct Signaling

Outgoing Trunk Group Is Out of Service 

[I4 10:40:00.299 BCM  01-1 BCM_Main]  "bcm_sel_term_tg_id(): get_tg_from_route() fail" 
[bcm_bcsm_util.c:2614]

[***ERROR*** 10:40:00.299 BCM  01-1 BCM_Main   ]  "Route Selection Failure" 
[bcm_obcsm_sa_proc.c:3961]

 
   
 
    
   
 This is an indication that the outgoing H.323 trunk group is out of service. 
 
    
   
 Verify the status of the outgoing trunk group. 
 
    
   
 Example 
 
    
   
 
    
CLI>status trunk_grp id=8991;

 
   
 
    
   
 
    
Reply : Success: 

 
   
 
    
   
 
    
 
   
 
    
   
 
    
TGN ID -> 8991

 
   
 
    
   
 
    
ADMIN STATE -> ADMIN_OOS 

 
   
 
    
   
 
    
OPER STATE -> Trunk group in-service

 
   
 
    
   
 
    
REASON -> ADM executed successful

 
   
 
    
   
 
    
RESULT -> ADM configure result in success

 
   
 
    
   
 
    
 
   
 
     
    
   
 Solution 
 
    
   
 Use CLI to place the trunk_grp in-service. 
 
    
   
 CLI> control trunk_grp id=8991; target-state=ins; mode=forced;  
 
     
    
    
   
 Outgoing H.323 Gateway Is Out of Service 
 
    
   
 
    
[***WARN**** 10:47:44.793 H3A3 01-1 Main ] "Call failure H3A--->BCM sent for csaid=41 
callid=0 reason=H323 gateway/gk seem to be OOS" [h3a_sig_sai.c:1525]

 
   
 
    
    
   
 This is an indication that the outgoing H.323 gateway is "out of service." 
 
    
   
 Verify the status of outgoing H.323 gateway. 
 
    
   
 
    
CLI>status h323_gw id=CHINA_3; 

 
   
 
    
   
 
    
Reply : Success: 

 
   
 
    
   
 
    
 
   
 
    
   
 
    
ADMIN STATE -> ADMIN_OOS 

 
   
 
    
   
 
    
H3A PROCESS NUMBER -> 32

 
   
 
    
   
 
    
H3A PROCESS NAME -> H3A3

 
   
 
    
   
 
    
ENDPOINT ID -> 

 
   
 
    
   
 
    
ACTIVE CALLS -> 0

 
   
 
    
   
 
    
RAS STATE -> CCH323_RAS_STATE_NONE

 
   
 
    
   
 
    
RAS PORT -> 0

 
   
 
    
   
 
    
IP ADDRESS -> 

 
   
 
    
   
 
    
REGISTERED GATEKEEPER ID -> NOT REGISTERED

 
   
 
    
   
 
    
PRIMARY GATEKEEPER ID -> 

 
   
 
    
   
 
    
PRIMARY GATEKEEPER PORT -> 0

 
   
 
    
   
 
    
PRIMARY GATEKEEPER IP -> 

 
   
 
    
   
 
    
H323 VERSION -> 4

 
   
 
    
   
 
    
TIME TO LIVE -> 0

 
   
 
    
   
 
    
NUM ALT GATEKEEPERS -> 0

 
   
 
    
   
 
    
ALT GATEKEEPER PERMANENT -> FALSE

 
   
 
    
   
 
    
THRESHOLD ENABLED -> FALSE

 
   
 
    
   
 
    
OUT OF RESOURCES -> FALSE

 
   
 
    
   
 
    
ALT GATEKEEPER LIST -> 

 
   
 
     
    
   
 Solution 
 
    
   
 Use CLI to place the h323_gw in-service. 
 
    
   
 
    
 
   
 
    
   
 
    
CLI>control h323_gw id=CHINA_3; target-state=ins;

 
   
 
    
   
 
    
Reply : Success: CLI change successful

 
   
 
    
   
 
    
 
   
 
    
   
 
    
H323GW ID -> CHINA_3

 
   
 
    
   
 
    
INITIAL STATE -> ADMIN_OOS 

 
   
 
    
   
 
    
REQUEST STATE -> ADMIN_INS 

 
   
 
    
   
 
    
RESULT STATE -> ADMIN_INS 

 
   
 
    
   
 
    
FAIL REASON -> ADM found no failure

 
   
 
    
   
 
    
REASON -> ADM executed successful

 
   
 
    
   
 
    
RESULT -> ADM configure result in success

 
   
 
     
    
    
   
 H.323 Gateway Fails to Register with GK (Invalid Alias) 
 
    
   
 When the H.323 gateway registers with a GK, sometimes an alias list is provided to the GK in the RRQ message from the gateway. Currently, this configuration is supported on IOS gateways (that are not in use on the Cisco BTS 10200 Softswitch) when FXS ports are involved. If an RRJ message is received by gateway with reject reason "invalidAlias," this is symptomatic of an alias list being provided to the GK when the GK not configured to be responsible for the prefix associated with each of the aliases. 
 
    
   
 
    
[+ .            H3A3 .    .          ] "value RasMessage ::= gatekeeperReject : "

 
   
 
    
   
 
    
[+ .            H3A3 .    .          ] "    {"

 
   
 
    
   
 
    
[+ .            H3A3 .    .          ] "      requestSeqNum 11"

 
   
 
    
   
 
    
[+ .            H3A3 .    .          ] "      protocolIdentifier { 0 0 8 2250 0 3 }"

 
   
 
    
   
 
    
[+ .            H3A3 .    .          ] "      rejectReason invalidAlias : NULL"

 
   
 
    
   
 
    
[+ .            H3A3 .    .          ] "    }"

 
   
 
    
   
 
    
 
   
 
    
   
 
    
 
   
 
    
   
 Example: 
 
    
   
 Local GK that gateway is trying to register with configured as follows: 
 
    
   
 •zone prefix China-GK 30* 
 
    
   
 •zone prefix China-GK 281* 
 
    
   
 •zone prefix China-GK 29* 
 
    
   
 Gateway has the following aliases that it wishes to register: 
 
    
   
 c2620.50#show gateway 
 
    
   
 Gateway China-GW1 is not registered to any GK. 
 
    
    
   
 Alias list (CLI configured) 
 
    
   
 •E164-ID 20751101 
 
    
   
 •E164-ID 20751102 
 
    
   
 •E164-ID 20751103 
 
    
   
 •E164-ID 20751104 
 
    
    
   
 In this case, China-GK does not have a prefix to match any of the E164 numbers. 
 
     
    
   
 Solution 
 
    
   
 Add a zone prefix entry to China-GK that would cause a match on the alias numbers that are trying to be registered. 
 
    
   
 –zone prefix China-GK 20* 
 
     
    
    
   
 Outgoing H.323 Gateway Unregistered with GK and Needs to Use RAS 
 
    
   
 
    
[I4 10:52:44.824 H3A3 01-1 Lib_DBM] "H3A: h3a_use_ras Checking for RAS" [h3a_dbm.c:543]

 
   
 
    
   
 
    
[I4 10:52:44.824 H3A3 01-1 Lib_DBM] "h3a_get_dest_ip_addr: Need to use RAS ......" 
[h3a_dbm.c:484]

 
   
 
    
   
 
    
[4? 10:52:44.824 H3A3 01-1 H_EVT] ": for callID 5 <cch323_call_setup_normal in 
gw/src/cch323_gw_api.c:4247>"

 
   
 
    
   
 
    
 [bts/os/src/bts_debug.c:200]

 
   
 
    
   
 
    
[4? 10:52:44.824 H3A3 01-1 H_225_EVT]  "H.225 SM: process event H225_EVENT_RAS_RESOLVE, 
for callID 5 <cch323_send

 
   
 
    
   
 
    
_event_to_h225 in gw/src/cch323_h225.c:337>" [bts/os/src/bts_debug.c:200]

 
   
 
    
   
 
    
[4? 10:52:44.824 H3A3 01-1 H_225_EVT]  "cch323_run_h225_sm: received event 
H225_EVENT_RAS_RESOLVE while at state

 
   
 
    
   
 
    
H225_IDLE <cch323_run_h225_sm in gw/src/cch323_h225.c:10085>" [bts/os/src/bts_debug.c:200]

 
   
 
    
   
 
    
[4? 10:52:44.824 H3A3 01-1 H_EVT]  ": state = 0 <cch323_traverse_enum_contact_list in 
gw/src/cch323_gw_api.c:

 
   
 
    
   
 
    
4652>" [bts/os/src/bts_debug.c:200]

 
   
 
    
   
 
    
[I3 10:52:44.824 H3A3 01-1 Main]  "Rel message from STACK--->H3A for callid=5, cause 
code=16" [h3a_sig_sai.c:1549] 

 
   
 
    
    
   
 This is an indication that the outgoing H.323 gateway needs to use RAS to complete the call, but because the gateway is not registered with a GK, the call is released. 
 
    
    
   
 Verify the status of the H.323 gateway with a CLI command. 
 
    
   
 
    
CLI>status h323_gw id=CHINA_3;

 
   
 
    
   
 
    
Reply : Success: 

 
   
 
    
   
 
    
 
   
 
    
   
 
    
ADMIN STATE -> ADMIN_INS  

 
   
 
    
   
 
    
H3A PROCESS NUMBER -> 32

 
   
 
    
   
 
    
H3A PROCESS NAME -> H3A3

 
   
 
    
   
 
    
ENDPOINT ID -> 

 
   
 
    
   
 
    
ACTIVE CALLS -> 0

 
   
 
    
   
 
    
RAS STATE -> CCH323_RAS_STATE_GRQ

 
   
 
    
   
 
    
RAS PORT -> 59723

 
   
 
    
   
 
    
IP ADDRESS -> 10.89.225.165

 
   
 
    
   
 
    
REGISTERED GATEKEEPER ID -> NOT REGISTERED

 
   
 
    
   
 
    
PRIMARY GATEKEEPER ID -> China-GK

 
   
 
    
   
 
    
PRIMARY GATEKEEPER PORT -> 1719

 
   
 
    
   
 
    
PRIMARY GATEKEEPER IP -> 10.89.227.198

 
   
 
    
   
 
    
H323 VERSION -> 4

 
   
 
    
   
 
    
TIME TO LIVE -> 0

 
   
 
    
   
 
    
NUM ALT GATEKEEPERS -> 0

 
   
 
    
   
 
    
ALT GATEKEEPER PERMANENT -> TRUE

 
   
 
    
   
 
    
THRESHOLD ENABLED -> FALSE

 
   
 
    
   
 
    
OUT OF RESOURCES -> FALSE

 
   
 
    
   
 
    
ALT GATEKEEPER LIST -> CLI>status h323_gw id=CHINA_3;

 
   
 
    
    
   
 This shows that the H.323 gateway is in service, but it is not registered with a GK. The following are possible reasons for this: 
 
    
   
 •Incorrect provisioning for H323_GW2GK (incorrect gk name, incorrect gk ip address, security violation). 
 
    
   
 This can be verified by trace logs as a GRJ would be sent back by GK as follows: 
 
    
   
 
    
[+  .            H3A3 .    .          ]  "value RasMessage ::= gatekeeperReject : "

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "    {"

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "      requestSeqNum 11"

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "      protocolIdentifier { 0 0 8 2250 0 3 }"

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "      rejectReason terminalExcluded : NULL"

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "    }"

 
   
 
    
    
   
 •GK is down (no alternate GK, or alternate also is down). 
 
    
   
 This can be verified by trace logs as a timeout would occur (waiting for a GCF or GRJ) after the H.323 GRQ has been sent. 
 
     
    
    
   
 Stable Calls Are Dropped When CA Switches Over 
 
    
   
 If Annex E functionality is provisioned on the Cisco BTS 10200 Softswitch, but stable calls are being dropped when the H.323 process restarts or CA switches over, check to see whether the configuration is correctly registered with the GK: 
 
   
 
    
   
 Step 1 Log on to GK. 
 
    
   
 Step 2 # show gatekeeper endpoints. 
 
    
   
 Step 3 Examine the display of the GK, which should look similar to the example below: 
 
    
   
 
 
   
 
    
 
      
      
      
 
        
        

          CallSignalAddr 
        
 		 
        
        

          Port 
        
 		 
        
        

          RASSignalAddr 
        
 		 
        
        

          Port 
        
 		 
        
        

          Zone Name 
        
 		 
        
        

          Type 
        
 		 
        
        

          Flags 
        
 		 
      
 
      
 
       
 aaa.bbb.ccc.ddd 
 		 
       
 1234 
 		 
       
 eee.fff.ggg.hhh 
 		 
       
 12345 
 		 
       
 City GK 
 		 
       
 VOIP-GW 
 		 
       
 E 
 		 
      
 
      
 
       
 iii.jjj.kkk.lll 
 		 
       
 5678 
 		 
       
 ppp.qqq.rrr.sss 
 		 
       
 56789 
 		 
       
 City GK 
 		 
       
 VOIP-GW 
 		 
       
 E 
 		 
      
 
      
    
 
   
 
   
 
   
 
 
    
   
 Step 4 Verify that both the CA and H323-GW are registered with the GK with Flags=E as shown in the above example. 
 
   
 
    
     
    
    
   
 No Matching Dial Plan Found on Incoming H.323 Trunk Group 
 
    
   
 
    
[I2 14:45:24.288 BCM  01-1 Lib_RTM]  "dial_plan(pcld=45145211, dp_idx=0): no match" 
[rtm_dial_plan.c:492]

 
   
 
    
   
 
    
[***ERROR*** 14:45:24.288 BCM  01-1 BCM_Main]  "No Dial Plan Entry for digits in dial plan 
0" [bcm_obcsm_sa_proc.c:8916]

 
   
 
    
   
 
    
 
   
 
    
   
 After the SETUP message has been received at an incoming H.323 gateway, BCM uses the dial_plan_id in the incoming trunk group and the called number to find out how to route the call. If no match is found, this error will be issued. 
 
     
    
   
 Solution 
 
    
   
 Add an entry to dial_plan for called number and assign the ID to incoming trunk_grp. 
 
    
   
 
    
CLI> add dial_plan id=cdp1; digit_string=451452; dest_id=ipdest; min_digits=7; 
max_digits=10;

 
   
 
    
   
 
    
CLI> change trunk_grp id=8991; dial_plan_id=cdp1;

 
   
 
    
   
 
    
 
   
 
     
    
    
   
 Configuration at Softswitch or Gatekeeper Has Placed Routing into a Loop 
 
    
   
 
    
[I5 10:16:20.921 BCM  01-1 BCM_Main]  "BCM:TPM:Incr Counter( 3 ):4199302144" 
[bcm_tpm_proc.c:106]

 
   
 
    
   
 
    
[***ERROR*** 10:16:20.921 H3A3 01-1 Main]  "alarm=99 reason=<Loop detected!!> call cleared 
for callid=1

 
   
 
    
   
 
    
39 " [h3a_alarms.c:281]

 
   
 
    
     
    
   
 Solution 
 
    
   
 The routing problem could be in either the GK or the Cisco BTS 10200 Softswitch. Check the GK against the dialedDigits pattern in the ARQ. For example: 
 
    
   
 
    
destinationInfo "

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "      {"

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "        dialedDigits : "9991231234""

 
   
 
    
   
 
    
[+  .            H3A3 .    .          ]  "      }"

 
   
 
    
    
   
 There are multiple ways that a GK could determine the destCallSignalAddress to send back in an ACF: 
 
    
   
 •A registered E.164 address (in this case, highly unlikely) 
 
    
   
 •A static route configured (has been observed) 
 
    
   
 •Default routing (highest frequency of problem) 
 
     
    
    
   
 Outgoing H.323 Calls Routed to Incorrect Endpoint When Using RAS 
 
    
   
 
    
[I3 14:25:17.215 H3A3 01-1 Main]  "Rel message from STACK--->H3A for callid=8, cause 
code=3" [h3a_sig_sai.c:1549]

 
   
 
    
    
   
 After the SETUP message has been sent out, a RELEASE COMPLETE is received from the remote endpoint. In this case, the remote endpoint does not service the destination address (cause code=3). 
 
     
    
   
 Solution 
 
    
   
 Log in to the GK that the outgoing H.323 gateway is registered with and determine the routing for called number. GK could be configured to route based on several configurations: 
 
    
   
 •Called number is matched against static routing. 
 
    
   
 •No routing defined for called number, uses default routing. 
 
    
   
 •Routing is based on tech prefix (will be prepended to called number in an ARQ). 
 
     
    
    
   
 Outgoing H.323 Calls Routed to Incorrect Endpoint When Using Direct Signaling 
 
    
   
 
    
[I3 14:25:17.215 H3A3 01-1 Main]  "Rel message from STACK--->H3A for callid=8, cause 
code=3" [h3a_sig_sai.c:1549]

 
   
 
    
    
   
 After the SETUP message has been sent out, a RELEASE COMPLETE is received from the remote endpoint. In this case, the remote endpoint does not service the destination address (cause code=3). 
 
    
   
 Verify the value assigned to the SOFTSW_TSAP_ADDR for the outgoing H.323 trunk group 
 
    
   
 
    
CLI>show trunk_grp id=8991;

 
   
 
    
   
 
    
Reply : Success: Entry 1 of 1 returned.

 
   
 
    
   
 
    
 
   
 
    
   
 
    
ID=8991

 
   
 
    
   
 
    
CALL_AGENT_ID=CA146

 
   
 
    
   
 
    
TG_TYPE=H323

 
   
 
    
   
 
    
SOFTSW_TSAP_ADDR=10.89.227.119;

 
   
 
    
   
 
    
TG_PROFILE_ID=CHINA

 
   
 
    
   
 
    
STATUS=INS

 
   
 
    
   
 
    
DIRECTION=BOTH

 
   
 
    
   
 
    
SEL_POLICY=ASC

 
   
 
    
   
 
    
GLARE=SLAVE

 
   
 
    
   
 
    
ALT_ROUTE_ON_CONG=N

 
   
 
    
   
 
    
SIGNAL_PORTED_NUMBER=N

 
   
 
    
   
 
    
DIAL_PLAN_ID=cdp1

 
   
 
    
   
 
    
DEL_DIGITS=0

 
   
 
    
   
 
    
OPER_STATUS=NF

 
   
 
     
    
   
 Solution 
 
    
   
 Use the CLI to change the trunk group as given below: 
 
    
   
 
    
CLI> change trunk_grp id=8991; softsw_tsap_addr=10.89.227.219;

 
   
 
     
    
    
   
 RAS Still Used When Outgoing H.323 Call Is Provisioned to Use Direct Signaling 
 
    
   
 
    
[I4 14:29:21.163 H3A3 01-1 Lib_DBM    ]  "H3A: h3a_use_ras Checking for RAS" 
[h3a_dbm.c:543]

 
   
 
    
   
 
    
[I4 14:29:21.163 H3A3 01-1 Lib_DBM    ]  "H3A: we need to use the destIP from trunk_grp 
table " [h3a_dbm.c:489]

 
   
 
    
   
 
    
[***ERROR*** 14:29:21.163 H3A3 01-1 Lib_DBM    ]  "h3a_get_dest_ip_addr: softsw_tsap_addr 
not set..." [h3a_dbm.c:494]

 
   
 
    
   
 
    
 
   
 
    
   
 Although the configuration specified that RAS was not to be used, no valid remote endpoint is provided, the fallback mechanism is to try RAS to determine the remote endpoint. 
 
    
   
 Verify the configuration for the outgoing trunk group with CLI: 
 
    
   
 
    
CLI>show trunk_grp id=8991;

 
   
 
    
   
 
    
Reply : Success: Entry 1 of 1 returned.

 
   
 
    
   
 
    
 
   
 
    
   
 
    
ID=8991

 
   
 
    
   
 
    
CALL_AGENT_ID=CA146

 
   
 
    
   
 
    
TG_TYPE=H323

 
   
 
    
   
 
    
TG_PROFILE_ID=CHINA

 
   
 
    
   
 
    
STATUS=INS

 
   
 
    
   
 
    
DIRECTION=BOTH

 
   
 
    
   
 
    
SEL_POLICY=ASC

 
   
 
    
   
 
    
GLARE=SLAVE

 
   
 
    
   
 
    
ALT_ROUTE_ON_CONG=N

 
   
 
    
   
 
    
SIGNAL_PORTED_NUMBER=N

 
   
 
    
   
 
    
DIAL_PLAN_ID=cdp1

 
   
 
    
   
 
    
DEL_DIGITS=0

 
   
 
    
   
 
    
OPER_STATUS=NF

 
   
 
    
   
 
    
QOS_ID=china_qos1

 
   
 
    
   
 
    
TRAFFIC_TYPE=LOCAL

 
   
 
    
   
 
    
H323_GW_ID=CHINA_3

 
   
 
    
   
 
    
CAUSE_CODE_MAP_ID=H323_CHINA

 
   
 
    
   
 
    
ANI_BASED_ROUTING=N

 
   
 
    
   
 
    
NO_ANSWER_TMR=185

 
   
 
    
   
 
    
 
   
 
    
   
 Since the SOFTSW_TSAP_ADDR column is not displayed, it contains a null value. 
 
     
    
   
 Solution 
 
    
   
 Use CLI to change the outgoing trunk group. 
 
    
   
 
    
CLI> change trunk_grp id=8991; softsw_tsap_addr=10.89.227.219;

 
   
 
    
   


 
 
    

    

        

















    

        

    
    
    




















  
Was this Document Helpful?

  
    
    
  
  
      
      FeedbackFeedback
  






			
    

	

















  
    
  



    

			
    

	
















    
Contact Cisco