Archive for January 2006

VoIP – Internet Broadband Telephone Services Lifecycles

With all the new VoIP Internet broadband telephone services you might be wondering about their lifecycles. Well, if you cannot provide quality of service (if you do not own the least line) there is no way you will be able to keep your customers happy over a prolonged period of time. Do not invest into Vonage (it’s a tax write-off – I’ll explain later). Packet8 seems to be one of the better and cheaper VoIP solutions. You can check it out here.

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 and DoS attacks[31] 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). 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.

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.