Walking around the last Fall VON trade show in Boston, you’d have found 300+ companies with a core focus on VoIP and SIP, each proclaiming that they are the next “must have” IP communications solution. One thing is for sure; VoIP technology is no longer considered a sideshow without market traction. In fact, this latest VON show treats VoIP as a done deal, and proven technology, as it should. Now, the same venue that held together the VoIP community over the last 10 years is trying to prove that video is the next big thing for the IP communications industry. Video will clearly be a major focus of next generation wireline/wireless carriers and IP communications technology, including SIP and IMS, will play a pivotal role in its deployment. A decision to use IP communications components to enter the prepaid business, or to lower operations costs and economically expand, starts with two basic questions - what is the business case, and what are the entry costs? The business case is as individual as the service provider, and in most every market, it’s a compelling one. Answering the entry cost question starts with understanding what the components of IP communications network are, what they do, and what you’ll need. Basically, you’ll need three things: software, hardware, and network connectivity. There is a core set of software components required for IP communications service delivery, often referred to as a Service Delivery Platform (SDP). The SDP is the “service node” that connects to a Media Gateway or Session Border Controller (SBC) to interact with a prepaid subscriber on the PSTN. The SDP software components run on standard server hardware based on Linux or Solaris operating systems. SDP vendors include different components depending on the vendor’s product portfolio, but at a minimum, the list includes an Application Server and an IP Media Server, along with a third party database and Web servers. The database server is used for storing subscriber profiles, authentication, and call detail records, while the Web server is used for customer self-provisioning and account maintenance. If you’re running both pre and post paid services, you may also need a separate billing system. The prepaid application service logic itself is running on top of the Application Server and is based on the session initiation protocol (SIP). There are two main approaches to Application Server design – the first uses XML scripts as service logic, and the second embeds SIP protocol syntax in Java programs. To better understand how the XML-based approach works, think of the Application Server as a traditional player piano and the XML script as the music roll paper telling the piano which notes to play. The Application Server reads the XML script (music roll), and tells the IP Media Server, database server, web server, and network elements what to do. For example, when a call is initiated by a prepaid subscriber, the Application Server can interact with a network element via SIP to establish the A-leg, play a welcome prompt, collect their PIN number using DTMF, and then call the database server to authenticate the subscriber’s PIN. So the Application Server (the player piano) instructs (plays) all component functions (notes) of the SDP to assemble a call scenario (the music). In a prepaid application, the IP Media Server plays prompts, collects & plays DTMF under the control of the Application Server prepaid service logic, and IP Media Servers are implemented as either dedicated DSP-based hardware or standard server-based media processing software. While a DSP-based Media Server is usually needed for conference call audio bridging and transcoding, a software-based Media Server is all that is needed to perform IVR functions for a prepaid application. If the SDP also incorporates a Service Creation Environment, this XML-based service logic can be easily modified by either the service provider or vendor to add service logic customization and enhancements. Your subscribers may be on the legacy PSTN network with a PSTN phone, or increasingly, may be on a VoIP phone. Your service must address both use cases, a TDM-connected subscriber and a VoIP call from a SIP end point. There are two ways to interconnect with the PSTN and allow communications to and from. The first is via direct hardware connection to the PSTN. To do this, you will need a Media Gateway, possibly controlled by a softswitch. A relatively new and extremely economical alternative is through what’s called SIP peering, where you route your calls directly to a wholesale carrier who provides outbound call terminations (which is to say, the call goes from the IP network to the PSTN network and recipient’s phone). A Session Border Controller, or SBC, as we mentioned earlier is used to connect to TDM-facilities owned by wholesale carriers via SIP peering. Either approach gets you to the PSTN and the subscribers and recipients that connect to it. Any discussion of SIP prepaid applications and services needs to at least touch on the subject of how the cost arbitrage model is changing in the face of IP communications networks. Traditional prepaid calling card services offered on the PSTN were all about saving money on individual long distance calls. Then VoIP services came to the market and introduced a cost arbitrage based on low-cost network access that bundled in unlimited long distance calling. Looking forward it will be possible to have unlimited calling plans that can be used across VoIP and wireless networks, i.e. fixed mobile convergence. The original long distance arbitrage market, which started with prepaid calling services, is rapidly evolving to include IP networks and multiple services incorporating multi-media. SDPs need to be broad enough in capabilities to take on these challenges. All-in-one prepaid platforms may have been acceptable in the past, but contemporary SDPs need to run multiple services that can adapt to new networks types. We are no longer in a market where one service can sustain a business model, since IP communications is enabling service providers to do much more. While the original need that drove prepaid services on an IP platform was lower cost, now it is to support multiple services and to use SIP peering to enter the market without substantial Capex/Netex investments. Building a network vs. building a revenue stream: In making your software and hardware decisions, be sure to select a comprehensive and integrated software SDP platform, a cheaper and far easier alternative than assembly of individual software components, and an approach that ensures you’re able to run multiple applications over your single platform rather than reinvesting for each new service. Then choose your hardware, which will probably run Linux,, so you’re not locked in. Next, you’ll have to decide whether you want & need a media gateway and possibly a softswitch. Depending on the routes you pick and your business decisions, some routes are SIP peering no brainers, and others will require this investment. So where is the opportunity? There is a lot of discussion on converged networks embracing all network and subscriber types: wireline, wireless, VoIP, etc. What we’re seeing today is that VoIP’s are beginning to dominate, and at some point will be the de facto standard for networks. This could be described metaphorically as Global VoIP Warming: currently there are glaciers of PSTN and 2G wireless, but they’re slowly melting as emerging carriers changeover or pursue VoIP from Day 1. How fast will they melt? Over time, but large chunks will fall quickly making for business model opportunities. Good planning up front will make you fast on your feet, with the right technologies in place to capture every major opportunity. Just remember that low cost per minute and flexible access to service are the two goals you’re working towards, and that prepaid is going to be the first crossroad for VoBB, through cards, affinity marketing, etc., and low cost, low end services. Get your pencil sharpened, shop carefully and get ready. So how can we help? What’s your question? Write to Ken Osowski at keno@pactolus.com.