Communications Over VoIP Networks

When terminal devices like IP phones wish to communicate, call processing software like Cisco CallManager is typically involved in the process. While some calls will be between two IP phones on the same subnet, some may be on a remote IP network (for example, across a WAN link), while others will be to traditional phones connected to the PSTN. When two users with IP phones on the same subnet need to communicate, a router does not need to be involved, consistent with how IP operates. However, when the users are located on different subnets, a router (or Layer 3 switch) must be involved in order to route the IP-based voice traffic from one subnet to the other. In this case, the router used between the subnets does not need to be voice-enabled. Instead, it will simply route traffic across the network as it would any IP packets. Only the third situation requires a voice-enabled router – when a user on the IP network needs to communicate with users on the PSTN. In this scenario, a router that includes a voice module is needed to convert between IP and voice in one direction, and voice and IP in the other.

In order for a router to properly route voice traffic across an IP network or to an external user connected to the PSTN, dial peers need to be configured on the router. Remember that users using an IP phone will not be dialing the destination IP address that they wish to reach. Instead, they will be dialing a complete phone number or extension number associated with the user they wish to reach. The configuration of dial peers associates a phone number or extension number with an IP address or the voice port to which the call should be forwarded. For example, if a user wishes to reach another user on the IP network at extension “1234”, a dial peer (specifically, a VoIP peer) would be configured on the router mapping that extension to the destination IP address. Similarly, if a user needed to connect to someone on the PSTN, the phone number (usually a small portion of the number) could be configured in a dial peer (known as a plain old telephone service or “POTS” peer) to specify that the traffic should be forwarded out of a voice port on the router, which may be connected to a PBX or directly to a PSTN trunk link.

One of the advantages of configuring dial peers is that an administrator has a high degree of control over the entire call-routing process. For example, in order to reduce costs, an administrator could configure a dial peer such that when a user in the Toronto office needs to connect to PSTN user in Frankfurt, the call is first routed over the IP WAN to the Frankfurt office, where a voice-enabled router dials the (now local) call to the Frankfurt PSTN. An obvious advantage in this scenario is that the long distance changes associated with originating the call in Toronto are reduced to a local call. In the same way that both POTS and VoIP peers can be configured, so can dial peers for both VoFR and VoATM.

Outside of helping to route calls along the correct path, dial peers are also used to apply different attributes to the various “call legs” that a transmission passes over between the source and destination devices. A call leg is simply the logical path between voice gateways (such as a router) or between a gateway and destination device. Examples of attributes that might be applied to a particular call leg include the codec used, QoS settings, and so forth. You will learn more about codecs and QoS settings upcoming articles.

Ultimately, the process of routing a call from a particular source to the correct destination is somewhat similar to a traditional voice call on the PSTN. When a user picks up an IP handset, the local gateway (such as the Cisco router) provides the user with dial tone. As the user keys in the number they wish to reach, these digits are forwarded to the gateway, which collects them until the appropriate dial peer can be identified. Once identified, the call is forwarded along the call leg to the next gateway (or destination or PSTN switch). At the most basic level, this is similar to how a PSTN switch or PBX makes forwarding decisions on a traditional voice network.

Author: Dan DiNicolo

Dan DiNicolo is a freelance author, consultant, trainer, and the managing editor of He is the author of the CCNA Study Guide found on this site, as well as many books including the PC Magazine titles Windows XP Security Solutions and Windows Vista Security Solutions. Click here to contact Dan.