Re: [Enum] Overlap dialing user experience (Re: I-DAction: New draft - draft-bellis-enum-send-n-00)

[Paul Kyzivat <pkyzivat at cisco.com>]

Paul R,

Your reply was educational to me. Thanks.

You talk of this as primarily for SP, and question applicability to user 
enum. I understand that, I think. But the SP can only do this when it 
knows there is a call attempt. That works fine when it is a black phone 
connected to a SP server, sending digits one by one.

But what happens when the client phone is itself a sip UA? Even if it is 
going to delegate the call routing decisions to a SP server, it still 
has to determine the end of the dial string in order to know when to 
send an INVITE. So it seems that this DB needs to be accessible from 
those customer devices. How does that fit into your view?

	Paul K

Rosbotham, Paul wrote:
> Hi all
> 
> I too have been watching this debate with interest & biting my tongue, but threshold reached.
> 
> I chair the UK telecoms standards agency.  The concept of Send-N was developed there for usage in the numbering database that UK industry is currently procuring (more below), from a requirement agreed by a group that contains every major UK telco.  So, yes, we do sort of know that Ofcom provides a numbering plan because it's our day-to-day business.  We also know what it's issues are hence why we want something better.
> 
> I should at the outset say
> 
> - I'm ambivalent about bringing Send-N into the international domain & potential use of it in user-ENUM; I can see the attractions & issues, but my main concern is the introduction of our national database that I have a regulatory obligation to implement.
> - I apologise that a lot of this is UK-centric, however it is worthy of mention here because the issues are pretty much replicated wherever there's a variable length numbering plan.
> 
> So, to where Send-N originally arose.  We are currently putting together a database that is notionally for support of portability, but (subject to the economics) may well contain the association of every number to the terminating domain.  It will offer a real-time query interface using an ENUM-like approach, but most telcos will in practise download the whole thing into their networks and query locally (again, in many cases using a network-internal ENUM approach).
> 
> As Lawrence says, it is possible to take the Ofcom numbering plan and embed it into your callservers/switches, and use that to ascertain when you've got sufficient digits to query the database.  However,
> 
> - errors do creep into the plan.
> - for reasons that are too complicated/irrelevant to go into here, it isn't exhaustive, in particular in the 0800 ranges that Clive Feather mentioned in an earlier mail.
> - it is a large amount of data that uses significant technical resources on callservers/switches and human resources to keep up to date.
> ...for this reason I think every telco to some degree relies on interdigit timers in those areas of the plan with more variability.
> 
> Now, given we're introducing a common database of numbers, the users of that database (ie the telcos) felt it appropriate to add functionality to it to indicate when it had been queried with insufficient digits.  Otherwise, we yield the benefit of not having to break out each individual number range for routeing purposes on our callservers (database is telling you that info), only to lose it because we have to break them out to check we've got enough digits prior to querying the database.  
> 
> A sensible telco won't be querying the database each time an end-user keys a digit, there would still be some basic number length info in the callserver.  For example, in the geographic code 01744 I know there are 10 & 11 digit numbers so will query after 10, receiving a Send-1 if it turns out the individual level within 01744 is one which is 11 digits long.  Conversely, 01772 has only 11 digit numbers so I'll query after 11.  This means the number length tree I have to hold on my nodes is <1000 entries long, versus nearer 25,000 entries now.
> 
> There's a valid question of whether Send-N should have been in the same database as the individual numbers, but from our perspective we're building a common/private database, and it makes little sense to build/have to query two separate databases versus putting it in a single one.  As an individual number database, we don't have wildcards, and in any case in a regime with portability meaning the numbering space is highly fragmented they're of little value.  I doubt there are any number ranges in the UK that are used solely by a single telco with no exported numbers so wildcarding based on number range simply doesn't work (as highlighted by Richard Stastny's mail).
> 
> As I say, I'm ambivalent on the usage in public ENUM.  Certainly there appears to have been a misconception to date that ENUM clients will know when the user has completed dialling.  For fixed length plans and applications where the customer has a "send"/"call" key that is the case, but for blackphone support it certainly isn't without using interdigit timeouts.  The ITU information has been mentioned as helpful.  Thanks for that, I kicked off the initiative back in 2000 so glad to hear it's added some value.  However, it really isn't much more than a map to provide clues (either to number length or where to go to try to find out)...it certainly isn't a reliable or comprehensive source of data for originating telcos to know how many digits to expect on international calls.
> 
> Regards
> 
> Paul Rosbotham
> Manager, Interconnect Strategy & Technology Regulation 
> Cable&Wireless 
> Europe, Asia and US
> Direct Dial: +44 1772 451506
> Mobile: +44 7957 805573
> www.cw.com 
> 
> 
> 
> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
> Lawrence Conroy
> Sent: 09 April 2008 23:50
> To: Jay Daley
> Cc: enum at ietf.org
> Subject: Re: [Enum] Overlap dialing user experience (Re: I-DAction: New
> draft - draft-bellis-enum-send-n-00)
> 
> 
> Hi Jay, Brian, folks,
>   must resist - nope - I can't. This one has finally reached my  
> threshold.
> Jay - I know that you ARE aware of Ofcom's number plan docs. These have
> absolutely F. all to do with ENUM, or LDAP, or any other implementation.
> They are a representation of the national number plan in the UK, and  
> they
> DO give the digit length for each block. From this can be derived:
> (i) the set of general prefix-dependent number length rules, AND
> (ii) the number of digits needed to determine the route for calls to
>       numbers in any of these blocks.
> [NB - (i) and (ii) ARE NOT THE SAME].
> Looks pretty static to me (qua Ofcom-anointed number plan changes).
> 
> 
> 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
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum