Reprints     Printer-Friendly    Email this Article    RSS        Font Size     What's This?

[Design Application]
RECOMMENDED READING:
  •  DSP Core's CLIW Breeds VLIW Performance

Implement A Single-Chip Multichannel VoIP DSP Engine


The VoIP engine's scalable design handles a full T1 trunk (24 channels) of compressed video or fax signals over an IP network.

Contributing Author  |   ED Online ID #3469  |   May 15, 2000

Article Rating: Not Rated

The Internet explosion has created an affordable communication pipe. It's not only facilitating e-mail correspondence and web browsing, though. Voice over Internet protocol (VoIP) communications is now garnering support as well.

Many packet-based voice technologies can be found in VoIP products, like VoIP gateways, voice-capable cable modems, IP phones, and PBXs. All of these new applications rely on DSP technology for multimedia processing. In fact, designers can implement a single-chip multichannel VoIP DSP engine that is scalable and can handle a full T1 trunk (24 channels) of compressed voice or fax communications over an IP network (Fig. 1).

VoIP systems carry the voice and signaling information that's required to interface telephony equipment to a packet network. Full-duplex real-time voice or fax communications are compressed by the VoIP DSP engine and encoded by a microprocessor into network-ready frames. UDP/IP headers are added to the compressed packets and then sent to the IP network. Packets received from the network are decoded by and fed into the VoIP DSP engine and decompressed. A dynamic jitter buffer automatically compensates for network delay variation to enable smooth real-time voice communication. Voice processing includes echo cancellation, voice compression, voice-activity detection, and voice packetization.

The processor implements the industry-standard RTP/RTCP packet-streaming protocol, adaptive jitter-buffer management, and fax-relay support. It also executes the media gateway control protocol (MGCP) or any other IP call control stack. These very complex protocols can be licensed from protocol companies such as RadVision, or from VoIP chip/subsystems vendors like Audiocodes. These companies license portable C language software application libraries with all of the modules that are needed to support VoIP, including RTP/RTCP and the MGCP call control stack.

The MGCP Client Stack application library provides communication with a call-control entity. It supports the IETF MGCP protocol, and any IETF-compliant call agent can control it. MGCP assumes a call-control architecture in which the call-control intelligence is outside the VoIP gateway and is handled by an external call agent. MGCP commands, received from an external call agent through the IP network, are decoded and executed on a lower-level stack that accesses the VoIP DSP engine. MGCP commands create new connections, delete existing connections, modify connection parameters, and report call and connection status.

Designers have a number of VoIP DSP-engine architecture options at their disposal. As in any other situation, it's important to choose the DSP that best fits the application and customer requirements. Considering the increased drive for higher channel density (maximum number of channels/calls per chip), designers must focus on the voice-algorithm load.

Preprogrammed VoIP DSP Engine
It's possible to buy a standard DSP and write the software or purchase it from a third-party speech-coder vendor. This formidable task, though, requires a lot of effort. Instead, designers should employ preprogrammed VoIP DSP engines like the Audiocodes AC48XXX. These engines contain all of the algorithms and meet the tough real-time requirements. When designers face price pressures—which are usually associated with high-volume products—they should try an integrated solution with a DSP core and other peripherals in a single chip.

The VoIP DSP engine uses a DSP core, on-chip SRAM, and an interface to external memory to be cost-effective without compromising performance (Fig. 2). To avoid an unnecessary load on the DSP core, designers should include a DMA that autonomously transfers information from the pulse-code-modulation (PCM) interface to buffers in the external memory, and later from the external memory to the on-chip SRAM for digital signal processing.

When the signal processing is completed, the DMA moves the data back to the external memory and forwards the packetized data to the host interface at the microprocessor request. The DMA also performs the data transfers in the opposite direction for packets that are coming from the host interface and directed toward the PCM interface.

Carrying voice-over-packet networks creates new problems that didn't exist with traditional telephone networks, such as much longer network delays, lost voice packets, and echoes. A delay in VoIP applications comes from a combination of network and speech processing delays, which cause echoes and prevent fluent conversations. Network delays are a function of the capacity of the network and the packet processing. Speech-processing delays involve a combination of the actual compression and voice-frame collection. VoIP systems are able to solve this by implementing echo-cancellation algorithms.

IP networks may drop data frames. Data packets that contain voice are time sensitive. And unlike pure data packets, dropped packets can't be corrected through retransmission. This problem is addressed by "replaying" the last packet received during the interval when the lost packet was supposed to be played out.

The VoIP DSP-engine requirement set features various voice-compression algorithms with varying voice/audio quality and bandwidth efficiency, along with fax and data-modem capability. The fax and modem support is necessary to serve any call type, including fax and modem, rather then rejecting or disconnecting these types of calls. The requirement set is shown below:

  • Vocoders: G.723.1, G.729a, G726/727, G.711
  • Fax: V.17 group 3 fax relay
  • Modem: V.32bis
  • Echo canceller: G.165/G.168 compliance
  • Tone signaling: DTMF relay (EIA/TIA464 compliance)




<-- prev. page     [1] 2     next page -->

Reprints     Printer-Friendly    Email this Article    RSS        Font Size     What's This?


  • Network-On-Chip Tools Arrive for The Masses
  • Tackling System Design Challenges Through Early Verification
  • ESL Tools Take Center Stage As Designers Move Up
  • Parasitic Extraction Tool Targets Next-Generation Custom ICs
  • Synopsys Jumps Into ESL-Synthesis Pool
  • Verify Control Systems Before Committing To Hardware
  • You're Using How Many FPGAs?
  • Tool Up For The FPGA Blitz
    1) Build A Smart Battery Charger Using A Single-Transistor Circuit
    (185 views today)
    2) Hot Hands For Some Cool Rock: Motion Sensing Meets Audio Engineering
    (169 views today)
    3) Adjustment-Free Fan Controller For Under $1
    (114 views today)
    4) What's All This Transimpedance Amplifier Stuff, Anyhow? (Part 1)
    (109 views today)
    5) Science Fiction Meets Science Fact In Today's Robot Research
    (109 views today)
    ALL TOP 20







    POST YOUR COMMENTS HERE

    Name:

    Email:
    Rate this article:

     less useful more useful 
    1
    2
    3
    4
    5
    Your Comments:

    Enter the text from the image below




    Please refresh the page if you have trouble reading this text.
    (Acceptable Use Policy)
     
     

    PartFinder

    Find real-time pricing, stock status, same-day/next-day shipping options and more. Brought to you by Digi-Key. Go to PartFinder.    
    GlobalSpec

    PART SEARCH :
    Powered by: GlobalSpec - The Engineering Search Engine
    Sponsored Links

    Electronic Design Europe Electronic Design China EEPN Power Electronics Auto Electronics Microwaves & RF
    Mobile Dev & Design Schematics Find Power Products Military Electronics EE Events Related Resources