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
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).
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?
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
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.
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
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...