For small voice networks with only a few dozen phones that exist on a single site, design considerations for digital signal processors (DSPs) will probably not keep you up at night. In fact, you may never have to think about them at all! But for larger multi-site networks, the placement of your DSP resources is important, since when not placed appropriately they could interfere with conferencing performance. In this article, we outline what you need to know to design your network so DSPs work the most efficiently for you.

DSPs are the specialized hardware that employ the mechanisms of voice digitization and encoding in VoIP communications, but they are not limited to digitizing voice. DSPs multiplex, encode, transcode, and introduce a series of voice-specific features that make your conversations more pleasant and productive. You can think of them as the heart of VoIP.

Conferencing is arguably the most resource-intensive process that DSPs perform and can introduce problems in multisite deployments. The location where the multiplexing takes place affects the network as well as the resources being used. For example, for a small number of participants, the DSP of the initiating phone plays the role of the conference bridge, often bridging between three to five participants. In this case, all participants send and receive their voice packets between the conference originator and themselves, as shown in the following diagram.

In this scenario, phone 111 has initiated a conference call with phones 222 and 333. All phones exchange voice packets with the DSP in IP phone 111 and receive the multiplexed stream of packets from that phone.

However, for conferences with a larger number of participants, the DSP resources on an IP phone are not powerful enough to multiplex the required streams. In such cases, IP PBXs have their own DSP resources that can be used as a conference bridge. The following is an example of a larger conference where the IP PBX plays the role of the conference bridge.

Notice that the conference will have all voice streams converge at the conference bridge, or in other words, the DSP resources found within the IP PBX.

Things get even more complex when you have multi-site deployments. As an example, take a look at the following scenario where four phones, two at each remote site, are participating in a conference.

In this situation, the conference bridge is found within the voice gateway at one of the two sites. For an evenly balanced conference with two phones at each site, this is fine. However, imagine a situation like this:

In this case, phone 777, which is the conference initiator, is using the conference bridge at the remote site. This means that the WAN link is saturated with four streams of voice packets from the other participants, an arrangement which is inefficient. In this scenario, the other voice gateway would be a better choice for conference bridge.

The choice of which device to use as a conference bridge is usually part of the configuration of each phone connected to the IP PBX. The conference initiator determines which device is to be used as the conference bridge. The appropriate bridge choice should be configured based on expected usage.

Other design considerations

Some additional considerations for DSPs include:

• Make sure your voice gateways have sufficient DSP resources for transcoding. Examine the specifications of the devices before you purchase them, making sure they provide enough DSP resources for your expected usage.
• Ensure that you purchase high-quality endpoints that incorporate decent DSPs. This is usually evident in device datasheets that indicate a variety of supported codecs.
  
  

Conclusion

Even though DSPs may not be given much consideration by VoIP network engineers, it is important to know what they are and how their performance and configurations affect your network. We hope this article has shed some light on this little discussed but important subject.

You may also like:

Customizing a VoIP deployment for your multi-site customer

Handling ICT system complexity through configuration management

VoIP troubleshooting resources