Re: Send-n, rat holes and real issues

"Rosbotham, Paul" <[email protected]>
Newsgroups gmane.ietf.enum
Message-ID <CF70278861C76843835D4160627745D204CD33@GBCWSWIEM001.ad.plc.cwintra.com>
ok, I'll attempt to decode for you (although the need to do this highlights the need for some kind of system, be that SEND-N or something else) :

S1_Code : the field "Number Length" is of the form X+Y, where X = national destination code (area code) and Y is local number.  So 0+10 means 10 digit NSN with no area code, 4+6 means 4 digit area code with 6 digit local number etc etc

S3_Code : in principle the "Number Length" field would report the number length, but since for 03 numbers they're uniform 10 digits, it hasn't been populated.

S5_Code : the "Notes" field contains the number length

S7_Code : as S5

S8_Code : as S5.  Note that the 0500 range is contained within S8 rather than S5 because it is a historic code that falls within the definition of 08 (ie 0500 is legacy freephone, and nowadays all new freephone is within 080).  Note also that there is a significant amount of churn in this file so whatever analysis you do now will be outdated within days/weeks.  In brief, whenever a range marked as "Allocated(Closed)" - which will always be 9 digit numbers - becomes totally clear, it is re-allocated as a 10 digit number range (obviously with 10x as many numbers).  The frequency of this is unpredictable as it's driven by customer behaviour.

S9_Code : as S5.

I note that both S8 and S9 have rows with no entry in the Notes field.  I would assume that these are 10 digits long, but this is an assumption.  Perhaps this re-inforces that getting the data is a non-trivial activity?  

Although we've used the UK as an example, my experience is that the majority of countries' numbering plans present such difficulties when attempting to decode, and because as an originating carrier we need to provide any-any connectivity globally, we're forced into the position of having to attempt to do that.  Each time we get it wrong, we either lose $$$s due to calls being unable to complete, or present a lousy customer experience via post dial delay.

Regards

Paul


-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Duane
Sent: 08 July 2008 14:56
To: [email protected]
Subject: Re: [Enum] Send-n, rat holes and real issues


[email protected] wrote:
>> Do you have a URI or data set I can run a script over?
> 
> It's all at 
> http://www.ofcom.org.uk/telecoms/ioi/numbers/numbers_administered/

Length is one of the fields in both the excel files and CSV files but
doesn't seem to be in any rows, you said the regulators has a fair idea
of this information, do they publish it at all?

-- 

Best regards,
 Duane
_______________________________________________
enum mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/enum

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.