Best wishes
James
Director, AARNet Enterprise Services
street address: Binary
Centre, Bldg1, Level 2, 3 Richardson Place, North Ryde, NSW 2113
mobile: 0422 007 466
email. james.sankar@aarnet.edu.au
telephone: +61 2 9779 6938
website: http://www.aarnet.edu.au/services/enterprise-services-consulting
sip: 6938@aarnet.edu.au
important
This email and any files transmitted with it are confidential, and the rights of confidentiality in such information are not waived or lost by its mistaken delivery
to you. Any dissemination, copying, use or disclosure of the email and/or such files without the permission of AARNet, or the sender, is strictly prohibited. If you have received this email in error, please contact the sender immediately and delete all copies
of this transmission.
OK, Thanks Rui/peter/james/alex/victor/all,
I can see we're talking at cross purposes. The main thing, throughout all ofthis enum stuff, is to encourage/force some interoperability between variousvendor's (let's call them) 'unified messaging' solutions. If that's not theprimary problem/challenge, could someone tell me what is?
In the first instance, we should have no interest in the technicalconsiderations. We should just look at the potential market and figure outhow, if we we're able to come up with an approach which pulled a market, anyprivate vendor would want to jump on it.
So let me illustrate the potential market. I.e. global groups. To be clear."Groups" tend to fall into these three divisions.
We can see that there have been many discussions about ENUM going on aroundvarious domains for many years. E.g.So that's one indication of one global conversation, around some piece ofResearch, which takes place, in different languages, in hundreds of domains,at any one time. Even when these researchers get together at conferences,their records are buried around various institutional and association websites. We all know that because, since the web was invented, we can all seeit.
In the case of RIPE, we will discover what its institutional peers have incommon only by reading documents which are buried on some other (higherorder) domain. E.g. http://www.nro.net/wp-content/uploads/RIR_WTPF13_2.pdfThis is not an unusual situation. Everyone within some sphere of practice issiloed, and often try and overcome their limitation by inventing anotherinstitution, domain, & web site. And keeping the same discussions separate.
While this fragmentation of effort is now obvious, we have librarians who,because the limit themselves to manhandling information/papers/journals (andignore Communications solutions as studiously as Communications techniciansignore their needs) must pay publishers to aggregate journals on behalf ofglobal (peer) groups.
Bringing it down to our present situation. Our BOF, at this terena domain,have our enum discussion, which will have no record unless the elist has anarchive. So while James will suggest the OVCC guys have an interest in ourdiscussion, and I point to the Ripe enum group, and Peter I am sure willhave some interested parties inside Geant and Dante, there is simply nowherein domain in cyberspace we might all look to as a spot where othercommunities with an interest in ENUM might reside, or have resided. Thedemands for collaboration are obvious, and we all have ideas about real time& asynchronous tools, But that's not important until we have some means offinding our global peers, or peers who might have proceeded us in the sameinquiry.
If you consider a solution to this problem, You'll be thinking (perhaps, interms of a new TLD, say) .research. Or using an existing domain like .edu.Regardless, if you are a librarian it will be quite an obvious thing toconsider using an old classification scheme for the domain. What is, usingthe existing way of classifying domain names called http://ddc.typepad.com/is just as recognizable to a (dewey) librarian as www.025.431.com
Now the only shortfall of this approach, using six numbers, is that it canonly define 999,999 virtual domains. But it's strength is that these becomenot just pointers to a million transitional domains, but long term archivesin their own right. It's the policies, which are made for the use of virtualrooms - interoperable, open source, open access, IPv6, etc - where the realinfluence resides. A Global user group doesn't get issued one unless theyagree.
So you might understand. I don't see the domain being issued by network, orservice, operators. They get issued by librarians.If we get that far, we'll need a prefix to be tacked on to a room's number,so people can dial in to a room/conference, using the PSTN, withoutincurring toll charges.
I hope that scopes the concept clearly.All the best, si
-----Original Message-----From: Rui Ribeiro [mailto:rui.ribeiro@fccn.pt]Sent: Wednesday, 29 May 2013 6:14 PMTo: 'Simon Fenton-Jones'; 'James Sankar'Cc: discussion@nrenum.net; tf-media-prep1@terena.org; 'Alex GalhanoRobertson'; 'Victor Reijs (work)'; 'Peter Szegedi'; enum-wg@ripe.net; 'JuanQuemada'Subject: RE: [discussion] Re: Global Virtual Numbering
Hi all,
{{Something like this would be possible:
00 ### @ %%%%%%%%00 ### @@ %%%%%%%00 ### @@@ %%%%%%00 ### @@@@ %%%%%00 ### @@@@@ %%%%
Can't figure out why we'd need a network number though.}}
I see two reasons upfront:1. TERENA (or NRENum.net admins) don't have the structure to delegatedirectly every block.2. Organizations (NRENs, PCMG's*, ...) will want to delegate some blocks ontheir own or "transpose" their current numbering into the "global tree".
* PCMG's = entities like: Polycom, Cisco, Microsoft, Google, ...
Rui RibeiroGestor Serviço Técnico de VídeoGEANT3 - SA3 - T4, eduCONF LeaderFCCN
Aviso de Confidencialidade/DisclaimerEsta mensagem é exclusivamente destinada ao seu destinatário, podendo conterinformação CONFIDENCIAL, cuja divulgação está expressamente vedada nostermos da lei. Caso tenha recepcionado indevidamente esta mensagem,solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para otelefone +351 218440100 devendo apagar o seu conteúdo de imediato.This message is intended exclusively for its addressee. It may containCONFIDENTIAL information protected by law. If this message has been receivedby error, please notify us via e-mail or by telephone +351 218440100 anddelete it immediately
-----Original Message-----From: James Sankar [mailto:James.Sankar@aarnet.edu.au]Sent: Tuesday, 28 May 2013 8:47 PMTo: Rui Ribeiro; 'Alex Galhano Robertson'Cc: discussion@nrenum.net; tf-media-prep1@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 theadded complexity of providing revenues to justify investment. The OpenVisual Communications Consortium (OVCC) are working with carriers, managedservice providers, video vendors and supporting service providers to do justthat. Given we seem to be redefining the objectives and goal it may makesense to gain an insight into the issues and challenges that the OVCC faceso that we can take that effort and any learnings into account. If thiswould be of value I can organise OVCC leaders in the technical WG to meetvia video.
Best wishes
James Sankar
On 28/05/13 8:27 PM, "Rui Ribeiro" <rui.ribeiro@fccn.pt> wrote:
Hi Alex,
{{I insist, we need to clearly define our objectives with this globalnumbering plan.}}
IMHO, we need a way to allow addressing of IP voice and video terminalswithin the global numbering plan that is widely used, without therestrictions 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 allacknowledge that. But, for the moment, numbers are needed and thecorrect approach to "route" numbers into URIs is using ENUM. Yes, Iwould look for a "number-only global addressing scheme".
{{- We want it to be "E.164 compilant", so we could call from anyvideophone or even any standard phone.}}
There is a subtle thing that is mixed on this sentence. First, yes, weshould be E.164 compliant, as this would promote integration with thecurrent PSTN network and ease future integration. The other thing is tomake a call... I would like, but it isn't a MUST today, to be able todial from a(pstn) phone to these "number-only global addressing scheme". "In thefuture", if we are an extension of e.164, then it would be easy foroperators 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 notneed it.But we want it because some countries (its universities and even NRENs)have dificulties to obtain real telephone numbers and make this realnumbers the addres of its videoconference rooms.}}
True. Look at the wider picture and think of other service providersthat, already promote V&V services within their own numbering plan.What if there was an global service that would accommodate thesenumbers/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 videoconferencesoftwareB- groups: group of deskphonesC- 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 onetelephone number on our business cards. And it is easy to map thoseaddresses 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 arejust numbers... they will then be used for whatever purpose peoplewants to use them. We should not block their usage upfront by saying"only to be used by physical terminals". There should be rules aboutthe quality of the records, but other than that, we should promoteinnovation 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 formost 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 withall the problems associated with it: uptake, different rules, businesscase, politics, ...2. bigger numbers (at least more 3 digits...) 3. doesn't solve supranational entities/networks.
I'm in favor of B, but based on the concept of networks. There shouldbe a "world wide registry" for these networks and then there will beregistrys to take part of those numbers. Of course NRENs could apply totake care of the CC code, if they want to, but this would open up themanagement outside country boundaries. For instance, on eduCONF, thenumbering that we aim is supra national, where should it be placed on aCC code hierarchy. Where should, for instance,Polycom/Cisco/Microsoft/Google register costumers?
(please don't flame me on these reference to companies (PCMG). They area big part of the videoconference ecosystem, preparing the model toallow them to enter is, IMHO, a wise decision)
{{If we decide for option B, I would like to make some other questionsabout that IPv4 aproach I proposed a few days ago.}}
We could use a "network" prefix to that kind of numbering... just likeany other network (educonf, country's nren, PCMG, ...) it would beinteresting because it could be registration free and hassle free. Infact most of it would be able to be automatically assigned. But itisn't a"silver bullet"to solve the issue because many terminals are behind nat and you can'taddress all the terminals these way.
Again... the wide/open the model, the more distinct and innovative theoptions will be.
{{1- How many NRENs or Universities are using NATed IP addresses in itsMCUs?As H.323 and SIP is not so good with NAT, I dare say no NAT and noprivate IP addresses (10/8, 172.16/12 or 192.168/16) are been used forthese video resources.}}
Many... most (if not all!) of our VoIP network is behind an SBC that isthe only "public" IP address known on the open network. H.323 is evenless good transversing NAT, nevertheless there are many using thatarchitecture.
{{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 Polycomare taking major steps. There are some NRENs that are providing theservice in IPv6.
Of course there isn't a date to remove IPv4. The question, is when willit 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 befrom1 digit to 5 digits (?). Where NP that are equal to E.164 CC could bereserved to NRENs or regulators of those countries.NUMBER = extension number within the network addressed by {NP}. Thetotal 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 toanother "numbering war". ;-)
This structure would allow us to delegate about 40k networks...
Rui
Rui RibeiroGestor Serviço Técnico de VídeoGEANT3 - SA3 - T4, eduCONF LeaderFCCN
Aviso de Confidencialidade/DisclaimerEsta mensagem é exclusivamente destinada ao seu destinatário, podendoconter informação CONFIDENCIAL, cuja divulgação está expressamentevedada nos termos da lei. Caso tenha recepcionado indevidamente estamensagem, solicitamos-lhe que nos comunique esse mesmo facto por estavia ou para o telefone +351 218440100 devendo apagar o seu conteúdo deimediato.This message is intended exclusively for its addressee. It may containCONFIDENTIAL information protected by law. If this message has beenreceived by error, please notify us via e-mail or by telephone +351218440100 and delete it immediately