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

Troubleshooting External PSTN calls with No-way audio/dead Air Issue

 

 

Introduction

 

This document discusses how to Troubleshoot  No-way audio/ dead Air Issue for the PSTN Outbound and Inbound Calls.

 

 

Problem Description

 

Outbound and inbound calls are not working - no-way audio. The PSTN Outbound and Inbound Calls are going through and getting connected fine but after that there is nothing heard, No-way audio/dead air issue for the PSTN calls outbound.

 

Network Scenario

 

Mobile phone->PSTN -T1 PRI--> MGCP Gateway -->CUCM -- IP Phone

 

Components

 

CUCM 8.5.1

MGCP Gateway IOS version 12.1

 

Resolution

 

Troubleshooting Procedure

 

1) The CUCM traces revealed that the call was connected fine and there was no issue found in the sdi/sdl traces.

     CUCM only plays role in the call setup /tear-down of connection but not during conversation.

 

  • The Inbound and outbound calls have symptoms of dead air.
  • CUCM traces reveal that the call connects all fine and there seems to be loss of audio packets.
  • While testing the call customer didn't notice any change in TX count. It was showing zero while RX count was increasing gradually.
  • Installed the Wireshark tool.

 

2)  The Gateway isdn debugs below also didn't reveal the root cause. MGCP Gateway Debugs

 

 

MGCP  Gateway Debug for Troubleshooting

 

   Transfer Capability = Speech

 

                Transfer Mode = Circuit

                 Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98381

                 Exclusive, Channel 1

        Facility i =  0x9F8B0100A10F02014A06072A8648CE1500040A0100

                 Protocol Profile =  Networking Extensions

                 0xA10F02014A06072A8648CE1500040A0100

                Component =  Invoke component

                        Invoke Id = 74

                         Operation = InformationFollowing (calling_name)

                                 Name information in subsequent FACILITY message

        Calling  Party Number i = 0x2183, '9186255864'

                Plan:ISDN,  Type:National

        Called Party Number i = 0x80, '43000'

                 Plan:Unknown, Type:Unknown

000365: *Jan 12 02:58:18.271: ISDN  Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x9FC1

         Channel ID i = 0xA98381

Exclusive, Channel 1

000366: *Jan  12 02:58:18.367: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8  callref  = 0x9FC1

        Progress Ind i = 0x8088 - In-band info or  appropriate now available

000367: *Jan 12 02:58:18.543: ISDN  Se0/0/0:23 Q931: RX <- FACILITY pd = 8  callref = 0x1FC1

         Facility i =  0x9F8B0100A11702014B020100800F4E4F5244414D203630323030202020

                 Protocol Profile =  Networking Extensions

                 0xA11702014B020100800F4E4F5244414D203630323030202020

                 Component = Invoke component

                        Invoke Id =  75

                        Operation = CallingName

                                 Name Presentation Allowed Extended

                                 Name = NORDAM 60200

000368: *Jan 12 02:58:21.255: ISDN Se0/0/0:23  Q931: TX -> CONNECT pd = 8  callref = 0x9FC1

000369: *Jan 12  02:58:21.287: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref  = 0x1FC1

[Connection to 10.17.2.9 closed by foreign host]

 

D6506#telnet  10.17.2.9

 

d3825voice#debug isdn q931

debug isdn q931  is              ON.

d3825voice#term mon

d3825voice#

000405:  *Jan 12 03:08:43.303: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8   callref = 0x0007

        Cause i = 0x8090 - Normal call clearing

000406:  *Jan 12 03:08:43.583: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8   callref = 0x8007

000407: *Jan 12 03:08:43.603: ISDN Se0/0/0:23  Q931: TX -> RELEASE_COMP pd = 8  callref = 0x0007

000408: *Jan  12 03:08:48.355: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref =  0x0008

        Bearer Capability i = 0x8090A2

                 Standard = CCITT

                Transfer Capability = Speech

                 Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

         Channel ID i = 0xA98397

                Exclusive, Channel 23

         Facility i = 0x9F8B0100A116020101020100800E4E574420546573742050686F6E65

                 Protocol Profile =  Networking Extensions

                 0xA116020101020100800E4E574420546573742050686F6E65

                 Component = Invoke component

                        Invoke Id = 1

                         Operation = CallingName

                                Name  Presentation Allowed Extended

                                Name  = NWD Test Phone

        Calling Party Number i = 0x0181,  '3165543998'

                Plan:ISDN, Type:Unknown

         Called Party Number i = 0xA0, '6341600'

                 Plan:Unknown, Type:National

000409: *Jan 12 03:08:48.583: ISDN  Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8008

         Channel ID i = 0xA98397

                Exclusive, Channel 23

000410:  *Jan 12 03:08:49.683: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8   callref = 0x8008

        Progress Ind i = 0x8088 - In-band info or  appropriate now available

000411: *Jan 12 03:08:53.031: ISDN  Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x8008

000412:  *Jan 12 03:08:53.403: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd =  8  callref = 0x0008

000413: *Jan 12 03:11:26.731: ISDN Se0/0/0:23  Q931: RX <- DISCONNECT pd = 8  callref = 0x8008

        Cause i  = 0x8090 - Normal call clearing

000414: *Jan 12 03:11:26.967:  ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x0008

000415:  *Jan 12 03:11:27.031: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd =  8  callref = 0x8008

 

called number: 316 -6341600

calling  party: 316 554 3998

 

Then the packet capture was taken  on interface of the MGCP Gateway.

 

 

 

3).  Ping from the Subnet the IP Phone

 

Ping from the subnet of the ip phone to GW's interface and vice versa wasn't working fine.

 

Root cause

  1. The MGCP GW was having two interfaces GIG 0/0 and Ethernet GIG 0/1 both in same subnet.
  2. The signaling and media for mgcp was binded to gig 0/0..
  3. It was found that no routing exists between gig 0/0 and the device IP subnet.
  4. The wire-shark trace/packet capture was taken for the outbound calls at BOTH the interfaces of the GWs i.e. Ethernet GIG 0/0 and 0/1.

 

Solution

 

All the traffic and signaling was happening through the second interface 0/1 and the below change were made and router was reloaded to get things back to normal:-

 

MGCP bind media source-interface (interface Ethenet Gig 0/1)

 

So that binded the MGCP media streaming to the Ethernet GIG interface 0/1

 

MGCP Interface was wrongly configured and  that is the cause for the issue. Binding the correct source interface ensured that the media streaming got through for the inbound/outbound calls.

 

Make test calls and ensure the calls are all going through fine and media got through for the inbound/outbound calls.

 

Related Information

 

4169
Views
0
Helpful
0
Comments