November 2007 | Volume 10/ Number 11
VoIP Peering in Search of a Viable Interconnect Business Model
By Richard “Zippy” Grigonis
George Smine, Director of Product Marketing, Nominum (http://www.nominum.com), says, We're definitely focused on carrier peering or interconnect. Over the past year we introduced a software product called Navitas which is an ENUM IP application routing directory that serves as the in-network database with the capacity to store a large set of telephone numbers, routing plans and global dialing prefixes. We call it a 'routing directory' because it acts as a database in the network, providing a virtual cloud of data inside an IP network, and its main task is to help manage the complexity of data between the old and the new network worlds. It helps providers perform route optimizations, or to provide telephony services such as number portability, toll-free numbering, and so forth. The way many carriers deal with interconnects is that they still abide by the traditional business model of dealing with financial settlements. Sometimes they don't charge each other for the traffic that's going through, but often they do. But whether they do or not, they want to understand how calls are being managed, what the issues are of call quality, and so forth.
Last year we saw a change in attitude and difference in adoption in looking at peering, says Smine. Initially people felt that VoIP peering would take the path of IP peering, meaning that everything was going to be free. This is not a traditional billing per-minute model, but a 'bill and keep' model where IP Networks of similar size choose to interconnect directly to save costs, with no interconnect fees. In telephony, however, if you're receiving a lot of traffic and a lot of calls are terminating on your network, then it means that you're getting paid termination charges. You're charging the originating carrier. So the perception of VoIP peering has changed in that the people interested in moving to IP peering are also the traditional telephony providers and when it comes to peering, we see a continuation of the telecom interconnect and termination model. The difference with IP is that it gives carriers the opportunity to peer beyond the physical interconnection.
We're still seeing a lot of interconnects occurring over private peering, meaning at the physical layer, or at 'carrier hotels', says Smine. Some people talk about a very high level of peering where they may not need to go through a private or dedicated line and they may be doing it over the free Internet and not be worried about detailed charges for every call, but the majority look at this interconnect business as sustaining the existing business model by billing on a per minute basis.
Tom Moresco, Principal Product Manager, Telcordia Service Interconnection Registry, Telcordia (http://www.telcordia.com) says, Bartering minutes does occur between carriers. It works best when the providers are somehow equivalent, such as the same size. We see that some federation members are not interested in settlement because they're all 'birds of a feather', more or less. However, when traditional Telcordia customers come to us and want to interconnect with these federations or each other, the traditional business models are still in play. Also, with the advent of new IP-based services, the value to the customer goes up, so service providers may be more willing to adopt non-traditional business models. The whole thing is being shaken out - various pockets in the industry have either implemented a settlement-free model or else a traditional model, on a service-by-service basis, be it an information service or a more traditional service such as VoIP, which is evolving into an application anyway.
Telcordia's Service Interoperability Registry provides an authoritative source of multiple countries national destination codes and number portability data that populate the Nominum Navitas IPRD inside a carrier's network.
A third interconnect model now exists, says Seamus Hourihan, Senior Vice President of Marketing and Product Management, Acme Packet; Fees to provide termination are paid on a per-subscriber basis of the service provider providing the service, irrespective of how many calls are actually made by that subscriber population. Hence, network service providers recover their operating costs from end users, not from the network interconnection. Incremental costs of the interconnection can be split evenly between interconnecting networks.
Hourihan's company, Acme Packet, offers the Net-Net SBC which provides the mechanisms for security, service assurance and network reach at service provider peering points.
I'll take one OS-3 to Canada, please
Tiscali International Network (http://www.tiscali.net), or TINet, is the carrier arm of Tiscali S.p.A. (http://www.tiscali.com) a preeminent independent European telecom company and ISP that manages a huge IP network capable of supplying its 3.3 million residential and business customers (in Italy and the U.K.) with such services as Internet access (both dial-up and ADSL), voice, VoIP, media, mobile connectivity, VAS (Value-Added Services), and other advanced products.
Maurizio Binello is COO at TINet, which happens to be the world's only carrier dedicated exclusively to wholesale IP-MPLS. We're a group of companies inside the Tiscali Group that offers IP transit and voice termination to other carriers. We started from scratch in 2001 and have done a great deal since then, dealing with 15 international operators in the IP business. We started selling IP transit in 2001 and then in 2003 we expanded to deal with voice, selling voice termination to carriers. We had things to learn, but we also had the luxury of being able to start out immediately with VoIP, and were not burdened with legacy TDM equipment.
Peering in the IP world is based on the interconnection between networks to exchange traffic settlement-free, says Binello. This is still with us. IP Peering is not regulated. It's based on the assumption that companies of more or less the same size peer with each other to exchange traffic. For voice, however it's a very different story. Voice has been regulated and structured for many decades. When the idea of VoIP peering appeared, everybody with an IP background thought it would involve exchanging voice traffic for free. This does not really happen, of course, because the people who want to do it for nothing are smaller operators, and they want to lower their cost base. You really need the incumbents to go along with the idea, since most of the voice traffic ends up there. But the incumbents don't like that, obviously.
What I'd like to see happen,
says Binello, is that there could be more voice peering centers that really become marketplaces where buyers and sellers of different sizes meet. The big operators, however, already have interconnections with each other, so you'd see medium and small-sized carriers dealing in such peering centers. However, the technical standardization isn't quite there yet. Even so, having third-parties running such exchange points would be helpful to promote standards - the ones they use - and to offer such services as protocol translation and transcoding, and thus simplify the interconnection process.
We can see the realization of a few of Binello's prognostications in the form of Arbinet-thexchange, Inc.'s (http://www.arbinet.com) announced introduction of its managed paid PeeringSolutions offering, customized for the U.S. domestic market. Initial participants include XO Communications, PAETEC, InfoHighway, BBCOM, RIO, plus other service providers. Arbinet's PeeringSolutions allows U.S. domestic carriers, such as CLECs, cable and mobile operators, to peer and exchange traffic with each other regardless of their network technology. Settlement for the calls is determined and agreed upon by the providers, with a variety of settlement options including traditional paid settlement and bill and keep agreements, allowing carriers to maintain full control of the economics of their business.
Building the Building Blocks
Just as we were going to press on October 5, 2007, Dialogic announced its acquisition of the EAS Group Inc. , which includes such subsidiaries as SnowShore (the folks who bring you the IP Media Server) and Cantata Technology, the later being an amalgam of two former companies, Excel Switching Corporation, and Brooktrout Technology, which owns over 90% of the American fax board market.
Just prior to the acquisition, Yours Truly spoke with industry legend James Rafferty, who at the time was Senior Product Manager for VoIP Products at Cantata. Certainly the thing that's been driving VoIP Peering has been 'islands of VoIP' appearing and becoming more prevalent. There's also a movement toward having more formalized groups for peering, perhaps the most famous being the VPF [Voice Peering Fabric], but there are others out there that are doing peering at the IP level rather than using the old 'exchange of minutes' model.
The VPF (http://www.thevpf.com) of which Rafferty speaks enables the Ethernet LANs of different companies to connect via facilities at 60 Hudson in New York City, 700 South Federal in Chicago or Beijing, China. Calls are routed through the VPF and then to your LAN and desktop IP Phone, with no interworking with the PSTN or unnecessary Internet routing hops involved.
As far as Cantata is concerned, says Rafferty, where we play in this space tends to be for services to these folks that are doing peering. There's a belief that everybody's using the same codec and so you don't need to do interworking or transcoding. Our experience is that that isn't the case at all. Transcoding tends to be a 'hot button' for us and many of our customers have resorted to our technology to do transcoding in border situations, or we've actually had some cases where customers have taken our, say, IMG [Integrated Media Gateway] and used it for a transcoding service for entities in a peering fabric that might need it.
One really cool thing has come up in the last few months or so, says Rafferty. We worked with some partners to create of pool of devices, using a single IP address. Essentially we're using various servers out there in the industry that can be used to front-end our IMGs, so that you can establish a pool of transcoding resources, which can be called upon when you need transcoding between different next-gen networks. Many of our customers are really excited about pooled transcoding resources.
We also do some interesting work with ENUM [E164 NUmber Mapping], says Rafferty. We can translate between a telephone number and a SIP address. We can do it to multiple registries, because we have the ability to go through and access up to four different DNS [Domain Name Service] servers. Recently we announced a partnership with XConnect. When we told them we had the ability to connect to multiple DNS registries, and they liked that a lot, because many products go to the first registry and then, if they can find what they're looking for, they stop. Our technology can do lookups in a hierarchy of multiple registries.
NexTone (http://www.nextone.com) is the well-known purveyor of SBCs (Session Border Controllers) that support real-time NAT (Network Address Translation) traversal, have sophisticated security facilities in OSI layers 2 through 5, and are imbued with SIP and H.323 signaling intelligence, thus enabling service providers to successfully interconnect to any fixed or mobile IP network while simultaneously building towards an IMS (IP Multimedia Subsystem) network service architecture.
John Longo, Vice President of Marketing at NexTone, says From a NexTone perspective, our play really is in terms of providing equipment such as SBCs and our MSx [Multi-Protocol Session Switch] to facilitate those interconnects. Peering can occur on a bilateral basis where carriers choose to interconnect directly and establish their own terms, or they can do it on a multi-lateral basis where you have 'facilitors' involved, since somebody has to organize the contractual business relationships, security, and all of that. That's where you see players such as Stealth Communications and the VPF, XConnect, Arbinet, and so forth. Then you have Global Crossing, where they're actually providing the peering across their own network. So I always think of peering in terms of the change in the industry model to move away from the buy/sell/resell markup-the-minutes scenario.
I don't think I see a change in functionality or requirements for Nextone when it comes to peering, says Longo. We have a robust platform that works very well at the network edge where carriers and enterprises have established a variety of possible paths that a call or session can take. You'll find our equipment in peering facilities because of our ability to deal with both bilateral traffic and to instantly decide what to do with a call: use least cost routing, send it to the PSTN, or what-not.
Various forms of VoIP peering will proliferate in the near future. As to which interconnect business model will succeed, it's difficult to say, though the incumbent operators tend to call the shots and they obviously won't be giving up charging on a per-minute basis any time soon.
XConnect (http://www.xconnect.com) is one of the major drivers of the VoIP Peering / ENUM federation model and global adoption of peering. Particularly in Europe, they're perhaps the Number One company. In the U.S. there are other names that they work with on a partnership level: for example, in June 2007 they announced with Telcordia a plan to pursue national federations and other integrations between XConnect's ENUM registry and their legacy registries, and also pursue their next-gen service model. XConnect prides itself on being able to provide Plug-and-Peer VoIP interconnection services dedicated to connecting IP communications providers and by-passing the legacy PSTN.
XConnect's Founder and CEO, Eli Katz, says, When speaking of peering you first must ask what entities and features are you trying to peer? There's 'pure' IP peering, which involves connecting one, two or N-number of networks together to enable IP packets to flow in Layers 2 and 3, which is where you find your Ethernet and IP routing. That's a fairly well-known, mature industry, where some industry players provide basic IP connectivity. That's an important component, obviously. You can't communicate from A to B without having packets go from A to B, and whether people are using public or private networks, we see very much a genuine growth in both of those. Billions of minutes per month are happily traveling via public IP networks as we speak, and at the same time we see a growth in private IP or private Ethernet connectivity. Why is one chosen over the other? Typically it involves a classic cost/benefit analysis. Environments where we're providing a federation for a finite number of members, typically on an in-country basis, will almost always come with dedicated Layer 2 connectivity to enable a completely private, cause-enabled, high-bandwidth, high-scalability service.
On the other hand, if you're talking about international connectivity, says Eli, where either the federation is on an international footing or you're trying to connect up service providers across the world, or you're linking together carriers to satisfy a certain configuration across the world, then the cost benefit analysis may suggest using global distributed Ethernet connectivity. But that's a bit harder to do, and so we see public IP as a more common approach. Looking forward, I think we'll continue to see the evolution on both sides. Public IP will continue to grow in its ability to handle minutes, and indeed we see that growing on a month-by-month basis. And the federations that we run, whenever it's on a more localized country basis, or involving a specific group of operators, always come with some sort of straightforward Ethernet connectivity which is a fairly standard opportunity. So, that's our view on the most basic Layers or peering of pure IP packets.
If we look at the other extreme of what we're discussing in terms of peering - in the sense that you're talking about complete IP communications peering - an end user-to-end user situation is the kind of environment where much of the activity is done in the application and you don't actually need any service providers in the middle, says Katz. It's just a matter of running communications as an application on my PC, and you're running the application on your PC. We don't need service providers, carriers or network operators. The communication just sort of 'happens' as a sort of 'pure' peer-to-peer environment with no central control or elements. I think we're very far away from such a model appearing everywhere. I don't think the entire telecoms industry is about to spontaneously implode and a trillion dollars worth of investment disappear from the global telecom scene. I think we'll continue to see a prime environment whereby service providers will continue to provide services to end users.
So those are the two extremes, says Katz. In the middle, which is the space where we at XConnect very much like to operate, is primarily between service provider-to-service provider peering in the 'pure' IP sense and, more optionally, carrier-to-service provider peering.
There are a number of operators who provide registry services, says Katz. We can discuss these registry services without necessarily using the term ENUM, which is a bit of a red herring in this case. It's a very good protocol, but it's not the be-all and end-all of everything having to do with peering. Registry services enable the smooth optimization of a call from service provider A to service provider B. The registry component is the first building block in how to deliver successfully scalable, efficient IP interconnections between service providers. There's a lot more complexity here than simply having some large database the cloud and everybody queries it, gets their answers, and presto, you now know how to route the calls. There's significantly more complexity involved, and that needs to be delivered as part of that registry building block in service provider-to-service provider peering.
Some of the complexity I'm talking about has to do with access to the data, says Katz. As a service provider, am I happy having my data being accessed by everybody? Sometimes yes, sometimes no. I as a service provider would like to have all of the necessary data for my peering and I'd like to have that in my network so I don't have to do remote queries. If I'm peering with Peering Partners A, B, C and D, I'd like to have all of their data sitting in my database in my network so I can query it locally. That provides some 'tension' in the sense that, in terms of the other service provider on the other side of that peering relationship, am I happy for it to have all of my data, and synchronized to tens of thousands of changes on a daily basis, sitting in its network? So there's a policy element that needs to be carefully considered in the management of that data and the provisioning, and in fact there is a lot of work going on in the standards bodies in these areas.
Katz continues: And there's a growing amount of complexity concerning policy. If the type of call I'm making is a video call, then I want the interconnection to be at point X, not at point Y; so it's not a simple case of looking up a number. It's not even true to say that you can simply look up the number and get one answer. It could be that with either service provider, if I'm interconnecting with service provider A, I want to interconnect with it via point of interconnection #1 and if it's interconnecting with service provider B, I want it to send calls with another session that comes in at point of interconnection #2. So all of this we wrap up on the policy side of what a registry is. It's a much richer environment than simply something involving the lookup of one telephone number yielding one answer. The complexity involves such questions as 'With whom am I peering?', 'What is the level of access to the data?', 'Is it based upon a different type of service?', and 'Does it elicit the same response from SPIDERs?' [Note: SPIDER is not ENUM per se, it is simply a registry can push data into a private ENUM database. The Service Provider ID E.164 Record (SPIDER) registry consists of shared database tools that enable 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 not-for-profit industry group administered by a Board of Directors comprised of IP-communications industry representatives. 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.]
I've just touched upon some of the complexity involved in purely the registry component of provider peering, says Katz. Without the registry, the whole network is simply a giant free LAN. On the other hand, the directory is not just merely an easy one-off lookup to get a single answer. Most of the environments that we see, and for which we are providing services today, involve a lot more complexity regarding the policies relating to
the access and the actual type of answer retrieved.
Now imagine the data sitting in a central registry, says Katz, such as the SPIDER registry that can push data into a private database. We strongly believe in the push model, which means that wherever possible, first, service provider A should have access to the data in service provider B's registry and that data, according to the peering policy, should be pushed out to service provider A. That means that service provider A can do an 'in-network query' of the data. There are different types of vendor-based solutions for delivering a registry-type database service in your network. We happen to provide something called a Local Directory Service, which is a highly efficient IP service that delivers thousands of queries per second, coping with literally hundreds of millions of phone numbers. It based on a high-speed, dedicated directory server specifically designed to deliver data. We also work with some of the other vendors out there such as NetNumber, Nominum, and so forth.
Signed, Signaled and Delivered
Then there is the matter of signaling and its relationship to VoIP peering. Signaling is the next building block in service provider-to-service provider peering. To clarify what we mean by signaling, let's once again allow XConnect's Eli Katz to explain what happens after the registry look-up process.
We've now identified where the call is going and how the call is going to travel and what type of call it is, says Katz, and what network elements are involved, and then identifying the next hop in the network. At this point you can have bilateral signaling relationships between providers. My signaling, INVITE, SIP Sessions, and whatever else, can come direct from the service provider. Or else there's a role for a federation to enable that signaling to actually take place on an intelligent multiprotocol signaling engine environment. To clarify this point, a number of our competitors in this space are mainly and/or solely focusing on the registry component, and very much from our perspective we look to deliver such data wherever it's required by the customer in a complete, holistic solution that includes the registry and the signaling components.
Katz elaborates: The benefits and the main rationale that we see for the signaling component we offer is that, from the standpoint of the service provider, if you're talking about interconnecting and interoperating with one, two, five, ten or a few more other service providers, then that's no big deal; your engineering department people can do interconnect testing and two weeks later up will come the first provider, and then you'll work through the other interconnect issues - interconnecting at the SIP level today can be quite a challenge. Now, if you're trying to interconnect to tens or hundreds of operators, then doing that using a classic bilateral signaling methodology involves a huge amount of engineering resources and there are also a huge number of SIP interoperability challenges. It's not just a 'one-off' exercise. When I as a service provider make a change to my side to a new equipment vendor and I move from softswitch A to softswitch B or I purchase a different model or I move to a different version number of software running on that model, then I really should undertake a full interconnect test with all of my partners, because there's always some sort of impact one way or another on signaling management. So that's where we see our rationale for the second building block of our services, which is providing those signaling interoperability services.
The third building block is what we call our security element, says Katz. That specifically addresses some of the concerns in relation to scalable and efficient IP interconnection of nasty things such as phishing and spitting. These unfortunately are new threats which are slowly creeping up on the horizon and to a degree have, fortunately, not yet had a major impact. Unfortunately, however, the underlying rationale shows that, in the same ways that we've seen with spit, spam and even instant messaging and SMS [Short Messaging Service] texting, it's the next frontier for the baddies out there. That's why security is very much part of our solution. It's put in place based on signaling, heuristics, and applying similar fault patterns and security directives derived from an examination of email and spam, and applying that expertise to the Internet telephony world. It's a whole additional building block of validation security, in terms of making sure the calls are coming from where they should be coming from, which involves identity validation management and at the same time, preventing spit or 'spam over Internet telephony'.
It would be lovely if every provider managed their network perfectly, says Katz, and everybody could validate and authenticate every user connected to their network, and every user would behave and not spoof their identity or attach a spit generator to the network. In such a utopian world, you wouldn't need any of these additional levels of security. Unfortunately, we don't at the moment live in such a trusted and trusting world.
The public hasn't heard a great deal about security in this regard, says Katz, probably because, where you have a small steady federation of interconnection, that can be managed within the limits of your own OSS and BSS systems. Some of the additional security elements can be managed through your own monitoring, and so forth. But when you start to widen that federation and the contractual relationship that you have is now with many parties from many different countries, you therefore now encounter the classic scenario of: 'Oh, I trust him, I know him, I have a contractual relationship with him.' And it doesn't necessarily follow that everything will be okay, especially on an international basis or if a Tier 1 is trying to interconnect with a Tier 3, and vice versa. That's where we see more signaling requirements as well as security requirements relating to the federation. That's also why both signaling and security are core components of the service we at XConnect deliver.
A Small Circle of Friends
Our fourth building block in VoIP peering is the commercial building block, says Katz. This concerns the commercial relationship between the different service providers in a federation. Really, you have a choice of two business models; first is the classic settlement basis, which is what 99.99 percent of the world uses today, which means that I pay you for every one of my calls that enters and terminates in your network and vice versa. Secondly, however, is the new paradigm, which is the 'bill and keep' model approach that's settlement-free. I'd like to point out that, without a fully-managed settlement-free environment, you as a service provider are basically making yourself vulnerable to massive abuse. If I as a service provider decide to peer with you as a service provider, and we agree between us to do this on a settlement-free basis, then I need to feel comfortable that you're not going to start selling terminations to me out in the open market, and thus using me as a transit element, rather than dealing solely with the traffic coming from your own customers.
So there needs to be a very careful managed approach to settlement-free models, says Katz, both in terms of the technology, identify authentication, validation, monitoring the balance of traffic and whatever is on the contractual side. Simply saying, 'We agree on a settlement fee, have a nice day, end of story,' is not really an overly-sensible approach to take forward. But we very much have the systems in place that allow us the flexibility to offer to our customers, according to their policies, whatever it is they would like to do. In certain federations they may indeed want settlement-free relationships with providers A, B, C, and in other federations they might want a hybrid relationship, or a conventional settlement-based one, for that matter.
We take our four building blocks and essentially provide federation services according to the customer requirements, says Katz. We can provide that on a private basis, so that there could be a group of operators wanting to interconnect with each other and have some sort of federation services - it could just be for registry access, for example. Or it could be for the registry, signaling and security, or it could even include some commercial settlement or settlement-free management.
That's where we provide a private arrangement on a managed service basis to a group of network operators. We're doing that now, very much on a world-leading basis, in three countries where we have made announcements. We'll be making similar announcements in other countries before the end of 2007. Essentially we're talking here about a managed service for a complete federation suite of services.
XConnect also runs its own federations, and some of these are on a settlement or settlement-free basis, says Katz. Once again, it depends on the size of the customer, and ultimately it's their choice as to the routes and they can utilize a number of different federations that we offer.
SPEERMINT and PEPPERMINT
Obviously, VoIP Peering and similar forms of real-time communications on a large scale would be facilitated by more 'standardized standards'. Take for example, the IETF's working group called Session PEERing for Multimedia INTerconnect (SPEERMINT), which is related to but is distinct from the ENUM and SIPPING working groups. Whereas the ENUM Working Group concerns itself with the structure and lookup of data for the translation of E.164 numbers into URIs (RFC3761), SPEERMINT is focuses on the use of the resulting URI data, as well as non-ENUM-derived URI data, for use in signaling and routing of real-time sessions. SPEERMINT thus tackles issues other than network interconnection, and extends into higher layers of the OSI stack, including signaling, trust/authentication, and security. Indeed, most of SPEERMINT work concerns Layer 5 (Session) peering, where SIP methods operate. Essentiallyk, SPEERMINT, takes a collection of protocols and provides a set of recommendations as to how they should be used.
As Eli Katz of XConnect says, We at XConnect take an active role in the IETF and we actually contribute in various working groups. Right now, there's been some activity in creating
a new working group called PEPPERMINT. [Note: Provisioning Extensions in Peering Registries for Multimedia Interconnection (PEPPERMINT) will define a set of protocols that can be used to exchange provisioning data to registries in support of efforts such as SPEERMINT. At the moment the current standard of exchanging provisioning data such as call routing tables involves primitive methods such as swapping Excel spreadsheets.] We're very much involved in PEPPERMINT and thus creating an IETF globalized standard for provisioning data to the registries. As I mentioned previously, the complexity and breadth of the data we're looking at is not any more a simple, single database look-up using a phone number. Life is more complex than that, and therefore the provisioning of such data is likewise more complex. That's why we take an active role in both SPEERMINT and PEPPERMINT.
VoIP Peering will continue to grow and ultimately dominate the way that businesses connect with its partners and customers. Opportunities will pop up not just for the carriers in the market today, but for those organizations, both public and private, yet to begin peering. We all think of VoIP-based peering but in fact peering as such will include all sorts of enhanced applications that will generate revenue for service providers.
Richard Grigonis is Executive Editor of TMC's IP Communications Group.
Today @ TMC
ITEXPO West 2012
October 2- 5, 2012
The Austin Convention Center
The World's Premier Managed Services and Cloud Computing Event
Click for Dates and Locations
Mobility Tech Conference & Expo
October 3- 5, 2012
The Austin Convention Center
Cloud Communications Summit
October 3- 5, 2012
The Austin Convention Center