Solved: dial-peer config for international calling

cooperben · ‎12-22-2011

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

Maciej Karpinski · ‎12-27-2011

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.

View solution in original post

acampbell · ‎12-22-2011

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

Regards, Alex. Please rate useful posts.

Chris Deren · ‎12-22-2011

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

cooperben · ‎12-22-2011

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.

Chris Deren · ‎12-22-2011

You can restart the DNA service to see if that helps.

Chris

cooperben · ‎12-23-2011

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?

Chris Deren · ‎12-23-2011

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

cooperben · ‎12-27-2011

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!

Carlo Poggiarelli · ‎12-27-2011

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

Please rate all helpful posts "The more you help the more you learn"

cooperben · ‎12-27-2011

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

Maciej Karpinski · ‎12-27-2011

Then it seems as AT&T doesn't allow calls marked international, it should work if you remark all international calls as unknown.

Maciej Karpinski · ‎12-27-2011

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.

cooperben · ‎12-27-2011

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.

cooperben · ‎12-29-2011

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

arnela.jokhoo · ‎12-29-2011

Yes! it maybe Service Provider issue maybe with another telco switching its routed through for certain numbers only.