VoIP Challenges

Good speech quality is a strong requirement of any commercial network,
wireless or otherwise. Traditionally, this has been achieved through 64-
Kbps (G.711) voice coding and the use of circuit-switching, which establishes
a dedicated transmission path from the source to the destination.
Nowadays, more advanced speech coding schemes can approach the quality
of G.711 with a much lower bandwidth requirement. The GSM Enhanced
Full-Rate Coder is one such advanced coding scheme and many others are
available. Good speech coding is not the only requirement, however. Other
requirements include low-transmission delay, low jitter (delay variation), and the requirement that everything transmitted at one end is received at
the other (low loss).
These requirements are somewhat contradictory when viewed from an
IP perspective. For example, the requirement for low loss could be achieved
through the use of TCP at layer 4. That, however, would cause excessive
delay, both at the start of the transfer when a TCP connection needs to be
established and during the transfer when acknowledgements and retransmissions
would cause a delay in the delivery of the voice packets. In order
to minimize delay, one could use UDP at layer 4. UDP, however, offers no
protection against packet loss.
Given the choice between UDP or TCP, the issue is whether we consider
minimizing delay to be more important than eliminating packet loss. The
answer is that, for speech, excessive delay and excessive jitter are far more
disturbing than occasional packet loss. Obviously, excessive packet loss is
unacceptable, but a limited amount (less than 5 percent) can be tolerated
without noticeable speech quality degradation. Consequently, when transporting
voice, UDP is chosen at layer 4, rather than TCP.
It is clear, however, that something more than UDP is required if VoIP is
to offer reasonable voice quality. At a minimum, the destination application
needs to know the coding scheme being used by the source application so
that the voice packets can be decoded. The application also needs timing
information so that packets can be played out to the user in a synchronized
manner and help mitigate against delay in the network. Moreover, the
application needs to know when packets are lost, so that a previous packet
could be replayed to fill the gap if appropriate.
In order to fulfill these needs, a protocol known as the Real-Time Transport
Protocol (RTP) has been developed. This protocol resides above UDP in
the protocol stack. Whenever a packet of coded voice is to be sent, it is sent
as the payload of an RTP packet. That packet contains an RTP header,
which provides information such as the voice coding scheme being used, a
sequence number, a timestamp for the instant at which the voice packet
was sampled, and an identification for the source of the voice packet.
RTP has a companion protocol, the RTP Control Protocol (RTCP). RTCP
does not carry coded voice packets. Rather, RTCP is a signaling protocol
that includes a number of messages, which are exchanged between session
users. These messages provide feedback regarding the quality of the session.
The type of information includes such details as lost RTP packets,
delay, and inter-arrival jitter.
Whenever an RTP session is opened, an RTCP session is also implicitly
opened. This means that, when a UDP port number is assigned to an RTP session for the transfer of voice packets (or any other media packets, such
as video), a separate port number is assigned for RTCP messages. An RTP
port number will always be even, and the corresponding RTCP port number
will be the next highest number, and hence odd. Thus, if we again consider
the IP protocol stack for voice transport, it appears as shown in Figure 8-2.
It should be noted that RTP and RTCP do not guarantee minimal delays,
low jitter, or low packet loss. In order to do that, other protocols are
required. RTP and RTCP simply provide information to the applications at
either end so that those applications can deal with loss, delay, or jitter with
the least possible impact to the user.