Ron hotmail ha scritto:
The short answer is no, you will never have a situation where the
'local' part of the term number is mistaken for part of the dialcode.
for example,
your customer dials 0119647701773352 (Iraq mobile number)
Iraq 011964
Iraq-Baghdad 0119641
Iraq-Mobile 0119647701
this would cause a match on Iraq, and Iraq-Mobile, but not on baghdad,
the 'most' accurate match would be the dialcode with the most digits...
That's the way I'm doing it :
let's MAX_PRE_LENGHT be the maximum lenght for a prefix (as today it's
10, for 0061891006, Australia Christmas Island)
and DST_LENGTH the lenght of the called number (DST)
for i in range(min(MAX_PRE_LENGTH, DST_LENGTH)):
probablePrefix = DST[0:min(MAX_PRE_LENGTH, DST_LENGTH)-i]
select probablePrefix from a table with all the prefixes (and other
info you can need)
if we found something that's the prefix, break to the application
else continue with a smaller try
From the original post it seems there are two tables, one for the
country and one for the city, like having one table with
0011964 - Iraq
and one with
Iraq - 1 - Bagdad
Iraq - 7701 - Mobile
I don't know if this speed up things, in my case it surely won't since I
have a large-grained detail for locating the call (I'm not interested in
city codes, so for example I've only one entry for Italy, and not a lot
of entries like 'Italy Milan', 'Italy Rome'...) so a join would slow the
benefit of smaller values for MAX_PRE_LENGTH, it depends on the application.
Seems that when you need to have fine-grained detail the search is made
in reverse, for example message boxes for cellular phones :
<black box understanding warning>
if I call (not a real number, but I know a real example I won't post for
obvious reasons) 345 - 333444555 while the cell is off I get a voice :
"answer 333444555, the phone is off, leave a message"
if I call 345 - 3333333444555 the message is the same : "answer
333444555, the phone is off, leave a message"
so the search is made backwards, and the application starts as long as
only one possible match is found.
I don't even think we are talking about relational db here, probably
some directory to speed up things with a tree-search, anyone working in
the large who can confirm ?
</black box understanding warning>
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
