| VoIP Telephony and Infrastructure

Media Servers

The term media server is totally overloaded in the VoIP world (and even more so within the IT industry as a whole). If we restrict ourselves to VoIP-related definitions only, a server so named still could be any of the following:

• Interactive voice response (IVR) server or media slave, possibly running VoiceXML or MRCP
• Signaling Media Server (Media Gateway Controller) to handle call control in Voice/VoIP network
• Call distribution (ACD) for receiving and distributing calls in a contact center
• Conferencing Media Server for voice, video, and other applications
• Text-to-speech server (TTS) for listening to e-mail, for instance
• Automated voice-to-e-mail response system
• Voice or video applications server
• Streaming content server
• Fax-on-demand server

Sure, some of these are similar and can roughly be grouped together, but at best you’ll get this down to semi-overlapping groups that center on two general areas: interactive media services and call or resource control. The point here is that in the VoIP world, we haven’t standardized architectures and naming conventions yet so we are left with technically vague terms like media server, media gateway, and the worst offender, softswitch (a marketing term we will not spend more time on this except to note that it was intended to conjure up the image of a class 5 switch being displaced by a software blob that runs these media servers and media gateways but has become so overloaded that it has completely lost any technical meaning it once may have enjoyed).

Interactive Media Service: Media Servers

On the other hand, there is another kind of media server that actually contains DSP resources that it uses to process speech or video (and perhaps one or more additional form of media). These may be involved with generating and receiving DTMF tones, executing the logic of an IVR system, converting text-to-speech or handling streaming or document content in response to speech or DTMF input. Or it may orchestrate multiway call traffic, conference calls, handle translation between codecs, or even fax processing. Media servers of this class may provide VoiceXML interpretation for interactive, dynamic voice applications.

Call or Resource Control: Media Servers

This class of media server is responsible for managing communications resources at a higher level, such as handling call control while managing media gateways that have DSP and other gateway resources for the actual media manipulation. Most Media Servers support VoIP protocols but are likely also to support others as well, such as digital voice or video trunks, or even analog voice through media gateways. Examples of this kind of media server include call control servers from PBX vendors that control separate gateways, voice processing servers that manage and redirect DSP resources located elsewhere, and call distribution systems that manage off-board call handling resources such as switches and IVR systems.

The H.323 Gatekeeper

This gatekeeper is the manager of one or more gateways, and is responsible for providing address translation (alias to IP address) and access control to VoIP terminals and gateways. A gatekeeper acts as the central authority for other gateways, allowing an administrator to quickly and authoritatively roll out changes across a voice network. Gatekeepers limit the number of calls at a given time on a network by implementing control over a proxy. A gatekeeper works something like this: A user wants to make a call to another user at a different physical location, and his phone registers with a local gateway. The gateway then passes on his call information to the gatekeeper, which acts as a central hub to other gateways and users. The gatekeeper then passes call setup information to the gatekeeper at the other office, which in turn hands it to the appropriate destination gateway, and finally to the desktop of the called party. Many call control media servers include an H.323 gatekeeper.

Registration Servers

In a traditional PSTN or PBX switching system, where each user is at a fixed location, usually tied in place by copper wires, routing calls is (relatively speaking) simple. So-called find-me/follow-me services on PSTN or PBX switches can add PSTN mobility. Forwarding or extension-to-cellular features can increase this sense of mobility, but all these solutions require active user programming or rely on fixed forwarding algorithms and are rooted in the PSTN.

But with VoIP, a user can be geographically located virtually anywhere on the planet (as long as minimum QoS conditions are present). A registration server acts as a point of connection for mobile users. Johnny can log in to the registration server from his hotel room in Amsterdam with an unknown IP address and the registration server will let the gateways know where to route his traffic. That way, Johnny can keep the same phone number no matter where he is physically located. A similar example can be seen with instant messaging networks. A user can log in using his screen name from home and be reachable to the same users as if he had logged in from work. In the H.323 world, registration is a function of a gatekeeper; however, this can be a separate function in the SIP realm.

Redirect Servers

A SIP redirect server acts as the traffic light at the VoIP intersection. Very much like a web page with a redirect tag built in, a redirect server will inform a client if the destination the caller is trying to reach had changed. Armed with the updated information from the redirect server, the client will then rerequest the call using the new destination information. This takes some of the load off proxy servers and improves call routing robustness. In this way, a call can quickly be diverted from a proxy, rather than require the proxy to complete the connection itself.

Media Gateways

A gateway is a device that translates between protocols in general by providing logic and translation between otherwise incompatible interfaces. A voice or media gateway in particular tends to translate between PSTN (trunking) protocols and interfaces and local line protocols and interfaces (though that’s not universally true). In addition, the potential protocols and interfaces that a voice gateway now might support include Ethernet and VoIP protocols as well. The voice gateway could have H.323 phones on one side and an ISDN trunk on the other (both digital) or a VoIP phone on one side and an analog loop to the carrier, or even VoIP on both sides (say, H.323 to the station and SIP trunking to the carrier). The point is that there are literally hundreds of different equipment classes that all fall under the voice gateway moniker and thousands of classes that fall under gateway to begin with.

One class of VoIP media gateway connects traditional analog or digital phone equipment or networks to VoIP equipment or networks. A simple home-user implementation of a VoIP gateway like this is an ATA, or Analog Telephone Adaptor. At a minimum a VoIP media gateway will have both a phone interface (analog or digital) and an Ethernet interface. For an ATA, a regular analog phone is connected to the adaptor, which then translates the signal to digital and passes it back over the Ethernet. Of course, media gateways can get much more complex than this. PBX vendors have split out the line-card cabinet portion of their product and recast it as a media gateway, with the gateway under the control of a media server. IP routing companies have added analog and digital voice/video interfaces to routers and recast them as media gateways. And in many respects these products do contain overlapping functionality even though they may not be equivalent.

Firewalls and Application-Layer Gateways

Within a firewall, special code for handling specific protocols (like ftp, which uses separate control and data paths just like VoIP) provides the logic required for the IP address filtering and translation that must take place for the protocol to pass safely through the firewall. One name for this is the Application Layer Gateway (ALG). Each protocol that passes embedded IP addresses or that operates with separate data (or media) and control streams will require ALG code to successfully pass through a deep-packet-inspection and filtering device. Due to the constantly changing nature of VoIP protocols, ALGs provided by firewall vendors are constantly playing a game of catch-up. And tests of real-time performance under load for ALG solutions may reveal that QoS standards cannot be met with a given ALG solution. This can cause VoIP systems to fail under load across the perimeter and has forced consideration of VoIP application proxies as an alternative.

Application Proxies

A Proxy server acts as a translator for transactions or calls of different types. If Johnny’s phone speaks IAX and Jen’s phone speaks only SIP, the proxy sits between them and translates the message as necessary Even if both sides speak the same protocol, be it HTTP or SIP, there are security or NAT or other boundaries that call for either a proxy or packet manipulation in an Application Layer Gateway (ALG) within a firewall. The benefit of an application proxy is that it can be designed specifically for a protocol (or even a manufacturer’s implementation of a protocol). In addition to allowing boundary traversal, a proxy can also be used as a means of access control, ensuring that a user has the rights to place a call before allowing it to proceed. And the best proxies can even guard against malformed packets and certain types of DoS attacks. Depending on the complexity of your call requirements, a proxy may be integrated into a PBX or Media Server, or it may be an entirely different piece of hardware.

Endpoints (User Agents)

In a phone system, an endpoint on the network was known as a terminal, reflecting the fact that it was a slave to the switch or call-control server. But today’s endpoints may possess much more intelligence, thus in the SIP world the term User Agent is preferred. This could be a hardware IP telephone, a softphone, or any other device or service capable of originating or terminating a communication session directly or as a proxy for the end user.

Softphones

With the advent of VoIP technology, users are able to break free of classical physical restrictions of communication, namely the special-purpose telephone terminal. A softphone is a piece of software that handles voice traffic through a computer using a standard computer speaker and microphone (or improved audio equipment that is connected through an audio or multimedia card). Softphones can emulate the look and feel of a traditional phone, using the familiar key layout of a traditional phone and often even emulating the DTMF sounds you hear when you dial a call. Or it may look more like an instant messaging (IM) client, and act like audio chat added to IM.

In fact, a softphone doesn’t even need a computer microphone or speaker: my favorite doesn’t need to send media through the computer at all in telecommuter mode—it just uses H.323 signaling to tell my media server which PSTN number (or extension) to dial for sending and receiving the audio. This lets me turn any phone into a fully featured clone of my work extension without regard to QoS available to me on my Internet connection.

Because a soft phone resides on a PC, the principle of logically separating voice and data networks is defeated as the PC must reside in both domains. You will need to consider this trade-off as you design appropriate security policy for your VoIP network, although the long-term trends favor voice-data integration, so at best maintaining physical separation can be only a temporary strategy.

Consumer softphones have exploded over the past few years and nothing is hotter than Skype in that space. Skype is the brainchild of the people who brought us the Kazaa file sharing framework. Utilizing peer-to-peer technology and an encrypted signaling and media channel, Skype has proven to be both easy to set up and use securely by end users, while simultaneously being a thorn in the side of network administrators. Because it aggressively jumps past firewalls to create call traffic, it is considered to be a threat by many enterprise security groups.

One of Skype’s major enhancements over instant-messaging-based voice is its superb codec, which is actually better than that used within traditional telephone infrastructure. This provides superior call quality when contacting other Skype users. Another major benefit of Skype is the ability to reach any phone in the PSTN by way of SkypeOut gateways. With its PSTN gateway, Skype has become an attractive alternative for small overseas call centers and other Internet businesses.

Are You Owned?—Consumer Softphone Gotchas

Many consumer-oriented softphones contain advertising software that “phones home” with private user information. Several popular softphones (such as X-Lite) store credentials unencrypted in the Window’s registry even after uninstallation of the pro-gram. Softphones require that PC-based firewalls open a number of high UDP ports as part of the media stream transaction. Additionally, any special permissions that the VoIP application has within the host-based firewall rule set will apply to all applications on that desktop (e.g., peer-to-peer software may use SIP for bypassing security policy prohibitions).

Also consider that malware affecting any other application software on the PC can also interfere with voice communications. The flip-side is also true—malware that affects the VoIP software will affect all other applications on the PC and the data services available to that PC (a separate VoIP phone would not require access to file services, databases, etc).

IM Clients

Instant messaging is perhaps the dominant means of real-time communication on the Internet today. IM’s roots can be traced back to the Internet Relay Chat (IRC) networks, which introduced the chat room concept but did not track online presence and never reached the popularity of IM. Just as IM is the next logical step from IRC, voice chat is the next leap from text-based chat. Most of today’s most popular IM clients have included voice functionality, including AOL’s Instant Messenger, Yahoo! Messenger, and MSN Messenger. Skype took the opposite approach and created a chat client that focuses on voice as the star and text chat as an afterthought. Even Google jumped aboard the IM bandwagon, releasing Google Talk. Let’s take a look at these clients to see what makes them similar, and what makes them different.

AIM, AOL’s IM service, surely wasn’t the first on the scene, but it has the largest base of users. Initially AIM was limited to users of the AOL Internet service, but eventually it was opened up to the Internet as a whole. With the addition of a proprietary voice capability in late 1999, AOL was a VoIP pioneer of sorts. (although voice chat was first available through Mirablis’s ICQ). Yahoo! Chat jumped aboard the voice bandwagon soon after, and Google’s more recent client has included voice from the beginning. In 2005, Yahoo announced interoperability with Google and MSN (who also has a voice chat plug-in for messenger that is also used with its Live Communication Server product). In addition, Microsoft’s popular Outlook e-mail client (and entire Office suite in the case of LCS) can be linked to Microsoft Messenger. Also worth mentioning is the Lotus Domino IM client that competes with Microsoft LCS in the enterprise instant messaging (and presence) space, as well as Jabber, which can be used to tie together both public and private IM services using the XMPP protocol.

Google Talk is the newest comer to the IM game. Though Google Talk is still in its infancy, it stands to succeed due largely to a philosophical stand point, embracing open standards over proprietary voice chat. Google Talk aims to connect many different voice networks over a series of peering arrangements, allowing users to minimize their need to run several IM clients. Like Skype, Google seeks to bridge traditional phone calls with Internet telephony, promising to federate with SIP networks that provide access to an ordinary telephone dial tone. Google recently released a library called libjingle to programmers, allowing them to hack new functionality into Google Talk. It will be interesting to see where Google takes Google Talk in the future.

Video Clients

Most of us can probably think back and recall seeing episodes of The Jetsons when we were younger. Or pictures of the AT&T PicturePhone from the 1964 World’s Fair. Movies have all but promised these devices to be a staple of every day life in the future. And for decades, the video conference has been pushed by enterprises seeking to save money on travel (though investments in video conferencing equipment tend to sit around gathering dust). Live video on the Internet has its adherents, and today we see yet another wave of marketing aimed at the business use of video. So, will video finally take off around VoIP just like audio, or is there something different going on here?

The video phone has been tomorrow’s next big technology for 50 years but the issue has been more sociological than technological. Certainly, popular instant messaging clients have included video chat capabilities for some time now, although each client typically supports only video between other users of the same client or messaging network. And although it always gives me a kick to see someone else announcing that they’ve solved the gap with technology, the point is well taken that video is here to stay in VoIP systems—even if it doesn’t get as much use as VoIP.

The latest on the video bandwagon is the Skype 2.0 release. At only 15 frames per second and 40 to 75 kbps upload and download, Skype Video works well on a standard home DSL line or better. Other popular IM clients with video include Microsoft’s Messenger and Yahoo Instant Messenger. AIM now offers video as well.

H.323-based IP videoconferencing systems have been available in hardware and software from many sources for almost a decade at this point, so there’s no shortage of vendors in this space. And SIP video phones are available from many of these same vendors and from startup companies in the SIP space.

Wireless VoIP Clients

Over the past few years, an explosion of wireless VoIP solutions has hit the marketplace. Most of these solutions are immature and if broadly deployed can completely overrun the available bandwidth on 802.11b (or g) networks that were not engineered for high-density voice, even with QoS prioritization. And although 802.11a networks can handle higher wireless VoIP densities, they present other backward-compatibility issues of their own. And we haven’t even gotten to the security issues yet! Still, the promise of WiFi VoIP is tantalizing, and most enterprises that have deployed VoIP solutions seem to have experimented with it. The idea of a combined cellphone/WiFi phone (and maybe PDA too) seems just too compelling to ignore, even if power consumption issues sideline keep the concept sidelined in the short term.