With the usual fanfare, Microsoft released Windows XP in October. Reviews touted the operating system's improved stability, multimedia capabilities and richer features. But few explored its communications services, and little was made of its SIP-based client that enables PC-to-PC and PC-to-phone VoIP calls. The average Joe may not be aware of XP's calling capabilities, but everyone in the VoIP world-from providers to device manufacturers-sees Microsoft as a much-needed VoIP champion.
Their hope is that Microsoft's support of SIP (Session Initiation Protocol) will drive residential and international calls to the Internet. If consumers take advantage of the SIP client and finally recognize the benefits of making calls over the Internet, the VoIP market could get a much-needed boost. Another possibility is that consumers might ignore XP's communications capabilities, much like they did NetMeeting's videoconferencing features.
If SIP-based traffic does increase, however, service providers will have to make some infrastructure adjustments. Anticipating these needs, Microsoft is introducing a SIP-based proxy server, which will be used to relay call invitations, rejections and acknowledgements. Location servers, registrar servers, redirect servers, softswitches and gateways that bridge H.323 and SIP traffic are a few of the network elements that may need to be added to the mix.
These PC-to-PC or PC-to-SIP phone calls will not accrue revenue, however, asserts Rick Woods, vice president of product management at Intec Telecom Systems. "These calls aren't billable services. They will be another free Internet activity." Service providers won't charge for the calls because the quality may be second-rate, and the resources required to separate the voice calls from the data calls are too costly.
"Investing in a service that is almost free is a contradiction for service providers," says Raanan Grinwald, senior product manager at Mind CTI. "The sophisticated mediation devices and tools necessary for collecting and analyzing the data would require years to show a return on investment."
These rudimentary calls may not generate revenue, but they should usher in diverse SIP-based applications that will be profitable. Unlike the more prevalent and mature H.323 standard for IP telephony, SIP supports the addition of rich, innovative services.
"Compared to H.323 or MEGACO [media gateway control], which have been focused on voice and call setup and teardown, SIP is more application-focused, letting you add applications on top of the network protocol," says Morten Seifert, manager of product marketing at Digiquant. "SIP is the beginning of a new era for VoIP."
Even with industry support for SIP, some VoIP insiders advise caution. "Windows XP may create an influx of traffic, but the industry will still need to mature," says Opher Kahane, co-founder and CEO of Kagoor Networks, a VoIP equipment vendor. "The protocol is immature and has created little commercial traffic. We should adjust expectations, because it will be at least 18 months before it is a viable commercial protocol."
Billing and SIP
The onset of SIP-based calls does raise billing concerns. Martin Demers, senior vice president and CMO at Ace-Comm, describes SIP as a "mini version of SS7 that goes beyond SS7 to create the connection of two endpoints." These calls use URLs rather than phone numbers to locate a recipient. "SIP is built to find any user and locate them wherever they move," Demers explains.
To make these calls, the caller sends an invitation to the call recipient. The invitation is routed through the proxy server to a location server, which knows where to reach the recipient based on the recipient's URL. From the location server, the invitation is sent to the call recipient, who either accepts or declines the request. If accepted, the proxy server will route the requests to the different end points and set up and break down the call.
With this type of dynamic architecture, the call is not controlled from start to end by a specific network element. "It's a more generic, flexible and distributed protocol," says Mind CTI's Grinwald. "Unlike H.323, which has originating gateways or gatekeepers that know when a call started and when it ended, SIP uses low-level connections crossing a variety of elements. It moves the responsibility of setting up a call to other elements, and they have no acknowledgement of what happened and they provide no accounting information. The protocol is very unfriendly to billing."
To gather accounting information, some element manufacturers have added proprietary software to the devices so they can keep track of the entire call.
Recording the call termination time is another concern raised by billing developers. "Nothing shows that a call was terminated," says Digiquant's Seifert. "Nothing ensures that the proxy server knows that the call has ended." He adds that service providers can gather termination information in a controlled environment, but it would be impossible on the Internet.
To provide the services over the Internet, the client must be configured to know all termination parties. "The service provider must create a controlled chain for all calls," says Seifert. By designating a route with known SIP proxy servers, the service provider can gather call information. For now, Seifert quickly adds, this isn't an immediate problem, because SIP-based traffic is rare. He expects that by the time that traffic becomes more common, SIP standards committees will have created a method to record terminated calls.
The mediation companies face different concerns. The main problem is that SIP-based traffic creates a record for every event that occurs during the call, such as who is calling whom, time to dial, time to pick up and so on. "SIP-based traffic generates 20 times more records than circuit-based calls, and not all the events are meaningful," says Ace-Comm's Demers. "The records must be consolidated to represent what has taken place. For example, there is no clear indication of when the conversation starts, or the 'answer time' in a conventional environment. The mediation system must collect each record, aggregate them and compare them with information from other sources."
Scrubbing VoIP CDRs
Service providers will have to address these billing and mediation issues if they choose to rate and bill SIP-based traffic, but meanwhile VoIP providers are grappling with their own set of mediation and billing demands. The VoIP architecture puts the heaviest burden on the providers, because it requires many more elements than the PSTN to complete a call.
Gatekeepers, gateways, softswitches and class 4 and class 5 switches each play a part in creating a call, and each produces its own set of records. "Gathering the different call records from gatekeepers and gateways and putting together enough information to describe that call is a complex task," says Intec's Woods.
iBasis, a wholesale VoIP provider, says its biggest billing challenge occurs when it doesn't own a gateway that is passing traffic onto or off the iBasis network. For billing and settlement on these gateways, iBasis is working on an in-house system to track where the call came in and the exact IP addresses and endpoints, explains Ajay Joseph, vice president of network architecture. The call records from the Cisco gateway and the Digiquant RADIUS servers are sent to an in-house developed tool, which decides if the traffic is intra- or interdomain and who the partners are. The system is in trial right now, and Joseph expects to release it in late 2002.
Another wholesale VoIP provider, ITXC, agrees that other carriers' gateways do pose problems, especially when they produce inaccurate data. Once ITXC realized its homegrown mediation tool was not meeting network demands, it turned to Intec to help scrub and filter its data.
Intec's Inter-mediatE gathers information from ITXC's VocalTec equipment. Cisco gateways are also on the network, but VocalTec gathers call information from the gateways. ITXC defined what data would be captured and the formats, and Intec worked with VocalTec to create the formats and enter them into the mediation platform's data dictionary. The VocalTec equipment produces CDRs in an ASCII format with comma-separated values. The data collected includes "originating gateway, terminating IP address, gateway identifiers, start time and duration. These are traditional voice call records with an IP flair," Woods says.
Intec's mediation platform is taking care of what Woods describes as VoIP's two biggest problems: duplicate records and inaccurate data. Date errors-when the date is either a year or two in the future or a year or two too old-are often the result of partners' device configuration errors. Time errors often occur when traffic passes through different time zones. Intec worked closely with ITXC to clean up this type of "sloppy data," says Lee Cascio, vice president for network development and engineering at ITXC. "We have implemented business rules and created a script that sends an alarm if the records show 2003, or some other improbable date. Then we contact the affiliate and have them reconfigure the device."
Intec and ITXC also tackled duplicate records. In the VoIP network, where multiple devices create CDRs that are passed to the mediation platform, more than one device may provide similar or identical data. The mediation platform must sift through all the records and pass the most accurate representation of the call to the billing system.
"In a distributed network, a call passes through multiple platforms of different technologies, but there's always a good record of the call," says Cascio. "We select the call record of the device closest to the customer supplier to
decide the charges. We also do a huge amount of reconciliation to ensure that the account reflects the same amount of minutes and seconds."
Duplicate records also occur during network congestion. Likewise, when a backup device takes over for a primary device ( a "failover" situation), both devices may send identical records.
"The mediation platform, using business rules, has to decide which record is the most appropriate. All the incoming data must be examined," says Intec's Woods. "Once the service provider understands why the circumstance occurred, parameters can be applied to the call records to decide which records best describe what occurred on the call. These rules are often based on how the network was built and how it is routed."
Net2Phone-one of the VoIP provider options available on Windows XP-is another company that has experience troubleshooting VoIP networks. Not only has it had to trim the excessive number of records produced by the network elements, it has also had to create safeguards for when an element produces no records.
"It's critical that a messaging or alarm system is in place where the billing system or mediation platform sends a message to an element when it doesn't receive a CDR after a given time period," says Dominick Tolli, co-president of Net2Phone. "These CDRs must be stored on the element so that when the link comes back up, the records can be funneled to the billing or mediation platform."
To prepare for SIP traffic, Net2Phone is making some adjustments to its CDRs to capture routing and quality of service information. "To improve our billing capabilities, we are trying to match industry standards and add more information to the records," says Tolli.
After a couple of years of experience with VoIP, iBasis has discovered some soft spots within the network elements. Among the improvements it would like to see: having more information on the CDR, being able to gather data in real time without overwhelming the device's CPU and putting more storage on the devices.
"We would like to get more real-time information from the gateway without taxing the CPU," says iBasis' Joseph. "We need metrics on a per-call basis that code the call as successful or unsuccessful and indicate the reason for the success or failure. That information gives a good indication of what is occurring in the network. We also need direct measurement information about performance. We can get that information from SNMP, but it starts taxing the device's CPU, and it's not in real time."
These metrics would help providers monitor network performance, but Clarent, a softswitch developer, has additional advice for ending bottlenecks in the back-end systems. Don Brown, senior director of marketing, says many service providers' billing systems can't process the incoming records because their database is unable to handle the load.
"VoIP providers often miscalculate how many subscribers they will put onto their networks," he says. "Many times their billing systems can't handle the high volume of calls."
Amdocs also sees billing databases as a source of problems. "Breakdowns often occur because of a database's lack of scalability," says Mark Farmer, director of product marketing. "Providers may have built their own billing solution that can't keep up with the network growth. As millions of records are passed to the billing databases, it can't capture all the transactions, and the carrier will start losing revenue."
VoIP Performance Demands
During the last three years, successful VoIP providers have experienced significant increases in traffic and have had to scale their infrastructure to carry the millions of minutes passing over the network.
"A couple of years ago, a provider could put in a VoIP gateway in a certain region and be done. They managed a couple dozen gateways; now they have thousands to manage," says Farmer. "And they are facing telco challenges, such as revenue assurance, network monitoring and maintenance, and NOC [network operations center] requirements."
As network demand increases, VoIP providers are adding performance-monitoring tools. They are conducting active and passive tests that reveal aggregate network performance and individual call quality. In some cases providers are also relying on the mediation platform to help them understand what is occurring on their networks.
Each call on ITXC's network produces records that are passed to the network management system. How the call
originated, its routing parameters, and the different network elements that participated in the call are a few of the items that the mediation platform conveys. In addition to the CDRs, ITXC also collects SNMP data to monitor network performance.
Other VoIP providers are adding network management tools. iBasis has deployed Brix Networks service assurance software to help verify the quality of VoIP services. The provider installed Brix 1000 Verifiers in its central offices and manages the devices from its NOC.
"We are measuring performance between and among POPs by gathering network measurements, such as packet loss, delay and jitter, and measuring connectivity and performance on a round-the-clock basis," says Laura Holly, product line manager at Brix. "The measurements range from general network tests of Layer 3 infrastructure up to IP applications at Layer 7." iBasis' routing system then uses the data to move calls along the highest quality routes.
While these measurements help route traffic, Brix has also developed a method to assign an MOS (mean opinion score) on to individual VoIP calls. The MOS method, which rates voice clips on a scale of 0 to 5 (with 4 being decent), is prevalent in the PSTN world but rarely found in IP networks.
Most MOS measurements are established by transmitting voice wave forms and testing how well the files transmitted. The computational demand on processing capacity is high, explains Holly, and it does not scale to a per-call basis. That's why Brix chose the E model approach, a method to determine the quality of calls.
The E model attributes an MOS to a particular call by taking into account the network attributes of packet loss and delay. "The system is customizable, letting users decide what is acceptable and unacceptable performance," says Holly. "The test could be a combination of packet loss and delay, or some other measurements."
Kagoor Networks is another performance testing company in the VoIP arena. Kagoor has developed a traffic management device that classifies IP traffic and gives special treatment to designated traffic with special needs, such as voice. Using Kagoor's VoiceFlow, the service provider can determine how traffic should be routed and can measure quality of service from the user's perspective.
For Kagoor's Kahane, QoS measurements go beyond the typical metrics of packet loss, jitter and delay. Instead, he expects that VoiceFlow could be used to combine all these measurements into a single score that could be passed to the billing system.
"Bombarding the system with individual metrics does not measure QoS," he says. "These statistics must be separated and molded into a single score, which will be used as a measure of quality that can be tied into billing and rating."
As VoIP becomes more prevalent, Brix and Kagoor expect these call rating mechanisms to support SLAs. If each call is rated for QoS, the aggregated metrics could be used to offer credits to customers when an SLA was not met.
The appearance of network management tools completely devoted to VoIP is only one sign that the sector is maturing. Other signals also underscore the growing adoption of VoIP, such as the increasing volume of international and long-distance minutes that are traversing VoIP networks and the increasing number of service providers-large and small-that are realizing the cost benefits of VoIP.
This volatile sector can be easily transformed by new developments and technical advancements. SIP may be the protocol that will disrupt current VoIP networks and usher in an evolution. "If a provider doesn't have a publicly announced SIP strategy, you can be sure that they have one in the lab," says Brix' Holly. "Everyone is interested in SIP and has a plan for deployment in the near term."
As the protocol becomes more established and the network elements add SIP interfaces, VoIP providers will face additional billing challenges. Current providers, and those just entering VoIP, will apply hard-earned lessons from H.323 to the constantly evolving, dynamic IP network.
VoIP: The Burden of Excess Data