• Handling virtual numbers
Skip to end of metadata
Go to start of metadata

This working document is to discuss the potential technical solutions for handling virtual numbers in the NRENum.net tree.

Basic design principles

  • NRENum.net tree must be clean as much as possible, i.e. virtual and valid PSTN numbers must be kept separate.
  • TERENA, or any other service coordination body, should not be in charge of the allocation of virtual number ranges to service participants.
Option 1 (proposed by Misi)

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.

Example:
  • Valid numbers in Hungary (+36): ...6.3.nrenum.net
  • Virtual numbers in Hungary (+36): ...6.3.virtual.nrenum.net
ProsCons

Peter: Guaranteed separation

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

Peter: 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.)

Misi: 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.

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.

 

Mariano: I do not agree with this situation. I prefeer one nrenum.net tree. In my opinion the creation of a new tree like v.nrenum.net is unnecessary, adds complexity to the management of resources and is also confusing.
Misi: 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.
Rui:

That remembers me of a very old e-mail I’ve sent a few years ago… “how many trees are too many?”… https://www.terena.org/mail-archives/tf-vvc/msg00792.html

I don’t agree with this also.
  
Option 2 (propsed by Bernie)

Choose an 'unused' country code, delegate that code as a virtual country in the NRENum.net tree, and populate the virtual numbers under that county code. The virtual country code must be selected in line with the ITU-T numbering plan.

Option a) is to use a flat virtual numbering plan, not to create holes. Virtual number blocks must be administrated (e.g. by TERENA).

Option b) is to reproduce the traditional country codes under the virtual CC.

Example (assuming that the virtual CC is +999):
a) If flat numbering is used:
  • Valid numbers in Hungary (+36): ...6.3.nrenum.net
  • Virtual numbers in Hungary (+36): ..(assigned block for Hungary).9.9.9.nrenum.net

Pros

Cons
Peter: No separate tree to query

Peter: The country code must be carefully selected:

  • h323.net uses +878 4010 xxx
  • Intrenet2's suggestion is: +83
  • Simon H. suggestion is: +10 (it's not under US +1[1-9])
  • Voxbone is offering +883 5100 xxx
Rui: We can just take one prefix anyway… If this gets just “too big to fail”, there will be no way to take it back and ITU-T and others will just have to play along with the “de facto” configuration.Peter: Basic design principle #2 (see above) must be revised!!!

Simon: I suggest NRENUM pick a number like "+10" which is in complete political deadlock "Is it in US +1? No because the US is actually +1[1-9]. IMHO +10 is never ever going to be assigned. +83 or something else might get assigned.

IMHO I would NOT even attempt to get it through the ITU until there is a massive install base using the number plan to give it some credence.

Misi: I think it is bad idea to centralize and give the power to govern the worldwide virtual numbering plan to one entity. I prefer country wide distributed model as it is works in the golden E164 tree. IMHO never works to pressuring from a central organization a uniform policy to every country. People (so we) are very different (kind) country by country, never underestimate this.

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.

 

Alex: It seams to me that creating a unique, flat global numbering should look like a new skype, msn or google talk service, but using numbers instead of usernames.

If calls can be initiated or terminated in PSTN (yes, it is true) and if we choose for a centralized model, we can assume the risk to bring particular country characteristics (as regulatory issues) to this central office. I am not sure if a centralized model is better than a decentralized one. ENUM (and NRENum.net), as it is today, seams for me to be the best way to deal with this issue. Divide and conquer.  

  

b) If traditional CC plan is maintained:
  • Valid numbers in Hungary (+36): ...6.3.nrenum.net
  • Virtual numbers in Hungary (+36): ...6.3.9.9.9.nrenum.net

Pros

Cons
IN ADDITION TO THE ABOVE

IN ADDITION TO THE ABOVE

Peter: Basic design principle #2 (see above) is okay.

Rui: This will take you out of one hole and put you on an another one… think of these “virtual” numbers as IP addresses… IP addresses are managed in blocks rather on geography. It worked for IP addresses, why not use the same strategy. Give blocks of numbers based on requests presented by organizations… (thinking out of academic world here…)

People dial people, not countries… Historically Country prefixes are there because of national control, routing and invoicing purposes, not because they are easy to the users. The internet game is very different and (IMHO) VoIP is an Internet like game, therefore, we should be more and more near the Internet model rather than on the PSTN model of doing stuff.

Misi:

If the country national dialing plan has such range inside the county code 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!".

 
  
Option 3 (proposed by Kewin)

Check the national numbering plans if there is a dedicated number range reserved for VoIP service or test purposes or add more digits to the existing numbers.

Option a) Use holes in the number ranges of the national plans to populate virtual numbers.

Option b) Put additional digits to the existing valid numbers.

a) Example (assuming that the reserved number range in Hungary is +36 55):
  • Valid numbers in Hungary (+36): ...6.3.nrenum.net
  • Virtual numbers in Hungary (+36): ...5.5.6.3.nrenum.net
ProsCons
Peter: No separate tree or country codePeter: What if there is no such a number range
Mariano: I agree with option 3. In fact we are currently doing this in Argentina without problems. We use prefix 8 after CC for virtual numbers.
For example: +548416001 is a VN (... and +543534539100 is valid PSTN number). Keeping this scheme (option 3) is important to us, because we have several services that require virtual numbers (videoconferencing, fixed or mobile extensions) .

Rui: That was what I've done back in 2002 for GDS and VC systems. We use the "4" as the "IP network prefix", as it isn't used on PSTN. After these years I've found that I don't have the time to manage this, it is of little perceived value from management, indifferent to the user and didn't become a standard nationally (private companies can't use it)... that is why I'm in favor of a non-national virtual number management.

Alex: In Brazil, we decided to look for the numbering plan of our contry.

For each Area Code (2 digits), real telephones in Brazil have 8 digits, begining from 2 to 9. +55 AC [2-6]XXX-XXXX -> for fixed landline +55 AC [7-9]XXX-XXXX -> for mobile phones.

We decided to use 1XXX-XXXX for our clients' virtual (IP) phones. So, it is very ease for us to use virtual AND real phones all together. And it is also easy to maintain both numbers (virtual and real ones) in the same tree.

 
  
b) Example (assuming that the longest number is 11 digits):
  • Valid numbers in Hungary (+36): 9.8.7.6.5.4.3.2.1.6.3.nrenum.net
  • Virtual numbers in Hungary (+36): x.x.x.9.8.7.6.5.4.3.2.1.6.3.nrenum.net
ProsCons
The least potential harm to the existing numbering plans, digits can always be added.

Too long numbers are resulted.

Some cases the total length of numbers could be limited...

  • No labels

8 Comments

  1. Anonymous

    I do prefer option 2 (unused country code). Along with this decision, one must think of the operation. I would like to see this numbering being handled by an institution like TERENA or RIPE.

    Rui Ribeiro

    1. I think it is bad idea to centralize and give the power to govern the worldwide virtual numbering plan to one entity. I prefer country wide distributed model as it is works in the golden E164 tree. IMHO never works to pressuring from a central organization a uniform policy to every country. People (so we) are very different (kind) country by country, never underestimate this.

  2. I agree with option 3. In fact we are currently doing this in Argentina without problems. We use prefix 8 after CC for virtual
    numbers. For example: +548416001 is a VN (... and +543534539100 is valid PSTN number). Keeping this scheme (option 3) is important to us, because we have several services that require virtual numbers (videoconferencing, fixed or mobile extensions) . These services do not have associated a real PSTN number. In addition, we have no access DID (Direct Inbound Dialing) for all extensions. (We use a single PSTN number and an IVR system) So, we prefer to use virtual numbers... (8xx institution prefix).
    Mariano Martin
    1. You wrote you agree with option 3, but in your detailed example, what you used is inside your country code +54. You wrote a number range what is unused inside your country code +54 prefix what was my proposal option 1.

      So for me it is confusing your comment. Can you please clarify it?

      Thank You!

      1. Anonymous

        Mihaly, I agree with option 3.

        Option 1 says: "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"

        I do not agree with this situation. I prefeer one nrenum.net tree.

        Option 3 says: "Check the national numbering plans if there is a dedicated number range reserved for VoIP service or test purposes. Use those number ranges of the national plans to populate virtual numbers."

        My examples are:

        0.0.1.9.3.5.4.3.5.3.4.5.nrenum.net is a valid PSTN Number

        1.0.0.6.1.4.8.4.5.nrenum.net is a Virtual Number (Starts with prefix 8 in Tier2)

        It isn´t necessary that all the countries choice the same prefix (8 or any other). Somebody said "People dial people" ... so people do not need to distinguish between virtual or real number using a particular prefix.

        I agree when you say that "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" ... However, in my opinion the creation of a new tree like v.nrenum.net is unnecessary, adds complexity to the management of resources and is also confusing.

        I think the issue of virtual numbers needs no further discussion. Let freedom to decide for each country to do about it within the Tier2

        I propose modify 2.1 F Policies, like that:

        2.1 Numbers to be entered in the nrenum.net tree must be:

        a) Valid E.164 numbers. Members are responsible for the validation.

        b) Virtual numbers (i.e. GDS) may be populated from Tier2 (after CC). Members are responsible for avoiding conflicts with the national dialplan.

         

        That´s what I think ...

         

        Thanks!

         

        Mariano


         

         

         

         

        1. Anonymous

          The best rates for virtual numbers can be found at www.voipclub.biz
  3. Anonymous

    I see a fourth option for unleashing virtual numbers.  (I am not an NREN, but heavily involed with ENUM.)

    Visit freenum.org for another dialing plan; virtual numbers are plainly recognisable by an infix asterisk.  These numbers can still be dialed on an ordinary phone (except rotary phones, grinn) but are plainly distinct.  The part after the * functions as an Internet Telephony Administrative Domain and can be reserved at IANA.  The part before the * is then up the ITAD administrator.

    I think it is a big advantage to visually separate virtual numbers from PSTN numbers, and this is a very useful trick for doing so.

    Cheers,

    Rick van Rein / OpenFortress / http://openfortress.nl/

  4. IMHO Opions 3 sounds like a bad idea, as (among all the options) option 3 bears the highest risk of conflicts to come up later-on, i.e. if such national number blocks get assigned in future. Such conflicts may also restrict future enhancement of nrenum.net services, e.g. if virtual numbers once would get connected to the PSTN or another system that uses E.164 numbers as identifiers.

    It is a different story if a national E.164 number plan administrator (regulator) assigns such a block for nrenum.net, as in that case there is a clean solution / separation of number ranges.

    I already expressed earlier the following on the virtual number topic:

    There appear to be 2 different kinds of requirements for virtual numbers [ short and shortage (smile) ] :

    1) having short numbers

    2) overcome the number shortage (or unavailability) in some countries

    When is comes to the "short numbers" requirement, I doubt that the main nrenum.net tree is the right place to solve this; as it simply doesn't scale well and has a big potential to mess up existing E.164 number plan. I feel, this should be rather solved outside the main nrenum.net tree.

    Concerning the options to overcome the number-shortage/unavailability, the big question to be asked beforehand should always be: "What happens, if the virtual-number space once will get assigned in the real (E.164) world and nrenum.net-virtual-numbers overlap with ordinary PSTN users'?" and what is the likelihood for this to occur.

    All the best,
      Bernie [ who "invented" nrenum.net together with Kewin ]

    --

    http://ucom.ch/
    Tech Consulting for Internet Technology