• Handling virtual numbers

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Create a separate tree (i.e. virtual.nrenum.net) to populate the virtual numbers completely separate. It also means that the virtual tree must be queried separately.

Guarenteed Guaranteed separation

An other tree to query in a sequential order.

(There is no operational golden tree so to resolve URI we have to query multiple tree anyway. IMHO I don't see it as a big drawback to query plus one tree.)

The resolver can very cleanly decide if it want to use virtual numbers or not.
Furthermore resolver can decide the order of preference of virtual and not virtual numbers.
Zero time to wait for anybody and for anything, we can do it now.
There is no need to wait for ITU to permit (if ever permit) a new country code.
I prefer to delegate it the the same way as the nrenum.net tree, so every country prefix is delegated to the country, and every country can create a local policy. 
Countries are not the same so this way the delegation is not centralized, so this way it is not underestimating the local knowledge, differences, national authority policies etc. 

In this virtual tree all number range could be delegated what are

  1. Not part of the national numbering plan
  2. Or what the national authority sated as a "test",  "sandbox" , or "VoIP" etc. number range

If the country national dialing plan has such range inside the county code (see "point 1, and 2. above") we will see the country code prefixed calling number on our endpoint if it rings. So country codes are "well known" so we and all people, who use the service, can know from calling number the locality of the caller. What i think is a useful information.
e.g. We can change the language if we pick up the phone and say "Good morning.", and not "Pálinkás jó reggelt!".

In other hand if we e.g. get from ITU +999 country code. (I use for example only +999 country code. Of course we could get another country code.)
If we delegate the real country code inside this +999 country code then we need to teach the world(to the "users") what prefix belongs to what country.
e.g. how to parse +99936 prefix, it is the Hungarian virtual number prefix.
I think it is not possible in short term to teach the world, so average user will not know that this call comes from Hungary.

So for end user it will be confusing to get a call from a +99936 virtual number range,
and if we use only +999 and centralize the dialplan then we loose the locality information also of the caller.

Option 2 (propsed by Bernie)