Wednesday, May 24, 2006
Spring VON Europe - ENUM Now? - The Panel
So I still owe you a report from the ENUM Now? panel I moderated. As already said in my previous post, I opened up with a short presentation setting the scene.
The first presentation was given by Richard Shockey from Neustar with ENUM - Will it pay. Richard presented a short but excellent overview on User, Infrastructure and Private ENUM. He explained where ENUM stands now, how it can be used as SCP replacement for number portability.
His resumee:
and of course his ceterum censeo: No SS7
Next to present was Albert Gouyet VP Marketing and Product Management from Nominum. Since ENUM is DNS and Nominum is providing one of the most efficient DNS software for ENUM, his take on ENUM was also interesting:
ENUM is taking off, it has reached the tipping point!
From a vendors point of view, ENUM is a new platform for telephony applications, to provide cheaper OPEX and CAPEX and simplify the operational processes.
His resumee - 4x yes for ENUM:
Netnumber is a solutions provider with his TITAN platform, so Glenn concentrated in his presentation on the (private) Carrier ENUM implementations using this platform for a number of purposes in the US. The range of applications is quite impressive. Netnumber participated also in the launch of SPIDER (see here).
The last presentation was given by Adrian Georgescu from AG-Projects. Adrian is also involved in ENUM since a long time (recently also in the ENUM launch in Romania). Adrian is also involved in the practical side, so his presentation had the title: Provisioning the ENUM Tree.
His major statements where:
To summarize: IMHO the panel gave an excellent overview where ENUM stands now and where it is heading.
The first presentation was given by Richard Shockey from Neustar with ENUM - Will it pay. Richard presented a short but excellent overview on User, Infrastructure and Private ENUM. He explained where ENUM stands now, how it can be used as SCP replacement for number portability.
His resumee:
- ENUM is the core signaling technology for the NGN-Network to Network Interface
- DNS Caching Servers are the NGN IP-SCP
- All Call Query - Query on Call Origination
- All data associated with a call delivered at call set up
and of course his ceterum censeo: No SS7
Next to present was Albert Gouyet VP Marketing and Product Management from Nominum. Since ENUM is DNS and Nominum is providing one of the most efficient DNS software for ENUM, his take on ENUM was also interesting:
ENUM is taking off, it has reached the tipping point!
From a vendors point of view, ENUM is a new platform for telephony applications, to provide cheaper OPEX and CAPEX and simplify the operational processes.
His resumee - 4x yes for ENUM:
- Yes, as its own function inside networks
- Yes, as technical issues are being resolved
- Yes, as ROI is confirmed
- Yes, as a platform for more than just ENUM - Application-level routing directories
Netnumber is a solutions provider with his TITAN platform, so Glenn concentrated in his presentation on the (private) Carrier ENUM implementations using this platform for a number of purposes in the US. The range of applications is quite impressive. Netnumber participated also in the launch of SPIDER (see here).
The last presentation was given by Adrian Georgescu from AG-Projects. Adrian is also involved in ENUM since a long time (recently also in the ENUM launch in Romania). Adrian is also involved in the practical side, so his presentation had the title: Provisioning the ENUM Tree.
His major statements where:
- ENUM is not an application or a stand-alone product
- ENUM provides an ultimate number portability solution
- ENUM provides a mapping between namespaces managed by different authorities
- Querying multiple trees introduces call setup delays (I will come back on this soon)
- ENUM cannot be left in the hand of amateurs
To summarize: IMHO the panel gave an excellent overview where ENUM stands now and where it is heading.
Spring VON Europe - ENUM Now? and what ENUM?
I know this is a bit late, but I still owe you a report from the ENUM Now? panel I moderated. I opened up with a short presentation setting the scene. Here a more detailed explanation:
User ENUM as defined in RFC 3761 and to be used in e164.arpa is around quite a long time already. The up-take is quite slow, although there are already over 40 countries delegated in e164.arpa. But only two countries have noteworthy commercial operations (Austria and Germany), a few others are soon to come. Most countries are still in different stages of trials, stuck into legal, regulatory, privacy and validation discussions, thwarted by the existing PSTN operators (not only the incumbents), other countries seem even to have no idea yet what to do with ENUM.
How long can you trial that the DNS works? Of course this is not the real reason. Nowadays in any new development all concerns have to be taken into account up-front and solved, including world-hunger. And if the trial is nearing the end, it is very easy to raise another concern. Existing commercial implementations are of course suffering from Metcalfe's law. If GSM would have been introduced in this way, we would still have trials only, not to mention the Internet itself.
Country opt-in and especially end-user opt-in seems not to be the best idea (yet). So in the mean-time ETSI TISPAN started to investigate Infrastructure ENUM. The basic idea of Infrastucture ENUM was to provide a separate tree for service provider opt-in, without user opt-in and country opt-in.
This approach had three serious draw-backs:
But in the meantime more and more providers got the idea that peering via IP networks for VoIP applications has some advantages. And since E.164 numbers are still the main vehicle for public user identities (and not SIP URIs), some kind of mapping is necessary. So there was a requirement and a market for ENUM technologies and service providers looked around and started to joined private clubs enabling them to peer (or interconnect) via IP.
These ENUMs have many names (carrier, operator, enterprise, etc. ENUM). The generic term now is Private ENUM. Companies started to offer such "services" in the public Internet, some with restricted access and also within private networks. For more information see here.
These implementations work fine (showing also that no more ENUM trials are needed), but they all have a serious drawback: you may only reach the E.164 numbers hosted by the members of the club. This can be quite a large number, e.g. if one considers GSMA, but nevertheless. To reach other numbers, you may either use again the PSTN, which reduces service availability and QoS and requires transit charges per minute, or a provider needs to participate in quite a number of such ENUM trees.
One solution to this problem could be to provide a globally accessible Ueber-ENUM tree e.g. Infrastructure ENUM in ie164.arpa.
In the second half of 2005 IETF finally got the message, gave up the resistance and re-chartered the ENUM WG to deal also with Infrastructure ENUM issues. In the meantime and after some discussions a (stable) requirements draft exists and also a proposal for an RFC to create a parallel Infrastructure ENUM tree in ie164.arpa. There exists in addition a proposal for temporary national solutions to be implemented immediately during the time the negotiations with IESG, IAB, RIPE and ITU-T may take, but still keep a linkage with e164.arpa. Some trials are already in preparation and I will report here about their progress.
How comes the ITU-T into play?
As mentioned above, the ETSI TISPAN idea failed because a global service provider club defining the policy and also having the responsibilty for the root of a common Infrastructure ENUM tree simply cannot be established at all, or at least in a reasonable timeframe.
So the second choice was to involve the ITU-T and the national regulators again and go down a parallel path as was done with RFC3761 and e164.arpa. The draw-back for service providers is that again a country opt-in is required. It is also up to the national regulators to define what the rules are for service providers to be able to opt-in. That is to define what a "Carrier-of-Records" is within the given country code.
So we may be back again in future from Private ENUM to Infrastructure ENUM. Infrastructure ENUM has to potential, together with the work of the IETF WG SPEERMINT to provide a global framework for IP-based peering or IP Interconnection for real-time and multi-media communictions, helping to migrate finally all communications from the PSTN to IP. Infrastructure ENUM is also the ultimate number portability solution, allowing a global all call query (ACQ) for any E.164 number.
Are we going a full circle? So what about User ENUM?
If Infrastructure ENUM is implemented by the service providers, is there still room for User ENUM?
Yes.
Infrastructure ENUM will be the default routing used by service providers to provide basic connectivity for all their end-users (no end-user opt-in) based mainly on SIP.
User ENUM will not be used by all end-users, it still is opt-in, but it will be used by power-users on the Internet and especially by enterprises to provide them with an overlay network. User ENUM allows additional applications (basically any application locatable via an URI) to be linked to E.164 numbers. One type of power users are the communities now emerging on the Internet. At the last two IETF meeting a number of new innovative Enumservices where proposed and I expect more to come.
So User ENUM is not dead and may be revived soon.
I think I got carried away a bit.
And what about the ENUM now panel? - see next post ;-)
User ENUM as defined in RFC 3761 and to be used in e164.arpa is around quite a long time already. The up-take is quite slow, although there are already over 40 countries delegated in e164.arpa. But only two countries have noteworthy commercial operations (Austria and Germany), a few others are soon to come. Most countries are still in different stages of trials, stuck into legal, regulatory, privacy and validation discussions, thwarted by the existing PSTN operators (not only the incumbents), other countries seem even to have no idea yet what to do with ENUM.
How long can you trial that the DNS works? Of course this is not the real reason. Nowadays in any new development all concerns have to be taken into account up-front and solved, including world-hunger. And if the trial is nearing the end, it is very easy to raise another concern. Existing commercial implementations are of course suffering from Metcalfe's law. If GSM would have been introduced in this way, we would still have trials only, not to mention the Internet itself.
Country opt-in and especially end-user opt-in seems not to be the best idea (yet). So in the mean-time ETSI TISPAN started to investigate Infrastructure ENUM. The basic idea of Infrastucture ENUM was to provide a separate tree for service provider opt-in, without user opt-in and country opt-in.
This approach had three serious draw-backs:
- first, all service providers need to agree on ONE common tree and
- second, to be globally available, the tree need to be public
- and last, but not least, to be reachable via the public Internet and also via ENUM, service providers need to provide their users with SIP URIs.
But in the meantime more and more providers got the idea that peering via IP networks for VoIP applications has some advantages. And since E.164 numbers are still the main vehicle for public user identities (and not SIP URIs), some kind of mapping is necessary. So there was a requirement and a market for ENUM technologies and service providers looked around and started to joined private clubs enabling them to peer (or interconnect) via IP.
These ENUMs have many names (carrier, operator, enterprise, etc. ENUM). The generic term now is Private ENUM. Companies started to offer such "services" in the public Internet, some with restricted access and also within private networks. For more information see here.
These implementations work fine (showing also that no more ENUM trials are needed), but they all have a serious drawback: you may only reach the E.164 numbers hosted by the members of the club. This can be quite a large number, e.g. if one considers GSMA, but nevertheless. To reach other numbers, you may either use again the PSTN, which reduces service availability and QoS and requires transit charges per minute, or a provider needs to participate in quite a number of such ENUM trees.
One solution to this problem could be to provide a globally accessible Ueber-ENUM tree e.g. Infrastructure ENUM in ie164.arpa.
In the second half of 2005 IETF finally got the message, gave up the resistance and re-chartered the ENUM WG to deal also with Infrastructure ENUM issues. In the meantime and after some discussions a (stable) requirements draft exists and also a proposal for an RFC to create a parallel Infrastructure ENUM tree in ie164.arpa. There exists in addition a proposal for temporary national solutions to be implemented immediately during the time the negotiations with IESG, IAB, RIPE and ITU-T may take, but still keep a linkage with e164.arpa. Some trials are already in preparation and I will report here about their progress.
How comes the ITU-T into play?
As mentioned above, the ETSI TISPAN idea failed because a global service provider club defining the policy and also having the responsibilty for the root of a common Infrastructure ENUM tree simply cannot be established at all, or at least in a reasonable timeframe.
So the second choice was to involve the ITU-T and the national regulators again and go down a parallel path as was done with RFC3761 and e164.arpa. The draw-back for service providers is that again a country opt-in is required. It is also up to the national regulators to define what the rules are for service providers to be able to opt-in. That is to define what a "Carrier-of-Records" is within the given country code.
So we may be back again in future from Private ENUM to Infrastructure ENUM. Infrastructure ENUM has to potential, together with the work of the IETF WG SPEERMINT to provide a global framework for IP-based peering or IP Interconnection for real-time and multi-media communictions, helping to migrate finally all communications from the PSTN to IP. Infrastructure ENUM is also the ultimate number portability solution, allowing a global all call query (ACQ) for any E.164 number.
Are we going a full circle? So what about User ENUM?
If Infrastructure ENUM is implemented by the service providers, is there still room for User ENUM?
Yes.
Infrastructure ENUM will be the default routing used by service providers to provide basic connectivity for all their end-users (no end-user opt-in) based mainly on SIP.
User ENUM will not be used by all end-users, it still is opt-in, but it will be used by power-users on the Internet and especially by enterprises to provide them with an overlay network. User ENUM allows additional applications (basically any application locatable via an URI) to be linked to E.164 numbers. One type of power users are the communities now emerging on the Internet. At the last two IETF meeting a number of new innovative Enumservices where proposed and I expect more to come.
So User ENUM is not dead and may be revived soon.
I think I got carried away a bit.
And what about the ENUM now panel? - see next post ;-)
Spring VON Europe - Waiting for Dinner
Saturday, May 20, 2006
Private ENUMs and VoIP Peering
As I also mentioned my short introduction moderating the "ENUM Now" panel most activities regarding ENUM is taking place currently in Private ENUM space. Private ENUM is defined currently as everything not in e164.arpa (User ENUM) and also not in the envisaged Infrastructure ENUM in ie164.arpa.
So basically the US Provider ENUM mentioned in my previous blog entry is also a Private ENUM.
Nearly every week some new developments happen here - a short summary.
XConnect to Acquire e164.info
XConnect, the world’s largest provider of “Plug and Peer” Voice over IP (VoIP) peering services announced that they will be acquring e164.info, the operator of the largest international private ENUM registry. The combined company creates the world's largest VoIP peering community worldwide, serving more than 150 VoIP operators.
So XConnect is now the largest ;-)
SPIDER
On Tuesday at the Spring VON Europe Arbinet and Netnumber jointly announced SPIDER, the Registry of Registries.
The charging system is also a bit weird from an European perspective, it is created after the US model in SS7, where you pay per dip, in the SPIDER case for a sucessful dip. Together with the push model this requires that you have your fingers in the customers SW and set up a complicated charging transfer system. To me it seems more feasible to charge per transaction in the database.
USER and/or Infrastructure ENUM in Romania by AG-Projects
This also clearly shows that two separate trees for User and Infrastructure ENUM is required, before this confusion in increasing.
ENUM starts in Bulgaria
Just over two months after the U.S. (+1) Enum delegation, the country code +359 has been assigned to the Bulgarian Internet Society (ISOC-Bulgaria), adding Bulgaria to the club of ENUM enabled countries. The codes are governed by the International Telecommunication Union (ITU) in co-operation with national governments.
The Aim for ISOC-Bulgaria is to foster the implementation of ENUM public and infrastructure services, delivering local & global number portability based on the best practices from other ENUM deployments around the world, said Veni Markovski, President and Chairman of the Board of ISOC-Bulgaria.
“This development will bring new possibilities for additional services and deliver robust, flexible and cost effective Local number portability solutions, offering new services to the end user and additional revenues for the services providers”, said Alex Nikolov CTO of Enum2Go Ltd who were responsible for the first commercial deployment of Enum services based on the +87810 country code.
Over recent months several more countries have announced major developments in this field; The Republic of Ireland have launched a commercial service, Austria have commenced their Infrastructure Enum trial, and the United Kingdom is aiming to have a commercial service in readiness for November 2006. These major developments, are creating a growing interest from service providers and opening new possibilities for global investors as new service offerings are emerging.
In the week of the announcement of the progress made by Bulgaria towards accession to European Union, this news is yet another reassuring step for the IT sector and the society.
Amen
So basically the US Provider ENUM mentioned in my previous blog entry is also a Private ENUM.
Nearly every week some new developments happen here - a short summary.
XConnect to Acquire e164.info
XConnect, the world’s largest provider of “Plug and Peer” Voice over IP (VoIP) peering services announced that they will be acquring e164.info, the operator of the largest international private ENUM registry. The combined company creates the world's largest VoIP peering community worldwide, serving more than 150 VoIP operators.
So XConnect is now the largest ;-)
SPIDER
On Tuesday at the Spring VON Europe Arbinet and Netnumber jointly announced SPIDER, the Registry of Registries.
The Service Provider ID E.164 Record (SPIDER) registry is a set of low-cost, lightweight shared database tools that enables the efficient exchange of interconnect address information between trusted communications service providers and VoIP communities. The SPIDER registry is managed by SPIDER Registry, Inc., a non-stock, not-for-profit industry group administered by a Board of Directors comprised of IP-communications industry representatives from around the world. The SPIDER registry database infrastructure was created to address a well-defined industry problem relating to the interconnection of VoIP services between the large number of VoIP “islands” or communities emerging around the world.
SPIDER is not ENUM, it is a registry which may push the data in your private ENUM database. In principle the model is workable, here I trust Netnumber and Doug Ranalli. But they claim to be a global registry, so I wonder how this scales if all 4.000.000.000 phone numbers of the world are pushed down to your DNS or SIP Redirect server - good luck.The charging system is also a bit weird from an European perspective, it is created after the US model in SS7, where you pay per dip, in the SPIDER case for a sucessful dip. Together with the push model this requires that you have your fingers in the customers SW and set up a complicated charging transfer system. To me it seems more feasible to charge per transaction in the database.
USER and/or Infrastructure ENUM in Romania by AG-Projects
ANISP, the Romanian Internet Service Provider Association http://www.anisp.ro representing more than 40 service providers (http://www.anisp.ro/?c=membri) has awarded AG Projects to build the ENUM platform for provisioning of the ENUM tree 0.4.e164.arpa. The Romanian ENUM exchange will be hosted in two RoNIX locations (Romanian Network for Internet eXchange) and will be backed up by an infrastructure hosted within the European backbone. The 0.4.e164.arpa is under the authority of the Romanian regulatory body ANRC, which by end of this year planned to define the final procedures of delegation and administration of the public ENUM tree 0.4.e164.arpa.
“We selected AG Projects to provide infrastructure ENUM and SIP peering services to facilitate on-net multimedia sessions between Romanian VoIP operators. We believe that Internet standards combined with the use of global identities like E.164 numbers in the official 0.4.e164.arpa tree are the key to enable transition from the classic PSTN to rich-media IP services like voice and video over IP” says Mihai Batraneanu, President of ANISP.
So I am a bit confused now: Is it User ENUM or Infrastructure ENUM?This also clearly shows that two separate trees for User and Infrastructure ENUM is required, before this confusion in increasing.
ENUM starts in Bulgaria
Just over two months after the U.S. (+1) Enum delegation, the country code +359 has been assigned to the Bulgarian Internet Society (ISOC-Bulgaria), adding Bulgaria to the club of ENUM enabled countries. The codes are governed by the International Telecommunication Union (ITU) in co-operation with national governments.
The Aim for ISOC-Bulgaria is to foster the implementation of ENUM public and infrastructure services, delivering local & global number portability based on the best practices from other ENUM deployments around the world, said Veni Markovski, President and Chairman of the Board of ISOC-Bulgaria.
“This development will bring new possibilities for additional services and deliver robust, flexible and cost effective Local number portability solutions, offering new services to the end user and additional revenues for the services providers”, said Alex Nikolov CTO of Enum2Go Ltd who were responsible for the first commercial deployment of Enum services based on the +87810 country code.
Over recent months several more countries have announced major developments in this field; The Republic of Ireland have launched a commercial service, Austria have commenced their Infrastructure Enum trial, and the United Kingdom is aiming to have a commercial service in readiness for November 2006. These major developments, are creating a growing interest from service providers and opening new possibilities for global investors as new service offerings are emerging.
In the week of the announcement of the progress made by Bulgaria towards accession to European Union, this news is yet another reassuring step for the IT sector and the society.
Amen
The ENUM Babuschkas and US Provider ENUM
At my short introduction moderating the "ENUM Now" panel I mentioned the ENUM Babuschkas: User - Infrastructure - Private - Carrier - Operator - Enterprise - Federation ENUM (Note: I will report on this panel as soon as I have all slides available)
The US ENUM LLC was not happy with these naming options and decided to introduce a new term: Provider ENUM. But they also allow you to call it "Carrier" or "Infrastructure" ENUM ;-)
So the group reacted quite fast on the restriction imposed not to do Infrastructure ENUM in e164.arpa and simply implements the trial in a separate tree - in this case "e164enum.us."
Congratulations to all involved here!
In a press release from May 16, 2006 the Country Code 1 ENUM LLC (LLC) announced the launch of a second ENUM technology trial that will focus on service provider interconnection requirements:
The U.S. Provider ENUM trial will be based on the "Framework Document for a U.S. Provider ENUM Trial" . The trial of Provider ENUM (sometimes referred to as "Carrier" or "Infrastructure" ENUM) is expected to be conducted over a four-month period beginning in July. This trial will be carried out in parallel with the current End-User ENUM trial and will use a different domain name and separate numbering resources. As with the End-User ENUM trial, no commercial end-users will be involved in the Provider ENUM trial.
TSPs with assigned numbering resources that seek to exchange end-user traffic with other TSPs on an IP basis are encouraged to participate.
The results of the trial will form the basis of requirements for a commercial implementation to assist U.S. service providers. The CC1 ENUM LLC plans are consistent with the Internet Engineering Task Force (IETF) ENUM Working Group efforts to progress a global solution for Provider ENUM. The proposed U.S. implementation, targeted for 2007, should be easily transitioned to the global solution when it becomes available.
I like the last paragraph, because it shows a way forward and is not incompatible with the now envisaged future developments in IETF ENUM WG.
I am sceptical about another statement in the framework document
In addition to the basic trial as outlined below, the trial implementation will provide a platform that may be used to test other architectural alternatives and capabilities, which may include:
2. and 4 allow to do "Linkage with other non-US trials" as pointed out also in section 7.3.2 of the framework, but please not with a DNAME (this would not work with i.3.4.e164.arpa), but by using the EBL ressource record as described in draft-lendl-enum-branch-location-record. Provided they are allowed to put this record into the sacrosanct e164.arpa.
In this section there seems also to be a slight misunderstanding where ie164.arpa belongs too: ie164.arpa as defined in draft-ietf-enum-nfrastructure does NOT belong to ETSI.
Anyway, once again, well done!
The US ENUM LLC was not happy with these naming options and decided to introduce a new term: Provider ENUM. But they also allow you to call it "Carrier" or "Infrastructure" ENUM ;-)
So the group reacted quite fast on the restriction imposed not to do Infrastructure ENUM in e164.arpa and simply implements the trial in a separate tree - in this case "e164enum.us."
Congratulations to all involved here!
In a press release from May 16, 2006 the Country Code 1 ENUM LLC (LLC) announced the launch of a second ENUM technology trial that will focus on service provider interconnection requirements:
The U.S. Provider ENUM trial will be based on the "Framework Document for a U.S. Provider ENUM Trial" . The trial of Provider ENUM (sometimes referred to as "Carrier" or "Infrastructure" ENUM) is expected to be conducted over a four-month period beginning in July. This trial will be carried out in parallel with the current End-User ENUM trial and will use a different domain name and separate numbering resources. As with the End-User ENUM trial, no commercial end-users will be involved in the Provider ENUM trial.
TSPs with assigned numbering resources that seek to exchange end-user traffic with other TSPs on an IP basis are encouraged to participate.
The results of the trial will form the basis of requirements for a commercial implementation to assist U.S. service providers. The CC1 ENUM LLC plans are consistent with the Internet Engineering Task Force (IETF) ENUM Working Group efforts to progress a global solution for Provider ENUM. The proposed U.S. implementation, targeted for 2007, should be easily transitioned to the global solution when it becomes available.
I like the last paragraph, because it shows a way forward and is not incompatible with the now envisaged future developments in IETF ENUM WG.
I am sceptical about another statement in the framework document
In addition to the basic trial as outlined below, the trial implementation will provide a platform that may be used to test other architectural alternatives and capabilities, which may include:
- Non-terminal NAPTR records
- Carrier (Provider) domain branch under e164.arpa
- The provision of NAPTR records in Tier 1
- Linkage with other, non-NANP Provider ENUM trials
- Selective Control of Resolution/Call Admission
- Hiding the “root” of the Provider ENUM tree (i.e., e164enum.us) from everyone but “authorized” service providers (i.e., trial participants).
2. and 4 allow to do "Linkage with other non-US trials" as pointed out also in section 7.3.2 of the framework, but please not with a DNAME (this would not work with i.3.4.e164.arpa), but by using the EBL ressource record as described in draft-lendl-enum-branch-location-record. Provided they are allowed to put this record into the sacrosanct e164.arpa.
In this section there seems also to be a slight misunderstanding where ie164.arpa belongs too: ie164.arpa as defined in draft-ietf-enum-nfrastructure does NOT belong to ETSI.
Anyway, once again, well done!
Friday, May 19, 2006
Spring VON Europe - To IMS or not to IMS
One hot topic at the VON Sessions was the IMS. There are two camps fighting each other fiercely. Everybody reading my blog and also everybody present at my Industry Perspective presentation on Wednesday knows which side I belong to.
But during the discussions I had to shift my position slightly. It is not IMS per se which is bad, it is how you implement it. You may implement IMS also on the Internet (if you want to), and you may implement a plain RFC3261 compliant SIP server in a walled garden.
So the camps are really the Internet vs. the Walled Gardens, the IMS is only used as an example, of course because it may help you to make the walls higher.
To make this point clear I use a picture from a presentation Jay Batson gave recently:
Title: What is good for operators may not be good for nations.
In my presentation I deleted operators (service providers) and replaced it by manufacturers. Alistair Woodman from Cisco proved this correct the next day in his Industry Perspective when he said: "We manufacturers like complicated protocols and also different protocols: the more the better, we make a lot of money out of Interworking Units".
The picture clearly shows in a nutshell the issue. There is only a minor mistake on this picture: the word IMS should not be placed on the person, it should be places on the gun.
The correct analogy is: the gun is the IMS, the person is the service provider and the manufacturer is the manufacturer.
A gun per se is not bad, it is always the person pulling the trigger. It could be a policeman or a criminal. You can also not blame gun manufactures for simply producing and selling guns. (You may blame them for lobbying and supporting the NRA ;-)
So one may not blame IMS per se, one may only blame a service provider trying to implement IMS in a walled garden, but this can also be done with an OpenSER (an even better gun?).
See also the presentation from Adrian Georgescu on Building Scalable SIP networks using IMS-in-a-Box and P"P networks.
Keep It Simple, Stupid.
So since we now have demystified IMS a bit, we may concentrate on the two real questions from a service providers point of view:
1. should he implement his voice and multi-media services using IMS or something else?
2. should he implement his voice and multi-media services in a walled garden or on the Internet?
Question 1: IMS or not?
This is up to him. A service provider should always look what he gets for his money and what he will get in return from his subscribers. My personal opinion here is that this will not work out for IMS based products, at least not for the fully monty standard bodies and manufacturers are promising at the moment, and also not now. Every service provider should keep in mind that he now has to compete with the virtual service providers on the Internet, and they do not need to wait until the promised applications are available in IMS in the distant future. They can implement it now. If the SP does not get his investments back, this is stranded costs, as I also pointed out in my presentation.
One operator seems to have got this message -KPN. KPN is approaching IMS very carefully and will only implement two functions, the S-CSCF (basically a simple SIP-proxy) and the only real asset IMS has: the HSS. Eventually a P-CSCF for their mobile part as an outbound proxy.
I suggest that all operators should look at the excellent KPN presenation Colin Pons gave at the break-out panel: IMS: Walled In or Open very carefully. See also Martin Geddes commenting on this in KPN: a viable IMS vision and here.
Question 2: Walled garden or not?
Here we have to distinguish between three sub-options:
a) Is the SP reachable from other SP's on the public Internet, via bilateral peering agreements or via so-called federations. This is a SP decision and is currently discussed all over the place, in all standards bodies (e.g. SPEERMINT), in national bodies dealing with IP Interconnect and in a number of conferences. I will come back on this in one of my next posts on ENUM.
b) Are the application servers also within the walled garden or are they available via the public Internet? Can anybody provide an third-party service or only for selected third-parties, or something in between. This is an issue not so much discussed yet, but very important for innovation speed and global availability of services.
c) Does the user has access to the SP from the public Internet or is he bundled in via the access? This issue is currently the hottest in the net-neutrality discussion, because this works only if the SP disables the end-user to use the services he provides also over the Internet access.
KPN seems to have here also a very open approach:
The KPN Strategy is: "Making the Internet even more significant for our consumers"
and to concentrate on identity management, presence, location, user preferences and profile mediation, service and personal mobility.
KPN: "Preserve the E2E principle"
The KPN design principles and guidelines state: "No service intelligence shall reside in the IMS core elements"
So I strobgly recommend that operators, carriers and service providers may reconsider their plans of using IMS: the full monty, not all of it, or none of IMS.
This may be of course a problem for the IMS manufacturers, but also for new-entrant VoIP providers hoping that the telcos binge-drink the IMS and fall over.
My two cents for SP:
1. Do not use IMS now, wait until it gets ready and even then do not use all of it.
2. Do not implement the end-user access and the applications in a walled garden.
3. for interconnect, use all options available now, but finally you MUST find a way to peer with ALL other service providers via IP. Do not rely on the PSTN as default.
and finally:
4. Do not believe too much in conspiracy theories like all incumbent telcos and regulators are bad. They are all cooking only with water. Leave the conspiracy theories to the "Da Vince Code" (also a big flop, BTW)
But during the discussions I had to shift my position slightly. It is not IMS per se which is bad, it is how you implement it. You may implement IMS also on the Internet (if you want to), and you may implement a plain RFC3261 compliant SIP server in a walled garden.
So the camps are really the Internet vs. the Walled Gardens, the IMS is only used as an example, of course because it may help you to make the walls higher.
To make this point clear I use a picture from a presentation Jay Batson gave recently:
Title: What is good for operators may not be good for nations.
In my presentation I deleted operators (service providers) and replaced it by manufacturers. Alistair Woodman from Cisco proved this correct the next day in his Industry Perspective when he said: "We manufacturers like complicated protocols and also different protocols: the more the better, we make a lot of money out of Interworking Units".
The picture clearly shows in a nutshell the issue. There is only a minor mistake on this picture: the word IMS should not be placed on the person, it should be places on the gun.
The correct analogy is: the gun is the IMS, the person is the service provider and the manufacturer is the manufacturer.
A gun per se is not bad, it is always the person pulling the trigger. It could be a policeman or a criminal. You can also not blame gun manufactures for simply producing and selling guns. (You may blame them for lobbying and supporting the NRA ;-)
So one may not blame IMS per se, one may only blame a service provider trying to implement IMS in a walled garden, but this can also be done with an OpenSER (an even better gun?).
See also the presentation from Adrian Georgescu on Building Scalable SIP networks using IMS-in-a-Box and P"P networks.
Keep It Simple, Stupid.
So since we now have demystified IMS a bit, we may concentrate on the two real questions from a service providers point of view:
1. should he implement his voice and multi-media services using IMS or something else?
2. should he implement his voice and multi-media services in a walled garden or on the Internet?
Question 1: IMS or not?
This is up to him. A service provider should always look what he gets for his money and what he will get in return from his subscribers. My personal opinion here is that this will not work out for IMS based products, at least not for the fully monty standard bodies and manufacturers are promising at the moment, and also not now. Every service provider should keep in mind that he now has to compete with the virtual service providers on the Internet, and they do not need to wait until the promised applications are available in IMS in the distant future. They can implement it now. If the SP does not get his investments back, this is stranded costs, as I also pointed out in my presentation.
One operator seems to have got this message -KPN. KPN is approaching IMS very carefully and will only implement two functions, the S-CSCF (basically a simple SIP-proxy) and the only real asset IMS has: the HSS. Eventually a P-CSCF for their mobile part as an outbound proxy.
I suggest that all operators should look at the excellent KPN presenation Colin Pons gave at the break-out panel: IMS: Walled In or Open very carefully. See also Martin Geddes commenting on this in KPN: a viable IMS vision and here.
Question 2: Walled garden or not?
Here we have to distinguish between three sub-options:
a) Is the SP reachable from other SP's on the public Internet, via bilateral peering agreements or via so-called federations. This is a SP decision and is currently discussed all over the place, in all standards bodies (e.g. SPEERMINT), in national bodies dealing with IP Interconnect and in a number of conferences. I will come back on this in one of my next posts on ENUM.
b) Are the application servers also within the walled garden or are they available via the public Internet? Can anybody provide an third-party service or only for selected third-parties, or something in between. This is an issue not so much discussed yet, but very important for innovation speed and global availability of services.
c) Does the user has access to the SP from the public Internet or is he bundled in via the access? This issue is currently the hottest in the net-neutrality discussion, because this works only if the SP disables the end-user to use the services he provides also over the Internet access.
KPN seems to have here also a very open approach:
The KPN Strategy is: "Making the Internet even more significant for our consumers"
and to concentrate on identity management, presence, location, user preferences and profile mediation, service and personal mobility.
KPN: "Preserve the E2E principle"
The KPN design principles and guidelines state: "No service intelligence shall reside in the IMS core elements"
So I strobgly recommend that operators, carriers and service providers may reconsider their plans of using IMS: the full monty, not all of it, or none of IMS.
This may be of course a problem for the IMS manufacturers, but also for new-entrant VoIP providers hoping that the telcos binge-drink the IMS and fall over.
My two cents for SP:
1. Do not use IMS now, wait until it gets ready and even then do not use all of it.
2. Do not implement the end-user access and the applications in a walled garden.
3. for interconnect, use all options available now, but finally you MUST find a way to peer with ALL other service providers via IP. Do not rely on the PSTN as default.
and finally:
4. Do not believe too much in conspiracy theories like all incumbent telcos and regulators are bad. They are all cooking only with water. Leave the conspiracy theories to the "Da Vince Code" (also a big flop, BTW)
Spring VON Europe - Rewind
I have to apologize by my readers, but I was not able to blog from the VON- too busy. I was also not able to read other blogs, so I may be out-of-sync. Except maybe Jeff, James, Martin and Andy. I have no idea how Andy is doing this, Jeff is suspecting that he has a clone writing his blog entries while he is wine tasting (see below). BTW, James features a second blog now: Chaotica.
This time I will work my way backwards.
This time I will work my way backwards.
Tuesday, May 09, 2006
Mobile Operators reacting to Viviane - Too little, too late?
this Tuesday, May 9, 2006 the International Herald Tribune is asking. Vodafone is announcing to cut their roaming charges by 40% over the next year, after Orange announced a cut by 25% and T-Mobile UK announced a flat 1 Euro per minute.
This will not be enough, a Ovum analyst said and a spokesman from Viviane Reding said, that she still plans to introduce her regulation before summer break.
Reding said already in March that she planned to regulate roaming charges in the EU by tying them to domestic calling rates (which one of the 100 different rates a normal mobile operator is offering?) and eliminating charges for receiving calls outside the home markets.
The latter is a bit contradictory to the current plans to lower the termination charges to mobile operators (the market 18 for mobile termination) as a whole, or are the mobile operators now in a double squeeze?
In my opinion the roaming charges should go away, but called mobile subscribers should take their part, in the home network or abroad. It is not my problem if somebody wants to be mobile, in the country or outside, but I do not want to pay for it. I do not see any reason to pay different charges for calling a mobile or a fixed line. This is basically a "cross subsidy" from the "rich" fixed operators to the "poor" mobile operators. Not only a subsidy, but in also in the wrong direction.
Back to roaming charges: what I consider funny now is the comments from some mobile operators or their lobby groups. Tom Philips, head of regulatory affairs at the GSM Association said proudly: "The cuts by Vodafone show the market is competitive"
Huh? We obviously live on different planets.
IMHO this shows exactly the opposite: There was no movement up to now by the mobile cartel, only at gun-point. And one may ask also the question, if they really are able to cut their charges to half so easily, what is really possible?
And of course, coming from an up-to now heavily regulated incumbent, I enjoy to see others always crying for regulation (of somebody elso, of course, according to the Floriani Principle), now to suffer also ;-)
This will not be enough, a Ovum analyst said and a spokesman from Viviane Reding said, that she still plans to introduce her regulation before summer break.
Reding said already in March that she planned to regulate roaming charges in the EU by tying them to domestic calling rates (which one of the 100 different rates a normal mobile operator is offering?) and eliminating charges for receiving calls outside the home markets.
The latter is a bit contradictory to the current plans to lower the termination charges to mobile operators (the market 18 for mobile termination) as a whole, or are the mobile operators now in a double squeeze?
In my opinion the roaming charges should go away, but called mobile subscribers should take their part, in the home network or abroad. It is not my problem if somebody wants to be mobile, in the country or outside, but I do not want to pay for it. I do not see any reason to pay different charges for calling a mobile or a fixed line. This is basically a "cross subsidy" from the "rich" fixed operators to the "poor" mobile operators. Not only a subsidy, but in also in the wrong direction.
Back to roaming charges: what I consider funny now is the comments from some mobile operators or their lobby groups. Tom Philips, head of regulatory affairs at the GSM Association said proudly: "The cuts by Vodafone show the market is competitive"
Huh? We obviously live on different planets.
IMHO this shows exactly the opposite: There was no movement up to now by the mobile cartel, only at gun-point. And one may ask also the question, if they really are able to cut their charges to half so easily, what is really possible?
And of course, coming from an up-to now heavily regulated incumbent, I enjoy to see others always crying for regulation (of somebody elso, of course, according to the Floriani Principle), now to suffer also ;-)
Mobile Broadband Access - Myth and Reality - No IM allowed
I posted something similar already in September 2005 about E-Plus and Skype, but VoIP is VERBOTEN.
This time the phun comes from T-Mobile UK, regarding their web'n' walk professional product, which proudly presents it's great value for 20 Pounds a month:
Web ‘n’ walk professional makes surfing the internet on your laptop simple and easy. Just put the web ‘n’ walk card in your laptop and away you go. And it's great value.
*Web ‘n’ Walk professional is subject to a minimum term contract and credit check. Compatible handset or device required.
OK, this is normal
To ensure a high quality of service for all our customers, a fair use policy applies. T-Mobile defines fair use as total UK data use (both sent and received) of up to 2GB per month. T-Mobile may contact customers who exceed this volume of data in two (or more) consecutive months in any six month period to ask them to reduce their usage. If usage is not reduced, notice may be given, after which network protection controls may be applied which will result in a reduced speed of transmission.
So unlimited means 2GB. And note the ENSURE high Quality for ALL OUR CUSTOMERS: you must not use it too much, because if two or three of you bastards are in one cell, there will be troubles. This definitely leads to the next statement, which is outragous:
Use of Voice over Internet Protocol and Messaging over Internet Protocol is prohibited by T-Mobile. If use of either or both of these services is detected T-Mobile may terminate all contracts with the customer and disconnect any SIM cards and/or web ‘n’ walk cards from the T-Mobile network.
Not only VoIP, but also IM is VERBOTEN. And because they cannot prevent it technically, they do it in the contract.
So no Skype, Jabber, Messenger, etc. not even with text messages.
They must have a lousy network, if even text messages are degrading it.
What applications will they block next? Video download from Warner Bros? Large File tranfer? VPNs?
This raises one question: is the contract really terminated. Since the above 20 quids are for a 18 month minimum contract, do they simply throw you out or do you have to pay the fully monty?
I suspect the latter, because otherwise this would be a nice way to get out of such a contract ;-)
This time the phun comes from T-Mobile UK, regarding their web'n' walk professional product, which proudly presents it's great value for 20 Pounds a month:
Web ‘n’ walk professional makes surfing the internet on your laptop simple and easy. Just put the web ‘n’ walk card in your laptop and away you go. And it's great value.
- Download and send large files and emails quickly
- Fast download and upload speeds
- No data download limits*
*Web ‘n’ Walk professional is subject to a minimum term contract and credit check. Compatible handset or device required.
OK, this is normal
To ensure a high quality of service for all our customers, a fair use policy applies. T-Mobile defines fair use as total UK data use (both sent and received) of up to 2GB per month. T-Mobile may contact customers who exceed this volume of data in two (or more) consecutive months in any six month period to ask them to reduce their usage. If usage is not reduced, notice may be given, after which network protection controls may be applied which will result in a reduced speed of transmission.
So unlimited means 2GB. And note the ENSURE high Quality for ALL OUR CUSTOMERS: you must not use it too much, because if two or three of you bastards are in one cell, there will be troubles. This definitely leads to the next statement, which is outragous:
Use of Voice over Internet Protocol and Messaging over Internet Protocol is prohibited by T-Mobile. If use of either or both of these services is detected T-Mobile may terminate all contracts with the customer and disconnect any SIM cards and/or web ‘n’ walk cards from the T-Mobile network.
Not only VoIP, but also IM is VERBOTEN. And because they cannot prevent it technically, they do it in the contract.
So no Skype, Jabber, Messenger, etc. not even with text messages.
They must have a lousy network, if even text messages are degrading it.
What applications will they block next? Video download from Warner Bros? Large File tranfer? VPNs?
This raises one question: is the contract really terminated. Since the above 20 quids are for a 18 month minimum contract, do they simply throw you out or do you have to pay the fully monty?
I suspect the latter, because otherwise this would be a nice way to get out of such a contract ;-)
