Add a comment
It can be daunting to think of all the things a successful VoIP call needs to do – in addition to the call setup, which we covered previously, the conversation portion of the call needs to be converted into packet format, sent across the network, reassembled, and then converted from packet format back to voice.
Here’s a look at a couple of the different standards available to enable VoIP traffic across the network.
Codecs – short for “enCOde/DECode” – are required at both ends of the phone conversation to allow the audio signal to be sent and received across the network. Each codec has different bandwidth requirements and characteristics that can affect network performance.
First, there are G.711 and G. 729 – commonly used codecs standardized by the ITU. G.729 compresses the data and therefore requires less bandwidth to send the conversation packets, but this compression is “lossy,” – some degredation in quality will occur – much like a low quality JPEG doesn’t look as good as the original photo, or an MP3 file doesn’t sound as good as a CD.
G.711 doesn’t use any compression, but as a result, the bandwidth requirements are much higher.
Once the codec has encoded the data, the next protocol, Real-Time Transport Protocol (RTP) transfers the data to the receiver. RTP is used almost exclusively for the transfer of VoIP on almost every network. (Skype is an exception – they use a proprietary protocol.) Riding on top of UDP, RTP is used to send data in one direction with no acknowledgements – which makes sense. If a packet gets lost in a VoIP conversation, it’s too late to resend it – the damage is done, so sending an acknowledgement packet just doesn’t make a whole lot of sense. This is also why RTP packets tend to have smaller payloads – in VoIP, it’s more important to get a little data to the other end of the connection quickly, even if it would be more “efficient” to put more data in the packet.
RTP uses even-numbered UDP port numbers, determined during call setup.
There’s also an optional profile, Secure RTP, which provides data encryption and message authentication – but it has a performance impact. While phone hardware and firmware of recent years have minimized encryption overhead, it can still create performance degradation at those devices, such as gateways, that handle a large number of media streams.
Then there’s the Real-time Transport Control Protocol (RTCP), which provides statistics about the RTP flow for a given call. RTCP defines sender and receiver packet types, and uses the odd-numbered UDP ports – usually the RTP port value, plus one.
The statistics that RTCP provides are important to help determine the quality of the call and any underlying network metrics that contributed to the quality rating. RTCP metrics help keep track of the jitter, lost packets, and the NTP timestamp (which can be used to compute a round-trip delay value.)
RTCP-XR, is an extended version of RTCP designed to provide information such as loss rate, discard rate, burst density/duration, gap density/duration, round-trip delay, end-system delay, signal/noise level, echo return loss, R-factor and MOS.
These don’t include the proprietary metrics for call-quality – be aware that different vendors have different call quality monitoring solutions.
--------------
More Information:
- Get a sneak preview of the Free VoIP eBook
Webinar
- VoIP Monitoring Webinar
NetQoS VoIP Solutions
- Converged VoIP and Data Networks
- NetQoS VoIP Monitor
 |
