Hi
I am exploring the applicability of pdb module in finnish number portability scheme. Looks like carrier id 000 cannot be used as zero is already reserved for "the number could not be found" result in pdb protocol.
(Queries seem to work after I changed MIN_PDB_CARRIERID in common.h to 0, but unfortunately that configuration just does not make sense.)
Is there any way out of this other than using internally different value for carrier 0? I rather use correct ids if somehow possible to avoid mapping logic in routing script.
Note about help text consistency: When going through pdbt.c there is this comment above import_csv function: /* Read a csv list from the given file and build a dtree structure. Format of lines in csv file: "<number prefix>;<carrier id>". Format of carrier id: "D[0-9][0-9][0-9]". Returns the number of lines imported or -1 on error. */ Isn't the third line incorrect? Same thing also in help text output of pdbt -h. docs/data_format.txt mentions letter D only in front of carrier name file. What is the meaning of D anyway in this context?
Here is my awk pipe contribution to scripts/get_carrier_names_finland.sh: curl -o - "http://www2.ficora.fi/numerointi/nure_numbering.asp?nums=tot&lang=en" | awk '/<tbody>/, /</tbody>/' | awk -F"</td" -v RS="</tr" '{ gsub(/.*>/,"",$1) gsub(/.*>/,"",$2); gsub(/ä/,"ä",$2); gsub(/Å/,"Å",$2); gsub(/ö/,"ö",$2); if ( $2 != "") { printf "D%.3d %s\n",$1,$2 } }'
On Sunday 12 September 2010, Mikko Lehto wrote:
I am exploring the applicability of pdb module in finnish number portability scheme. Looks like carrier id 000 cannot be used as zero is already reserved for "the number could not be found" result in pdb protocol.
Hello Mikko,
you're right, the carrier id 0 is somehow special. Probably its because this is not used for carrier ids from the german regulation authorities, i think has also some special meaning in old carrierroute versions.
(Queries seem to work after I changed MIN_PDB_CARRIERID in common.h to 0, but unfortunately that configuration just does not make sense.)
Do you refer to the fact that then also the internal logic of the module needs to be changed as well?
Is there any way out of this other than using internally different value for carrier 0? I rather use correct ids if somehow possible to avoid mapping logic in routing script.
Well, the module could be changed, that maybe could also use something like 997 or 998 for the "not found" id could be used.
Note about help text consistency: When going through pdbt.c there is this comment above import_csv function: /* Read a csv list from the given file and build a dtree structure. Format of lines in csv file: "<number prefix>;<carrier id>". Format of carrier id: "D[0-9][0-9][0-9]". Returns the number of lines imported or -1 on error. */ Isn't the third line incorrect? Same thing also in help text output of pdbt -h. docs/data_format.txt mentions letter D only in front of carrier name file. What is the meaning of D anyway in this context?
You're right, it should be only in the carrier name file. I'll fix this. Somehow this is used from german regulation authorities, it stands probably for the country name. We could probably change it, patches are welcome. ;-)
Here is my awk pipe contribution to scripts/get_carrier_names_finland.sh: curl -o - "http://www2.ficora.fi/numerointi/nure_numbering.asp?nums=tot&lang=en" | awk '/<tbody>/, /</tbody>/' | awk -F"</td" -v RS="</tr" '{ gsub(/.*>/,"",$1) gsub(/.*>/,"",$2); gsub(/ä/,"ä",$2); gsub(/Å/,"Å",$2); gsub(/ö/,"ö",$2); if ( $2 != "") { printf "D%.3d %s\n",$1,$2 } }'
Great, thank you! I'll add it to the repository, and also fix the german one (some changes in URL)
Henning
(Queries seem to work after I changed MIN_PDB_CARRIERID in common.h to 0, but unfortunately that configuration just does not make sense.)
Do you refer to the fact that then also the internal logic of the module needs to be changed as well?
Yes, exactly.
Well, the module could be changed, that maybe could also use something like 997 or 998 for the "not found" id could be used.
Those are part of the reserved range around here, but length is four starting from 9900. 0998 could be "not found" and 9900 first four digit carrier.
That would work for my case, maybe I'll try mapping zero to something else with my vintage C skills.
You're right, it should be only in the carrier name file. I'll fix this. Somehow this is used from german regulation authorities, it stands probably for the country name. We could probably change it, patches are welcome. ;-)
It's OK like that, I'll rather mess with the "not found" case for now.
Country prefix could actually be useful if one file has carrier names from multiple countries.
Great, thank you! I'll add it to the repository, and also fix the german one (some changes in URL)
Nice, I see you like wget more :)
On Monday 13 September 2010, Mikko Lehto wrote:
Do you refer to the fact that then also the internal logic of the module needs to be changed as well?
Yes, exactly.
Well, the module could be changed, that maybe could also use something like 997 or 998 for the "not found" id could be used.
Those are part of the reserved range around here, but length is four starting from 9900. 0998 could be "not found" and 9900 first four digit carrier.
That would work for my case, maybe I'll try mapping zero to something else with my vintage C skills.
Hello Mikko,
a more general solution would be of course nice.
You're right, it should be only in the carrier name file. I'll fix this. Somehow this is used from german regulation authorities, it stands probably for the country name. We could probably change it, patches are welcome. ;-)
It's OK like that, I'll rather mess with the "not found" case for now.
Country prefix could actually be useful if one file has carrier names from multiple countries.
Indeed, even if i don't think this is at the moment activly used for the lookup.
Great, thank you! I'll add it to the repository, and also fix the german one (some changes in URL)
Nice, I see you like wget more :)
Ah, sorry. It was just a matter of "its already installed on the test machine" as i wanted to give it a try. :-)
Regards,
Henning
-
Henning Westerholt -
Mikko Lehto