Building Residential VoIP Gateways: A Tutorialby T Y Chan and Debbie Greenstreet,Glenn Yancey and Kim Devlin-Allen,David Jarrett and Keith Buchanan,Sophia Scoggins PhD,Matt Harvill and Demetri JobsonVoIP Business

Building Residential VoIP Gateways: A TutorialPart One: A Systems-Level Overviewby T Y Chan and Debbie Greenstreet,VoIP Group,Texas Instruments IncorporatedWhile voice-over-IP (VoIP) products have been deployed in the market for over sevenyears, recent announcements by service providers such as Vonage, AT&T, Sprint andothers have created a flurry of activity by consumer equipment manufacturers racing toroll out residential VoIP gateway products. These low-cost devices are usually standaloneboxes that provide VoIP functionality for POTS (plain old telephone system) via abroadband modem (usually cable or DSL). They serve as a bridge between theTMD/analog POTS world, and the IP-centric, packet-based world of the Internet.As with most consumer products, their designers are usually faced with meetingaggressive product cost targets along with tight development schedules. The productfeature shopping list often includes features not only specific to the basic VoIP gatewayfunctionality but to other ancillary functions as well. These include data bridging androutings, such as found in common residential router products, emerging voice andsignaling security features such as voice encryption and IPSec, and quality of service(QoS) features necessary to troubleshoot and maintain residential VoIP services.This article is the first in a series intended to assist engineers by providing detailed designconsiderations for all major portions of VoIP residential gateway products. This partserves as a functional overview of the major components often required in today’s VoIPresidential gateways. It goes into detail about the key elements necessary for a qualityvoice over IP call, and highlights some of the design considerations of the telephonycircuitry (which will be explored in additional detail in a subsequent article).Overviews of the security, data routing and QoS monitoring elements are provided aswell, to serve as an introduction to more detailed design analyses that will follow insubsequent articles.

Mimicking POTSFig. 1: Network’s-Eye View Of A VoIP CallSince the majority of today’s installed base of handsets are still POTS-type units, mostVoice over IP calls originating from customers premise equipment (CPE), come from aPOTS phone connected to a voice gateway. The unit at the remote location could beanother VoIP CPE device or simply a POTS phone connected to the PSTN. The flow of asample VoIP call through the network is depicted in Fig. 1.Of course, for any VoIP system to be successful, it must first provide the equivalentexperience that end users have grown accustomed to with current POTS systems. Toreplicate the user’s traditional interface with the PSTN, tone generation and detectionfunctions are necessary. Dialed digits must be accurately collected and replayed at thereceiving end to successfully execute a call.Tone generation/detection is not only necessary at the beginning of the call. Tone-drivenfeatures like voicemail and calling card functions, tone generation/detection must behandled mid-call as well. Therefore the VoIP processing must also support the ability tosuccessfully transmit dual-tone multiple-frequency (DTMF) tones in-band; however,vocoders with compression may distort these tones. To avoid these potential distortions,designers need to turn to advanced techniques such as IETF request for commentRFC2833 when passing tones in conjunction with the use of low bit rate vocoders. A tonegeneration function is necessary to provide depressed tone playback and call progresstones. The ability to detect tones and properly switch processing for fax and data modemsignals is also a requirement, as all types of telephony currently available on the PSTNmust be supported.

Dealing with EchoCombating problems with echo are an essential element to VoIP adoption in thetraditional telco world. As VoIP moves to replace the PSTN system, it must adopt robustecho-cancellation techniques to meet the demands of packet networks.Echo is present in conventional POTS networks, and the PSTN employs echo cancellersthroughout the system. Line echo is caused when a connection involves conversionbetween a four-line to a two-line telephony hybrid. Echo is generated toward the packetnetwork from the telephone network.Fig. 2: Block Diagram Of A TDM-IP GatewayPSTN specifications dictate that echo cancellation functionality is necessary when thedelay exceeds 50 ms. However, because the IP network portion of the VoIP solutionalmost always adds more than 50 ms of round trip delay, line echo cancellation isessential when VoIP solutions interface to the PSTN. To do this, the echo canceller, asshown in Fig. 2, compares the voice data received from the packet network with voicedata being transmitted to the packet network. The echo from the telephone network isremoved by a digital filter on the transmit path into the packet network.The echo-cancellation tail length, that is the length of the echo required to be cancelledby the processor, varies among different VoIP applications. The tail-length requirement isdetermined by the distance between the gateway equipment (residential gateway) and thefour-to-two line hybrid. Typically this ranges from an 8-ms tail size for residential/SOHOapplications to 32 ms, compared to up to 128-ms tail sizes for carrier applications.Since most phone calls established via residential VoIP gateways will, at some point,terminate to PSTN equipment, line echo cancellation is required. For residential

gateways, a typical length of 8- to 16-ms echo-cancellation tail-length capability isusually sufficient. As a minimum quality benchmark, the echo-cancellation functionalityshould be compliant to ITU G.165 and G.168 standards.Voice EncodingVoice encoding is necessary to convert the analog signal to voice packets. This oftenincludes compression to reduce the 64-kbit/s stream produced by G.711-PCM-encodingstream (used by most traditional PSTN trunk lines) to a lower bit rate for more efficienttransport across both the network and the subscriber’s "last mile" link.Typical vocoders used in VoIP systems today include G.729ab and G.723.1. TheG.729ab vocoder offers data rates as low as 8kbit/s and the G.723.1 at 5.3 and 6.3 kbit/s.The tradeoff between these low bit rate vocoders and G.711 is reduced bandwidthutilization vs. slightly higher voice quality. The G.729a is an optimized implementationof the very common G.729 voice compression algorithm. It is important to note thatG.729 is the base algorithm and that G.729 is interoperable with G.729a. G.729ab, theappendix B portion of this algorithm, incorporates the voice activity detection function inthe vocoder itself.Detecting VoiceVoice activity detection (VAD) and related silence suppression, whether incorporated inthe codec or as an external software function, should also be supported as a configurable(enable/disable) feature in VoIP designs. The VAD monitors the received signal for voiceactivity. When no activity is detected for a specific period of time the software preventsunnecessary packetization and subsequent transmission of silence. This function alsomeasures the idle noise characteristics of the telephony interface and noise measurementsare subsequently relayed to the receiving gateway. Comfort noise generation (CNG), theplayout of low-level background noise to the receiver, is recommended for userconfidence in the call connection. If the call appears too quiet, users may anticipate thatthe call has been disconnected.Residential gateways must also support the use of fax relay techniques. Fax relay offersbandwidth reduction and a more robust, reliable means of connecting fax over IP calls,and is a very popular feature for SOHO and SMB equipment. Fax relay functionalityinvolves demodulation of the facsimile scan data, encapsulation into IP packets, andsubsequent demodulation of the fax IP packets at the receiving gateway. This requiressupport of the T.30 fax protocol implemented between the fax machine and the VoIPgateway, as well as T.38 fax IP packet encapsulation for IP transmission.

POTS interfacesResidential VoIP gateways interface to traditional telephony equipment through FXSsignaling to a pulse code modulation (PCM) interface. This interface receives PCMsamples from an analog codec interface and forwards them to the appropriate functions,such as those described above. Conversely, the interface forwards processed PCMsamples received from the DSP to the digital interface. The PCM interface performscontinuous re-sampling of output samples to avoid sample slips.PlayoutWhen voice and fax samples have been processed, they must be packetized. VoIPsystems typically employ real-time packets (RTPs). On the receive side a voice playoutunit is necessary to buffer received voice packets and forward them to the vocoder forplayout to the user. This playout unit also serves as a jitter buffer/manager to queueseveral packets, avoiding packet under-run or over-run.Implementing The FeaturesThe features described above are typically implemented in software, usually on a DSP.They can, however, be implemented in a RISC processor. This is advisable only when theadditional processing requirements for the typical RISC functions are minimal. ForRISC-only VoIP architectures, the available CPU cycles (MIPS) must be carefullymanaged between voice processing and network/telephony signal processing. Thefunctions described so far represent the telephony signal processing tasks required forsupporting VoIP media streams. The VoIP gateway must also support signalingprotocols, for both the telephony side and the packet side of the gateway.Packet And Telephony Network SignalingTranslation of the telephony signals to packets is only a part of the VoIP gatewaysolution. A gateway must also support telephony control signals, such as on-hook andoff-hook functions as well as network control signals or protocols such as SessionInitiated Protocol (SIP) -- both of which place very different demands on the hostprocessor and its software. There is a comprehensive set of processing tasks that aretypically executed on a RISC processor that translates the telephony signals/protocols tothe packet protocols and vice versa.

Analog Phone And PSTN interfacesFig. 3: Software Functions In A Typical VoIP GatewayIn most applications, a software-based state machine-like service that serves as a callcontroller handles these functions (See Fig. 3). The call control executes the necessaryfunctions through a stage of each call in the gateway. Another critical element of thesignaling process is the network protocol stack itself. SIP is a very popular protocol forthe residential gateway market; however there are some deployments of Media GatewayControl Protocol (MGCP) and H.323.Supplementary Services And Device ProvisioningVoIP gateways used in residential applications require the support of functions typicallyavailable in phone services today. This includes features such as call waiting, callforwarding, visual message waiting indicator and call transfer. Software is required tointerpret these commands from the network and execute the function through the gatewayto the telephone.

As a remote device in the service provider network, the residential gateway must be ableto be configured either on premises or remotely, but not require separate monitors orother equipment. This configuration requires software in the gateway to accept andprocess the provisioning and it is desirable that the user interface be simple and easy touse. This provisioning software is not insignificant. There is also a preference in themarket that residential gateway devices have the capacity for dual image (program load)storage, such that a program update can be downloaded without deleting the currentimage. This has impact on the overall software program design, as well as FLASH andSDRAM requirements.Fig. 3, again, shows a comprehensive view of the functional blocks required in acomplete VoIP residential gateway system. In addition, device drivers, Ethernetinterfaces, real time operating systems (RTOS), and IP stacks should not be overlooked.Fig. 4: A Foreign Exchange Station (FXS) Supporting A POTS PhoneTo connect the old reliable analog phone to the voice gateway, a Foreign ExchangeStation (FXS) is needed (see Fig. 4). In some applications, for outside calling using thePSTN, an FXO connection is needed (see later Fig. 5).The FXS consist of two parts, a codec and a SLIC. A codec is comprised of an ADC anda DAC. The ADC is used convert the analog signal from the analog phone into digitalsignal for transmission onto the VoIP network. The DAC is to convert digital signals toanalog levels to drive the analog phone. The sampling rate for ADC and DAC is usuallyin the 8-kHz range in order to achieve an audio bandwidth of 4 kHz. The Subscriber LineIC (SLIC) device emulates PSTN networks' voltage levels. It needs to detect on-hook,off-hook and generate ringing voltages which can range to 120 V. Its main function is tocombine the analog signal with the PSTN voltages.

Fig. 5: A Foreign Exchange Office (FXO) In A Residential GatewayFor the case for when a voice gateway CPE device needs to connect to a local phonecompany, this requires a Foreign Exchange Office (FXO) interface (fig. 5). The FXOconsists of a codec and the data access arrangement (DAA). The codec has the samefunctionality as in the FXS, while the DAA emulates a (POTS) phone. Its main functionis to remove the high voltage dc bias, and it only passes the analog ac signal throughwhen coming from the PSTN system, by applying a loop closure towards the PSTN.Uses for FXO ports are: Lifeline for power failure: used when there is no power to the voice gateway,which prevents calls from connecting to the packet network. In this case, theanalog phone (through FXS) connects directly to the FXO port through a relay Call redirection: used in the case when the subscriber dials a number that isunreachable through the packet network. In order to complete the call, the voicegateway will redirect the call through the FXO port. For a user-friendly gatewaythe CPE device dials the digit to the FXO port, which prevents customers fromhaving to redial the numbers Remote VoIP calling: when a customer is not at home, they can still make a VoIPcall by calling their home number through the PSTN network. The voice gatewaypicks up the call through the FXO port, and forwards it to the VoIP network.Additional details on FXS and FXO design circuitry will be discussed in upcomingarticles.Voice Gateway Data FunctionsIn CPE residential applications, the voice gateway is normally connected on the LANside of a broadband modem. If the household has more than one PC, the voice gatewaycan be a standalone device terminating IP connections by connecting to a router or hub. Ifthe home has a single PC, then introducing a voice gateway will involve creating a homenetwork and purchasing a router or hub. To ease the adoption of packet voice services,the most appropriate configuration for a voice gateway is to include a data routingfunction for connecting another PC. This way, the PC connects to the LAN side and the

modem connects to the WAN side of the broadband modem. In this type of configuration,the voice gateway should include data routing functionality.In deciding on the functionality and performance of data functions, it is useful tounderstand the application and configuration of the broadband connection. With theexception of VDSL, most residential broadband modems have capacities well below 50Mbit/s. Therefore, in designing a voice gateway, it is necessary to understand the enduser application in order to determine the appropriate price/performance goals. Some ofthe data functions that should be included are: Routing NAT, NAPT, dynamic and static Firewall DHCP client / server PPPoE TFTPIncluding these popular and useful functions makes the transition to VoIP easier for theconsumer to connect with their broadband service. Further, incorporating a voice gatewayinto a router or hub lowers the cost of ownership by not requiring customer to purchase aseparate box. When the household purchases another PC, a switch can be purchased tonetwork the PCs and voice gateway together.VoIP Security ElementsSecure voice communications is receiving a great deal of attention by service providersdeploying residential VoIP services. Secure VoIP implementations can leverage manysecurity elements already established for data communications. One of the key functionsof the current Internet security infrastructure is monitoring the integrity of the datatransmitted. This element covers both the assurance that the message between twoentities has not been tampered with, as well as the authentication of the recipient. Asimilar element is the support for non-repudiation, which is the rejection of a digitallysigned message (by secure keys). The confidentiality level of Internet security ensuresthat the recipient and the transmitter of the message are the only ones that may view thecontents of such a message. The authorization function of the security element suiteassures a network user access to a particular network service only upon verifying identity.Depending upon the level of security concern by end users or service providers, variouslevels of security features may be required. One common feature is encryption of thevoice payload itself. Another level of security might require encryption of the signalingmessages that establish the phone call.

Pulling it All TogetherWhile there is pressure to put together a residential gateway solution at the lowestpossible cost, it imperative that the components selected achieve optimal quality andperformance. The voice processing, network and telephony signaling, POTS interfaceand Ethernet interface are the minimum functions required to develop these gateways. Itis also essential to understand the types of supplementary services and the extent ofprovisioning functions required in order to ensure that the product is complete. Regionalconsiderations and programmability requirements will dictate the type, and ultimately thecost of the POTS interface. In addition, for residential gateways requiring advancedfeatures such as data-routing functionality or voice encryption or authentication, requireadditional processing power. If including these features, a designer must take care toensure that the proper amount of processing power and a sufficiently-flexible architectureis available to support such requirements. Subsequent articles in this series will go intofurther detail on the issues and tradeoffs of these features.About The AuthorsDebbie Greenstreet [email protected] is the product management director for TI'svoice-over-packet group. She is responsible for product definition and direction of voiceover-cable and SME voice gateway products. Debbie has more than 18 years ofexperience in the networking and telecommunications field, in hardware and softwaredesign, as well as program and product management at companies such as HyundaiNetwork Systems and Raytheon. She earned a BEE at the University of Virginia.T Y Chan [email protected] is a senior technical staff member with TI's voice-over-packetgroup, serving as the system engineering manager for VoIP customer premise equipmentproducts. Since joining TI in 1989, T Y has held various positions in the company,including engineering manager for DVD solutions and system manager for PCprocessors. He earned both a BSEE and MSEE at Bradley University.

Part Two: VoIP Telephony InterfacesBy Glenn Yancey and Kim Devlin-Allen,VoIP Group,Texas Instruments IncorporatedWhen developing a VoIP system, one key area of consideration is the interface to ananalog telephone. The designer must understand the telephony requirements that exist inthe PSTN, as they must also be supported in VoIP systems. These articles are intended toprovide engineers with design considerations for all major portions of their VoIP product.In this portion, we’ll focus on the two most common interfaces to a standard POTSphone: Foreign eXchange Subscriber (FXS) and Foreign eXchange Office (FXO). It willdescribe the functionality provided by FXS and FXO circuits, cover some history of FXSand FXO, discuss industry standards, and highlight some of the challenges designers mayface when supporting analog telephony interfaces on their VoIP residential gateway.FXS and FXO are common terms in the world of analog telephony, but what is thedifference between the two and why are they important in VoIP applications? In atraditional telephone connection over the PSTN, the telephone central office switch feedsbattery and provides ringing to the phone. The phone itself completes the tip/ring circuitto request service or answer a call from the PSTN. For calls placed over the Internet, theFXS circuit emulates the telephone central office switch. The residential gateway“pretends” to be the switch, providing both battery and ringing to the phone and detectingloop current. The FXO circuit, on the other hand, emulates a phone, providing loopclosure and detecting incoming ringing.Local Central OfficeForeign Central OfficeTipSwitchLocalSwitchRingCarrier SystemFXOAnalog orDigitalCarrier SystemFXSTipRingTipRingFig. 1: Dial Tone From A Foreign Central OfficeThe terminology of FXS and FXO came from the desire to enlarge local calling areas.Before 800 toll-free calling was available, business customers seeking alternatives toexpensive long distance charges were offered a foreign dial tone service. Carrier systems,first analog and then digital, were created to support this service, extending dial tone froma foreign central office (Foreign eXchange Office) to multiple local central office sites

(Foreign eXchange Stations). This application was one of the earlier uses for the FXOinterface and is responsible for the terminology that still exists today.Analog Phone And PSTN interfacesThe FXS circuit consists of two parts, a CODEC and a SLIC (Subscriber Line InterfaceCircuit). A CODEC is comprised of an ADC and a DAC. The ADC converts the analogsignal coming from the analog phone into a digital signal for transmission over the VoIPnetwork. The DAC converts digital signals to analog levels to drive the analog phone. Inorder to achieve an audio bandwidth of 4 kHz, the sampling rate for both the ADC andDAC is usually around 8kHz. The SLIC device emulates PSTN voltage levels. It mustdetect if the phone is on-hook or off-hook and generate ringing voltages up to 120 V.The circuitry for the FXO consists of a CODEC and a data access arrangement (DAA).The CODEC has the same functionality as in FXS, converting analog speech to digitalsignals, and vice versa. The DAA emulates a (POTS) phone. Its main function is toremove the high voltage dc bias, passing only the analog ac signal from the PSTN byapplying a loop closure towards the PSTN.FXO Mirrors FXSIn VoIP gateways the FXS circuit is the primary interface for establishing outgoing callsand receiving incoming calls over the packet network. In a central office application thetwo-wire SLIC interface on a POTS line card serves as the FXS interface. In CPEapplications, the FXS circuitry exists in the gateway, providing dial tone, battery currentand ring voltages and detecting loop closure from the phone. Because this switchfunctionality resides at the CPE level, a direct connection to the PSTN is not necessary.There are cases, however, when a connection to the PSTN is useful using the FXOinterface. It presents the same type of interface to the central office as an ordinary POTStelephone, with some improvements. Some important uses of the FXO port include: Lifeline for power failure: when there is no power to the voice gateway, thegateway is not able to connect to the packet network to place or receive a call. Inthis case, a relay can be used to connect the analog phone directly to the PSTN.When this situation occurs, the FXO circuit is intelligent and can detect a call is inprogress, preventing that call from being disconnected once power is restored. Call re-direction: when the packet network is unavailable due to networkcongestion, the FXO circuit can remember the number dialed by the subscriberand route the call through the FXO circuit to the PSTN, to complete the call. Thisprocess prevents customers from having to redial the phone number when thepacket network is down. Remote VoIP calling: when a VoIP customer is not at home, they can still makea VoIP call by calling their home number through the PSTN network. The voicegateway receives the call through the FXO port and forwards it to the VoIPnetwork.

Fig. 2: Basic FXS InterfaceFig. 3: Basic FXO InterfaceFigs. 2 and 3 show how the FXS and FXO interfaces provide some common functions,referred to as “BORSCHT” functions. The BORSCHT terminology is oriented towardsFXS functionality, while FXO tends to be a mirror image of some of these functions.

B: Battery feed function found in an FXS linefeed interface. The complementary functionin an FXO interface is battery sink. As seen in Fig. 3 a connection is made between thecentral office tip and ring leads by the FXO off-hook relay, with current limiting beingprovided by the FXO.O: Over-voltage protection must be provided by the FXO due to exposure to lightningand power cross conditions. The SLIC’s Tip and Ring inputs in the FXS circuit aredesigned to provide additional over-voltage protection.R: Ringing is provided by the central office, but the FXO must be able to detect ringingand forward this information. The FXS circuit must provide ringing to the phone. A lowvoltage ring signal generated by either the CODEC or SLIC is amplified by the SLIC andplaced on the local loop to ring the phone.S: Signaling refers to the ability of the FXO to receive on/off-hook information andpresent an off-hook on-command to the central office. It must also detect ringing andother conditions and transmit this information. The FXS must be able to detect on/offhook states, detect and generate DTMF tones, and generate signals for caller ID.C: Coding is a function of the CODEC devices that are part of both the FXS and FXOinterfaces. It refers to the A-to-D and D-to-A coding of the voice signal.H: Hybrid functionality is essential for stability and good voice quality and is equallyimportant in both the FXS and FXO interfaces. Echo functions are detailed below.T: Test is not normally an FXO function as automated maintenance and testing isprovided by the central office. However, because the FXS circuit bypasses the PSTN, therequired test and diagnostic functionality are included in the CODEC/SLIC.EchoThe importance of stability and good voice quality are essential whether a call is madeover the PSTN or packet network. The potential impact of echo is critical to the functionsof both the FXS and FXO interfaces. Note too, that special hybrid functionality isrequired in both cases within the CPE device to handle the various line impedances in theworld. Ordinary POTS telephones have relatively uncontrolled impedances between 200Ω and 400 Ω. Since the current from office to subscriber is two-wire with no gain added,the impedance variations typically encountered do not affect performance. Stability andline echo issues can arise, however, when a carrier system uses two-to-four wire voicefrequency (VF) hybrids on each end, as well as possible gain in the four-wire path.Line echo results from either the delayed “bleed-though” of the transmitted voice signalinto the receive path at the hybrid (2-wire to 4-wire conversion point) or from reflectionsin the local loop due to impedance mismatches. Line echo is always present in the PSTNand is not necessarily a problem. In fact, some of your telephone’s transmit signal iscoupled into the receive path in order to generate sidetone. Sidetone lets the speaker hearhis or her own voice in the receiver. Without sidetone, the speaker would be unsure if heor she was being heard on the other end, and could make for an awkward conversation.

When uncontrolled, however, excessive line echo can affect a caller’s experience in twoways: The louder the echo, the more disruptive it will be during a voice call. Manytimes low levels of echo are present on the line, although they are not detectableby the user. The length of delay of the echo also greatly affects voice quality. This delayrepresents the time that elapses between when the user speaks, and when he or shehears their echo. Round trip echo delays greater than 25 ms will begin to affectvoice quality.The main function of the hybrid circuit that completes the 2-to-4-wire conversion andvice versa is to limit the amount of outgoing transmit signal that “bleeds” into theincoming receive path. As a result of transhybrid imbalance (hybrid componentimperfections, impedance mismatches, etc.), some amount of Tx signal always gets intothe Rx path (see Fig. 4).Tx PortLocal loop (Tx Rx)HybridEcho bleed-through in the hybrid dueto transhybrid imbalanceRx PortFig. 4: Line Echo At 2-To-4-Wire ConversionIn addition to the echo caused by transhybrid imbalance, hybrid termination impedancemismatches can also cause line echo. If a line is not correctly terminated with itscharacteristic impedance, echoes will be generated. This echo is a result of the incomingsignal from the 2-wire local loop hitting the hybrid termination resistance and reflectingback down the line (Fig. 5). Improperly terminated CPE equipment such as phones ormodems can also generate echoes in the local loop.Echo due to impedancemismatches at 2-wireinterfaceTx PortHybridLocal loop (Tx Rx)Rx PortFig. 5: Line Echo At The Local Loop

To get a bett

throughout the system. Line echo is caused when a connection involves conversion between a four-line to a two-line telephony hybrid. Echo is generated toward the packet network from the telephone network. Fig. 2: Block Diagram Of A TDM-IP Gateway PSTN specifications dictate t