Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

How to Troubleshoot the Voice Call Failures in PGW & MGW ?

  • Introduction
  • Problem Description
  • Troubleshooting Call Failure
    • Using Debugs Running on MGW
    • Using Snoop Caputre taken on PGW
  • ISDN Cause Code & Failure Reasons

Introduction

This Document is created based on the Frequently asked questions in the discussions, "How to Troubleshoot the Voice Call Failure in PGW & Media Gateway AS5400? ". This will help you to identify the Call failure when the Call is terminated to the PSTN Carrier using the PSTN Gateway (PGW) and the Media Gateway. Call flow is as follows

     PGW  <----------> MGW <-----------> PSTN Carrier

Problem Description

When a Call is Routed from the PGW to the PSTN Carrier thru the Media Gateways using E1/T1 carriers, calls can fail in the network due to multiple reasons like E1/T1 related issues, PSTN Operator issues and System related issues.

In order to maintain better uptime and Call Completion Ratio, we need to identify the reason for Call failures. This document covers the Troubleshooting Steps to identify the end-end call failure reasons both at the Media Gateway, PGW level and based on the reasons action can be taken.

Troubleshooting Call Failure

Troubleshooting can be done at both the MGW and PGW. Both the caputures will help analzing the end-end call failure.

1. Using Debugs Running on MGW

Step 1: Enable the Debug on the MGW

# debug voip ccapi inout

Step 2: Make one or more test calls or live calls can be captured to identify the call failure reasons.

Step 3: Capture the "debug voip ccapi inout"   output

Using the "debug voip ccapi inout" you get the following Call informations in detail like, Calling Number, Called Number,

Incoming Dial-peer, Outgoing Dial-peer, Trunk group lables, ANI (A Number CLI), ANI type, NPI, Presentation and also the CAUSE VALUE.

This Cause Value well help you to identify the reason for call drop..

cc_api_call_setup_ind_common:

   cisco-username=10.10.75.32

   ----- ccCallInfo IE subfields -----

  cisco-ani=17815057901

   cisco-anitype=0

   cisco-aniplan=1

   cisco-anipi=0

   cisco-anisi=0

  dest=19871394826

   cisco-desttype=0

   cisco-destplan=1

   cisco-rdie=FFFFFFFF

   cisco-rdn=

   cisco-rdntype=-1

   cisco-rdnplan=-1

   cisco-rdnpi=-1

   cisco-rdnsi=-1

   cisco-redirectreason=-1   fwd_final_type =0

   final_redirectNumber =

   hunt_group_timeout =0

Apr 25 12:00:15.155 IST: //-1/022A3B022355/CCAPI/cc_api_call_setup_ind_common:

   Interface=0x66784508, Call Info(

  Calling Number=17815057901,(Calling Name=)(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),

   Called Number=19871394826(TON=Unknown, NPI=ISDN),

   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,

  Incoming Dial-peer=100, Progress Indication=NULL(0), Calling IE Present=TRUE,

  Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=80

Apr 25 12:00:15.155 IST: //-1/022A3B022355/CCAPI/ccCheckClipClir:

   In: Calling Number=17815057901(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed)

Apr 25 12:00:15.155 IST: //-1/022A3B022355/CCAPI/ccCheckClipClir:

   Out: Calling Number=17815057901(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed)

Apr 25 12:00:15.155 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 25 12:00:15.155 IST: :cc_get_feature_vsa malloc success

Apr 25 12:00:15.155 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 25 12:00:15.155 IST:  cc_get_feature_vsa count is 1

Apr 25 12:00:15.155 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Apr 25 12:00:15.155 IST: :FEATURE_VSA attributes are: feature_name:0,fearture_time:1714949976,feature_id:80

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/cc_api_call_setup_ind_common:

   Set Up Event Sent;

   Call Info(Calling Number=17815057901(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),

   Called Number=19871394826(TON=Unknown, NPI=ISDN))

Apr 25 12:00:15.159 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

Apr 25 12:00:15.159 IST: :Inside cc_build_feature_vsa

Apr 25 12:00:15.159 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

Apr 25 12:00:15.159 IST:  feature call basic

Apr 25 12:00:15.159 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_build_feature_vsa:

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/cc_process_call_setup_ind:

   Event=0x66393440

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/ccCallSetContext:

   Context=0x6707BF28

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/cc_process_call_setup_ind:

   >>>>CCAPI handed cid 80 with tag 100 to app "_ManagedAppProcess_Default"

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/ccCallProceeding:

   Progress Indication=NULL(0)

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/ccCallSetupRequest:

   Destination=, Calling IE Present=TRUE, Mode=0,

  Outgoing Dial-peer=7, Params=0x67077D60, Progress Indication=NULL(0)

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/cc_fill_tg_params:

   Not a cic call

Apr 25 12:00:15.159 IST: //80/022A3B022355/CCAPI/ccCallSetupRequest:

   Peer(Active Connections=0)

Apr 25 12:00:15.159 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:

Apr 25 12:00:15.159 IST: : updating existing feature vsa

Apr 25 12:00:15.159 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:

Apr 25 12:00:15.159 IST:  feature call basic

Apr 25 12:00:15.163 IST: //80/022A3B022355/CCAPI/ccCallDisconnect:

   Cause Value=44, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

Apr 25 12:00:15.163 IST: //80/022A3B022355/CCAPI/ccCallDisconnect:

   Cause Value=44, Call Entry(Responsed=TRUE, Cause Value=44)

Apr 25 12:00:15.163 IST: //80/022A3B022355/CCAPI/cc_api_get_transfer_info:

   Transfer Number Is Null

Apr 25 12:00:15.215 IST: //80/022A3B022355/CCAPI/cc_api_call_disconnect_done:

   Disposition=0, Interface=0x66784508, Tag=0x0, Call Id=80,

   Call Entry(Disconnect Cause=44, Voice Class Cause Code=0, Retry Count=0)

Apr 25 12:00:15.215 IST: //80/022A3B022355/CCAPI/cc_api_call_disconnect_done:

   Call Disconnect Event Sent

Apr 25 12:00:15.215 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr 25 12:00:15.215 IST: :cc_free_feature_vsa freeing 66380F50

Apr 25 12:00:15.215 IST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Apr 25 12:00:15.215 IST:  vsacount in free is 0

Step4:  Now look at the ccCallDisconnect:  highlighted in Red in the above line

Apr 25 12:00:15.163 IST: //80/022A3B022355/CCAPI/ccCallDisconnect:

   Cause Value=44, Call Entry(Responsed=TRUE, Cause Value=44)

Cause Value = 44 is Requested channel not available as per the ISDN Failure cause code

Find the attached Table for Cause Value and Failure reasons

Table : ISDN Failure Cause Codes  

Failure Cause Code

Meaning

1

Unallocated or unassigned number.

2

No route to specified transit network.

3

No route to destination.

6

Channel unacceptable.

7

Call awarded and being delivered in an established channel.

16

Normal call clearing.

17

User busy.

18

No user responding.

19

No answer from user (user alerted).

21

Call rejected.

22

Number changed.

26

Nonselected user clearing.

27

Destination out of order.

28

Invalid number format.

29

Facility rejected.

30

Response to status enquiry.

31

Normal, unspecified.

34

No circuit/channel available.

38

Network out of order.

41

Temporary failure.

42

Switch congestion.

43

Access information discarded.

44

Requested channel not available.

45

Preempted.

47

Resources unavailable, unspecified.

49

Quality of service unavailable.

50

Requested facility not subscribed.

52

Outgoing calls barred.

54

Incoming calls barred.

57

Bearer capability not authorized.

58

Bearer capability not available now.

63

Service or option not available, unspecified.

65

Bearer capability not implemented.

66

Channel type not implemented.

69

Requested facility not implemented.

70

Only restricted digital information bearer capability is available.

79

Service or option not implemented, unspecified.

81

Invalid call reference value.

82

Identified channel does not exist.

83

Suspended call exists, but this call ID does not.

84

Call ID in use.

85

No call suspended.

86

Call with requested call ID is cleared.

88

Incompatible destination.

91

Invalid transit network selection.

95

Invalid message, unspecified.

96

Mandatory information element missing.

97

Message type nonexistent or not implemented.

98

Message not compatible with call state or message type nonexistent or not implemented.

99

Information element nonexistent or not implemented.

100

Invalid information element contents.

101

Message not compatible with call state.

102

Recovery on timer expiry.

111

Protocol error, unspecified.

127

Interworking, unspecified.

Inorder to further analyse at the ISDN q931 protocol level you can enable the following debug

Step 1: Enable the following Debug on the MGW

# debug isdn q931

Step 2: Make one or more test calls to identify the call failure reasons.

Step 3: Capture the "debug isdn q931"   output

Using the "debug isdn q931" you get the following information.

Using the debug isdn q931 command, you can identify the layer 3 status of the ISDN link established and

gives you the Call status established with the far end operator using ISDN q931 protocol Disconnect reasons.

20:52:14: ISDN BR0: TX -> SETUP pd = 8 callref = 0x2E

   20:52:14: Bearer Capability i = 0x8890

   20:52:14: Channel ID i = 0x83 20:52:14: Keypad Facility i = '5551111'

   20:52:15: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xAE

   20:52:15: Channel ID i = 0x89

   20:52:16: ISDN BR0: RX <- PROGRESS pd = 8 callref = 0xAE

   20:52:16: Progress Ind i = 0x8A81 - Call not end-to-end ISDN,

     may have in-band info

   20:52:16: Signal i = 0x01 - Ring back tone on

  20:52:34: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xAE

   20:52:34: Cause i =0x829F08 - Normal,unspecified or Special intercept,

     call blocked group restriction    

   20:52:34: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x2E

   20:52:34: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0xAE

Step4:  Now look at the cause i:  highlighted in Red in the above line

Cause i = 0x829F08

9F is the Disconnect Causecode and the equivalent failure reason is " Normal unspecified"

9F

Normal, unspecified

This message reports the occurrence of a normal event when no standard cause applies. No action is required.

Cause i = 0x82A108

A1 is the Disconnect Causecode and the equivalent failure reason is " Circuit out of order"

A1

Circuit out of order

The call cannot go through due to some problem in the ISDN network.

Refer this link for call failure and Disconnect reasons

http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

2. Using Snoop Capture taken on PGW

Step1: Take the snoop capture in the PGW and on the Wireshark apply the voip call flow

             snoop -d bge0 -o /tmp/snoopop.cap

             Run using the root user on PGW

         

Step2: Snoop output taken on bge0 / bge1 will caputure the calls thru the leg. Now Decode the output snoop file on the Wireshark and take the voip call Graph.This will provide the call with SIP-PGW-ISUP call trace

Attached the Sample Wireshark voip call flow output graph with "Call failure reason"

Step3: Using the Wireshark graph you can get the following details as shown in the snapshot attached.

Call flow : SIP <-----------> PGW (MGCP) <-----------> MGW <-------------->PSTN Carrier.

Calling No. : 12345678

Called No.  : 2066357073

Originating & Destination Gateway IP

SIP(5060) Call flow : 192.169.2.10 to 192.150.10.2

MGCP(2427) Call flow : 192.150.10.4 to 192.148.75.38

ISUP Call flow between the OPC 7566 & DPC 7156 to the PSTN Carrier

Disconnect Reason : Cause 16, Normal Call Clearing which states its a normal call

Based on the Wireshark graph, Disconnect reasons and call flow, we can identify where the failure occurs and the reason for call failure.

Testcall- PGW.JPG

Comments
New Member

Hi mpaneers,

Logs from the MGW & PGW contradict each other. Logs from MGW shows that the MGW & PGW are setup in signaling mode. The snoop trace screenshot shows the PGW & MGW are setup in Call Control mode.

Kindly modify the snoop trace with screenshot taken on signaling mode.

Thanks.

Hi


Thanks for your feedback.

Both the examples shown are two different outputs taken on a different call setup to show the debug output and the snoop capture taken on PGW.

As you said, PGW snoop capture is taken on Call control Mode of operation. I dont have the signaling setup in my lab since its been recently migrated from signaling to call control. so I couldnt attach the signaling mode call flow capture. Similar snoop capture can be taken for the PGW with the Signaling mode of operation.

Thanks.

New Member

Hi ,

Could you please explain complete call flow for one call. if you are busy, could please suggest us book to read.

Regards,

Karunakar K

7127
Views
5
Helpful
3
Comments