- Service Provider Voice Implementation Models
- Residential Applications: Voice over Broadband
- Small/Medium Business Applications (Voice over T1/E1/PRI/CAS)
- IP Trunks
- Session Border Controller (SBC) Models
- Voice Security in Service Provider Networks
- Common Issues and Problems When Deploying IP-Based Telephony Services
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
Common Issues and Problems When Deploying IP-Based Telephony Services
This section discusses some of the common issues encountered by providers when deploying IP-based telephony services over their IP infrastructure. The issues are ongoing and need to be maintained for the life of the VoIP service.
Convergence-Related Issues
As discussed earlier in the chapter, VoIP is primarily deployed on converged IP networks. Recall that a converged network is defined as a network capable of transmitting all types of traffic including data, voice, video, and images. Most existing SP IP networks have been designed to carry primarily data traffic and are geared toward data applications such as email, web traffic, and so on. The VoIP traffic is sensitive to time, the packets need to be delivered within a specific time period, and the network needs to facilitate this through various mechanisms. Deploying VoIP in such networks introduces new challenges for the SP's operations staff that needs to carefully monitor the health of their network and work closely with other groups in the company to provide VoIP continuity across the network. For example, in a DOCSIS/IP network, different groups are responsible for managing and maintaining the HFC/RF network, and another group is responsible for the IP network. Although these groups have totally different job responsibilities and technical background, they both need to work closely to provide quality service to the cable providers' customers.
Issues in Media Affecting Quality
Unlike circuit-switched voice networks that have dedicated paths and fixed bandwidth for every call, VoIP networks can share the same resources for data and voice traffic. In some cases, link overutilization or poor media characteristics (noise on RF links) can result in dropped or delayed packets.
VoIP traffic or packetized voice traffic needs to be sent at fixed intervals at the transmitting end so that the receiving end can predictably receive these packets and decode them. Because of serialization delay at the transmitting end, network delay, and jitter, these packets can arrive at the receiving end at varying intervals.
VoIP endpoints use dejitter buffers to compensate for variance in delay during media packet transmission through Real-time Transmission Protocol (RTP). If the dejitter buffers overflow because of excessive delay, this can impact voice quality so that it might sound like a robotized voice. Excessive packet loss can cause issues such as choppy voice quality.
Other voice quality issues can be caused by things such as codec mismatch, where each endpoint uses a different codec (for example, G.711 versus G.729).
Issues in Signaling Affecting the Services and Features
Voice signaling protocols such as MGCP, NCS, and SIP carry important information about how voice calls need to be set up, how resources need to be allocated, and how QoS needs to be provided to the voice traffic.
Network congestion and resource oversubscription can adversely affect voice-signaling protocols that can affect the services and features these protocols support. Voice signaling–related issues can also be caused because of improper network design and misconfigurations.
If voice signaling gets impaired, it can have a range of effects from delayed call setup to failed call setup, from loss of dial tone to one-way voice, and so on.
These issues are often caused by interoperability issues between equipment from different VoIP vendors. Even though they claim to be compliant with protocol standards, they can still have varying implementations of protocol stacks in their products.
IP Routing–Related Issues
SPs might deploy various routing protocols such as Open Shortest Path First (OSPF), Intermediate System–to–Intermediate System (ISIS), Border Gateway Protocol (BGP), and so on for providing IP connectivity across their infrastructure. These routing protocols carry network information that is used for calculating the most efficient path for carrying customer traffic through the SP network.
The failure of these routing protocols can result in a loss of IP connectivity or degraded service for the SP's customers. Such failures can severely impact VoIP traffic. If a link or node in the SP network fails, causing the routing protocol to reconverge or recalculate its routes, the voice traffic might be sent over a low-bandwidth link that can cause voice degradation. For this reason, the SP needs to carefully tweak routing protocol timers to make sure that the network can converge in a timely manner, minimizing the impact to VoIP traffic.
High Availability and Convergence for Business Continuity
A lot of non-Tier1 and non-Tier2 SPs might not implement redundancy in their network when deploying data-only applications. This becomes a critical issue when VoIP is deployed in such networks. A failed router or switch in the SP core network can cause loss of service to data and voice customers.
Therefore, it is critical for the SP to implement redundancy in the network so that a loss of a link or node does not result in loss of service to its users. Implementing redundancy in the network might involve deploying hardware and software with high-availability features. Redundancy is implemented at a device level where the hardware has active and standby components. If the active component fails, the standby can take over without causing a network outage. Redundancy is also implemented at a link level where multiple links provide connectivity to other network resources, so if a link fails, the other links can carry all the traffic. In some cases, the SP might also choose to deploy redundancy in the form of additional hardware that can take over if certain devices in the network fail. Redundancy can also be implemented in software, such as in routing protocol implementations, which can provide alternate routes through the SP network if the primary/best path fails.
The focus here is not the type of redundancy, or the various specific challenges, but the impact of the failures. Thus, effectively tracking key metrics can help in sustaining the VoIP service. These metrics can range from protocol to Layer 2/3 and h/w uptime metrics.