12-22-2011 12:42 PM - edited 03-16-2019 08:40 AM
Users are complaining that international calls cannot be made. Recently, route patterns were updated to using explicit patterns, whereas before only 9.911 and 9.@ were defined (with no route filters). I'm not sure if this has anything to do with it. My main concern here is with the config for international calling on our 3825 ISR gateway (IOS 12.4T), which was not altered when the route patterns were.
I've pasted in relevant config below (let me know if more is needed). Under dial-peer 71, should that destinantion-pattern be 9.011T? And is the prefix command necessary now that a 9.@ route pattern is no longer defined in the CUCM? I'm concerned that this setup (installed prior to my employment) is configured for use with a 9.@ route pattern, instead of with explicitly defined patterns. For example, users get a fast busy when dialing London: 90114420xxxxxxxx, but the number is reachable by cell phone.
I'd appreciate a once-over of this config. If it looks good, then I guess I will take it up with the telco (AT&T). TIA
In CUCM:
9.011! and 9.011!# route patterns defined for international calling.
We only have one GW, Route Grp/List, and all memberships in the proper partitions and CSS's have been verified on the users.
In the IOS:
voice translation-rule 71
rule 1 /011/ /011/ type international national
voice translation-profile internat
translate called 71
dial-peer voice 1 pots
destination-pattern 9.T
incoming called-number .T
direct-inward-dial
port 0/0/0:23
dial-peer voice 71 pots
translation-profile outgoing internat
destination-pattern 9011T
port 0/0/0:23
prefix 011
Solved! Go to Solution.
12-27-2011 07:17 AM
Hi
Do you have primary-ni as switchtype? If you dial a 15-digit number the gateway will set the numbering plan to International and some of the telcos in US doesn't allow other numbering plans than unknown
Try to add the following to your serial interface
isdn map address ^011* plan unknown type unknown
For more information check out CSCdj64195 on Cisco But Toolkit.
12-22-2011 02:26 PM
Hi,
This case follows on from yesterday.
When you had the 9.@ pattern did you hide it with an obscure prefix like #*#9.@ or
did you delete it?
Also can you look at your 9.011! & 9.011!# patterns
Are they set to discard any digits ?
Leave you router alone for the present as the config look good
Regards
Alex
12-22-2011 02:40 PM
Also, ensure the 9.011! & 9.011!# patterns are in correct partition and point to expected Route List. You can also use Dialed Number Analyzer to analyze the routing path.
HTH,
Chris
12-22-2011 03:01 PM
Alex: I ended up deleting 9.@ after I saw no Dependencies on it. Those route patterns do not strip digits. In fact, the only thing changed from the defaults on their pages was to select the Route List, (we only have 1 Route List and 1 Route Group. They use the settings from the Device Pool because we only have one of those too.)
I'm not convinced that removing 9.@ is the culprit for not being able to dial international, as I see international calls in CAR after removing it. AT&T is doing some work in our building, so that is a coicidence. But they also claim no trouble with the PRI and I don't see any issues or errored seconds on the interface. This is why I started looking at the ISR's config.
Chris: I havent tried the dna because every time it tells me "dna is still initializing, try again after some minutes." I wait and wait, but it never clears, so basically I can't use it.
12-22-2011 03:05 PM
You can restart the DNA service to see if that helps.
Chris
12-23-2011 01:05 PM
Chris, I restarted the service a few times and still have had no luck. I realize the dna would be very useful right now, but I don't want to get off track with that and can follow up with the TAC on getting it running.
As for the issue with international dialing, does anythinhg jump out at anybody?
12-23-2011 02:37 PM
Can you reproduce the problem? If so do you see the call hitting the GW? If yes, can you provide output of "debug isdn q931"?
HTH,
Chris
12-27-2011 06:45 AM
Chris: I've been out out of the office for the Holidays and returned today to try out your suggestion.
On the ISR, I ran 'term mon' and then 'debug isdn q931'. Then I dialed a number in London from my extension 3704 and here was the output as I received a fast-busy for the call:
000511: Dec 27 08:42:34.217 CST: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 13
000512: Dec 27 08:42:34.221 CST: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0128 callID = 0x80A9 switch = primary-ni interface = User
000513: Dec 27 08:42:34.221 CST: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0128
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98396
Exclusive, Channel 22
Calling Party Number i = 0x0081, '3704'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x91, '0114420xxxxxxxx'
Plan:ISDN, Type:International
000514: Dec 27 08:42:34.309 CST: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8128
Channel ID i = 0xA98396
Exclusive, Channel 22
000515: Dec 27 08:42:34.313 CST: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x8128
Cause i = 0x829F - Normal, unspecified
Progress Ind i = 0x8488 - In-band info or appropriate now available
000516: Dec 27 08:42:43.458 CST: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0128
Cause i = 0x8090 - Normal call clearing
000517: Dec 27 08:42:43.474 CST: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x8128
000518: Dec 27 08:42:43.478 CST: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0128
EDIT: When trying a number for our affiliate in Seoul, South Korea, the call goes through and rings! I know that the London number is good, because it is reachable my cell phone. I am thinking more and more that this may be an issue for the telco!
12-27-2011 07:12 AM
Hi.
Can you send us the output of the same debug command for a call to South Corea and the output of your VG run conf?
Thanks.
Regards
Carlo
12-27-2011 12:01 PM
Carlo: Here is the debug output for the successful call from my extension 3704 to South Korea. The Called Number is Samsung Headquarters. As you can see it shows Type Unknown.
000569: Dec 27 13:57:09.636 CST: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0 0x0, Calling num 3704
000570: Dec 27 13:57:09.636 CST: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x019C callID = 0x811D switch = primary-ni interface = User
000571: Dec 27 13:57:09.636 CST: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x019C
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98396
Exclusive, Channel 22
Calling Party Number i = 0x0081, '3704'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '01182313802114'
Plan:Unknown, Type:Unknown
000572: Dec 27 13:57:09.688 CST: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x819C
Channel ID i = 0xA98396
Exclusive, Channel 22
000573: Dec 27 13:57:12.684 CST: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x819C
Progress Ind i = 0x8488 - In-band info or appropriate now available
000574: Dec 27 13:57:23.449 CST: %SEC-6-IPACCESSLOGNP: list 23 permitted 0 10.x.x.x -> 0.0.0.0, 2 packets
000575: Dec 27 13:57:25.125 CST: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x019C
Cause i = 0x8090 - Normal call clearing
000576: Dec 27 13:57:25.149 CST: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x819C
000577: Dec 27 13:57:25.149 CST: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x019C
12-27-2011 01:14 PM
Then it seems as AT&T doesn't allow calls marked international, it should work if you remark all international calls as unknown.
12-27-2011 07:17 AM
Hi
Do you have primary-ni as switchtype? If you dial a 15-digit number the gateway will set the numbering plan to International and some of the telcos in US doesn't allow other numbering plans than unknown
Try to add the following to your serial interface
isdn map address ^011* plan unknown type unknown
For more information check out CSCdj64195 on Cisco But Toolkit.
12-27-2011 07:32 AM
Maciej: Yes, that is our isdn switchtype. I will try that change after-hours tonight. In the meantime, I have opened and escalated a case with our telco/LD provider, AT&T.
12-29-2011 08:28 AM
OK, so I have finally got AT&T to admit that they are experiencing "international interconnect issues" in our area. Previously the config in the ISR as shown above worked just fine for calls to London, but not anymore.
Maciej, adding the command you provided to the serial interface to classify the calls as unknown works around the issue. With it on the interface, I can call London as before, and the 'debug isdn q931' output shows all calls with the 011 prefix going out as Unknown. I am leaving this command on the interface for now so that users can dial London as before. Once AT&T says they have "solved" the issue (and I use that term loosely), I will remove the command and test again with the original configuration.
Many thanks to all that have contributed to this thread. A successful workaround has been provided and I am confident the issue was never with our equipment or configuration. (As a side note pertaining to my question that spun off into this thread, I have not seen any problems or heard any complaints after removing the 9.@ route pattern entirely from our CUCM configuration.) Happy New Year
12-29-2011 07:15 PM
Yes! it maybe Service Provider issue maybe with another telco switching its routed through for certain numbers only.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide