dial-peer config for international calling

Answered Question
Dec 22nd, 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

I have this problem too.
0 votes
Correct Answer by maciej@karpinski.se about 2 years 3 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4 (7 ratings)
acampbell Thu, 12/22/2011 - 14:26

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

Chris Deren Thu, 12/22/2011 - 14:40

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 Thu, 12/22/2011 - 15:01

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.

cooperben Fri, 12/23/2011 - 13:05

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 Fri, 12/23/2011 - 14:37

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 Tue, 12/27/2011 - 06:45

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 Tue, 12/27/2011 - 07:12

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

cooperben Tue, 12/27/2011 - 12:01

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.se Tue, 12/27/2011 - 13:14

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

Correct Answer
maciej@karpinski.se Tue, 12/27/2011 - 07:17

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 Tue, 12/27/2011 - 07:32

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 Thu, 12/29/2011 - 08:28

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 Thu, 12/29/2011 - 19:15

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

scott.jones@orr... Mon, 12/03/2012 - 18:05

i just have to say that almost a year after the last post here where ATT 'resolved' the issue, i just cut one of our offices over to CUCM, and sure enough, same thing!  as soon as i put the plan/type to unknown and tried it, it works like a champ!

Amazing that telcos like them continue to grow as they do in spite of themselves...

Actions

Login or Register to take actions

This Discussion

Posted December 22, 2011 at 12:42 PM
Stats:
Replies:15 Avg. Rating:4
Views:1803 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 21,026
2 15,047
3 10,314
4 7,999
5 4,856
Rank Username Points
154
95
75
66
55