Outbound call dropped for a specific number.

dannypuckett · ‎04-09-2010

A couple of days ago we switched telco profiders from AT&T to TW Telecom. We had no issues with AT&T but have a very specific one with TW Telecom. One of the numbers we dial is being dropped with a fast busy by the called party switch. They stated that our call was being flagged as possible fraud because we were not sending them a 'Numbering Plan ID'. We never had problems calling this number when we were with AT&T so I am not sure if there is truely a problem and AT&T was masking it or is this an actual issue with our PBX. I have attached a debug of the call being made.

As a side note they also stated that we were sending a "Access Transport" and that we should not. No idea what they are talking about.

Here is my Serial config

interface Serial0/2/0:23
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn map address .* plan unknown type unknown
no cdp enable

Any suggestions?

William Bell · ‎04-09-2010

I am not sure about the "access transport thing" but I have had carriers be very, very particular about the Information Elements in the q931 setup message. It is perfectly understandable that one carrier would have different CO switches than the previous carrier. It is part of the baggage that comes along with switching carriers in my mind.

This command: isdn map address .* plan unknown type unknown

will need to go away. I assume you have dial-peers floating around somewhere? You could apply translation-profiles to your configuration and normalize the calling and called party plan/types to whatever the carrier wants to see.

For example, if your carrier said to send them only 10-digits and flag the call as "national" for any NANP number then you could have something like this:

voice translation-rule 100

rule 1 /^1/ // type any national plan any isdn

!

voice translation-profile testprofile

translate called 100

!

They probably want you to identify the source plan and type too (meaning, call originated from your voice network). You can use a "translate calling" statement in a translation-profile to accomplish this (and other methods exist I am sure).

Note, the above example is oversimplified. There are some good examples all over CCO for this stuff. For example, http://www.cisco.com/en/US/customer/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml.

Search for: " Number Translation using Voice Translation Profiles" on CCO and you will pick up a few other links.

HTH.

Regards,

Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

dannypuckett · ‎04-09-2010

Thanks for the response.

The technicial who configured this originally has left the company and I have inherited it by default so I

am still very much learning as I go.

Here is the rest of my config including pots peers. I notice

that 'dial peer voice 15 pots' is missing a few lines and the number I am having issues with is a 1877 number which If I understand this would be the peer that matches this string. Could this be my problem?

Thanks again.

William Bell · ‎04-09-2010

You have a lot of VoIP configs in this config but no voip dial-peers. So, I am not sure what is going on there. The dial-peer 15 config is suspect, but I have to assume based on your other dial-peers this gateway is expecting to receive "9" for calls that are directed to the 0/2/0:23 interface. Meaning, "9" is for off net. So, I have to guess that 918773402600 is what is being received by the gateway. If that is the case, then dial-peer 4 would be the matched dial-peer. Now, if the gateway is not receive 9 18773402600 and is instead receiving 18773402600 then dial-peer 15 would be used. Then you would have a problem because the destination-pattern 18T, when applied to 18773402600, would mean that the carrier would receive 773402600. Which would be wrong on many levels.

Based on your q931 debug, I don't thing dial-peer 15 is being hit.

You can check which dial-peer is being used by leveraging "debug voice ccapi inout". This spits out a lot of data, so be forwarned.

You can also use a "show voice call status" to see the dial-peers used for both legs of the voice call.

To test, you could also try this:

dial-peer voice 1877 pots

description test dialpeer

destination-pattern 918773402600

forward-digits 11

translation-profile outgoing testnumplanchange

!

voice translation-rule 10

rule 1 // // type any national plan any isdn

!

voice translation-profile testnumplanchange

translate called 10

translate calling 10

!

The dial-peer assumes that the gateway is actually receiving 918773402600. If that is not the case, fix that issue first. I can only assume it is an issue based on the config provided, so that is my disclaimer. Assuming it is accurate then test with the above config.

You may have to play with it a little. I also suspect that if you are having this problem with this 18773402600 number, then you are having it with other numbers too. But, figure out the solution for this number first and then work on the system-wide application of said solution.

HTH.

Regards,

Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

dannypuckett · ‎04-12-2010

Ok, I have made the changes you suggested by adding a pots dial-peer for that specific number. It appears that the plan and type are being sent but the call is still being dropped with a fast busy. Not sure what to check from here.

101859: .Apr 12 10:09:25.898 EDT: ISDN Se0/2/0:23 Q931: Applying typeplan for sw
-type 0xD is 0x2 0x1, Calling num 6142216348
101860: .Apr 12 10:09:25.902 EDT: ISDN Se0/2/0:23 Q931: Sending SETUP callref =
0x0278 callID = 0x89A9 switch = primary-ni interface = User
101861: .Apr 12 10:09:25.902 EDT: ISDN Se0/2/0:23 Q931: TX -> SETUP pd = 8 call
ref = 0x0278
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98390
                Exclusive, Channel 16
        Facility i = 0x9F8B0100A115020156020100800D44616E6E79205075636B657474
                Protocol Profile = Networking Extensions
                0xA115020156020100800D44616E6E79205075636B657474
                Component = Invoke component
                        Invoke Id = 86
                        Operation = CallingName
                                Name Presentation Allowed Extended
                                Name = Danny Puckett
        Progress Ind i = 0x8183 - Origination address is non-ISDN
        Calling Party Number i = 0x2180, '6142216348'
                Plan:ISDN, Type:National
        Called Party Number i = 0xA1, '18773402600'
                Plan:ISDN, Type:National
101862: .Apr 12 10:09:26.574 EDT: ISDN Se0/2/0:23 Q931: RX <- CALL_PROC pd = 8
callref = 0x8278
        Channel ID i = 0xA98390
                Exclusive, Channel 16
101863: .Apr 12 10:09:27.842 EDT: ISDN Se0/2/0:23 Q931: RX <- PROGRESS pd = 8 c
allref = 0x8278
        Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band inf
o
101864: .Apr 12 10:09:41.066 EDT: ISDN Se0/2/0:23 Q931: TX -> DISCONNECT pd = 8
callref = 0x0278
        Cause i = 0x8090 - Normal call clearing
101865: .Apr 12 10:09:41.098 EDT: ISDN Se0/2/0:23 Q931: RX <- RELEASE pd = 8 ca
llref = 0x8278
101866: .Apr 12 10:09:41.102 EDT: ISDN Se0/2/0:23 Q931: TX -> RELEASE_COMP pd =
8 callref = 0x0278

Any suggestions?

Thanks for all the help so far.