[enum-wg] [discussion] Re: Global Virtual Numbering

James, 

That would be good idea thanks. Is there somewhere we could have an open
elist or forum with an archive as well. 
RIPE? At least they're reaching out. https://www.ripe.net/ripe/raci 
There are quite a few other similar and related groups I'd like to both
invite and point at the discussions. E.g. Video as a Service (VaaS) LinkedIn
group. Google's Hangout guys. OCLC research.

Seems like these discussions have been coming and going in some remote
cyberplaces, forever, and no one can point at their records.
I hope we are starting to see the need for domains, and associated RTC,
whose numbers are issued by librarians. 
Anyway, we can talk about "markets" before we talk about the technical
issues? Cart before the horse and all that.

BTW, what number will you be using for the combined group's video
conferences:) (and stream?)
Regards, si.

P.s. I quite like this one from Rui. 
00{INP}{NP}{NUMBER}

INP = Internet Number Prefix CC (as "883", or something similar...) NP =
Network Prefix to be assigned by the global registry. It could be from
1 digit to 5 digits (?). Where NP that are equal to E.164 CC could be
reserved to NRENs or regulators of those countries.
NUMBER = extension number within the network addressed by {NP}. The total
number should not be longer than 14(?) digits.

Something like this would be possible:

00 ### @ %%%%%%%%
00 ### @@ %%%%%%%
00 ### @@@ %%%%%%
00 ### @@@@ %%%%%
00 ### @@@@@ %%%%

Can't figure out why we'd need a network number though.


-----Original Message-----
From: James Sankar [mailto:James.Sankar at aarnet.edu.au] 
Sent: Tuesday, 28 May 2013 8:47 PM
To: Rui Ribeiro; 'Alex Galhano Robertson'
Cc: discussion at nrenum.net; tf-media-prep1 at terena.org; 'Victor Reijs (work)';
'Simon Fenton-Jones'; 'Peter Szegedi'
Subject: Re: [discussion] Re: Global Virtual Numbering

Dear All

I know that this issue is a common one in the commercial world and has the
added complexity of providing revenues to justify investment.  The Open
Visual Communications Consortium (OVCC) are working with carriers, managed
service providers, video vendors and supporting service providers to do just
that.  Given we seem to be redefining the objectives and goal it may make
sense to gain an insight into the issues and challenges that the OVCC face
so that we can take that effort and any learnings into account.  If this
would be of value I can organise OVCC leaders in the technical WG to meet
via video.

Best wishes

James Sankar

On 28/05/13 8:27 PM, "Rui Ribeiro" <rui.ribeiro at fccn.pt> wrote:

>Hi Alex,
>
>{{
>I insist, we need to clearly define our objectives with this global 
>numbering plan.
>}}
>
>IMHO, we need a way to allow addressing of IP voice and video terminals 
>within the global numbering plan that is widely used, without the 
>restrictions of the current numbering plan.
>
>Restrictions = number associated with phone service.
>
>{{
>- We want to integrate videoconference and telephony services.
>}}
>
>True. 
>
>{{
>- We want a number-only global addressing scheme. No alfabetic characters.
>}}
>
>"In the future", URI dialing will be the way. I think that we all 
>acknowledge that. But, for the moment, numbers are needed and the 
>correct approach to "route" numbers into URIs is using ENUM. Yes, I 
>would look for a "number-only global addressing scheme".
>
>{{
>- We want it to be "E.164 compilant", so we could call from any 
>videophone or even any standard phone.
>}}
>
>There is a subtle thing that is mixed on this sentence. First, yes, we 
>should be E.164 compliant, as this would promote integration with the 
>current PSTN network and ease future integration. The other thing is to 
>make a call... I would like, but it isn't a MUST today, to be able to 
>dial from a
>(pstn) phone to these "number-only global addressing scheme". "In the 
>future", if we are an extension of e.164, then it would be easy for 
>operators to route calls from their terminals/phones.
>
>{{
>- The translation to URI will be done by NRENum.net.
>}}
>
>Yes.
>
>{{
>0- Do we really need virtual numbers?
>IMHO, we dont need it. At least, the majoroty of our NRENs does not 
>need it.
>But we want it because some countries (its universities and even NRENs) 
>have dificulties to obtain real telephone numbers and make this real 
>numbers the addres of its videoconference rooms.
>}}
>
>True. Look at the wider picture and think of other service providers 
>that, already promote V&V services within their own numbering plan. 
>What if there was an global service that would accommodate these 
>numbers/networks?
>
>{{
>As the answer is "we want it", let´s go on with other questions...
>}}
>
>Ok. ;-)
>
>{{
>1- What we should address?
>A- people: our office deskphone or our personal videoconference 
>software
>B- groups: group of deskphones
>C- video resources: MCU rooms, physical room "CODECs", Webconf rooms 
>(if we can make it interoperate, etc)
>D- all above
>
>I think letter C is the correct one, because we already have one 
>telephone number on our business cards. And it is easy to map those 
>addresses on NRENum.net. It is already done for most of us, I think.
>}}
>
>Option "E" - All of the above and whatever comes up next! Numbers are 
>just numbers... they will then be used for whatever purpose people 
>wants to use them. We should not block their usage upfront by saying 
>"only to be used by physical terminals". There should be rules about 
>the quality of the records, but other than that, we should promote 
>innovation of services.
>
>{{
>3- How should the scheme be?
>A- Hierarchical and country code dependent?
>B- Flat, non-hierarchical, independent on any existing coutry code
>
>I think this is the key question to be answered!
>It would be much easier if we choose leter A. It is already done for 
>most of us.
>But some people prefer the first choice: flat and CC independent.
>}}
>
>If A is chosen, there will be three problems:
>1. (must!) exist country organization to take care of the service with 
>all the problems associated with it: uptake, different rules, business 
>case, politics, ...
>2. bigger numbers (at least more 3 digits...) 3. doesn't solve supra 
>national entities/networks.
>
>I'm in favor of B, but based on the concept of networks. There should 
>be a "world wide registry" for these networks and then there will be 
>registrys to take part of those numbers. Of course NRENs could apply to 
>take care of the CC code, if they want to, but this would open up the 
>management outside country boundaries. For instance, on eduCONF, the 
>numbering that we aim is supra national, where should it be placed on a 
>CC code hierarchy. Where should, for instance, 
>Polycom/Cisco/Microsoft/Google register costumers?
>
>(please don't flame me on these reference to companies (PCMG). They are 
>a big part of the videoconference ecosystem, preparing the model to 
>allow them to enter is, IMHO, a wise decision)
>
>{{
>If we decide for option B, I would like to make some other questions 
>about that IPv4 aproach I proposed a few days ago.
>}}
>
>We could use a "network" prefix to that kind of numbering... just like 
>any other network (educonf, country's nren, PCMG, ...) it would be 
>interesting because it could be registration free and hassle free. In 
>fact most of it would be able to be automatically assigned. But it isn't a
"silver bullet"
>to solve the issue because many terminals are behind nat and you can't 
>address all the terminals these way.
>
>Again... the wide/open the model, the more distinct and innovative the 
>options will be.
>
>{{
>1- How many NRENs or Universities are using NATed IP addresses in its 
>MCUs?
>As H.323 and SIP is not so good with NAT, I dare say no NAT and no 
>private IP addresses (10/8, 172.16/12 or 192.168/16) are been used for 
>these video resources.
>}}
>
>Many... most (if not all!) of our VoIP network is behind an SBC that is 
>the only "public" IP address known on the open network. H.323 is even 
>less good transversing NAT, nevertheless there are many using that 
>architecture.
>
>{{
>2- How many of these video resources are using IPv6?
>Who has today an MCU using just IPv6?
>When do you plan to remove IPv4 from these devices?
>}}
>
>There are IPv6 resources available, all Cisco (Cisco, Tandberg, Codian) 
>products are IPv6 enabled. Others like Radvision, Lifesize and Polycom 
>are taking major steps. There are some NRENs that are providing the 
>service in IPv6.
>
>Of course there isn't a date to remove IPv4. The question, is when will 
>it be impossible to add terminals to the IPv4 network. When it happens, 
>we need to be prepared.
>
>
>As final comment:
>
>The structure that I propose is something like:
>
>00{INP}{NP}{NUMBER}
>
>INP = Internet Number Prefix CC (as "883", or something similar...) NP 
>= Network Prefix to be assigned by the global registry. It could be 
>from
>1 digit to 5 digits (?). Where NP that are equal to E.164 CC could be 
>reserved to NRENs or regulators of those countries.
>NUMBER = extension number within the network addressed by {NP}. The 
>total number should not be longer than 14(?) digits.
>
>Something like this would be possible:
>
>00 ### @ %%%%%%%%
>00 ### @@ %%%%%%%
>00 ### @@@ %%%%%%
>00 ### @@@@ %%%%%
>00 ### @@@@@ %%%%
>
>Eventually the INP should be just 1 digit, but that would send us to 
>another "numbering war". ;-)
>
>This structure would allow us to delegate about 40k networks...
>
>Rui
>
>Rui Ribeiro
>Gestor Serviço Técnico de Vídeo
>GEANT3 - SA3 - T4, eduCONF Leader
>FCCN
>
>Aviso de Confidencialidade/Disclaimer
>Esta mensagem é exclusivamente destinada ao seu destinatário, podendo 
>conter informação CONFIDENCIAL, cuja divulgação está expressamente 
>vedada nos termos da lei. Caso tenha recepcionado indevidamente esta 
>mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta 
>via ou para o telefone +351 218440100 devendo apagar o seu conteúdo de 
>imediato.
>This message is intended exclusively for its addressee. It may contain 
>CONFIDENTIAL information protected by law. If this message has been 
>received by error, please notify us via e-mail or by telephone +351 
>218440100 and delete it immediately
>
>
> 
>