H.323 Guide, Release 6.0.x
Chapter 5 - Troubleshooting

Table Of Contents

Troubleshooting

Outgoing Trunk Group Is Out of Service

Solution

Outgoing H.323 Gateway Is Out of Service

Solution

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

Solution

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

Solution

Configuration at Softswitch or Gatekeeper Has Placed Routing into a Loop

Solution

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

Solution

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

Solution

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

Solution


Troubleshooting


Revised: July 31, 2008, OL-15917-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;