Challenges

Quality of Service

Because the underlying IP network is inherently unreliable, in contrast to the circuit-switched public telephone network, and does not inherently provide a mechanism to ensure that data packets are delivered in sequential order, or provide Quality of Service (QoS) guarantees, VoIP implementations face problems mitigating latency and jitter.

Voice travels over IP networks in packets in the same manner as data, so when you talk over an IP network your conversation is broken up into small packets. These voice and data packets travel over the same network with a fixed bandwidth. This system is more prone to congestion[citation needed] and DoS attacks[24] than traditional circuit switched systems.

Fixed delays cannot be controlled (as they are caused by the physical distance the packets travel), however some delays can be minimized by marking voice packets as being delay-sensitive (see, for example, DiffServ). Fixed delays are especially problematic when satellite circuits are involved, due to long round-trip propagation delay (400–600 milliseconds for links through geostationary satellites).

A cause of packet loss and delay is congestion, which can be avoided by means of teletraffic engineering.

The receiving node must restructure IP packets that may be out of order, delayed or missing, while ensuring that the audio stream maintains a proper time consistency. Variation in delay is called jitter. The effects of jitter can be mitigated by storing voice packets in a jitter buffer upon arrival and before producing analog audio, although this further increases delay. This avoids a condition known as buffer underrun, in which the voice engine is missing audio since the next voice packet has not yet arrived. When IP packets are lost or delayed at any point in the network between VoIP users there will be a momentary dropout of voice if all packet delay and loss mechanisms cannot compensate.

It has been suggested to rely on the packetized nature of media in VoIP communications and transmit the stream of packets from the source phone to the destination phone simultaneously across different routes (multi-path routing)[25]. In such a way, temporary failures have less impact on the communication quality. In capillary routing it has been suggested to use at the packet level Fountain codes or particularly raptor codes for transmitting extra redundant packets making the communication more reliable[citation needed].

A number of protocols have been defined to support the reporting of QoS/QoE for VoIP calls. These include RTCP XR (RFC3611), SIP RTCP Summary Reports, H.460.9 Annex B (for H.323), H.248.30 and MGCP extensions. The RFC3611 VoIP Metrics block is generated by an IP phone or gateway during a live call and contains information on packet loss rate, packet discard rate (due to jitter), packet loss/discard burst metrics (burst length/density, gap length/density), network delay, end system delay, signal / noise / echo level, MOS scores and R factors and configuration information related to the jitter buffer.

RFC3611 VoIP metrics reports are exchanged between IP endpoints on an occasional basis during a call, and an end of call message sent via SIP RTCP Summary Report or one of the other signaling protocol extensions. RFC3611 VoIP metrics reports are intended to support real time feedback related to QoS problems, the exchange of information between the endpoints for improved call quality calculation and a variety of other applications.

[edit] Susceptibility to Power failure

Conventional phones are connected directly to telephone company phone lines, which in the event of a power failure are kept functioning by backup generators or batteries located at the telephone exchange. However, IP Phones and the IP infrastructure connect to routers and servers which typically depend on the availability of mains electricity or another locally generated power source[26]. Therefore, most VoIP networks and the supporting routers and servers are also on widely available and relatively inexpensive uninterruptible power supply (UPS) systems to maintain electricity during a power outage for a predetermined length of time. The amount of time typically ranges from as little as an hour and up to three, depending on the quality of the UPS unit and the power draw and characteristics of the communications equipment.

[edit] Emergency calls

The nature of IP makes it difficult to locate network users geographically. Emergency calls, therefore, cannot easily be routed to a nearby call center. Sometimes, VoIP systems may route emergency calls to a non-emergency phone line at the intended department. In the United States, at least one major police department has strongly objected to this practice as potentially endangering the public.[27]

A fixed line phone has a direct relationship between a telephone number and a physical location. A telephone number represents one pair of wires that links a location to the telco's exchange. Once a line is connected, the telco stores the home address that relates to the wires, and this relationship will rarely change. If an emergency call comes from that number, then the physical location is known.

In the IP world it is not so simple. Your broadband provider may know the location where the wires terminate, but this does not necessarily let them map an IP address to that location. IP addresses are often dynamically assigned, so your ISP may allocate an address for you at the time you go online, or at the time your broadband router is powered on. Your ISP knows your IP address, but does not necessarily know what physical location that corresponds to. The broadband service provider knows the physical location, but is not necessarily tracking the IP addresses in use.

There are more complications, since IP allows us a great deal of mobility. For example many users use their broadband connection to dial a virtual private network that belongs to their employer. When you do this the IP address you are using will belong to the range of the employer, rather than the address of the ISP, so this could be many kilometres away or even in another country. Another example: if you use mobile data (for example a 3G mobile handset or USB wireless broadband adapter) then the IP address has no relationship with any physical location, since a mobile user could be anywhere that there is network coverage, even roaming via another cellco.

In short there is no relationship between IP address and physical location, so the address itself reveals no useful information for the emergency services.

At the VoIP level, a phone or gateway may identify itself with a SIP registrar by using a username and password. So in this case, the Internet Telephony Service Provider (ITSP) knows that a particular user is online, and can relate a specific telephone number to the user. However, they do not know how that IP traffic reached them, and as we have seen the IP address itself does not necessarily give us any location information. Today a "best efforts" approach will be to look up that user in a database to see what physical address they chose to associate with that telephone number, and this is clearly an imperfect solution.

VoIP Enhanced 911 (E911) is another method by which VoIP providers in the United States are able to support emergency services. The VoIP E911 emergency-calling system associates a physical address with the calling party's telephone number as required by the Wireless Communications and Public Safety Act of 1999. All "interconnected" VoIP providers (those that provide access to the PSTN system) are required to have E911 available to their customers[28]. VoIP E911 service generally adds an additional monthly fee to the subscriber's service per line, similar to analog phone service. Participation in E911 is not required and customers can opt-out or disable E911 service on their VoIP lines, if desired. VoIP E911 has been successfully used by many VoIP providers to provide physical address information to emergency service operators.

One shortcoming of VoIP E911 is that the emergency system is based on a static table lookup. Unlike in cellular phones, where the location of an E911 call can be traced using Assisted GPS or other methods, the VoIP E911 information is only accurate so long as subscribers are diligent in keeping their emergency address information up-to-date. In the United States, the Wireless Communications and Public Safety Act of 1999 leaves the burden of responsibility upon the subscribers and not the service providers to keep their emergency information up to date.

A tragic example of a miscommunication with VoIP is the death of 18-month-old Elijah Luck in Calgary, Canada. In an emergency, 911 services were called. An ambulance was sent to the former home of the Lucks. The VoIP telephone company knew the correct address, as they were paying their bill from the correct current billing address the company had on record. "It's up to subscribers to ensure the company has up-to-date contact information" was the response from the VoIP company. After about a half hour wait, the Lucks called from a neighbor's land line, whereupon emergency services arrived in six minutes. Elijah Luck was pronounced dead at the Alberta Children's Hospital.[29]

[edit] Number Portability

Local number portability (LNP) and Mobile number portability (MNP) also impact VoIP business. In November 2007, the Federal Communications Commission in the United States released an order extending number portability obligations to interconnected VoIP providers and carriers that support VoIP providers[30]. Number portability is a service that allows a subscriber to select a new telephone carrier without requiring a new number to be issued. Typically, it is the responsibility of the former carrier to "map" the old number to the undisclosed number assigned by the new carrier. This is achieved by maintaining a database of numbers. A dialed number is initially received by the new carrier and quickly rerouted to the original carrier. Multiple porting references must be maintained even if the subscriber returns to the original carrier. The FCC mandates carrier compliance with these consumer-protection stipulations.

A voice call originating in the VoIP environment also faces challenges to reach its destination if the number is routed to a mobile phone number on a traditional mobile carrier. VoIP has been identified in the past as a Least Cost Routing (LCR) system, which is based on checking the destination of each telephone call as it is made, and then sending the call via the network that will cost the customer the least[citation needed]. This rating is subject to some debate given the complexity of call routing created by number portability. With GSM number portability now in place, LCR providers can no longer rely on using the network root prefix to determine how to route a call. Instead, they must now determine the actual network of every number before routing the call.

Therefore, VoIP solutions also need to handle MNP when routing a voice call. In countries without a central database, like the UK, it might be necessary to query the GSM network about which home network a mobile phone number belongs to. As the popularity of VoIP increases in the enterprise markets because of least cost routing options, it needs to provide a certain level of reliability when handling calls.

MNP checks are important to assure that this quality of service is met. By handling MNP lookups before routing a call and by assuring that the voice call will actually work, VoIP service providers are able to offer business subscribers the level of reliability they require.

In countries such as Singapore, the most recent Mobile number portability solution is expected to open the doors to new business opportunities for non-traditional telecommunication service providers like wireless broadband providers and voice over IP (VoIP) providers[citation needed].

[edit] PSTN Integration

E.164 is a global numbering standard for both the PSTN and PLMN. Most VoIP implementations support E.164 to allow calls to be routed to and from VoIP subscribers and the PSTN/PLMN[31]. VoIP implementations can also allow other identification techniques to be used. For example, Skype allows subscribers to choose 'Skype names'[32] (usernames) whereas SIP implementations can use URIs[33] similar to email addresses. Often VoIP implementations employ methods of translating non-E.164 identifiers to E.164 numbers and vice-versa, such as the Skype-In service provided by Skype[34] and the ENUM service in IMS and SIP[35].

Echo can also be an issue for PSTN integration[36] . Common causes of echo include impedance mismatches in analog circuitry and acoustic coupling of the transmit and receive signal at the receiving end.

[edit] Security

Another challenge is routing VoIP traffic through firewalls and address translators. Private Session Border Controllers are used along with firewalls to enable VoIP calls to and from protected networks. Skype uses a proprietary protocol to route calls through other Skype peers on the network, allowing it to traverse symmetric NATs and firewalls. Other methods to traverse firewalls involve using protocols such as STUN or ICE.

Many consumer VoIP solutions do not support encryption yet, although having a secure phone is much easier to implement with VoIP than traditional phone lines. As a result, it is relatively easy to eavesdrop on VoIP calls and even change their content.[37] An attacker with a packet sniffer could intercept your VoIP calls if you are not on a secure VLAN.

There are open source solutions that facilitate sniffing of VoIP conversations such as Wireshark. A modicum of security is afforded due to patented audio codecs in proprietary implementations that are not easily available for open source applications, however such security through obscurity has not proven effective in the long run in other fields[citation needed]. Some vendors also use compression to make eavesdropping more difficult[citation needed]. However, real security requires encryption and cryptographic authentication which are not widely supported at a consumer level. The existing secure standard SRTP and the new ZRTP protocol are available on Analog Telephone Adapters(ATAs) as well as various softphones. It is possible to use IPsec to secure P2P VoIP by using opportunistic encryption. Skype does not use SRTP, but uses encryption which is transparent to the Skype provider[citation needed]. In 2005, Skype invited a researcher, Dr Tom Berson, to assess the security of the Skype software, and his conclusions are available in a published report[38].

The Voice VPN solution provides secure voice for enterprise VoIP networks by applying IPSec encryption to the digitized voice stream.

[edit] Caller ID

Caller ID support among VoIP providers varies, although the majority of VoIP providers now offer full caller ID with name on outgoing calls.

In a few cases, VoIP providers may allow a caller to spoof the caller ID information, potentially making calls appear as though they are from a number that does not belong to the caller[39]. Business grade VoIP equipment and software often makes it easy to modify caller ID information. Although this can provide many businesses great flexibility, it is also open to abuse.

The "Truth in Caller ID Act" has been in preparation in the US congress since 2006, but as of January 2009 still has not been enacted. This bill proposes to make it an offence in the USA to "knowingly transmit misleading or inaccurate caller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value ..."[40].

[edit] Interconnection to traditional PSTN telephones

Some analog telephone adapters do not decode pulse dialing from older phones. The VoIP user may use a pulse-to-tone converter, if needed.[citation needed]

[edit] Fax handling

Support for sending faxes over VoIP implementations is still limited. The existing voice codecs are not designed for fax transmission; they are designed to digitize an analog representation of a human voice efficiently. However, the inefficiency of digitizing an analog representation (modem signal) of a digital representation (a document image) of analog data (an original document) more than negates any bandwidth advantage of VoIP. In other words, the fax "sounds" simply don’t fit in the VoIP channel. An alternative IP-based solution for delivering fax-over-IP called T.38 is available.

The T.38 protocol is designed to work like a traditional fax machine and can work using several configurations. The fax machine could be a traditional fax machine connected to the PSTN, or an ATA box (or similar). It could be a fax machine with an RJ-45 connector plugged straight into an IP network, or it could be a computer pretending to be a fax machine. [41] Originally, T.38 was designed to use UDP and TCP transmission methods across an IP network. The main difference between using UDP and TCP methods for a FAX is the real time streaming attributes. TCP is better suited for use between two IP devices. However, older fax machines, connected to an analog system, benefit from UDP near real-time characteristics[citation needed].

There have been updated versions of T.30 to resolve the fax over IP issues, which is the core fax protocol. Some new fax machines have T.38 built-in capabilities which allow the user to plug right into the network with minimal configuration changes[citation needed]. A unique feature of T.38 is that each packet contains a copy of the main data in the previous packet. This is an option and most implementations seem to support it. This forward error correction scheme makes T.38 far more tolerant of dropped packets than VoIP[citation needed]. With T.38, two successive lost packets are needed to actually lose any data. The data you lose will only be a small piece, but with the right settings and error correction mode, there is a high probability that you will receive the whole transmission.

Tweaking the settings on the T.30 and T.38 protocols could also turn your unreliable fax into a robust machine[citation needed]. Some fax machines pause at the end of a line to allow the paper feed to catch up. This is good news for packets that were lost or delayed because it gives them a chance to catch up. However, were this to happen on every line, your fax transmittal would take a long time. Another possible solution is to treat the fax system as a message switching system, which does not need a real-time data transmission (such as sending a fax as an email attachment (see Fax) or remote printout (see Internet Printing Protocol)). The end system can completely buffer the incoming fax data before displaying or printing the fax image.

[edit] Support for other telephony devices

Another challenge for VoIP implementations is the proper handling of outgoing calls from other telephony devices such as DVR boxes, satellite television receivers, alarm systems, conventional modems and other similar devices that depend on access to a PSTN telephone line for some or all of their functionality.

These types of calls sometimes go through without any problems, but in other cases they will not go through at all. If VoIP and cellular substitution becomes very popular, some ancillary equipment makers may be forced to redesign equipment, because it would no longer be possible to assume a conventional PSTN telephone line would be available in consumer's homes.

[edit] Legal Issues