cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
457
Views
0
Helpful
6
Replies

deployed ASA upgrade 8.4.2 now branch office unable to make ld calls

kdmyles
Level 1
Level 1

We deployed 8.4.2 over the weekend and now a branch office that connects to our core via ASA to ASA VPN tunnel is no longer able to make long distance calls.  We are using Callmanager 4.1 and it is connected to our core, the phones at the branch register fine and are abe to call internal extensions, but when dialing 800 numbers and longdistance they are not being directed to their PRI. 

6 Replies 6

barry
Level 7
Level 7

Are you running any service policies on your ASAs that will inspect SCCP?

Bary Hesk

Intrinsic Network Solutions

no

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect sunrpc

  inspect xdmcp

  inspect tftp

  inspect ip-options

  inspect mgcp

ok.... you may need to do some further tracing in order to work out what is going on.

+ How do your gateways connect to CUCM (MGCP or H.323)

+ Have you tried an ISDN Q.931 trace on your gateway to see if the call is hitting CUCM.

+ What do you see / hear on the phone when you try and place the call?

Barry Hesk

Intrinsic Network Solutions

This is what I get from my gateway on an ISDN debug but how do I decipher it?

*Apr 17 14:44:06: ISDN Se1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x03E4

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98381

                Exclusive, Channel 1

        Progress Ind i = 0x8283 - Origination address is non-ISDN 

        Calling Party Number i = '!', 0x83, '4043611134'

                Plan:ISDN, Type:National

        Called Party Number i = 0x80, '7102'

                Plan:Unknown, Type:Unknown

*Apr 17 14:44:06: ISDN Se1/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x83E4

        Channel ID i = 0xA98381

                Exclusive, Channel 1

*Apr 17 14:44:06: ISDN Se1/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x83E4

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

*Apr 17 14:44:14: ISDN Se1/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x83E4

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

*Apr 17 14:44:14: ISDN Se1/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x03E4

*Apr 17 14:44:59: ISDN Se1/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x83E4

        Cause i = 0x8090 - Normal call clearing

*Apr 17 14:44:59: ISDN Se1/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x03E4

*Apr 17 14:44:59: ISDN Se1/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x83E4

Fast busy when making 800 and long distance calls.

Ok... CUCM is clearing the call (DISCONNECT is in direction TX) once the call is connected so it does indicate a problem on "your" side.

You'll need to do some further tracing:

Have you tried performing a packet capture on the ASA between the phone and the gateway - as this should trap the RTP session and may shed some light on what is going on.

Is your G/W MGCP or H.323? If H.323 you may want to do some h225 tracing on it and again, this may assist.

If you G/W is H323, you may want to try disabling the h323 service policy on the ASA. Is the G/W located in the same location as CUCM or is it in the branch office?

Have you checked the ASA logs via ASDM to see if it is reporting any drops?

I have seen firewall stateful inspection code cause all manner of issues, however to be fair, not in recent times.

HTH

Barry Hesk

Intrinsic Network Solutions