Executive Summary

IP networks have supported voice communications for some time. Voice over IP (VoIP) services allow users to make calls between IP-based endpoints and to interconnect with the traditional public switched telephone network. VoIP applications use a variety of methods and protocols to manage connections and exchange media (i.e., the content of voice or video communications) over IP-based networks such as the Internet. In the majority of VoIP applications, connections are managed or controlled using one protocol or set of protocols, and the media is exchanged among the parties involved in the connection using a different transport protocol or set of protocols. The purpose of these separate connection control and signaling protocols is to allow the parties involved in the communication to establish, control, and terminate connections.  Many services that provide VoIP capability also support other forms of real-time media (video or screen sharing, for example).

This report uses the term VoIP impairment to refer to anything that prevents a VoIP application from being used in the manner desired by a user. An impairment affecting a VoIP service can occur anywhere along the data path, including in the end devices. For example, impairment may be the result of actions by a network operator, the VoIP provider itself, or the provider of a smartphone’s operating system. Impairment could likewise be the result of a poorly implemented network device or application, or may occur as a result of a configuration or misconfiguration of a home network. VoIP services can be rendered unusable if their quality is sufficiently reduced to prevent meaningful audio exchange between the participants, even if some VoIP traffic is still exchanged.

VoIP failure, as defined in this report, encompasses particular kinds of VoIP impairments that arise when VoIP calls cannot be established at all, or when no media is capable of being exchanged between VoIP endpoints. When network operators, VoIP providers, operating system vendors, or application store providers take steps that cause VoIP failures or prevent VoIP from being used, those steps are considered VoIP restrictions for the purposes of this report. The term VoIP impairments (plural) is used as shorthand for VoIP impairment, failure, or restrictions in this report. Issues related to interoperability between different VoIP services are out of scope.

This report discusses: (1) how VoIP works; (2) how VoIP may be impaired or restricted;   (3) methods for mitigating VoIP impairments; and (4) recommendations concerning VoIP impairment, failure, and restrictions. The report focuses on VoIP impairments that may occur in residential or mobile networks. This report makes no assumptions concerning the motivations behind actions that result in VoIP impairment, failure, or restrictions, or about the frequency or scale of such occurrences. 

There are a variety of technical causes of VoIP impairment, failure, and restrictions:

Port blocking. In the architecture of the Internet, communication between two systems is identified by five fields: (1) the source IP address, (2) the destination IP address, (3) the transport protocol in use, (4) the source port, and (5) the destination port used by the transport protocol. The pair of IP addresses representing two systems identifies all of the communication sessions between them, whereas the port number pair characterizes an individual communication session between the two systems. If traffic is prevented from flowing to or from the particular ports used by VoIP applications, VoIP failure can occur. This practice is known as port blocking.

Application-Level Gateways (ALGs). Many endpoints on the Internet sit behind a Network Address Translation (NAT) device. NAT allows multiple end devices within a local network (the network in a single home, for example) to share a single public IP address. NAT is challenging for applications such as VoIP that require reachability from the Internet. A variety of mechanisms have been developed for overcoming these challenges, including the use of Application-Level Gateways (ALGs), which can automatically detect traffic associated with particular VoIP services and help that traffic pass through NAT devices. However, ALGs may also affect traffic handling in such a manner as to impair the correct operation of other VoIP services.

Other network-based causes. The use of some network-based techniques that attempt to identify VoIP requests or VoIP traffic may result in VoIP impairment. These techniques may leverage the Domain Name System (DNS) infrastructure, deep packet inspection, or network-based flow policing and filtering that attempt to identify patterns of likely VoIP traffic.

Restrictions based on device, application, or application store. Actions taken on a device, in a VoIP application, or in an application store may restrict the use or functionality of VoIP applications. These examples often reflect business arrangements or agreements between application store providers, operating system vendors, device manufacturers, and/or mobile carriers.

When VoIP impairments occur, it may be very difficult for a user to solve the problem, even for technically sophisticated users. Whether a mitigation or workaround solution exists, and how difficult it may be to implement, depends on the mechanism that is impairing the VoIP connection. If mitigation options are unavailable, or if users lack the knowledge or willingness to pursue such, those users may be prevented from using VoIP altogether, or may need to switch to a different VoIP application. Mitigations available to application providers for dealing with VoIP impairment also depend on how the impairments are effectuated.

VoIP impairment, failure, and restrictions can create difficulties for VoIP users and may deter adoption of over-the-top VoIP services. VoIP impairments can also create difficulties for the operators of VoIP services and providers of VoIP applications, who may need to troubleshoot or work around impairments (where possible) to enable or restore their users’ connectivity.

BITAG’s Technical Working Group recommends the following to minimize the occurrences and impact of VoIP impairment, failure, and restrictions:

• Network operators should avoid impairing or restricting VoIP applications unless no reasonable alternatives are available to resolve technical issues. Certain network management actions may have the effect of limiting or restricting VoIP traffic as a method of ensuring network integrity. Examples include port blocks or traffic limitations implemented when a customer uses a vulnerable VoIP service that can be exploited by attackers for the purpose of flooding the network with unwanted traffic. In adopting any approach that has the effect of limiting the use of VoIP, network operators should seek to minimize the impact of the approach on legitimate VoIP use.

• VoIP-related ALGs in operator-supplied home routers should minimize their impact on traffic other than the operator’s VoIP service where possible. VoIP-related ALGs can interfere with some VoIP services while attempting to facilitate NAT traversal for other VoIP services. Because of these problems, BITAG recommends that VoIP-related ALGs in operator-supplied home routers should either allow the VoIP-related ALGs to be disabled for customers who do not subscribe to the operator’s VoIP service or minimize or avoid impact to independent VoIP services and all other traffic not associated with the operator’s own VoIP service. Where possible, VoIP-related ALGs in operator-supplied home routers should be disabled by default. ALGs for real-time applications (including VoIP) can be problematic for services other than VoIP, but recommendations concerning ALGs more broadly are outside the scope of this report.

• Manufacturers of home routers should disable VoIP-related ALGs by default. Some consumers purchase their home routers from retailers rather than from network operators. To limit the impact of VoIP-related ALGs on VoIP services, home routers sold to consumers should have VoIP-related ALGs disabled by default.

• Port blocking rules in consumer equipment should be user-configurable. The port blocking (or firewall) rules of consumers’ home routers should be user-configurable, whether the routers are provided by the ISP or purchased separately by the consumer. By making these rules user-configurable, technically sophisticated users may be able to eliminate port blocks that prevent them from using VoIP services. It is recommended that the documentation provided with the consumer equipment inform the consumer that port blocking or firewall rules have been implemented, the default ports blocked, and how consumers can modify those rules.

• If network operators intentionally use network policies or practices that impair or restrict VoIP, they should provide disclosures about those policies and practices and provide communications channels for feedback. BITAG recommends that network operators disclose their policies and practices that may or could result in VoIP impairment, failure, or restrictions. The information should be readily available to both customers and non-customers alike. For example, such policies could be provided on the operator’s public-facing web site or on a page dedicated to summarizing or describing the ISP’s network management practices. If specific VoIP applications are impaired or restricted, those applications should be listed by name, along with a brief description of the reason for the impairment or restriction. BITAG also recommends that ISPs provide a communications channel or other clear method for application providers and consumers to discuss the impact of VoIP impairment, failure, and restrictions, and possible mitigations.

• Application developers should design VoIP applications to be port-agile where possible. BITAG recommends that VoIP application developers design VoIP applications and services to be port-agile where possible. Applications designed to tolerate random source ports or to allow port selection to be user-configurable are better able to avoid VoIP impairments that result from port blocking or contention between multiple services for the same port. Whether particular applications can be re-designed to be port agile may depend on whether re-designed versions of the application can be made compatible with existing versions or other existing applications.