VoIP and ENUM

The ENUM update session on Thursday was moderated by Wilhelm Wimmreuter (Siemens) and featured three presentations:

• ENUM and Interconnect by myself
• ENUM, VoIP and "Gangsta Rap" - How they all come together by Tom Kershaw (Versign) and
• ENUM and XConnect by Baruch Sterman (Kayote)

The order was naturally given by the content, because I was talking about "User" ENUM" only, Tom about - in his words: Private (Carrier) vs. Public (User) ENUM - and Baruch about a specific implementation of Carrier (Infrastructure) ENUM within XConnect.

So I will also start with my presentation:

What was the basic idea of ENUM?

To allow end-users to opt-in with their EXISTING phone-numbers on the PSTN into e164.arpa to provide OTHER end-users with the capability to look up contact URIs on the Internet the first user wants to link to this number.

This approach has some draw-backs because most VoIP providers do not provide end-users with SIP URIs to be reached on the Internet without termination fees.
(Note: I will come back to this issue in my comments to the last presentation)

What is the basic requirement for ENUM?

A public SIP URI on the Internet. Any „IP Telephony or VOIP service“ not providing a SIP URI cannot be reached via the public Internet and cannot be used in ENUM, therefore Vonage and Skype cannot be considered as VoIP. Vonage is POTSoIP and Skype is an NGN.

In addition there is the problem of Metcalfe’s Law.
(or the critical mass or networking problem as Tom also mentions)

And last but not least: nobody understands ENUM.

What is needed today to implement ENUM?

• A virtual VoIP provider on the Internet providing you with a SIP URI
• A SIP Softclient, Terminal Adapter or an IP-phone
• You need to configure it properly
• If you want to use your own domain name, you need a DNS-hosting service providing you with the possibility to host SRV records.
• You need your national regulator to opt-in to ENUM
• Your regulator has not done this yet? - Then there is no-way to use ENUM with your national number
• You need to find a Registrar in this country
• You have to put all these pieces together by yourself
• Now you have to sit and wait, hoping that somebody will call you with an ENUM enabled device, or using a provider supporting ENUM look-ups
• BTW, is your provider from above doing ENUM look-ups?
• Calls from the PSTN will still terminate on your primary line
• Only calls from the Internet terminate on your IP device

Nobody is able to do this, except some freaks.

You cannot sell ENUM as is, because nobody understands it.

You can only sell a service or a product a customer understands.

What you can sell is:

• a product to an enterprise (or a freak)
• a service to moms and dads ah.. residential users

You have to bundle ENUM into a product or a service e.g. a VoIP (IP Communications) product or service

So new approaches are needed:

• ENUM for IP-based private networks ("PBX“ and “IP-Centrex”) with direct-dial-in (DDI) (a product)
• ENUM-enabled number ranges for nomadic users (teleworkers and road-warriors, using laptops, PDAs, WiSIP phones and dual-mode devices)
  
• mobile numbers with validation via the SIM-Card, to be potentially used with dual-mode devices -> both bullets enabling Fixed Mobile Convergence
• Geographic numbers (genuine or ported) for virtual VoIP providers
• residential users with terminal adapters and FXO ports (product for freaks)

In all these cases the calls are terminated on the same device

I then presented an real example for the usage of ENUM within enterprise PBX linking VoIP-islands together, featuring the following advantages (see animated slides)

• the enterprise PBX can be reached from PSTN and from Internet
• calls to other ENUM-enabled numbers are routed via VoIP and the Internet
• improved functionality (IM, Video, Conferencing, presence, …)
• better quality for native VoIP calls

A second real example showed the usage of the ENUM-enabled number range in operation in Austria since May 17th:

• The format of the number range is: +43 780 abcdef (ghi)
• the registration of the ENUM domain IS the number assignment
• a cancellation of the ENUM domain will relinquish the number
• easy, cheap, one-step process
• end-user is in control of the ENUM entries
• decoupling of number range allocation and gateway operator
• any gateway may route the whole number range,ust needs to be able to query ENUM
• any gateway may route similar number ranges (e.g. +87810, +42360, +260510, …)
• these gateways are called generic gateways

The ENUM-enabled number range provides for the first global IN-service.

So ENUM is on its way, but as Tom also pointed out in the next presentation, there a many problems left to be resolved (if ever):

• Opt-in of more countries (especially the US)
• Metcalfe's Law
• More applications and implementations
• VoIP providers providing SIP URIs
• etc, etc.

I will report on Toms presentation in my next post.

If the FCC or other national regulators decide that VOIP providers providing access to or from the (national) PSTN need also to provide access to (national) emergency services and now think the problem is solved, they may make a mistake.

National regulators think by definition only national. They assume national VoIP providers, access to national emergency services, and using national numbering resources - problem solved. Everything else is an Other People Problem (OPP).

1. This implies that if a VoIP service does not connect to the PSTN, access to emergency services is an OPP.
2. It is also an OPP, if the VOIP service connects not to my national PSTN but somewhere else.
3. Only if the VoIP service provider wants to offer the customer a number out of my national number range, the VoIP service provider is providing PATS (national public available telephony service) and has to connect to my national emergency service system, even if the customer wants to have only incalls. Or if the VoIP service provider is only providing outcalls within a gateway connected to my national network.
4. The VoIP service provider is providing outcalls to the PSTN via another country - this is an OPP.
5. The VoIP service provider is providing my national customer access to my national emergency services, but may use also the VoIP nomadic anywhere in the world - this is an OPP.
6. The VoIP service provider providing citizens of other countries (say a Vonage customer based in the US) access to 911 in the US, but now the Vonage customer is nomadic in Austria and dials 911 and this does not (and need not) work - this is an OPP.
7. A VoIP provider really wants to provide a feasible, consistent and always available access to emergency service to his customers, wherever in the world he currently is? Then the VoIP has to interconnect with +200 different national emergency service systems. Do we think of providing something to ease the VoIP service provider in doing this job.

No, because this is an OPP.

VoIP is a global service (or application) and needs a global solution. So please do not make any final decisions until these global solutions are available (e.g. via IETF ECRIT). But this may take another one or two years.

This part deals with numbering resources for VoIP:

The implementation of specific number ranges for personal nomadic usage for VoIP and for special purposes like ENUM should be encouraged. These number ranges enable new services, provide information to emergency services call takers and provide enough number space.

Nevertheless, VoIP providers require mainly because of customer demand (rational or non-rational) access to geographic number resources, both via porting-in and also with new number blocks. These geographic numbers should not only be available for residents, but also for non-residents.

There should be a consistent ruling at least within in Europe regarding access and obligations for geographic numbers, especially for multi-national or globally acting VoIP providers.

Arguments pro and con should also be backed by facts:

• what is the current usage of numbers?
• what are the current trends considering fixed to mobile migration?
• what can be expected within the next five years if non-residentials are allowed?
  

Some problems are also caused be the current minimum blocksizes (e.g 10000). Can the block-sizes assigned to VoIP providers be reduced or can there be an bundled assignement to a group of providers? It is possible to assign these number ranges per user, so the whole number range can be assigned flat.

This requires either an All-Call-Query IN solution or an ENUM based solution. The number range 0780 is ENUM-based and has a "blocksize" of 1 number.

More creativity (and good will) is requested here.

One additional regulatory problem was not discussed yet, but is lurking in the dark of European regulation:

If fixed-mobile convergence providing one number (see Onephone for All Breakout Session on Tuesday) is to be taken serious, this would cause to have both GSM and Wifi access on one device reachable via one number.

This implies that you either use a fixed (or personal) number on a mobile phone or a mobile number on a fixed phone. It is then the customers choice to port a mobile number to a fixed network or a fixed number to a mobile network. This problem has not even been touched yet in Europe.

Note: US readers may not know what I am talking about, because the have already fixed-to-mobile number portability, simply because there ARE NO mobile number ranges. All mobile phones use also geographic numbers.

This is basically what ETSI TISPAN IMS NGN is all about, but nobody there has this recognized yet (but there are other more important issues they have not considered yet).

This part deals with a way forward on Access to Emergency Services:

The Internet will be the Universal Service of the future

If the acess to emergency services on the PSTN is too restrictive, complicated or expensive, then there is a possibility that one possible way forward could be along the following lines of argument:

• Forget the PSTN, it will be dead very soon anyway
• Provide real-time communication services on the Internet only
• Finally better access to emergency services will be available on the Internet without any need for providers anyway.

This way-forward will be done without the regulators involved and may cause some potential problem for consumers.

Another more feasible way forward could be ( keeping in mind that access to emergency services IS essential):

• Providers (new and incumbents), industry and regulators should work together to provide the optimal solutions available at any given time.
• This solution could be upgraded continuously

Currently the service providers have the primary obligation to provide access to the PSAPs of the emergency service call takers. This obligations will change in future to other entities:

• Device manufacturers
• Access provider, enterprises
• Operating system manufacturers
• Infrastructure in the environment
• Infrastructure on the Internet (DNS)
• …

So why load ALL obligations on the service providers, if this has to change in the near future anyway?

But in the meantime for a transitory time VoIP providers are essential in providing access to emergency services, but they should get support to provide this access, to make the access as simple as possible. This is essentially true for global VoIP providers if they need to interwork with national emergency service access systems.

• A mapping database given a location providing in return an URI to either the responsible PSAP already connected to the Internet or a national specific ESRP (this is basically the open protocol Niklas Zennstrom was talking about)
  
• Emergency Service Routing Proxies (ESRPs) providing access to the existing national emergency service infrastructure to route calls properly to PSAPs on the PSTN and providing CLI for call-back.
• A database providing location information to PSAPs accessible by CLI. The database information is provided static by fixed providers (POTS or VoIP), dynamic by mobile operators or nomadic VoIP providers (via the ESRP)

These three entities could provide a smooth national transition from PSAPs connected to the PSTN to PSAPs connected to IP without involving the globally acting VoIP providers and finally also a transition to the final aim: access to PSAPs directly from any device connected to the Internet without the involvement of a service provider.

Warning: this entry is basically a rant.

To report from the Telecom Policy Europe Session on Monday I have to start with the presentation of Alain Van Gaever on Tuesday.

I agree with Alain that the Regulatory Framework in Europe 2002 is of course more advanced than the Regulatory Framework in the US, based on the Telecoms Act of 1996, because it has already defined electronic communication services and not the "stovepipe" titles as in the US.

The problem with the European Framework is that it replaced the "stovepipes" with a system I would like to call "Babuschka" definitions because it tries to define different types of VoIP services nested like the famous Russian puppets:

Coming from the "IP space" down to "Planet PSTN",

• there are the Information Services,
• containing as a subset the Public ElectronicCommunication Services (ECS),
• containing as a subset the Public Telephony Services (PATS),
• containing as a subscet the UniversalServices, touching base on "Planet PSTN".

Alain then said the differences of interpretation, what an ECS and especially what a PATS is, are only minor within the different countries of the EU.

Here I disagree.

The discussions on Monday and also the outcome of consultations and the ongoing discussions in the EU countries clearly show that this is not the case.

What confuses the discussions in the first place is the circular (some even say the seriosly flawed) definition of PATS in the EU framework.

So every country first tried to make some sense out of the definition when incorporating it in the national laws (and failed) and now the regulators and everybody else involved (mainly providers) try to make sense out of the laws and related ordinances and naturally come to very different conclusions.

So what are the problems with the PATS definition?

One problem is the circularity of the definition. It is e.g. not clear,

• Is a service automatically PATS, if access to emergency services is provided?
• Or if a service is PATS, then access to emergency services has to be provided?.

One could say this is a chicken and egg problem, but this is not so, because the PATS definition also bundles together seemingly unrelated issues with the so-called "rights & obligations" that come together with PATS.

PATS is basically about numbering, number portability, access to emergency services, directory services and integrity & availablity.

Number portability interestingly is listed here under rights.

The interpretations now follow different logical reasonings:

Some say e.g. if you do not provide access to emergency services, you are not PATS and therefore have no right to participate in number portability.

Why?

What is the connex between access to emergency services and number portability besides a artificial PATS definition?

Some others say, because you have a number out of a portable range, you must provide number portability.

Reason: either a number range provides service provider portability or not. If it provides number portability, everbody requesting a number out of this number range must support portability, both a donor or as recipient.

Another connex made is between numbering, especially geographic numbers and access to emergency services.

The approach of the Austrian regulator regarding access to emergency services is that an eventually flawed access to emergency services is better than none, which I support. To help emergency services call takers to distinguish between calls from fixed locations and nomadic users, the CLI displayed in incoming calls from nomadic users must not be a geographic numbers. This also makes sense. A holder of a geographic number may also be nomadic, but in this case he has to provide a different (nomadic) number in the CLI, as a temporary workaround.

BTW, to provide access to emergency services from any VoIP touching the PSTN the Austrian regulator simplifies the ECS-PATS discussion by simply stating that ECS = PATS, therefore any VoIP provider has to provide access to emergency services. Period. Only VoIP providers providing pure IP-IP services do not need to provide access to emergency services. Question: Why not? ECRIT is currently working on this.

The Austrian regulator on the other hand proposes in its recent consulation to provide geographic numbers only to residents having a physical connection within the geographic area. Why this now? Because of a (non-existing) danger of number exhaust. Non-existing for two reasons: first because only 50% of fixed numbers are currently used, the usage of fixed numbers has negative growth anyway and most VoIP want to port existing numbers anyway. The problem with emergency services is already solved above and also valid for non-residents

There is also another issue with numbers in VoIP. In the PSTN most numbers are related to a phone line and the numbers are used both for incalls and outcalls. This needs not to be true for VoIP, as one has clearly seen with Skype. SkypeIn and SkypeOut are two different services.

You need a number to be reached via SkypeIn, but you will never make an outcall via this number. On the other hand you may use SkypeOut without even having a number. Emergency calls are basically outcalls (except the CLI for callback). The interesting point here is that on the PSTN so-called "virtual" numbers have been in use 25 years ago (before 800 numbers where introduced) to provide customers local access to companies elsewhere. Nobody had any problem with this in the past. So what is the problem now? Could it be that the real problem is a completely different one?

BTW, the above example is still one of the major incentives for non-residents to have geographic numbers only for incalls to be reached by customers, relatives and friends by providing them a local number.

This leads to another problem also discussed on Monday: Why are VoIP providers so keen on geographic numbers and number portability? Because currently people are used to geographic numbers, and geographic numbers are still much cheaper to be reached locally and they are reachable, because they are routed. Providers and their customers also fear that weird new number ranges may not be included in packages, will be charged with ridiculous high tariffs and even may have problems to be routed at all.

As the current developments in Austria regarding the new number ranges 0720 and 0780 show, this suspicion is valid.

Incomplete survey: the number range 0780 is still not reachable by some (mobile) providers in Austria, it is reachable from fixed and (some?) mobile providers in Germany and UK, it is not reachable from fixed and mobile providers in Australia and from Sweden it is reachable via Telia mobile, but not Vodafone mobile.
Correction: 780 is NOT reachable form Deutsche Telekom (720 is), but is is reachable by a call-by-call provider? Anyway, the whole issue is a complete mess.

The reason why it is not reachable from mobile providers is that they have not yet decided how much they will charge - with emphasis on how much.

My personal resumee and proposed way forward soon to come in Part 2.

Although I should do some blogging to catch up with the rest of the VON Europe 2005, I am physically unable to do so. The WiFi connection into the garden is excellent, but it is simply too hot. Vienna is experiencing the first heat-wave this year with over 30°C. So the only I managed to do is get this picture taken by one of my sons and post it, just to make anybody envious ;-)

Andy is pointing to an entry in Advanced IP Pipeline: Consortium Demos Its Solution For Emergency 911 Failures

A consortium of universities, governments and companies has banded together to develop a prototype of an emergency 911 system that could solve the nagging problem of locating distressed persons calling from VoIP phones. Called the NG911 Project, the system was demonstrated in Washington D.C. Thursday...

Spearheaded by Columbia University and Texas A & M, the NG911 Project entails using telephones modified at Columbia to connect to an emergency communications center (ECC) location server via a custom "SOS" user resource identifier (URI)....

"Internet phone customers are expected to top 25 million in the next several years," Henning Schulzrinne, computer science chair at Columbia's Fu Foundation, School of Engineering and Applied Sciences, said in a statement. "It is critically important that there be a technically sound and scalable 911 solution in place."....

Companies participating in NG911 include Cisco Systems and Nortel Networks....

Also playing a key role in the NG911 Project is the National Emergency Numbering Association (NENA), which coordinates emergency communications on a national level...

Now this is very interesting, basically because it involves all the usual suspects, but I have never heard about this. I not find anything about this on the NENA and Columbia web-sites. (Ok, I think nobody finds anything on the Columbia web-page ;-)

Next to come will be 911XP

Update: In the meantime it showed up at NENA.

VoIP/IP Leading research universities and technology companies showcased basic features of a next-generation IP-based emergency E9-1-1 solution Thursday, May 26, at the National Press Club in Washington, DC: Attended by representatives from the US Department of Transportation/NHTSA, Department of Commerce/NTIA, Federal Communications Commission, E9-1-1 Institute, NENA, other organizations and news media, the proof-of-concept demonstration highlighted the capabilities of an Internet-based emergency call delivery system for nomadic and mobile Voice over Internet Protocol (VoIP) users to an IP-capable PSAP (Public Safety Answering Point). The technology was developed by researchers from the Department of Computer Science at Columbia University and the Internet2 Technology Evaluation Center at Texas A&M University in partnership with University of Virginia, Internet2, the National Emergency Number Association (NENA), the offices of Emergency Communications for the States of Texas and Virginia as well as with the help of leading technology companies like Nortel, MapInfo Corporation, and others. The two-year project is partially funded by an NTIA grant. At our June annual conference, this proof-of-concept demonstration and equipment will be shown in NENA’s booth throughout Monday and Tuesday exhibit hall hours. There will also be a Monday session concerning the project. Here are additional information links. http://ng911.tamu.edu Project June 26 press release MapInfo June 26 press release

Note: the press releases are of course from May 26

Martin is giving a nearly endless list of features he wants from Skype. Most of them I would agree upon, although there is a danger of complicating the currently simple and intuitive user interface.

What is definitely needed is a better grouping of the buddy list and also a preset conference starting if all participants are online.

One item I really would like to see is an improved presence info. What I miss a a DO NOT MAKE A VOICE CALL, but you may send IM. Or a second button beside the answer call to answer with chat only, so the possibility to turn a voice call into a chat session. Essential in meetings.

I would also like to have some Call Forwardings:
a Unconditional Call forwarding and a conditional on not Reachable (not logged in), although I see the implications if I forward my incoming Skype calls to my mobile phone ;-)

If Skype is going mobile, this feature is essential anyway

Before I go into detail posting on the Telecom Policy Europe Session on Monday and the very interesting ENUM Update on Thursday, I want to give my general impressions from the VON Europe first.

As Jeff already pointed out:

In the end, our event ended up bringing together more than 2,500 people from 65+ countries, representing more than 1,000 companies. The VoIP Buzz was pretty loud this week in Stockholm where about 60 press announcements were made.

In addition, there where 130+ companies presenting at the exhibition.

Visiting the VONs both in the US and Europe for some years, I can only say that I am impressed. Although the VON events in the US are still twice the size, I think VoIP in Europe is gaining speed and catching up very fast. Up to now it was only recognized by experts that the VoIP scene in Europe is well advanced and in some aspects even more advanced than in the US and Asia, but since it was driven mainly by small up-starts (surprisingly un-typical for Europe), both on the supply and provider side, it was not on the radar of the large providers (telcos) and also not for the press and the public.

This seems to change now and the VON and Jeff's effort is a main driver here.

Just one example: In the bag usually distributed at the VON was beside the well known flyers from the sponsors also a copy of this weeks BusinessWeek, featuring on the cover the 25 Stars of Europe (Agendasetters-Managers-Financiers-Innovators)

Two (or three?) out of the 25 stars have a relation to broadband and VoIP and I have a slight suspicion this was the reason why the issue was in the bag in the first place:

1. Ben Verwaayen, the Dutch(!) CEO from BT Group as Agenda Setter listed under "Strike up the Broadband"
2. and of course Niklas Zennstom, the Swedish CEO of Skype as innovator listed under "Disruptive Telecom"(!)
3. I am am not sure if I should count also Bo Vesterdorf; president, Court of First Instance, Luxembourg, listed as agenda setter under "The man who said NO to Microsoft" ;-)

This clearly shows the public awareness broadband and VoIP is getting in Europe.

The basic problem of the VONs remain, you have to split up yourself into three parts to see the presentations, the exhibition and to do the networking.

Especially the last thing was very important this time, not only for me, I have heard this from others too. Since this time many newcomers where here the first time at a VON, one was busy beside the normal networking (exchanging news with old friends) with making new friends, asking questions and responding to questions.

So I missed many presentations on Wednesday and Thursday (even nearly my own ;-) by having one side-meeting after the other, talking and being talked to.

In addition there was the largest and busiest exhibition ever in Europe, so one had to spend some time there and most of the time the stands where very crowded.

I will report on the Telecom Policy Europe and also on the ENUM Update in separate entires, and I do not need to go extensively over the main session on Tuesday morning, because these presenations have already been covered by others, e.g. by Steve, by other bloggers and of course in the press..

Just a short re-cap: Jeff opened as usual with his warm-up on Shift Happens, giving the directions. Interesting for me also the presenation from Alain Von Gaever from the Commission, as a follow-up to the Telecom Policy Europe session on Monday. Alain did not present on Monday, but was there all day and actively participating in the discussions, and he tried to answer some of the issues from Moday in his presentation. I will come back to this presenation later.

I do not need to say anything about the presenation from Niklas Zennstrom on Skype, the crowd in the room peaked, and what he said is all over the blogs and the press.

I just want to pick out one statement from Niklas I consider very interesting (or curious).

Niklas requested:

• Provide open interface to emergency centrals which can receive text, voice and video over IP
• Build up national IP geo mapping databases managed by national authorities

I will come back on emergency service issues later, and basically IETF ECRIT is already working on this, but what I consider curious is that Niklas requests open(!) interfaces.

Hear! Hear! Maybe Niklas or somebody from Skype will show up on the ECRIT mailing-list or even at one of the next IETF Meetings (Paris, France would be a good place). Niklas, if you want to contribute, you are welcome ;-)

The morning session was closed by James Enck, excellent in content, slidewise and also presented by James.

I agree with Steve that this was the best presentation of the whole week (at least from what I have attended) and many others I asked shared this opinion. What is always refreshing with James (also on his blog) is that he is viewing as securities expert the whole scene from a different (non-technical) angle and therefore always providing new insights.

Jeff is thinking about two VONs in Europe next year and I wish him that each one will be larger than this one.

Finally the VON Europe is over and I am back in Austria having 24/7 Internet access, so I may start to catch up with blogging. Regarding my previous enrty I basically started to try to post on Wednesday evening and finally managed to have it online Thursday noon, so I gave up.

OK, I am used to the fact that WiFI Access in large meeting rooms is bad, because there are always some morons operating their laptop in ad-hoc mode. Same thing happend at the last ETSI TISPAN Plenary.

It is also known that WiFi and Internet access at VON events is shaky and not very reliable. But this time in Stockholm I was cut-off from the Internet for hours and this was the worst experience I had since years.

This was not only Pulvers fault: in addition to the WiFi and VON problems, the ISPs here seem to be offering Internet service like power supply in wartimes only for some hours a day. On Tuesday evening I booked in at the Radisson Viking approx. at 10 pm for 24 hours for a steep 20 Euro. I had access for 20 min and then it was over until after midnight. I had WiFI access, but no Internet connectivity. Considering this as a unique glitch, I was idiodic enough to book in on Wednedday again after 10pm, and the same happened after 10 min access. I went to bed after one hour, so I have no idea when the access came back, it worked again in the morning.

Other attendees told me that the same happend at the Radisson Strand and in some other hotels, so it must be a common feature in Stockholm. On Thursday morning at the VON I had Internet access only for seconds and the VON people told me it was the ISP.

One always hears that the nordic countries are ahead in Europe regarding broadband connections, but in these statistics obviously nobody considers up-time.

In addition, Stockholm Arlanda was the first airport that managed to loose my luggage on a direct flight and on arrival. So I had my luggage delivered to the hotel in the morning after.

The VON "Blur"

... and is reporting back to his new boss about the progress he already made in his training-on-the-job as CTO.

When the exhibition opened yesterday the first booth I had to visit was of course the booth of my friends from Kapsch CarrierCom, an Austrian supplier of carrier grade equipment, and the first company to use ENUM to access their corporate voice network (with real SIP URIs). It was nice to meet Henry and Willi there. Henry, having a new job with Pulver, is finally starting to get some basic knowledge about VoIP by reading VoIP for Dummies. It is never too late to start something new and exiting.

My problem to blog from the VON is very simple: no time. Too many things are happening here and all at the same time: Meeting old friends, making new friends, listing to the presentations and finally visiting the exhibition. Jeffs VON Blur.

I immediately bumped into Jeff and he was really exited to tell me that about 1500 participants from 62 countries registered, also many from Middle East and Africa. There are also over 130 exhibitors. He also told me that he is planning to have two events next year in Europe, one in Spring and the other in Fall.

Update: according to recent figures it is more than 2500 participants

It is now already Wednesday and I have no idea where the time is gone. I am halfway thru writing an entry for Monday about the Telecom Policy Forum on Monday, which I attended the whole day, basically aslo because I also was a speaker, but I did not manage to finish it yet.

I will also not manage to finish it today, because this evening is the already famous Pulver Party ;-)

So stay tuned

South Styria4

South Styria3 

South Styria2 

South Styria1 

To get prepared for a week of "VON Blur", I spent a relaxing weekend in the Wineland of South Styria, just at the Slovenian border, enjoying the 40 year reunion with my classmates.

I really envy Jeff having two shows on one day. Is this Washington, DC or Las Vegas?

I also enjoyed his two (nor so subtle) hints on the FCC:

Watching the movie and thinking about what had just happened at the FCC, one could draw some pretty clever analogies across both storylines..but I’m not going to. Not now.

and 911:

One thing which never came out during the course of the movie was what the Republic’s position on E911 over Real-Time Holographic Imaging communication might have been.

Good question ;-)

Maybe at least IETF geopriv (galactopriv?) should start to consider galactic coodinates.

CU in Stockholm at the VON next week, Jeff.

and I have (like everybody) to put my 2 cents worth into the blogosphere:

What are the lessons to be learnt?

Lesson 1:

For regulators: technology-independent regulation of telecommunication services translates to:

• as long as you do not touch the PSTN, you are not regulated.
• if you touch the PSTN, you are PATS
• it is all about numbers, emergency services and Legal Intercept

For VoIP providers:

• if you are providing VoIP services as POTS replacement, and also market these services as POTS replacement, you should not wonder if you finally are regulated like a POTS provider.

Ok, so in the US they have to live with this decision

One possible way forward is what Jeff is hinting at:

• The Internet will be the Universal Service of the future
• Forget the PSTN, it will be dead very soon anyway
• Provide real-time communication services on the Internet only
• Finally better access to emergency services will be available on the Internet without any need for providers anyway.

Another way forward could be taken with the more feasible and sensitive approach already taken by some European regulators (and Canada):

• Access to emergency services IS essential and should be provided even if not perfect
  
• Providers (new and incumbent), industry and regulators should work together to provide the optimal solutions avaiable at any given time
  

VoIP providers (especially global acting ones) will need support to provide access to emergency services:

• A mapping database which is given a location and providing in return an URI to either the responsible PSAP already connected to the Internet or a national specific ESRP
• Emergency Service Routing Proxies (ESRPs) providing access to the existing national emergency service infrastructure to route calls properly to PSAPs on the PSTN and providing CLI for call-back. These ESRP hide the national specifics
  
• A database providing location information to PSAPs accessible by CLI. The database information is provided static by fixed providers (POTS or VoIP)and dynamic by mobile operators or nomadic VoIP providers (via the ESRP). This dateabse is a national matter and can be replaced later by directly providing the information to IP-based PSAPs
  

This solution could be upgraded continuously

According to Skype Journal today the 3 Million User on-line concurrently threshhold was reached.

Since I got many questions asked regarding the new number range +43780 that went into operation in Austria yesterday - even from ENUM Experts, I would like to answer the most important questions here.

What is difference of +43780 to any other number range?

The number range +43780 is linked 1:1 with ENUM. If we leave out for a moment service numbers (e.g. 0800 freephone numbers), any other E.164 number range is first assigned in blocks to a network operator. The network operator in turn assigns a number out of this range to the end-user. The block assignment is necessary to allow other network operators to route calls to these range of numbers to the proper destination network via the so-called Point-of-Interconnect. If number portability is introduced, an IN-query may be necessary to route the call to the PoI of the network of the new operator.

An end-user may only opt-in with a given number in ENUM if he has the right to use this number (the number is assigned to him by an operator or directly by the regulator) and he is proving this fact to the ENUM Registrar. This is called Validation.

With the number range +43780 the opposite is the case. The number is first delegated in ENUM like any other domain name, and is assigned afterwards to the domain name holder (for political correctness). Therefore the complicated and expensive validation process is not necessary.

How are +43780 numbers routed on the Internet?

Like any other numbers in ENUM, directly on the Internet from calling to called party.

How are +43780 numbers routed on the PSTN?

All other E164 numbers are routed on the PSTN regardless of ENUM, in most cases to the still existing end-point on the PSTN. +43780 numbers are always routed to the nearest ENUM-enabled gateway. This gateway is querying ENUM and routing the call like any other ENUM-enabled server or client according the information contained in the NAPTR records.

Where is the nearest ENUM-enabled gateway?

Ideally within the originating network. If the originating network has no gateway, it should route the call to a the nearest network operating a gateway. This may be in the same country or in different country. In the worst case the call is routed via the international network to Austria.
This guaranties that a call to +43780 can be completed from any network in the world by default.

What are the tariffs to +43780 numbers?

The tariffs are charged to the end-user by the originating network. It is expected that calls are charged somewhere between a local or national call if a gateway exists within the network or within the country. In the worst case an internatonal call is charged to Austria if the originating network is not aware of the number range.

Does the VoIP provider get termination fees?

No, because the call is delivered on the Internet.

Does the gateway operator get termination fees?

Yes, according to the national interconnect regime.

Does a VoIP provider has the right to get the call delived via his gateway?

If a VoIP provider is operating a gateway, he has not right to get calls to his subscribers delivered via his gateway. The PSTN is not aware of ENUM assignments to VoIP providers and there is also no assignment of single numbers or number ranges to specific gateways. The decision which gateway to use lies completely within the originating network

Is an ENUM-enabled gateway dedicated to the number range +43780?

No, the gateway may route any call to a number or number range known to be in ENUM. Another ENUM-enabled number range is +87810. The gateway may also route calls to single numbers known to be in ENUM, e.g. if the calling user forces the call to ENUM by dialling a specific access code, or if the number is known to be in ENUM by an IN-query.

What if no compatible service in ENUM exists?

Since the ENUM entries are controlled by the end-user, the end-user may decide not to provide a NAPTR record containing a voice service. In this case the call cannot be completed with cause value "service not available". This may also happen on the PSTN if you call a fax device

What services are currently supported?

The ENUM-enabled gateway from Telekom Austria supports the enumservices sip, h323, voice:sip, voice:h323 and ifax:mailto. It is recommended that other gateways support a similar range of services. Update: h323 and ifax are still under construction.

Why is voice:tel not supported?

Voice:tel would require a forwarding of the call to the PSTN, which would incur costs. Since this cost cannot be charged to the calling user and also not to the called user, this calls are rejected with cause value "service not supported", if no other possibility to complete the call exists. If the user want to forward a call to the PSTN, he should use call forwarding with his VoIP provider.

Needs the same gateway to be used for outcalls?

No, on the contrary, it is very unlikely that the same gateway will be used. VoIP providers may not even be aware of the incoming gateways, but they need to provide the user with the capability of out-going gateways for calls to the PSTN. A user may also decide to use a different VoIP provider for outbound calls, although it is recommended to use this number range in CLI display for call-back and calls to emergency services to indicate nomadic usage.

What about number portability?

Number portability in the meaning of the PSTN is somehow not applicable or naturally built-in. The end-user may decide at any time to change the Registrar and also the Name Server Provider, similarly to any other domain name hosting.

The end-user may also decide to change his VoIP (or e-mail) provider by changing the content of the NAPTR record pointing to a given provider. Therefore service provider portability is done by the end-user.

Where do I get a +43780 number?

Anybody may register such a number, for available registrars see enum.at

I registered at www.my-enum.at the number +43 780 203 211, the SIP URI is pointing to my fwd-account. The fee per month with this registrar is 3,60 Euro.

According to LightReading "sources close to the FCC" say the ruling regarding E911 will come at the FCC’s Open Meeting on May 19th (tomorrow), and will require VOIP players to implement 911 service on a nationwide basis within 120 days of the order’s publication. They add that publication of the order will come a few weeks after the meeting, which would put the compliance deadline at late October or early November.

Tom Evslin is trying to tell the FCC that it is making a mistake if the ruling is "according to the sources" and is analyzing the situation and the potential alternatives the FCC should take.

I fully agree with Tom, I just ant to make some additonal notes from a European perspective:

Tom is correctly statting that:

... it is hard to ignore the fact that consistent E911 service is still not available on cellphones and the FCC has not seen fit to take emergency action there. According to a recent Wall Street Journal story, one third of 911 calls are made from cellphones.

I want to add here that I talked to emergency organisations here in Austria about this percentage and got the answer: ... well over 50% (not to mention mountain rescue, where by nature the percentage is over 95% - and they are really in urgent need of better location information than cell info.

Another important statement is the following:

If the FCC DOES decide to regulate as reported by sources, it will impose an obsolete solution based on obsolete technology on IP providers who are working on much better solutions based on new technology.

It is even worse. Since VoIP is an application and you basically do not need a service provider at all, IETF ECRIT and other groups like GEOPRIV are working on a solution providing the cabability of making emergency calls without the need of a VoIP service provider. So the FCC will impose obligations on the wrong entities.

So I also strongly suggest to the FCC 1. to do nothing and 2. to study the situation. Mobile operators provided weak solutions for ten years, so why the hurry now with VoIP? Weak and strong lobbying?

Tom is also pointing to the more "enlightened" approach of Canada. Also the regulators in Europe are holding back here, I just want to point to the recent VoIP ruling in Norway:

Related to emergency services, the ruling says:

9. VoIP providers that offer services that are used nomadically, will have an option to be granted temporary exemptions from the emergency calls caller location requirement based on further conditions, inter alia an obligation to inform its customers about potential risks.

The Austrian Regulator has a similar approach not to impose too strict regulations at the moment and wait for further developments.

As already announced here one month ago, the ENUM-based number range +43 780 went into operation today. A short decription of the number range is available here. Anybody may register such a number, for available registrars see enum.at

I registered at www.my-enum.at the number +43 780 203 211, the SIP URI is pointing to my fwd-account. The fee per month is 3,60 Euro.

There is only one gateway currently in operation with Telekom Austria, so calls get routed via the international network to Austria. The gateway supports SIP, H323 and also ifax:mailto. Any operator may implement his own gateway.. The call is charged within Austria like a national call.
Update: A second gateway is in operation in Austria (Colt).

On the Internet the number range can be used like any other number in ENUM.

Jeff's outstanding essay "E911/VoIP: Death of the Broadband Parasite in the USA?" served me as an eye opener and untied a knot in my brain about VoIP regulation, especially when he is citing his paranoid friend:

My friend's conspiracy theory highlighted three parallel activities: numbering; lawful intercept (CALEA); and emergency response (9-1-1). My friend suggested that, at the calculated moment, certain powerful forces from inside-the-Beltway would take action and put an incredible amount of pressure on government and industry to apply legacy thinking to kill innovative technology. I believe that, so far, we have, more or less, adequately kept at bay both the numbering and lawful intercept issues (although I am convinced these issues wait in the wings to further devastate IP-based communications advances). ...

No Jeff, numbering has not been kept at bay, because both CALEA and E911 are tightly coupled with numbering. E911 is all about using emergency numbers and CLI for identification and so is CALEA.

But all this is not VoIP Regulation. Let's step back and reconsider what VoIP stands for: VOICE over INTERNET protocol. Voice (and other communications) over the Internet is (currently) out of the reach of regulators and is not regulated by what is called "VoIP Regulation".

"VoIP Regulation" is only able to step in if voice (and only voice) communication is touching the PSTN:

• if a voice call originating on the Internet is terminating on the PSTN (needs a phone number)
• if a voice call originating on the PSTN wants to reach somebody on the Internet (needs a phone number)
• if a POTSoverIP phone (duck phone) wants to make or receive a call (needs a phone number)
• if one wants to make an emergency call to a PSAP connected to the PSTN (needs lots of phone numbers)
• if you want to intercept a phone call at a PSTN gateway (needs a phone number)

Trying to intercept genuine voice communication on the Internet is not easy to begin with and can easily be prevented by encryption (e.g with Skype or VPNs).

So "VoIP Regulation" is not dealing with VoIP, it is dealing only with VoIP touching the PSTN and all these issues are connected with numbering. If a VoIP provider needs a number for his customer to be reached from the PSTN or display a proper CLI for call back, gotcha. If you want to provide emergency calls (at least in i1 or i2), you need a number for ANI and callback, gotcha.

I always advised against this development, because it would introduce an unnecessary divide in global communications, namely driving broadband communication to IP-only and creating complications for the consumers, but in the mid-term will kill the PSTN faster then otherwise.

The reason is that if the tipping point is reached and more people will be connected to broadband, the PSTN will die very quickly. One should not forget that in Europe mobile penetration is reaching already 100%, which implies that every person has at least one broadband access capability.

For genuine Skype-Skype or even SIP-SIP with URIs you do not need a phone number. You also do not need a street address to receive an e-mail.

And of course these development will also kill the "broadband parasites". These are living on arbitrage only. If finally there is only "free" IP-IP communication and no real "service", only an applications and products, there is not more business case for specific VoIP providers then for e-mail providers.

Of course there will be some business left for residential users not having company accounts, but they will get VoIP service as add-on to the access, similar to e-mail and a 10MB webpage.

Update: And one should not forget that ECRIT and NENA I3 is working on emergency service access genuine on the Internet

In my recent post "Do we need phone companies for VoIP" I am citing Tom Evslins post "As the Phone World Turns Part 9 - Do we need Phone Companies?" and asking myself if this will be the last of the series. As I suspected, it was not the last one.

Tom is continuing with "As the Phone World Turns Part 10 - We Won't need Mobile Carriers Either!"

The essay is another tutorial, in this case about presence information and connectivity to IP by mobile access providers.

The title is a bit misleading, of course mobile carriers are necessary, but only as access providers to IP, but not anymore as mobile service providers. So is should read: we won't need mobile service providers either!

What I need in future is mobile access, provided by GPRS, UMTS, WiFi, WiMAX and whatever standard will be availbable in the future. What I also need is a means to identify myself to the network in question. This could be a SIM-Card, but it could also be a credit card or a Maestro card. I do not even need to identify myself to the network, I need only to provide prove to the access network that somebody is willing to pay for my charges.

What I do not need is a home NETWORK. What for? I am attaching to the Internet via the access network available at my current location - I do not need more. I do not need the e-mail services from my "home mobile network", so why should I need voice services?

So much for IMS NGN.

BTW, having no Home Network would allow me to roam also in Austria between networks, e.g. if my HOME network does not provide me coverage, so it would even be an improvement.

Today Austria is celebrating an important anniversary: e.g. from BBC:

Austria is celebrating the 50th anniversary of the end of the allied occupation after World War II.

Officials from Britain, France, the US and Russia - the four occupying Allied powers - are attending the event.

Russia has lent Austria the original copy of the State Treaty through which the country regained its sovereignty.

The state treaty was signed 50 years ago by the foreign ministers of the Allied Powers Pinay(France), MacMillan(GB), Molotow(UdSSR) and Dulles(US). The basic idea was to have similar ranks attending the anniversary, and this was also honored by 3 of the signatories: France and Russia sent the foreign ministers Barnier and Lawrow, GB is sending Alexander, the Minister for European Affairs. And what about the US?

Since Condolezza is exhausted from attending the other anniversaries in Europe and Russia last week, George is feeling sympathy with the poor woman and sending a high-ranking replacement: Rudy Boschwitz, Ex-Senator from Minnesota. Nothing against Minnesota, I am really fond of Minneapolis in March hosting the annual Spring IETF meeting, but who is Rudy Boschwitz and what is his relation to Austria?

This is just another nit: I always liked to travel to the US, both on business and vacation, but in the last two years I am starting to dislike to travel to the US. The hazzle starts with the special security checks at home, now you can't even take a gas lighter with you, immigration to the US is getting more and more a pain in the a**, maybe in fall I will need a new passport, although my old one is only 5 years old, and so on. What is more important is that I recognize that attendance to meetings in the US is shrinking, lot of nations stop to show up - just look at the number of different countries attending IETF meetings in the US and elsewhere.

Of course I understand the importance of the US market, but why not holding meetings intended for the US market for some years in Canada only? Spring VON in Vancouver and Fall VON in Toronto, Spring IETF in Winnipeg?

I was waiting to be able to use my mobile phone as an audio device for my laptop since years and did not really understand why nobody implemented this up to now. So I was really exited when Andy pointed on a recent entry to a Skype Push-to-Talk application for Symbian phones using Bluetooth. I should have know better.

I was never able to get Bluetooth working properly. I used an Acer Bluetooth stick on my previous laptop together with my Siemens mobile phone, but never managed to get it working properly, so I finally gave up and used the cable. Only the Siemens headset and the Siemens phone worked with Bluetooth.

When I got my new laptop I detected the Acer Bluetooth stick in a drawer after some time and having nothing else useful to do at the moment, I tried to use it again (yes, I did install the drivers first before I attached the stick). The only result was an immediate and complete freeze of Windows. So I forgot the whole issue for one year.

Now having also a new Nokia mobile phone and a Bluetooth headset, and knowing that a friend of mine is always using his Bluetooth headset talking to his laptop, I decided to give it another try and buy a new Bluetooth stick from Belkin featuring also headset connectivity on the box.

So I first tried it with the mobile phone and the Nokia PC Suite to and it worked. At least for some time. I finally detected that it works always after Reboot. Then it continues to work, but after the first save-to-disk it does not work anymore. It seems to be some problem with Nokia PC Suite, because Nokia PC Suite discovers the phone and connects, but refuses to communicate properly and also blocks all other programs to communicate. On the other hand, if I switch to the USB cable, it works immediately.

So I should have know better. I installed the above Skype PTT program from Usefulapps and when it was done, the Readme opened.

The first thing I read was: ... OhOH!

If you are using PC Suite for Nokia you will get error message "Can not find Bluetooth serial port" from Useful server. In order to resolve the problem disable(uncheck) all PC Suite Bluetooth ports by using PC Suite Connection properties dialog and restart the computer. In order to use PC Suite again stop Useful server by using Start/AllPrograms/Useful/Skype PTT for Nokia 6600/StopServer and enable PC Suite Bluetooth ports.

Ok, I tried everything proposed and even some things more, eg some popups from useful app ordering me to boot the laptop and the phone, which I did, booting the laptop and the phone at least three times in different orders. The Usefull application on the phone never could get in touch withuseful app on the laptop.

So I finally gave up after two hours trying. Maybe I am too stupid for this.

If you talk to the average regulator, you hear within five minutes that the Telecommunication Law and the derived regulation is technology neutral and VoIP is just another technology. Ok, if this is the case, I have a question for clarification (to stick to ITU-T terminology):

Why is every regulator in the world making consultations regarding VoIP (some of them already the second or third), making decisions, just to make another consultation after some time? Robert Shaw is pointing at the ITU-T VoIP Newsblog to the ITU-D 2005 Regulatory Proceedings giving a snapshot of the current consulations and decisions.

So if regulation is technology neutral, what is all this fuzz about?

Is VoIP not fitting in the current framework because it is more then just another technology? Is it a new model (to avoid the term paradigm)? Maybe the current framework is flawed and needs an update? So all current activities are only tinkering, not solving the basic problem and making things even worse?

Of course we are talking here about vertical and horizontal models ;-)

It is also interesting to see the winding path regulators are taking regarding VoIP: first regulators where very sceptic, then they remembered that they primarily have to act for the customer and the economy as a whole, and also they wanted to be considered innovative and cool. In the meantime the various lobbies had time to recover and also the really serious issues surfaced, e.g. emergency calls. BTW: one of the most serious issues is still lurking: legal intercept, because here really nobody has any idea how to do this.

Jeff Pulver is analysing the situation in the US regarding 911 in two entries and we will see the outcome next week.

Interesting also the situation in Canada. Bloggers are devided concerning the ruling, especially Ted Wallingford is swimming against the mainstream with his entry Feeding Bell Canada to the Dogs?. Most of his arguments are quite feasible and may also be valid at the moment - and I also was always saying that the incuments should stick to their knitting and provide basically access.

But one should also step back to see the bigger picture:

VoIP cannot be on one side an application for anybody else and on the other side a PATS service because it is offered by an incumbent. So this assumption is flawed from the beginning.

Very funny is the requirement that LECs have allow their customers to select their long distance carriers (para 242). This clearly demonstrates the understanding - I always though on IP I have equal access built in?

I also wonder (maybe because I was not too involved in the details and definitely have not read all 480 paragraphs like Tim Denton) what it means that the incumbents are not able to set their own prices? The monthly rate, or the prices for outcalls, the termination fees or are they even forced to charge for on-net calls?

The whole discussion especially in North America seems to be too much focused on VoIP as cheap POTS replacement, maybe triggered by Vonage et. al.

These implementations are IMHO stillborn anyway.

The reall challenge of the future is real-time communications, converging all types of communication to mobile devices, including presence and location based services. You cannot do this with a terminal adaptor or with an IP-phone pretending to be a steam-phone.

And what about Skype and fixed, mobile and IP convergence?

My friend Lawrence Conroy pointed out today an article dealing with a similar confused issue - copyright laws - by James Boyle : Deconstructing Stupidity in the Financial Times. He especially referred me to the following statement - I have no idea why ;-)

It is as if we had signed an international stupidity pact, one that required us to ignore the evidence, to hand out new rights without asking for the simplest assessment of need.

I want to pick up on the statement by Jon Peterson on slide 2 of his presentation: at the ITU-T/IETF NGN meeting in Geneva I posted last week:

On the Internet, telephony is an application
– Not necessarily a service, no service must be provided

ETSI has finally published officially the two documents on ENUM already approved at
the January 2005 TISPAN Plenary:

ETSI TR 102 055 V1.1.1
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); ENUM scenarios for user and infrastructure ENUM.

The first document covers the ETSI view on Infrastructure (Carrier ENUM), the second document deals with (User) ENUM

ETSI TS 102 172 V1.2.1
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Minimum requirements for interoperability of ENUM implementations

This document serves as the basis for the ETSI ENUM Plugtest and should therefore be retrieved by anybody participating immediately.

The ETSI ENUM Plugtests event will provide a vendor-neutral setting for equipment manufacturers, operators, ISPs, registries, software companies and system integrators to carry out controlled interoperability and conformance testing. It is a chance to discover ENUM system behaviour with miss-configured clients, servers, and intermediaries, so that they can explore the symptoms of such problems before their customers.

For further details and to register, please visit our web site. The registration deadline is 16th May 2005. Please, show your interest by registering as soon as possible, but payment is not due before 23rd May 2005. Upon registration, you will be provided with ETSI's preferential rates for hotels and car rental.

This invitation is open to anyone who may be interested so please feel free to forward it…

The rumor has been out for some time, but now it was announced by Henry officially:

I have started last week my new job at Pulver.com in the hope to contribute to SIP not being replaced by Skype and maybe we can also do something to interconnect all the SIP islands using URIs for IP-IP instead of phone numbers and the PSTN.

I wish Henry all the best in his new assignment and I hope that he will drive the SIP development in the direction he points out above with his usual enthusiasm. I also hope that Henry will be around for the next years, at least until I retire ;-)

Good luck and success, Henry!

The Framework Document for a US/CC1 ENUM Trials Program 6003_1_0 was published today by the US ENUM Forum as Released Document. Released Documents have been agreed to and balloted by the full ENUM Forum.

The document was also posted on the new website of the Country Code 1 ENUM Limited Liability Company on the webpage related to the CC1 ENUM trial information.

The document describes a framework for an ENUM trials program within the US/CC1. It gives a picture of how such trials might be conducted using a trial CC1 infrastructure, which is one of some of the possible architectures for implementing US/CC1 trials. The document also identifies some issues that would need resolution before trials could begin. This document is not intended to proscribe anything about trials that might be conducted by other CC1 countries.

Of interest is the trial schedule within the document:

The following schedule is based on the date on which the members of the ENUM Forum approve this document, and is expressed in incremental weeks from that date. It also assumes that the delegation of CC1 has already taken place.

The trial schedule is as follows:

Participants identified +2 weeks
MoU Signed +4 weeks
Trial Begins +6 weeks
Trial Ends +32 weeks
Report generation +36 weeks

This implies IMHO that the request for delegation to RIPE NCC and ITU-TSB should take place IMMEDIATELY and the trial may start somewhere End of June 2005.

According to Reuters the U.S. Federal Communications Commission Chairman Kevin Martin has proposed requiring Internet-based telephone services to offer 911 emergency services to customers by as early as the end of September, people familiar with the plan said on Wednesday. ... The proposal would require companies like Vonage Holdings Corp. to route 911 calls directly to primary emergency lines within four months of the order being issued, the sources said, declining to be identified because the proposal is not a public record. Martin has circulated the proposal so it could be voted at the agency's open meeting on May 19, the sources said. He would have to win the votes of two of the other three FCC commissioners for approval or work out a compromise with them. An FCC spokesman had no immediate comment.

Ok, I have some immediate comments:. This approach is typical how politicians solve technical problems today: by setting a dead-line. These technical morons always raise issues and come with endless problems, you just have to give them a certain date - if it works out, it is your success, if not, you simply blame the technicians - everybody knows how stupid they are.

Location infomation from mobile phones, biometric data on passports, too sexy cheerleaders in Texas, emergency calls from an application on a PC, all the same.

Being involved in IETF ecrit , NENA and ETSI EMTEL, I know of the intentions, requirements and the status of work in these groups to provide emergency services from devices connected to the Internet. To make it short: the issue looks promising and at the end-of-the-day the solutions provided will be superior what we have now, but there are still some problems to be solved and this will take some time.

One outcome of this will be basically derived from the same principle I talked aboiut in my post on the NGN: The Internet is end-to-end and VoIP is an application, not necessarily a service.

This implies that you may not have a VoIP service provider at all, so why put obligations on service providers in the first place. The obligations will shift to device manufacturers, access and infrastructure providers and to the PSAPs. But this will need some considerations and also regulatory and legal action, but these issues can definitely not solved within 3 month.

In addition, if you provide a VoIP service on the Internet only, you are not obliged to provide access to emergency services. Now if you provide OutCalls (say SkypeOut) in addition, you are? If your gateway feeding to the PSTN is not in the US?

Hmm, but if you provide InCalls from the PSTN, now you are obligated, because you need our national numbers, hehe, gotcha. But we are dsicussing calls TO emergency services, so what has this to do with InCalls to a E.164 number. Ah, it is the number displayed in the OutCalls to identify yourself to the ANI and ALI, or whatever. But what if I use two different providers for In- and OutCalls? The provider for OutCalls will not know the number I have from the provider for InCalls, so what is displayed in the OutCall. This will be no problem with future direct connectivity IETF ecrit is working on, because the identity and location will be transmitted directly to the PSAP, if the PSAPs have VoIP connectivity.

But this will not be the case until September. Ok, in the meantime Verizon and SBC may sell their products to the VoIP providers. Now I finally got it.

Good day!

Our well-known friend Vince Humphries (former with ERO) announced today via the RIPE ENUM WG list (see below) that the Australian ENUM Trial in 1.6.e164.arpa finally has started officially.

I wish Vince and all others involved in the trail good luck.

The post from the RIPE ENUM WG list:

The problem with the Next Generation Network (NGN) is not that there exists no definition what it is, it is the other way round: there are too many definitions and viewpoints, so everybody has his own opinion. This faith of course is depending what an individual thinks that the "Existing Generation Network" is. Bellheads living in a circuit-switching (TDM) world basically think the NGN is a "packet-based" network (because they like to be generic and want to avoid the term IP, because it is to "specific").

In turn the term NGN was not well understood (and if, not very much liked) by the netheads at the IETF, because they obviously consider "packed-based" as the "Existing Generation Network", not as NGN.

Living in both worlds, I personally consider (and have used it in this way intrisically in my blog) the term NGN as opposite to the "public" Internet, so the NGN is an IP-based network or application in a "walled garden". This separation can be in the transport layer (e.g. by having no or only a very controlled connectivity with the "public" address- or namespace), or on the application (or service) layer (e.g. Vonage or Skype), or both (e.g Yahoo!BB or the IMS NGN). This viewpoint is of course influenced by my work in ETSI TISPAN on IMS and also by my work in IETF on ENUM.

So I was very interested to visit the ITU-T Workshop on NGN in collaboration with the IETF and to hear the different viewpoints, especially what the IETF has to say on the NGN approach from ITU-T and ETSI.

The progam started after the welcome by Mr. Houlin Zhao (director of the ITU TSB) with a presentation from Brian Carpenter (IETF chair), stating the position of the IETF in general and citing from RFC3935 "The Mission of the IETF", 2004:

The goal of the IETF is to make the Internet work better.

and defining the Internet:

A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. The term includes both the “core Internet” (ISP networks) and “edge Internet” (corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices). The Internet is a truly global network, reaching into just about every country in the world. The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society.

He also set the scene of the IETF view in relation to the ITU-T NGN view:

We believe that the requirements and services described in the ITU-T NGN effort represent an important plan for future network activities, but

• they are just one plan
• we may disagree about the expected viability of

some design choices, based on collected experience in developing and deploying the Internet.

Next on the schedule was Session1: Requirements and Functional Architecture

For didactical reasons I start with the second presentation from Dave Meyer: A Brief Overview of the IETF and the Internet Architecture: Past, Present and Future.

The core statements of his presentation regarding the NGN where related to the End-to-End principle of the Internet:

... the end-to-end principle is perhaps the most fundamental and least
understood of the Internet’s architectural principles…:

• Nothing should be done in the network that can be efficiently done in an end-system.
• A function that must be performed at a higher layer should not also be performed at a lower layer (without a good reason)

He did not say it, but especially the first bullet point means: keep the network simple and stupid.

He then made a tour-de-force through the principles of the Internet architecture, for each point stating past, presence and future areas of activity:

Simplicity, Multiplexing, Transparency, Universal connectivity, Immediate Delivery, Subnet Heterogenity, Common Bearer Service, Connectionless Network, Minimal Dependency,Global Addressing, Regions, Mobility, Protocol Layering, Distributed Control, Global routing computation, Security, Network Resource Allocation

The conclusion was:

The Internet is evolving to support diverse and emerging requirements sets

• Including many of the requirements that are beginning to be specified by projects such as the ITU’s NGN
• Note this kind of “evolvability” is a fundamental property of the IA (deriving from its “minimalist semantics”)
• So where are the architectural misalignments?
• And where can we work together?

Ok, he knew the misalignments already, because Keith Knightson, Rapporteur ITU-T SG13 Q.3 -Architecture gave his presentation "Basic NGN Architecture - Principles & Issues" first.

Keith started with the Next Generation Network (NGN) definition from ITU-T Recommendation Y.2001:

A packet-based network able to provide telecommunication services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies.

It enables unfettered (unrestricted - for non-native readers) access for users to networks and to competing service providers and/or services of their choice. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users.

Ok, any net-head may sign this on a first look, but behold, WTF is meant by "services" and the "provision" of these?. "Service" is similar to "NGN", too may different definitions around.

One had to wait until the morning session 5 "Security" on the second day to get the simple answer from the IETF on this by Jon Peterson on slide 2 of his presentation:

On the Internet, telephony is an application
– Not necessarily a service, no service must be provided

But what is the understanding of ITU on "services? Let's have a look again at the presentation of Keith:

So on slide 4 (sorry, I have still problems putting pictures in the blog - so please look at the presentation itself) we have the horizontally-integrated network from ITU-T Rec. Y.2011 featuring two layers - the transport layer and the services layer. In the services layer we have telephone services, video services and data services (WWW, e-mail, etc.).

So phone and video is NOT a data service and WWW is a service? Interesting.

I do not want to comment on the rest of the slides (although it s tempting), just four of them:

Slide 8, the Basic Functional Architecture, which is basically a functional and very telltale view of slide 4:

First: so much about simplicity in the transport network: 10 "functions" including the customer "function" (whatever that is) - no further comment

Second: what about the "unfettered" access of users to networks (plural) and WTF are User-Network-Interfaces (UNI) and Network-Network-Interfaces (NNI) on the Internet? Note also very carefully that the UNI and NNI are at the transport layer and NOT at the service layer. Service interworking, third-party services and user access to services in "other" networks are only via the control point of the NNI (Session Border Controller).

And then my favorite - slide 13 (sic!) - the component/subsystem viewpoint - containing also the beloved IMS NGN et. al. Although I never really understood it - I have to admit I never really tried, because it gives me a headache - I see now two additional layers: the NASS/RACS layer and the applications layer (separated from the subsystem (services?) layer. I have to admit that this figure shows (different from slide 8) very tiny lines (NNIs?) to other networks on most layers (interestingly not on the RACS layer).

I do now want to comment in detail on back-up slide 27 - Generic Functional Architecture - enjoy yourself, just a last word on the IMS architecture itself (slide 28):

The major IMS network elements include (from here):

• Access Gateway (AG): This network element provides an interface between the radio network (Access Network) and the IP-based network.

• Access Network (AN): This is the radio portion of the network.

• Breakout Gateway Control Function (BGCF): Controls resources allocation to IP sessions

• Call Session Control Function (CSCF): Provides control and routing function for IP sessions.

• Foreign Agent (FA): Advertises itself to mobile stations in serving area. Provides registration information to Home Agent. Forwards packets from mobile to Home Agent.

• Home Agent (HA): Tracks current Foreign Agent serving the mobile. Forwards packets to current FA.

• Home Subscriber Server (HSS): Can take the place of a HLR in all-IP network. Contains AAA function and other databases

• Media Gateway (MGW): Provides interface for bearer traffic between IP and PSTN

• Media Gateway Control Function (MGCF): Provides signaling interoperability between IP and PSTN domains – SIP to ISUP and vice versa

• Policy Decision Function (PDF): As IP networks, unlike TDM networks, assign network bandwidth and resources in real-time, the PDF’s role is to assign resources according to demand and QoS requirements.

• Position Determining Entity (PDE): While some mobiles can determine position independently, the PDE can provide assistance by way of location determination algorithms

• SIP Application Server: Represents a platform for SIP application development and operation.

So this is the NGN idea of a simple network - at least 12 different network elements with approx. 22 different interfaces.

At the end of his presentation Keith raised some very good questions:

• A recognition in both organizations that some new approaches may be required?
• What kind of changes are required and/or foreseen?
• Could/should the expertise of the ITU-T and the IETF be jointly applied to create the principles and architectural framework for next generation networks?
• Do the ITU-T and IETF have different views on the architecture of next generation networks?
• Can a number of differences (if any) be identified and catalogued for study?
• Can ITU-T and IETF collaborate with a view to eliminating or (at least minimizing) any differences wherever possible?

My resumee is:

Within most of the topics discussed in the other sessions of the workshop (Nomadicity & Mobility, QoS, Control & Signalling Capabilities, Network Management and Security) at least the aim and goals where in common.

Identifiers, Naming, Numbering and Addressing where curiously NOT on the agenda AT ALL - maybe because this is not an issue at the IETF and ITU and ETSI do not get it yet that they will have a problem here - they still live in the E.164 name space.

But the detailed solutions within all these topics will require a common understanding of the basic architecture and there is still a long way to go.and the ITU, ETSI et. al. will have to change their position more then the IETF.