Solved: Major errors in GB number plan 1.1.18, 2.1.18 and 3.1.18. - Page 3

g1smdvoip · ‎09-19-2012

Originally posted: 2012-Sep-18.

About a year ago, I informed Cisco that various pieces of documentation detailing the GB number plan were inaccurate, incomplete, and out of date.

The majority of the published data seemed to be from some time back between 2003 and 2006, but with a substantial number of additional errors and inaccuracies and certainly not up to date.

It has taken many months to get the documentation amended with the correct information, but those changes do not appear to have made it back into the software.

I have recently seen a copy of the cisco GB number plan version 18 'dp-ffr.1-1-18.GB.exe', 'dp-ffr.1-1-18.GB.cop.sgn', 'dp-ffr.2-1-18.GB.cop.sgn' and 'dp-ffr.3-1-18.GB.cop.sgn', released only a few weeks ago, and that still has the same and many other errors included.

The faulty GB number plan file is as detailed at:

http://www.cisco.com/cisco/software/release.html?mdfid=278719042&softwareid=282074292&release=1.1.18-GB-NZ&os=Windows

http://www.cisco.com/cisco/software/release.html?mdfid=278719042&softwareid=282074292&release=1.1.18-GB-NZ-&os=Linux

http://www.cisco.com/cisco/software/release.html?mdfid=278719042&softwareid=282074292&release=2.1.18-GB-NZ&os=Linux

http://www.cisco.com/cisco/software/release.html?mdfid=278719042&softwareid=282074292&release=3.1.18-GB-NZ&os=Linux

Visit the above pages, mouseover the details there, then look for the 'flat pattern file' link in the popup box, specifically:

http://www.cisco.com/web/software/282074292/51298/GBNP.txt

This file contains a large number of errors.

I enclose the original and a corrected version of the 'flat pattern file'. The corrected version has dozens of fixes detailed within.

This file contains a large number of errors.

g1smdvoip · ‎09-29-2012

The same list of errors from above also applies here

'cm-locale-english_united_kingdom_CP-8.6.3.10000-12.cop.sgn'

'cm-locale-english_united_kingdom_CP-8.6.3.10000-13.cop.sgn'

'cm-locale-english_united_kingdom_CP-8.6.3.10000-14.cop.sgn' (but with some items in a slightly different order):

http://www.cisco.com/cisco/software/release.html?mdfid=283783671&softwareid=282074333&release=en_UK-CP-8.6.3

Visit the above page, mouseover the details there, then look for the 'flat pattern file' link in the popup box, specifically:

http://www.cisco.com/web/software/282074333/89132/GBNP.txt

This file contains a large number of errors.

I enclose the original and a corrected version of the 'flat pattern file'. The corrected version has dozens of fixes detailed within.

g1smdvoip · ‎09-30-2012

The number plan file detailed in 'cm-locale-english_united_kingdom_CP-8.6.3.10000-12.cop.sgn', 'cm-locale-english_united_kingdom_CP-8.6.3.10000-13.cop.sgn', 'cm-locale-english_united_kingdom_CP-8.6.3.10000-14.cop.sgn' and http://www.cisco.com/web/software/282074333/89132/GBNP.txt contains some extra rules compared to the number plan file detailed in the first post in this thread.

There's one extra rule for freephone numbers

# 0+800XXXXXX+#

P: 0 NATIONAL-ACCESS

P: 800XXXXXX FREEPHONE-NUMBER

P: # END-OF-DIALING

T: N

U: Y

and five extra rules for service numbers

# 11600[06]+!+#

P: 11600[06] SPECIAL-SERVICE

P: ! SUBSCRIBER

P: # END-OF-DIALING

T: N

U: Y

# 11611[17]+!+#

P: 11611[17] SPECIAL-SERVICE

P: ! SUBSCRIBER

P: # END-OF-DIALING

T: N

U: Y

# 116123+!+#

P: 116123 SPECIAL-SERVICE

P: ! SUBSCRIBER

P: # END-OF-DIALING

T: N

U: Y

# 141+!+#

P: 141 SPECIAL-SERVICE

P: ! SUBSCRIBER

P: # END-OF-DIALING

T: N

U: Y

# 1800[1-9]+!+#

P: 1800[1-9] SPECIAL-SERVICE

P: ! SUBSCRIBER

P: # END-OF-DIALING

T: N

U: Y

Should these rules also appear in the other file, or are they needed only in this one?

Why the difference?

g1smdvoip · ‎10-02-2012

Be aware that I corrected a typo in Item 12 several days ago and a typo in Item 3 and in Item 13 yesterday.

The posts above were updated and the two "corrected" files were also re-uploaded with all the corrections applied.

The updated files can be found at:

https://supportforums.cisco.com/servlet/JiveServlet/download/3737680-136005/GBNP-18-CORRECTED.txt.zip

https://supportforums.cisco.com/servlet/JiveServlet/download/3746762-136006/89132-GBNP-CORRECTED.txt.zip

g1smdvoip · ‎10-03-2012

I have taken the two "corrected" files mentioned above and sorted the entries within each one into a more logical order and, crucially, the data is now sorted in exactly the same order within both files.

This more clearly shows the differences between the two files (the six extra rules noted above and other differences).

The original number plan files included section headings for different number types, but many of the entries within each file were found to be in the wrong section.

The old headings were:

# Long Distance Calls

# International Calls

# Services, Mobile & Non Geographic Calls

# 5 Digit AC + 5 digit Subs

# 4 Digit AC + 5 digit Subs Part 1

# 4 Digit AC + 5 digit Subs Part 2

# 4 Digit AC + 5 digit Subs Part 3

# 4 Digit AC + 5 digit Subs Part 4

in one file, and

# Long Distance Calls

# International Calls

# Services, Mobile & Non Geographic Calls

in the other file.

I have created new section headings in both files and fixed the other problems too.

The new section headings are:

# Local Calls

# Long Distance Calls - 10 digits

# Long Distance Calls - 9 digits

# Non-geographic Numbers Charged at Geographic Rates

# VoIP, Corporate, Personal and Pager Numbers

# Mobile Numbers

# Non-geographic Numbers - 10 digits

# Non-geographic Numbers - 9 digits

# Non-geographic Numbers - 7 digits

# Premium Rate Numbers

# International Calls

# Services

The two new "reordered" files are linked from this post.

g1smdvoip · ‎10-05-2012

Some number ranges were duplicated in the original file but with slightly different rules. As I am unsure how the software works internally, I didn't address this issue in any of the above comments. The only other decision that has to be made is which of the duplicates to use and which to delete.

For numbers with a 5 digit area code and 5 digit subscriber numbers, use this?

# 0+13873+[2-9]XXXX

P: 0 NATIONAL-ACCESS

P: 13873 5DIGIT-SPECIALAREA-CODE

P: [2-9]XXXX SUBSCRIBER

T: N

# 0+15242+[2-9]XXXX

P: 0 NATIONAL-ACCESS

P: 15242 5DIGIT-SPECIALAREA-CODE

P: [2-9]XXXX SUBSCRIBER

T: N

# 0+1539[456]+[2-9]XXXX

P: 0 NATIONAL-ACCESS

P: 1539[456] 5DIGIT-SPECIALAREA-CODE

P: [2-9]XXXX SUBSCRIBER

T: N

# 0+1697[347]+[2-9]XXXX

P: 0 NATIONAL-ACCESS

P: 1697[347] 5DIGIT-SPECIALAREA-CODE

P: [2-9]XXXX SUBSCRIBER

T: N

# 0+1768[347]+[2-9]XXXX

P: 0 NATIONAL-ACCESS

P: 1768[347] 5DIGIT-SPECIALAREA-CODE

P: [2-9]XXXX SUBSCRIBER

T: N

# 0+19467+[2-9]XXXX

P: 0 NATIONAL-ACCESS

P: 19467 5DIGIT-SPECIALAREA-CODE

P: [2-9]XXXX SUBSCRIBER

T: N

or this?

# 0+13873+[2-9]XXXX
P: 0                             NATIONAL-ACCESS
P: 13873                         AREA-CODE
P: [2-9]XXXX                     SUBSCRIBER
T: N
# 0+15242+[2-9]XXXX
P: 0                             NATIONAL-ACCESS
P: 15242                         AREA-CODE
P: [2-9]XXXX                     SUBSCRIBER
T: N
# 0+1539[456]+[2-9]XXXX
P: 0                             NATIONAL-ACCESS
P: 1539[456]                     AREA-CODE
P: [2-9]XXXX                     SUBSCRIBER
T: N
# 0+1697[347]+[2-9]XXXX
P: 0                             NATIONAL-ACCESS
P: 1697[347]                     AREA-CODE
P: [2-9]XXXX                     SUBSCRIBER
T: N
# 0+1768[347]+[2-9]XXXX
P: 0                             NATIONAL-ACCESS
P: 1768[347]                     AREA-CODE
P: [2-9]XXXX                     SUBSCRIBER
T: N
# 0+19467+[2-9]XXXX
P: 0                             NATIONAL-ACCESS
P: 19467                         AREA-CODE
P: [2-9]XXXX                     SUBSCRIBER
T: N

For numbers with a 5 digit area code and 4 digit subscriber numbers, use this?

# 0+16977+[23]XXX

P: 0 NATIONAL-ACCESS

P: 16977 5DIGIT-SPECIALAREA-CODE

P: [23]XXX SUBSCRIBER

T: N

U: Y

or this?

# 0+16977+[23]XXX

P: 0 NATIONAL-ACCESS

P: 16977 AREA-CODE

P: [23]XXX SUBSCRIBER

T: N

U: Y

For 03 numbers, use this?

# 0+3[0347]X+XXXXXXX

P: 0 NATIONAL-ACCESS

P: 3[0347]X AREA-CODE

P: XXXXXXX SUBSCRIBER

or this?

# 0+3[0347]XXXXXXXX
P: 0                             NATIONAL-ACCESS
P: 3[0347]XXXXXXXX               03-NUMBER
T: N

dcrabbe · ‎11-02-2012

Wondering if anything had come of this?

Also looks like the GBNP is unusable in the new, Cisco advocated +e164 dialling scheme:

9.@ with (AREA_CODE EXISTS AND SUBSCRIBER EXISTS) matches UK national number including leading 0 (should require NATIONAL_ACCESS)

90.@ with (AREA_CODE EXISTS AND SUBSCRIBER EXISTS) doesn't match UK national numbers

is the AREA_CODE actually implemented with the leading 0?

g1smdvoip · ‎11-02-2012

Last I heard is that TAC are trying to convince another department to update the dial plan installer. It's a year since I first raised these issues.

I don't know how the area code is implemented by Cisco.

Technically, what we call an area code (e.g. 020, 0118, 01750 or 015395) in the UK, consists of two elements:

- a leading 0 (Trunk Code) that signifies that what follows is a non-local number,

- the NDC (National Destination Code), e.g. 20, 118, 1750 or 15395.

The 0 (Trunk Code) is not dialled from abroad, nor should it appear in an E.164 representation of a UK number.

In transforming a number from national to international format and vice versa, the 0 has to be stripped or inserted as appropriate, e.g. 020 3555 7788 <--> +44 20 3555 7788 and what is actually dialled depends on where you are calling from: 3555 7788 or 020 3555 7788 from within London, 020 3555 7788 from outside London, 00 44 20 3555 7788 from Europe, Africa and Asia and 011 44 20 3555 7788 from US/Canada, etc. I don't know exactly how Cisco implements these details.

This thread has been viewed 2000 times. Crikey!

dcrabbe · ‎11-02-2012

Agree ( I'm UK based).

I'm currently trying to build an international cluster using the new dial plan scheme where everything is built upto an +E164 format before being routed.

i.e user dials 9 0 131... and this is built up to +44131... before being routed.

to do this you need to be able to match the full number and strip out the NATIONAL_ACCESS leading 0

The above filters should do this (90.@ with a filter excluding the NATIONAL_ACCESS code)

yet they don't work as the AREA_CODE parameter seems to include the 0

As proof, 90.@ (AREA_CODE exists and SUBSCRIBER exists) doesn't match a 90131... number but does match the same number dialled as 900131...

g1smdvoip · ‎11-18-2012

I'm having trouble understanding (and especially given the level of detail provided above) how, after another two months, there's still no sign of any fix.

It took less than an hour to find and list all of the problems and another hour or so to write descriptive text for all of the issues. I can't see it taking more than a day or two to edit the respective files, and a few days to test-dial a whole bunch of phone numbers to verify those fixes.

Seriously, what's the hold up? It's now a year since I first raised these issues by email with various departments. Back then I imagined that the whole process would take a couple of weeks or so.

Stephen Leach · ‎11-19-2012

I am baffled as to the time taken by Cisco to address these issues.

Ian has put time and effort into this issue and provided very concise and well documented information detailing the failings in the UK/GB dial plan.

IMHO this should be escalated within Cisco to ensure that the correct dial plan exists and is not only distributed for current distributed with the installation media.

Thanks to Ian for highlighting and providing these updates a job very well done!

Can Cisco please advise status and ETA for release of the corrected dial plan?

Best regards

Steve

g1smdvoip · ‎12-19-2012

I have no idea what the problem is: staffing, will-power, know-how, internal politics, not-invented-here syndrome, or what.

Joseph Martini · ‎12-19-2012

To everyone on this thread, please contact your Cisco account representative and reference the internal bug opened for this CSCuc48084. This is low on the development priority list at this time so it will take a large push from the accout side to get this fix prioritized. Additionally if everyone opens a TAC case about this, we can attach every case to this defect and mark it external to show interest in the fix in addition to the pressure from the account side. Thanks.

Gordon Ross · ‎12-19-2012

Getting my SE & Account Manager to lean internally on this one bug isn't the issue. We really need Cisco to commit to keeping these up-to-date. At least a regular revision schedule for them. And that's a longer term problem which is harder to achieve. We need buy-in from the CUCM product managers to devote resources to it.

GTG

Please rate all helpful posts.

paolo bevilacqua · ‎12-19-2012

True. And having seen this kind of situations before, usually the answer from the wise PM is, sorry, we don't have resources, and they move on.

Evidently, what is important for customers, it is not for Cisco, and vice-versa.

Gordon Ross · ‎12-19-2012

Up-to-date localised dial-plans don't sell CallManager (and hence make Cisco money) Sexy/shiny new features do. So guess where the finite engineering resources are going to be focused...

GTG

Please rate all helpful posts.