Mike Hluchyj, CTO, Sonus Networks

If ever Mike Hluchyj, founder and chief technology officer at Sonus Networks Inc. (Nasdaq: SONS), asks you to join him in a game of poker, think twice before accepting.

When we met Hluchyj [pron: HLU-CHYJ] in London recently, BT Group plc (NYSE: BT; London: BTA) had announced only hours before the key vendor suppliers for its 21st Century Network (21CN), a project that Sonus was hoping to be involved with, courtesy of partner Marconi Corp. plc (Nasdaq: MRCIY; London: MONI). (See BT Unveils 21CN Suppliers, Marconi & Sonus Team for Next-Gen, and HR Unties Sonus/Marconi Tie-Up.)

But in one of the industry's biggest shock decisions of recent years, BT shunned Marconi, and, as a result, Sonus's immediate and most likely route into the British carrier's NGN plans was cut off (see BT Shuns Marconi for 21CN and Marconi in Turmoil).

At an early morning meeting, Light Reading was able to deliver news of BT's decision to Hluchyj and his PR minders, and while the latters' chins hit the floor in shock, the Sonus CTO stared into the distance like a poker professional about to bet his entire stack of chips on a seven-high hand.

He did admit later to being shocked at the news, but initially did well to hide his surprise and, no doubt, disappointment.

So who is Mike Hluchyj? Did he ever ply his trade at the Vegas tables? Nothing quite as reckless, it seems. Prior to forming Sonus in 1997, Hluchyj was CTO at switch vendor Summa Four, which was acquired by Cisco Systems Inc. (Nasdaq: CSCO) in 1998.

Before that, he was director of networking research at Motorola Inc.'s (NYSE: MOT) Codex business and on the technical staff at AT&T Corp.'s (NYSE: T) Bell Laboratories, now part of Lucent Technologies Inc. (NYSE: LU).

Hluchyj didn't talk about those previous roles, but he occasionally mentioned the early days at Sonus and some of the initial technical and architectural decisions that were made. He also discussed the emergence of the IP multimedia subsystem (IMS) architecture, Sonus's technical development in the session border controller sector, the rise of SIP, and Hluchyj's role in helping Sonus cope with the VOIP equipment sector's increasingly competitive pricing.

Then, of course, there's Sonus's unsettling year of missed reporting deadlines and accounting issues, which is lingering on like a bad smell in a small room (see 'Good Grief!' Sonus Disappoints Again, Sonus Promises, Promises, and Sonus Misses the Mark).

We started the discussion with a brief chat about the BT decision, though, before moving on to the sorts of issues over which Sonus actually has some control.

— Ray Le Maistre, International News Editor, Light Reading

Light Reading: Let's talk first about BT's news that your partner, Marconi, isn't involved in the 21CN project. Is there another route into the 21CN for Sonus? Do you have any other partners involved in that process?

Mike Hluchyj: We've announced Marconi as a partner, we've announced Motorola in the wireless space, and we've announced Samsung, but we haven't announced any others. But we're actively involved in talking to lots of different suppliers. [See Vendors Make Mobile Moves and Samsung Sings Sonus Song.]

Light Reading: Has it come as a shock that Marconi wasn't chosen for the 21CN? Are you disappointed? Marconi must have seemed like a very good partner to have in terms of winning business at BT.

Mike Hluchyj: [Puts on poker face] I think it's surprising, but Marconi will continue to be a good partner for us. We have other opportunities with them. Time will tell how things progress at BT. There may be other opportunities with BT in the future.

Light Reading: Have you seen any impact on your business from Sonus's ongoing reporting issues? It seemed as if you had put those accounting problems behind you, but they've crept back. Has that resulted in service providers holding back from making orders?

Mike Hluchyj: Not really. Last year was a difficult year for us because of the cloud that was hanging over us. The existing customers we had and which know us well had no issues. They understand us and our products, and they continued to buy from us. Last year was a very good year for us compared with 2003. [See Sonus Reports Q4, Full Year Results.]

But there were some new prospects that were worried because they didn't know us as well as our existing customers. They were worried about the cloud. In the environment in the U.S., if you don't report your numbers, people start asking, "What's going to happen? What's going to be uncovered? What scandal is going to blow up?"

We told them what was going on, we told them we were looking more closely at the numbers. When we finally reported, I wouldn't say exactly that it was a non-event, but there was no revelation of something drastically wrong.

The issues we're having now, that's because we're getting our new systems up to speed, particularly within the regulations. We're making the whole system that much more efficient. We're bringing in more people, putting all the systems in place, and we're going to put this issue behind us. But at this point, from what I can see, it's not impacting the customers or our prospects.

Light Reading: There have been some suggestions recently that the sector Sonus plays in, VOIP infrastructure, is experiencing even greater price pressure than other parts of the industry, and some analysts are reevaluating the sorts of revenues that can be generated by companies that focus on the softswitch sector. Are you seeing a greater squeeze on margins? Are carriers wanting more for the same price, or even wanting more for less?Mike Hluchyj: I don't know in terms of the squeeze on the margins. It's the nature of the business. In particular, as you're moving from the legacy world to the new world, it's a complicated business and there's a lot of very close interaction with the customers, and that interaction costs money. We're not selling PCs or legacy equipment.

I think we'll look back in 20 years and say, "Yes, this was the transition to IP." The whole underlying infrastructure is changing, from the core of the network to the access pipes. These networks are huge. Once you have a broadband connection into a home, the incremental cost of adding voice to that is quite small compared to having a whole parallel circuit-based infrastructure.

Light Reading: And will the RBOCs spend money with Sonus doing that, putting voice over their broadband access connections?Mike Hluchyj: Well, we've announced Qwest, BellSouth, and Verizon as customers. Up until about a year ago the RBOCs were all ATM, but that's changed. Some of them assumed that their traditional suppliers would be there for them, but they've found that this has been a much more difficult transition for the incumbent suppliers to make.

Light Reading: What's your position on IMS [IP Multimedia Subsystem]? That's being adopted by standards bodies in Europe and North America. What's Sonus doing there? Is that an approach you embrace? [See IMS Guide.]

Mike Hluchyj: We hear it all the time now from carriers. IMS is a nice architecture that's come from the 3rd Generation Partnership Project, for an all-IP environment. But it's maybe not been thought through completely in terms of connections to other carrier networks and the PSTN.

The way we have developed our products, how we've separated our functionality, is very IMS-like. I can lay our technology on top of an IMS architecture. It's not IMS, obviously. It's IMS-compliant, though – all the interfaces are there. In our architecture, we have our PSX, which is a policy server which has a database for all the routing logic and all the decision logic within the networks we build. That's always been a separate element, and if you look at the BGCF [Breakout Gateway Control Function] capabilities within IMS, the PSX is basically that function. If you look at other softswitch vendors, they combine that function with the routing function as one element. For IMS, they say they'll separate those later.

On the subscriber side, a lot of softswitch vendors tend to combine their call agent with all their subscriber data, and they call it a softswitch, or a feature server. We did our ASX, which is our access server, and our ADS [Access Directory Server], which has all our subscriber data. One ADS can have something like 1 million subscribers and can serve and push that data to many other ASXs, which is where the call agent resides. In IMS you have the HSS [Home Subscriber Server], which is the same concept. Our ADS is the equivalent of the HSS. Is the ADS an HSS? No, we're not there yet, but if you look at the architectural picture, the way we've done it fits really nicely with what IMS is all about. So what you'll see from us is not so much a brand new set of products, but an evolution of what we already do today.

Light Reading: So you have this distributed architecture already, and you just need to add the appropriate interfaces to the various IMS elements?Mike Hluchyj: That's right. The other thing we did which is very consistent with IMS is the separation of enhanced services from the softswitch. We were the pioneers in developing SIP as the interface from the softswitch to the application server. We brought that idea to the International Softswitch Consortium, now called the International Packet Communications Consortium.

If you look at IMS, there's a SIP interface from the serving CSCF [Call Session Control Function] up to the applications servers. That's already happening today, but where IMS will take that concept further is that each of those applications tends to have its own subscriber database. With IMS you can have a common subscriber database through the HSS for the applications, which is a very good thing to do. Light Reading: Do you believe SIP has matured enough for it to be the protocol of choice in fixed and wireless networks? There's not too much SIP traffic around at the moment, is there?

Mike Hluchyj: SIP has momentum as a protocol. In the early days of VOIP, H.323 had the momentum because it was more mature and had more capabilities, but that momentum shifted pretty quickly. Now the interest of the service providers has shifted towards SIP, and as it has become cheaper to put more intelligence in the end points, SIP has emerged as the protocol of choice. But if you look at minutes in the network, there aren't many SIP minutes on the access side, but I think that's growing very rapidly. And even cable operators are now looking at SIP and IMS. There's plenty of momentum behind SIP.

Light Reading: Session border control capabilities are still a hot topic in the VOIP world, and it looks as if Sonus might have been more active in that area lately. Sonus has announced carrier-to-carrier session control capabilities in the past, but have you extended that and developed a product for the edge of the network?

Mike Hluchyj: We announced our network border switch functionality in [December] 2003. [See Sonus Takes Session Control.] The first application we delivered, because we started with customers who had built trunking networks with gateways at the edges, is for carrier-to-carrier capabilities, and that's been deployed.

We also use third parties. I know the Acme Packet guys. When they started the company they came to see me and told me what they were doing. I've had a long relationship with them. They were focusing specifically on this session control area and have capabilities in the access area, capabilities we don't have today but which we'll add over time. More and more of that functionality will migrate to border switches, and there'll be one element that will manage the calls. Clearly there's functionality we need to add, but right now Acme is the partner we have. [See Acme Interoperates With Sonus.]

Light Reading: Will you develop those capabilities organically or through acquisition?

Mike Hluchyj: Organically. It's incremental on top of what we have, and we're 95 percent there. We're missing some functions such as NAT [network address translation] traversal.

Light Reading: As CTO, what are the main drivers and influences on the technical outlook and strategy at Sonus?

Mike Hluchyj: IMS on an architectural level is driving the thinking. We have to look at the scale of networks. It'll be fine for 10,000 subscribers, but what about 10 million? What will that look like? How do we achieve highly available and highly redundant networks? These are hard things to do – and where other vendors usually tend to trip up. I won't name names, but… In IMS, if you look at the architecture, a media gateway controller controlling a media gateway is just one tiny corner of IMS. You have lots of other elements to think about, but quite frankly you have vendors that can't even get a media gateway controller to control a media gateway. They do in the lab, but were never deployed. Now they're talking about IMS.

Light Reading: How much pressure are you under, as CTO, to drive down costs so that you can compete with the likes of, for example, Huawei Technologies? Mike Hluchyj: Something we've always done from the beginning, and we've instilled this in our engineers on the hardware side is to ask, how could someone else do this better? How could somebody beat us? Starting with the architecture, is there anything fundamentally inefficient about the way we're doing things?

If you look inside our product, there is no TDM backplane. We're unique in the industry in that eight years ago we decided that there was no point in having a parallel TDM infrastructure in the backplane. We figured the world was going packet anyway, and so that's the approach we're going to take. We knew there was a little bit of risk associated with that approach because when you convert something to packet there's an inherent delay while you wait to build the packet. So we focused on squeezing that delay as small as we could. If you look at how we do that in the box, in the gateway itself, we had no more than two-and-a-half milliseconds of delay, including echo cancellation processing and all the other processing. Early on, when we described to our prospects what the delay was, they didn't believe it. They were used to products with tens, maybe hundreds of milliseconds of delay.

How can we squeeze the cost down? Start with the architecture, then go to the components manufacturers and say, "Do you want our business? If you do, you have to give us really good pricing. I'm very vigilant. It's easy to fall back on your patterns – "We've always used this DSP, we've always used that…" Our customers are always working hard to drive down the prices, so we have to do the same with our component vendors.

If we need to manufacture at the moment, we manufacture in the U.S. I feel good about the vigilance we have about keeping our overall costs down. At the same time, if you look at the software, most if not all of the capabilities of the box are software driven, and that differentiation gives us a lot of benefits.