These are unedited transcripts and may contain errors.
ENUM Working Group:
CHAIR: Okay. Let's get this started. Welcome everybody. This is the ENUM Working Group session at RIPE 64. If you've more interested in the routing Working Group session, you have to go downstairs to the big hall. As I said, this is the ENUM Working Group. Welcome everybody. Also to our remote participants by personal email I've learned we have at least two, hopefully more. But confirmed two. Welcome everybody. Let me walk you through the agenda first. But very first of all, we're having a scribe, which is as usual from the RIPE NCC, and we have a Jabber [] bok from the RIPE NCC. As this session is going to be videocast, if you walk to the microphone for comment or question or anything else ?? oh, yeah yeah yeah. If you walk to the microphone for comment or question, state your name clearly. And also please be so kind and switch off your mobile phones so they're not interrupting the session.
Let me walk you through the agenda first. Action or point A we've almost completed. Second one, point B, the minutes of the previous meeting. Point C is the review of the action list from last time. We have two so far. Point D is the main presentations. I got a suggestion from Alex
ALEX MAYRHOFR: To flip point D 1 and point D 2 so we're going to have the presentation emum successes and failures first and only then the one from Wolfgang Tremmel. Point one is we have the ENUM presentations from the RIPE NCC. Point F is short news where Niall O'Reilly will have a short update on enum.org including action point 36.2 and a brief update on the ongoing action item point ?? I've made a mistake, 36.1. And I see Niall O'Reilly waving. It's actually 63.1, the update. Agenda item G is the usual place for plenary presentations. As we haven't had any plenary presentation so far so there's hardly anything to discuss. X,Y and Z are AOB and the closure.
Entitle has sent out a last call for the minute of the last meeting, that was on the 20th of March and any on line comments should have been submitted by yesterday noonish UTC. In case nobody here on site has any need for change, amendment or anything else according to the minutes of the 63 meeting, I would like to call the minutes now final. I do not see any hands waving or anything else. The minutes of the 36 meeting are now final.
NIALL O'REILLY: 63.
CHAIR: Of the 63rd meeting are final. Coming to agenda item C, review of action item list. We had two action points, that is still ongoing, to contact ENUM operators to facilitate a brain storming about ENUM operators. That was as a result of the panel discussion we had last time. And [Denis] later on will give an update of the findings so far and how we're going to proceed. Action point 63.2 is closed. This is the reallocation of the ENUM website and we will also have a short update on the relocation to the NCC which brings me to agenda item D, the main presentations. We've allocated 60 minutes for that. Again, the two subpoints are going to be flipped. We start off with Alex Mayrhofer on ENUM's successes, failures and alternatives.
ALEX MAYRHOFR: Thank you. Good afternoon, everybody. When I started that presentation, I wantued to give an overview of what we as the first commercial operator of ENUM registry back in 2004 think the market and the technology has evolved into, and given that certain applications of ENUM technology cannot necessarily be counted in as success. I wanted to point out that there's some part of the ENUM ecosystem being in use and that lines up pretty well with what Wolfgang is going to present. That's the reason why we flipped the presentations.
Again, the from my perspective, the ENUM ecosystem contains a couple of components. One is I like to call the protocol which can be separated into two different parts, the core protocol, how ENUM operates, and the other part of that is the definition of the actual ENUM services that can be used using that core protocol in order to transform e164 numbers, and closely related into the definition of the protocol, obviously IETF Working Group. Based on the core protocol and the definition of the ENUM services, a number of different ENUM flavors were established. One of them is that ?? what the ITF envisioned called user ENUM where end user to be found by any Internet user. The second flavor that was actually created as a response to the ?? not immediate success of the first flavor was infrastructure ENUM where rather than end users, carriers would be allowed to enter data into the ENUM tree. What developed besides the user ENUM and infrastructure ENUM developments was so called what I like to call private ENUM, the use of ENUM within a search wires network or something like that.
Looking at user ENUM first, what does the ecosystem that we have today consist of? In addition to the things I described above, the core and it's the administration of the e164.arpa, on one hand globally performed by RIPE NCC and closely connected to the interim procedures ?? it's a funny thing that even though these things are in place for 11 years they're still interim procedures and on the other hand e164.arpa is like the system operated by local registries. For example, we had a registry for plus 43, which is the country code for Austria. And finally, it involved interaction with the local regulator, given the proceed did foresee the regulator had to agree with the ENUM use, each and every registry had to go through the regulator in order to get permission to run the ENUM zone.
On the other hand, we have the community which is an important part which is local interaction between register, local service providers and community, and we still sort of have a half effort, ENUM federation, where we would foster that community development.
So for each of the things that I mentioned now, I have prepared a slide to go through and identify whether that part was successful or that part can be considered a failure.
So for the core protocol, that was defined by the ENUM Working Group for the first time in 2000, then was revised in 2004 and was again revised in ?? there's a typo ?? 2011, I think. The protocol itself is stable, it's deployed. It's out there on the Internet and private networks. But it's still a proposed sender. It's not on ?? it hasn't done IETF standard yet. Nobody took the effort to progress it on steno strike. Later in the development of that whole system, Patrik, the main contributor to the first ENUM RFC, came up with an alternative that was much simpler and involved the use of the so called URI resource record type but the show was already over. And the IETF Working Group was closed in may 201211. Considering that the IETF considers the closing of a Working Group a huge success, I would say the protocol development was pretty successful even though it took nearly ten years from the establishment of the Working Group until the closure of the Working Group.
The other part of the standarization work within the IETF was the definition of ENUM service registrations. In the first RFC that specified the protocol there wasn't registered specified in order to identify individual services. This was only done in the second revision of the ENUM protocol. And back then, we had so?called IESG approval and RFC publication required for the definition of an ENUM service, which was a very heavy weight process and involved a lot of work for anybody who wanted to have an ENUM service published by the IETF and also sort of excluded work from other standarization organisations. So if one of the mobiles and other organisations would have proposed an ENUM service record, they would have needed to go through the IETF process.
We finally changed that to specification required in RFC 6117 and 6118 and also allows ENUM service registration disconnected from the existence of the Working Group, so that was preparing the days of the Working Group as well.
We currentlyly have 40 services registered in the IANA register. There's something I didn't fill out. The most popular service is zip column, followed by email column and then http column and everything else from Skype column to whatever. So I would call that the system for defining and creating ENUM registration is a success. So to get to the standarization point of the whole ecosystem was completed quite well and worked out fine.
Moving to the implementation for user ENUM, in order to be able to actually register a phone number with ENUM, an individual registry for each country had to be established. And I have here my definition of user ENUM, the shortest one I think makes sense, it's the registration of ENUM records in publicly available DNS under control of the end user and under e164.arpa. That's not on the slide. Administration of e164.arpa by the RIPE NCC have been a success because they worked pretty well, as intended, and e164.arpa was used as the first it would style zone that was signed as DNSSEC. I rightly remember something like that.
For the local registry, each of the registries had to implement their services in line with local regulators. And that was done done quite successfully. For example, Austria, Germany, Switzerland and in the meantime they shot their ENUM service down already again. And one point was that because ENUM registrations are built on the actual phone number that was already allocated to a user, a very heavy weight process called ENUM validation was required, which was honestly so complex it was a failure. It took a lot of effort to work through and it wasn't really easy to perform for the end user and for the registers as well. Peter.
PETER KOCH: Do you want questions now or later or not at all?
ALEX MAYRHOFR: We have enough time.
PETER KOCH: Just wondering why you would rate this a failure. That could be read in a way that that means validation didn't work as expected in terms of people got their phone number hijacked or something like that?
ALEX MAYRHOFR: I didn't mean to imply it was a failure in terms because it didn't work out as intended but it was a failure from the market perspective. So it was so complex that it turned away most of the users. And whereas it did work in combinations best where the carrier had the validation information for the user. Technically it worked quite well. It was like, I would say over?engineered.
PETER KOCH: That is like perspective from one particular.
ALEX MAYRHOFR: That's my take, yeah.
PETER KOCH: Okay, that's fine.
AUDIENCE: I also wanted to stress a little bit on the fact you said that the validation part was the complex part and over?engineered, etc., etc., from your personal point of view. Is that really the case? I think from my point of view it was more, say, Internet service providers who weren't really in a position or able to make a bundle out of that technology, because ENUM to some extent reminds me of a turbo charger. Is there a market for a turbo charger.
ALEX MAYRHOFR: Yeah, I brought it up like a couple years ago.
AUDIENCE: You brought it up, right. I wouldn't really blame it on the validation part but much more on the inability to come up with use?case scenarios that are attractive to users.
ALEX MAYRHOFR: Right. I got sort of a little bit down the path of mixing in market things to the market slide already, even though I meant to mix in administrative and technical things in the first slides. Robert.
AUDIENCE: Just a small remark. You're absolutely right that the products are not the main problem but looking at the part which has been part of ENUM and it is fair to say that we spend a lot of effort to make validation as market neutral as possible and some extra things to make it possible that someone is available to validate another number coming from another carrier, and the demand actually was very very low, because technically, it's sexy, nice, all different things are implemented here, but absolutely nobody took this chance at the market. So looking at the technical development side, too much effort has been spent to enable something that doesn't feed the market requirements.
ALEX MAYRHOFR: So in the end, all of those details that you just mentioned hampered market adoption. I'm going to come to that on the next slide, which is user ENUM industry up take. We saw some very very eager early adopters. Mostly small VoIP operators. The large ones were too much of a carrier. And actually those very small and very eager VoIP providers are still sort of the only users of that system. We saw a little bit of up take from individual users but that was mainly because of wrong expectations in some cases. People thought if they registered their mobile phone numbers with ENUM they would be able to avoid rooming charges. ENUM is actually an infrastructure technology rather than a service that you can buy at your favorite hardware store.
Out of those early adopters, we saw zero large telcos and mainly because of two things, telcos saw user empowerment and free calls just as plain scare. In turn, because we had early adopters at that time, very small ones, we never reached a critical mass of a network. A network with very few participants is not really useful as we all know. And that left the early adopters frustrated. And did not attract new adopters. For example, one of those eager early operators did some statistics on his call volume and said we have ENUM completed calls of under 1% and if I now look at the cost that I have in administrating ENUM and paying you the registry fees, then the ENUM call minutes that should have been free in the first place are much more expensive than my plain PSDN call minutes. In turn, we also found out over the course of the development that it's not really about free calls, it's about new services. And in turn that promise that ENUM would allow you to use new services was overtaken, for example, by Skype, which already provided new services and call minutes are cheap at that point in time. So most of the people at that time migrated from a fixed telephone to mobile phone. So the industry out take was clearly a failure because it didn't reach a significant percentage of the actual users.
Looking at ?? wrong button. Look being at the current up take, I'm still running since five years, trawler.enum.dot.at because it's so easy to enumerate, I can crawl the whole e164 e164.arpa so that's what Ied found. Taiwan has 800,000 numbers, almost all of them point to go the same end point. I haven't tried whether that actually responds, followed by the usual suspects, I would say, with numbers that are reasonably to be expected compared to the number of delegations. For example, we have registration for 8,000 numbers and considering that you can add extensions behind the numbers reasonable well. So that's the currently status of e164.arpa. And if you look at the top line, 900,000 and it crawls one hundred numbers per minute. You can look it up yourself. Please don't overload website. It's a very old machine.
Given that user ENUM was identified as pretty much a failure, we also talked to other people in the market and industry and we think ?? that's also what you told us, still useful to have technology that translates between telephone numbers and Internet address and they said yes, we would love to have that, but it must not be under the control of the user. We went to great lengths to standardize and implement infrastructure ENUM. The response from the operators was user control is really bad. We want to control ENUM for the peering case our self and the user must not interfere with that. Once we have we had the registry in operation, all of them went silent. So we had zero uptake on the plus three and I was wondering was there any up take elsewhere, I don't really think so. That was a failure as well. Why? Those who would have been willing to use it were using user ENUM already and were using it in a style of ENUM all right. Furthermore, operators find out, no, we won't want to expose our data and market share and infrastructure to the public Internet. We better not expose how our number structure is. And finally that got us to the problem of VoIP peering. We would have had one provider interested but it doesn't make much sense to peer with yourself. And finally, VoIP peering is a lot more complex as we're going to hear from Wolfgang, and ENUM just covers the pure service discovery.
So where's the success? And the secret is it's invisible, because it's not on the Internet, it's private ENUM. Private ENUM is the use of ENUM technology in private environments. So it's not happening on Internet, just, for example, accessible from an operator's network only, it runs within the operator's network or runs within a group of operators or in form of a VoIP peering. And for that kind of usage, we see massive up take, however, we don't really see it because it's hidden. I would call private ENUM a success. It still uses the same protocol, still uses the same ENUM service registrations. It's just a name server that is hidden somewhere in the VoIP IP operator, having millions of numbers, it's just not exposed to the outside world.
What operators actually use private ENUMs for is the most important thing is the peering scenario. So I have a number, I want to find out who is the carrier for that number. And that, in most cases envelopes some kind of private ENUM look up where the response is a carrier identify. It's not a complete CPRI. It's the identifier, the number of the carrier assigned by the regulator or something like that. Local number portability queries. Is it a portable number or not? Caller name query is his something ENUM is very often used, that is in the US you're required to display the name of the caller before the phone actually rings which means there needs to be a huge database of caller names and most carriers or some carriers I know of use ENUM in order to transport the caller name to the switch and then deliver to the phone. Internal routing queries, in which part of my network is that phone number? And selecting an outbound trunk, which one to choose for which number. And the reason for that is ENUM is still the prime and the only standardized translation mechanism from E.164 numbers to an identifier.
Why was that so successful? Implement the in almost any vendor's VoIP switch. It's a functionality you can enable on the network equipment, on the VoIP network equipment. DNS is well understood,it works so well that it's used ?? it's very attractive to use it for other things that are not necessarily related to the previous definition of DNS. Private ENUM is much more nicer from an operator's perspective because it doesn't expose any data outside. Finally it allows the use of non?standard ENUM services. Can you essentially type anything you run on the ENUM server and run it and nobody's going to complain. Some of them use hex, so split DNS where different clients get different answers back.
So my point is private ENUM is a successful use of ENUM protocol, just the public administration didn't work out or maybe we haven't yet found a use case.
Looking at that, alternatives, user ENUM, what are alternatives? Actually, we have seen it ourselves, most of the people moved from fixed line to Skype, mobile phones, instant messaging. Phone numbers are not really that important anymore. If you have a smart phone it's likely you're going to someone by his name and not number. There's some sort of translation already existing. The first promise of ENUM to enable free calls to the Internet is not relevant, calls are cheap anyway. If I want to call someone in another country I use Skype anyway. And normal phones are, therefore, an alternative. It's not that expensive to use a phone anymore. And ENUM requires all information to be public, so the use cases where you, for example, I would publish my business card together with my numbers or anybody who calls me would be the business card, requires that you actually publish the information on the Internet in an open way, which is maybe worse than publishing it in a social network. So the real alternative is P2P SIP which might involve a mechanism to discover phone numbers as well.
For enterprises, almost all vendor specific has a window to connect PBX so the PBX connect was not really there, specifically because it also involved all the problems that come with VoIP peering like code ex?etc.. least cost routing, it became pretty cheap to do phone calls wherever you want to.
For the enterprise market there's a protocol being developed, it's called Viper. It's a whole bunch of protocols that allows PBX to discover when a call is reached via Internet. It's quite complicated. Quite complex. But it would essentially full full what ENUM promised for the enterprise market.
So for infrastructure, what are the alternatives that carriers are using? Because they still have the problem they need to peer. They use by lateral agreements, simple yes, no, decision. Do I peer with him? On the other hand, they're using many service operators connect together and exchange their traffic. And I'm the chair of an IETF Working Group that specifically addresses the problem of provisioning VoIP peering data A so if you're interested in the provisioning side rather than the look up side, it might be wise to go there.
That doesn't necessarily require the output to be infrastructure private ENUM but allows the use of a NAPTR record. Conclusion from my point, user ENUM was too complex. It should have been bundled into a product that people could buy. It never happened. It was financially unattractive. I have to pay for my ENUM registration for others to reach me. And it was overtaken by other services that became more attractive over time. Infrastructure ENUM was embraced by larger ones, only part of the problem, never reached critical mass to take off. Private ENUM is a success and I'm looking forward to hearing more from Wolfgang what the actual use of private ENUM in the service that you're running would be.
Thanks. Any questions?
Thank you very much.
(Applause.)
CHAIR: I guess I hardly have anything to do here, just call Wolfgang to the stage to give his view on private ENUM and the recent corporation or reasonable announced corporation between D six and connect.
WOLFGANG TREMMEL: Hello everybody. I'm Wolfgang Tremmel, working for DE?CIX. And as you see on the title slide we prepared this with our partner, X Connect. They do the technology for the new product we're running out. Unfortunately, Andrew from X Connect, we worked together on this, cannot be here but he's watching the webcast and he will be answering questions later via Skype. So I'm not the real technical expert on the technology I'm presenting. So be a bit easy on me, please, but you can ask all questions later to Andrew.
Most of you might know DE?CIX, it's the Internet exchange in Frankfurt. We run a highly redundant peering switching infrastructure. Basically we do have a fuelly redundant switching infrastructure, we have run a double star technology and highly successful in running 100 percent availability over the years. So we thought why not always use the same technology to do a new thing, to do kind of a voice peering of our platform. That was the motivation for that, not only peer peering but voice peering as well.
Basically the thing is we wanted to do it on the carrier grade stability and wanted to do it so voice carriers connect via us and do exchange their voice traffic over our IP platform. We used the same infrastructure, same kind of redundancy for that. The thing we are building is also fully redundant in two different sites. We are using voice routing technology and we also do ?? you might know in the German market, the number portability we have, that basically a phone number, a phone number is owned by the person with the telephone, he can carry it over to any other carrier. So what you can do in Germany, if you change carriers, you can take your phone number with you. There's a quite complex process about number portability in Germany. This process is more than ten years old and it uses an ISDN?based system for carriers to exchange the ported numbers. What we're doing here is we take this old?world number portability and put it into our system and basically what we have is it's a use case for ENUM for that. We are going to introduce this voice peering in the stage approach, we basically start with termination for plus 49 national carriers, second stage will be international carriers, and the third stage will be full exchange between all carriers. This is basically the structure of the system, what's called the vortex database is the interface between the old world number portability system into the new?world SIP and private ENUM based number query. Then we have the voice exchange which is the system where the carriers connect to, and underlying we have the DE?CIX IPP peering fabric. This is the database where the stuff comes in, the old numbers. It publishes the port numbers. We have ENUM registry SIP server which synchronises the database. And we have the voice of IP interconnection system here. That's the old world, how you do voice interconnect over PSTN, basically only phone, but no advanced services. This is the world we've been ?? in IP 20 years ago, everybody runs a cable to everybody. The voice carriers didn't realise yet that it's ineffective. You can do everything mostly but you have to run a lot of cables. This is what we're proposing, basically do a kind of a voice peering which also you connect to one central point and do all services over that central point. Basically I'm skipping over the sales pitch. You can read it on the presentation. If it wouldn't make sense for the carriers, we went do it. This is basically where ENUM ?? the first place that ENUM comes into this. The vortex IP database can be queried on ENUM on private ENUM, is the number there. And if, yes, it gets a pointer, and if no, then the number isn't ported into the database. Let's see. Alternate tiff to the ENUM query, of course, you can do most of the queries also via SIP, it doesn't matter if you do it via SIP or via ENUM, the only thing I've learned is that ENUM is a much simpler protocol, if you just wanted to query a number, it's much easier to do it via ENUM than to set up a SIP session and do the query via SIP. So we have the service providers here, the vortex registry. It gets an SIP end point, and the query goes through ?? so this is how a call basically would work through the network. End user tries to call a specific number. The user dials. We query the directory server. The queries over SIP or ENUM, ENUM is the simpler protocol. We check if it's, it connects to the interconnect. Then it queries the interconnect hub via SIP: It queries the registry again. If the call is allowed the whole thing can be policy based. We can do a full policy depending on who is calling who. And returns the SIP address of the target. And basically, then, the call takes place between the caller and the called network over the Internet connect hub. And the media and the hub which runs via our network, making the thing highly easy to configure for the participants and hopefully they will see the benefit as well.
Basically what ?? the other thing we have is the number portability query. We do a prefix ?? sorry. I need to read it. This is the thing I'm not familiar with. I'm going to skip over that. The provisioning and management, the infrastructure of the system by X Connect, the registry architecture. What is done is we do, basically, the private ENUM queried, we use a kind of extended ex?ENUM, in ENUM you only query for the target phone number. You do not know who is doing the call. So ENUM is extended in the way that we also do query with the source number plus the target number, which is quite easy. You just put it in front of the dotted string you are querying for. And basically that's it. We use the ENUM for query and then the SIP for processing the call. It's a complete private tree, as I said. It has number to do with public ENUM. It only takes place within the infrastructure. And for that, as you said, the ENUM protocol is basically perfect because it's a very simple protocol and makes the processing very effective.
Skipped over that. And as you see at the bottom, the standard ENUM only provides originator and the B number and the enhanced ENUM we are using also uses the source address but this is not commonly supported by the NGN telephone elements between the infrastructure. So that's basically a platform internal thing.
Of course we will work with the regulator and if anything is regulated we will support it. We will also supports future protocols, what's going to come. We're going to use and implement and we can also integrate with other registry or databases. We support a super query for other registries, for example the GSMA path finder and that can also be integrated into the system.
Okay. Any questions? Do you have questions for the software? We have Andrew, who's actually the expert on this. We have him on line. He can question much better than I can.
ALEX MAYRHOFR: Alex. A question about the modifications you sort of did ?? should I wait until Andrew is on line?
WOLFGANG TREMMEL: Andrew, can you hear us?
SPEAKER: I can hear you.
ALEX MAYRHOFR: I understand that you modified the ENUM query string so that in order to carry source and destination phone number, it did you do any other modifications to the ENUM protocol?
SPEAKER: No. So as Wolfgang said in the presentation, the thing that's important for us when we're looking at the services is to know other information about the originating leg of the call beyond the standard ENUM stuff which effectively all it gives us is the originating on service provider who's querying us and the destination phone number they're querying about. So in many services we also need to know the A number. We may also need to know, for example, the user, the code he can that it requires, lots other of other potential things that we would get from a normal SIP header. We effectively put a dot notation in front of the standard ENUM number to go between the ?? this really is only internally, between the interconnect tab and the registry. For example, we have the standard ENUM number format, query format in reverse dot formation and we put another dot and the code he can and another dot and the originating service provider and another dot, and that means that our registry understands that and can work on that. It's not strictly a change to the protocol, it's kind of an addition to the way we use it. The alternative is to just use SIP because SIP gives you all the information you could kind of possibly want, but obviously SIP is a much heavier protocol so to speak. We've seen enhanced ENUM and various service requirements but we haven't seen that being commonly independent adopted in the NGN that are queries. So the question is, really, for these kind of services where is ENUM going? Is it going to give us enough information to apply policy and routing roles that are needed or are we going to modify it to SIP in this model? If we enhance ENUM so much it becomes SIP, should we just have gone to SIP? That tends to be our ?? again, we don't enormously care too much how these things go. It's just us trying to keep up with the industry and understand where all the other players are going.
AUDIENCE: This question actually goes to the two of you. I'm just trying to get an idea about the numbers, the size of your operation, both nationally as well as internationally. So in terms of Germany, how much, say, VoIP providers, NGN service providers do you have on board already? What is the foreseeable future? And the same question essentially goes to Andrew as well to get an idea about X Connect's business worldwide in terms of NGN and web providers?
WOLFGANG TREMMEL: We're planning to roll out the service starting in July. We already had a meet Working Group our first customers. They were about 30 customers present. So this is about the group size we would like to start with. Of course I cannot talk for our customers, so as long as nobody has signed up, we don't know. But we are targeting, to say between 50 and 100 customers.
AUDIENCE: Okay. And thank you. And internationally? Andrew, maybe you could comment on that a bit as well.
SPEAKER: X Connect has 150?ish service providers connected to our network for various services and the big question is how many numbers does that constitute? It's a tough question to answer because in many cases we offer lots of different services so in some cases the kind of peering service that Wolfgang has outlined in Germany is the phase 1 service. Obviously just really has the numbers from those service providers that are already connected. Obviously for some of the other services, we have numbers for the PSDN because we do PSDN break out in a similar way using a private ENUM tree to actually provide the core routing. So I guess the ?? to give you an idea, we have the north American number database in our registry. Effectively, we have lots and lots of numbers and 150?odd service providers and sets of numbers. I think this business is really only just ?? we've been doing this a while, but actually the industry itself is really only just coming around to real, you know, true VoIP interconnect. There's still ?? it's still a tier 2 or tier 3 or has been to date thing to do. Now, you're seeing many many more tier 1, so my anticipation is that it will grow enormously quickly. And particularly, as you say, it's very important to do the national versus international. So obviously 80 something percent of voice traffic is national. That's why we work with companies bike DE?CIX to provide that high quality nationally and at the same time recognise in that international is essential. So there's definitely two markets. You'll see that the IPX providers are generally focused on the international market and we very much kind of look at the national markets and then linking those markets together as our approach to that.
AUDIENCE: Thank you. Maybe a quick follow?up question. I wonder in particular in Germany about any other, say, competitors or alternatives to your solutions? In particular the large telco operators may or may not have thought about their own solution already, and in this case I would call it the third?party solution which is offer by DE?CIX with X Connect but it's not a home grown solution among classic telco operators. Is there any alternative stream of innovation or thinking you're aware of?
SPEAKER: I think generally it depends on what you're looking at. So very much the service that most networks want to connect is still voice, as they move forward into NGN deployment, voice is still the ?? the BSDN is still the interconnect thing they want to do. So in that nature we're competing with the transient carriers, Deutsche Telekom being the prime one.
The start of this is the whole move away from that model to support a real, true, multi?media interconnect point, support video, to support all those kind of things. Effectively, the base of the platform and the base of the concept is really to put that real NGN connect point into place. I'm not sure anybody is really looking at that level. We certainly don't see that many at that level. If you see many uppers they'll be a voice IP transit network. We see an advantage in work Working Group DE?CIX as being that existing neutral high?quality carrier meet point. And for us that, model and the same model on the Internet is the same model people will be looking at. The other side of the coin is these transit networks used to make money and it's virtually impossible to do that now. So interconnection will be much more of a commodity that everybody realis that they have to do it. And actually there's no point in 500 people competing for it in the same way there's not ten competing internet exchanges in Germany today.
AUDIENCE SPEAKER: Okay. Thank you.
PETER KOCH: This is also a question mostly targeting Andrew. I'm a technical person, so some of these remarks or questions may sound economically naive, so I apologise. In the context of this forum I'm concerned or confused about the use of the term 'ENUM technology'. What I've seen here happen is that what endrew called enhancement of the standard was kind of an extension putting stuff in the DNS and excuse me but this is kind of the same approach that the electrical engineers or telco engineers that designed the number portability that Wolfgang described, which is based on IETF over ISDN with some magic in the last part of the IP address which works as an authentication token and on and on and on. This is the same way of addressing the problem in the limitations back then, trance form to 2011, 2012, which is, yes, for some things to happen here we would have needed a look at protocol to take into account things the DNS doesn't deliver. It's kind of a hack from a protocol perspective. So one question, and Carsten asked that question from an economic perspective, I'm trying to do it from a protocol side, are there other ?? does anybody know other enhancements or additions to the ENUM protocol that are subsumed under ENUM technology but incompatible on the wire? And what does that mean for this forum or exchanges on a merely technical basis? And what does it mean for this ?? how long are we going to call this ENUM in this context? That's basically my question.
SPEAKER: To answer your question, I guess the big question you're asking which is a very good one is what does ENUM mean. And for me you can split it up as I think I heard some of you guise saying earlier. For us ENUM is a means of enabling customers to query our database and our registry. Equally they can use SIP, equally soak SMF interface, theoretically ARQ, all of those things is us looking at ENUM as a protocol and a method which is commonly supported as an Internet face standard between the network. The question is: Is ENUM as a bigger picture in terms of the structural way that DNS works and the structural organization between DNS in terms of the root server, the delegation, is it in some way related to that? And my answer is not today, from our perspective. Because actually there isn't really a way for the Internet today and there's not an accepted market for it. We would be more unhappy if someone comes up and says actually this is how we're going to do it and it's going to be implemented, we would be happy to link into that system or offer the service. But for me that's the definite separation, the ENUM standard in terms of query response protocols, structure data, structure of records, as a standard between two network elements as a protocol standard, versus ENUM the concept to say it's actually going to be zoned in the same way DNS is and delegate it on a country code level. For me the first is simple protocol, query no different than INET or any of the other query methods we used in the old world, versus the bigger ENUM picture. My question, I guess, back to you: From our perspective we're doing the practical, what we see today and how we need to use it to deliver services. If the industry moves to say, actually it does make a lot of sense to have top level, in the same way the path finder was proposing, we'll fit into that architecture and we're more than happy to conform to that. Does that answer your question?
PETER KOCH: No, thank you. I really appreciate the answer and that was along the line I kind of expected here, that the ENUM terminology or the term ENUM is used on a higher level basis. Taken to the extreme, using IP or Internet technology to do a look up from phone number to some token that gives you routing clue for the VoIP call, is ENUM which in the furthest extreme would also have applied to the original IEPF extreme. What's a bit worrisome, though, is the distinction between the lookup part and the routing part. There was partly, and Alex might correct me, was partly discussed in the early drinks and experiment, that that so miserable failed. You post an open question here and I'm sorry, I can only point to that failed effort here and from a protocol design perspective it would be ?? also from an Internet perspective it would be better and more beneficial to anybody if the technology would merge again and reconvene, but that's not for us to decide here. Thank you, so far.
NIALL O'REILLY: Andrew, listening to Peter's question and your explanation for him, it occurs to me that there's another taxonomy if you like to describe what you're doing here which gets away from whether you're violating the concept of ENUM or not. If I understood correctly, you're using the DNS in a way whereby you take the parameters that you might be negotiating during SIP ?? negotiating in the SIP call set?up phase and instead you're encoding those parameters into a point in the name space of the DNS naming tree that you're using inside your application. And you're using that to pre?qualify the call as to whether it's worth bothering with the more complex SIP trance action that wouldn't have been worthwhile if the call wasn't going to be acceptable. Have I got the right end of the stick and does that help any?
SPEAKER: You've exactly got the right end of the stick. So the reason we tend to use registry as a term, it's a bit of an accepted term, I think what we actually have that sits in the middle is a routing and policy server. And effectively what we're doing is querying that routing and policy server to find out, first, is this call allowed and that allowed is a kind of could be a technical reason or a commercial reason. And secondly if this call is allowed, what route or service should we return for this particular call? And we are really using the ENUM protocol, the extended ENUM protocol to give us a richer decision base on which to make that routing and policy call than ENUM on its own would give us. So you can exactly say, if we queried ?? if they sent us the invite, we have all the information about that A party caller that we could possibly want. If they query us on standard ENUM, generally we have who is the originating service number and what's the B number. We don't know the A number or user agent or whatever other information might be useful for future policy. So it's really as you described it, using the protocol, it's just extending it to make a richer policy and routing decision.
NIALL O'REILLY: Thanks for reexplaining.
WOLFGANG TREMMEL: Any more questions? Okay. Thank you.
(Applause)
CHAIR: Thank you, Wolfgang, and thank you Andrew as well for this insightful presentation. I just wonder whether we would have any on line comments on the Jabber so far? None. Then I'd like to move on to the next item on our agenda which is ENUM operations and I'd like to ask Ann Barcomb from the RIPE NCC to give the update. Thank you.
ANN BARCOMB: Hello. I'm Ann and I'm giving this presentation on behalf of my colleague Anand who wasn't able to be here today. He will be available later on Jabber to answer any questions that you might have.
Sorry, just having to check this.
So there have been no real changes in the number of delegations since RIPE 63. We still have exactly 50. There is one more signed zone, that is Portugal. The rest, the same since 63. Perhaps a little more interesting, of the NX domain responses to queries in the ENUM zone, we see that roughly 99% come from Turkey and, of these, almost all are from a single operator also in Turkey, and actually this is also very similar to RIPE 63, also in the next?up countries, but also Turkey was predominant then.
We do have a little bit of change in the lameness, which is probably less nice here. There were two fully lame zones in 63, that's now four. And the number of completely good dropped from 40 to 35. And that's actually the extent of my update. But if you have any questions, then Anand is on Jabber for you.
CHAIR: Okay.
ANN BARCOMB: Thank you.
(Applause.)
CHAIR: Thank you, Ann. That was a very brief update, but nonetheless, helpful for any further thinking about the ENUM operations, which brings me to point F, the short news and this is the ?? basically the referral of what we had earlier, the two action items, 63.2 and 63.1, and I'd like to ask Niall to the stage first to give up an date on enum.org, website, and the completion of that very action item point.
NIALL O'REILLY: Thanks, Carsten. As you know, or many of you know, this is a short update that I give usually at each RIPE meeting. I didn't give it at the last time because we needed the time for the panal discussion, out of which arose the work that [Denis] has been doing and he'll report on in a moment. The enumdata.org website has been moved with the help of the RIPE NCC web team from its original hosting location which was provided by Kim Davies and I'd like to thank Kim for hosting it for so long and also the team in the RIPE NCC for moving it for us.
Now, I'm not sure ?? so we started this ?? Kim started this when he was one of the co?chairs of this Working Group a long time ago with Patrik Faltstrom. We drew up a standard questionnaire for people to answer and it included the data people sent in. It depends on the data from the people in the 50 or more country where's there's interest in ENUM who have delegations or who have closed down their delegations in some cases. The statistics that I have from ENUM data.org and from verifying that those statistics match the reality match pretty well what Ann has told you. We have 50 delegated ENUM domains, some of those are formerly in a trial status, some are in high at us status, not accepting registrations but keeping the delegation alive, 11 are in production and there's one new signed one. Here are the 11 prefixes in production, and here is ?? and here, indeed, are the six that have secure delegations. And then these are the ones, Sweden and various parts of France and Australia, France has some 11 country codes and six of those are covered by ENUM at the moment. I gather that may change in the near future. Five countries are having trials at the multi?homing. We don't have any new from his those trials, just at this stage. And if any of you in the room or any of you listening or reading the minutes eventually, please send us your updates so that we can fill in some of the blanks at least among the 50 who are maintaining delegation.
The questionnaire itself is other line at the enumdata.org website. If you want to fill in the data questionnaire fill it in in plain text and we'll look at getting it up on website. And thanks to the RIPE NCC who are now hosting that site and to Kim Davies for his kind consideration over the years.
Are there questions on that? No. While I'm standing here I'll move to item F3, which wasn't on Carsten's agenda. There was one other interesting piece of short news in January when the Canadian regulator, Radio, Television and Telecommunications Commission, brought out a regulation on interconnect, and the headline item of that was that a telco that's offering interconnect over IP to any other providers must also offer it to anybody else who is interested. So it's really a fairness of competition ruling, at least at the headline level. But it turns out there's a long policy document and somewhere down at clause 69 or 70 there's a mandate to investigate and begin to develop a carrier ENUM?based database for supporting interconnect in Canada. That space may be interesting to watch. I don't know. We'll see what happens. That's it for now. I guess it's [Denis]'s turn.
CHAIR: [Denis] [Baboota] is coming to the stage to give you an update on the panel discussion that we had at the last RIPE meeting in Vienna.
SPEAKER: Just a quick summary as to why we had the panel session. I was getting extremely frustrateed from operators saying we're doing this, we've done this authentication policy, etc., what was becoming more and more apparent was that there was nothing happening in end user ENUM, numbers weren't going up. Nobody seemed to be interested in asking questions of the operators. It was a case of well things are happening but they're a bit slow. That made me think that actually we're not ?? I was part of the UK ENUM consortium who were leading the governance on ENUM in the UK and we had Nominet as the operator for that, and in my view nothing was happening there. There was no growth in end?user ENUM. And we weren't actually talking to any of the operators or other governance bodies. So I just asked if we could have an open and free discussion to see whether there was any similarities between them, because everyone was going, everything's okay, but truthfully in my view nothing was. We had this panel discussion and from that panel discussion, we had some ?? an action point to go away and talk to the operators,ask them various questions. So we emailed 19 different operators. There were more that need to be done. And we emailed them with questions such as what is happening with ENUM nowadays, how can ENUM services be sold in the market, making phone calls for free doesn't seem to be the main thing anymore. They already ?? phone calls are quite cheap anyway and lots of people are going towards VoIP anyway. Making phone calls for free was not the only attractive solution. We were also asking questions like what are the potential other services between ENUM? And would anyone like to come up with any innovative services around ENUM? Unfortunately we only got three responses back. So we can't really base any main conclusions yet. What we're hoping to do is ?? what we're hoping for is we're going to get more responses in the next few months, maybe we can update a bit more at the next meeting. However, as it standards right now, the conclusions are fairly similar to Alex's presentation earlier today where, basically, it seems and I don't like to say this, but it seems like end?user ENUM is pretty much dead. But let's see what happens with that. We can see the private tree is expanding. There are things where it helps with number portability, for example, that it's very useful there. So generally speaking ENUM as a technology is absolutely brilliant, however, it doesn't seem like it is working in the end user ENUM tree. That's it.
NIALL O'REILLY: I'm wondering, from what you said you'd like to see this as work that's not quite complete yet?
SPEAKER: I still have faith in ENUM.
NIALL O'REILLY: You and Peter are going to be working further in gathering the information and finishing off the work that you undertook under this action item?
SPEAKER: Yes
NIALL O'REILLY: We might leave it open until the next meeting?
SPEAKER: Correct.
NIALL O'REILLY: Great, thanks.
SPEAKER: Any other questions? No? Thank you.
(Applause.)
CHAIR: Which, I guess I guess, brings me to the closing part of this ENUM Working Group session here. From my point of view, I don't have any issues that would interact with any other Working Groups, but that must not be the case from your point of view. So ?? or it doesn't have to be the case from your point of view. If there's any interaction with another Working Group, let us know. I can't see any hands waving. Any other business you'd like to bring up? None as well. Which, essentially, brings me really to the ?? maybe there's ?? is there somebody on Jabber? No. But I see Niall at the mike.
NIALL O'REILLY: Assuming we've reached item Z of the agenda, I'll summarize, we have no new action items and we've left one action item open; is that right?
CHAIR: That's totally exactly right. Thank you for having been here. Thanks to all the remote participants. This is the official closure of this session. There's one more thing. Thanks to the scribe, to Alex to the RIPE NCC, as well and for watching the Jabber space, and also thanks to the scribe for the online scribing. Last but not least, thanks to the technicians from the RIPE NCC who made the ?? and particularly the webcast available possible.
Yes, I guess that's the end of this RIPE 64 Working Group session on ENUM. Thank you so much for having been here.
(Applause.)
LIVE CAPTIONING BY ANNA PAPAMURPHY RMR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE