[Dundi] representation

[Joe Abley]

On 26 Oct 2004, at 12:22, Mark Spencer wrote:

>> Both +1700 and +1800 seem like parts of the E.164 number space which 
>> do not fit well within any system which seeks to answer questions 
>> like "where should I terminate a call to address B?". Maybe what is 
>> needed is an extension to provide answers for "where should I 
>> terminate a call to address B from address A?".
>
> what about 888, 866, 877 etc.  does that hold true for those numbers 
> as well?

My experience as a consumer of those numbers says "yes". It also holds 
for +64800 and +64508 numbers, and I'm sure many other countries have 
similar non-unique number termination schemes.

I think the issue of whether there is just one company which operates a 
given +1800 number (or equivalent numbers in other countries) is 
orthogonal to the problem, incidentally (since other people mentioned 
it), since I don't believe it's possible in general for the called 
party to route the call appropriately anyway.

> If we have to use callerid, that could be very damaging to the cache 
> if not properly implemented.

Geographic call routing is possible in the PSTN regardless of whether 
CLID is withheld from the called party. This suggests that there are 
PSTN services which will not map to dundi routing if the called party 
is left to route the call based on CLID alone.

Perhaps the model should be that sufficient information needs to be 
returned in the answer to the routing question to allow the station 
asking the question to route the call appropriately. This implies the 
ability to answer questions in the manner of "terminate +18005551212 
here for callers from +1519,+1905,+1416,+1705,+1902,..."; if multiple 
such answers are received, the originator of the call can then make an 
informed decision on where to route it, regardless of the presence or 
absense (or usefulness) of CLID on a particular call.

Since all the providers of such answers are effectively present in the 
number space in the same place, this seems like it has half a chance of 
not mutating the current caching scheme (there would just be more 
answers to cache).


Joe