Home

Welcome to the BITS_Project wiki!

Chapter 1: VoIP Call Quality

Background

RTP, the real-time transport protocol, RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. RTP does not have a well known UDP port (although the IETF recommend ports 6970 to 6999). Instead, the ports are allocated dynamically and then signalled using a different protocol such as SIP(Session Initiation Protocol) . In SIP and other protocols a RTP session is described by SDP(Session Description Protocol), which is not really a protocol itself but rather a formalised way to describe a media session.

Wireshark, a network analysis tool formerly known as Ethereal, captures packets in real time and display them in human-readable format.

Playing VoIP calls

To access the VoIP calls analysis, use the menu entry "Telephony->VoIP Calls...". The current VoIP supported protocols are: To play the RTP audio stream of one or multiple calls from the VoIP List, select them from the list and then press the "Player" button:

Figure 1: VoIP Calls You can now see all RTP streams available for the calls that you selected:

Figure 2: RTP Player

Problem Definition

For the moment, RTP Player feature works only for G711 A-Law and G711 u-Law RTP streams (other codecs not implemented). To Play other codec, we need to extract the RTP stream from the network capture file to verify the call quality. This step is manual and need a lot of effort in manual testing the audio call quality.

VOIP Call Quality solution

Build, an effective tool for RTP Analysis for mostly used audio codecs like G711, G722 opus, AMR and AMR-WB. Provide the complete analysis of Audio RTP for each and every packet like Sequence number, SSRC, Payload, Jitter, Redundancy etc. Decoding of RTP payload Converting the RTP payload in playable format for manual verification Analysis of Audio Quality based on predicted MOS score for automated procedure.

Chapter 2: VoIP RTP Quality

About MOS score

RTP quality is important factor to validate the SIP telephony call(audio) quality hence we need to verify the RTP Metrics like Packet Loss, Jitter, latency and come up with a predictive MoS score after extracting the RTP payload from the network capture file. MOS measures subjective call quality for a call. MOS scores range from 1 for unacceptable to 5 for excellent. VOIP calls often are in the 3.5 to 4.2 range. Mean Opinion Score (MoS) / R-Factor is sometimes used to determine the requirements for QoS. Quality of Service provides a guarantee of bandwidth and availability for VOIP call quality for Delay, Jitter, Echo, Congestion, Packet loss and Out of Sequence packets The MOS is highly subjective. One should not make decisions on a VoIP system based on the MOS alone. Other measurable parameters should be analyzed such as network delay, packet loss, jitter, and so on. As an alternative to the MOS, a different, less subjective rating has been introduced.

R-Factor is an alternative method of assessing call quality. Scaling from 0 to 120 as opposed to the limited scale of 1 to 5 makes R-Factor a somewhat more precise tool for measuring voice quality. R-Factor is calculated by evaluating user perceptions as well as the objective factors that affect the overall quality of a VoIP system, accounting for the Network R-factor and the User R-factor separately.

The following table demonstrates the effect of the MOS and R-Factor on the perceived call quality.

User Satisfaction Level MOS R-Factor Maximum using G.711 4.4 93 Very satisfied 4.3-5.0 90-100 Satisfied 4.0-4.3 80-90 Some users satisfied 3.6-4.0 70-80 Many users dissatisfied 3.1-3.6 60-70 Nearly all users dissatisfied 2.6-3.1 50-60 Not recommended 1.0-2.6 Less than 50

What affects your VoIP MOS test score. First, it is important to understand that MOS - Mean Opinion Score - is a relative scale and is built upon many factors which can affect voice quality. VoIP measurements are collected for after testing the one-way delay or the latency of the connection, packet loss with a metric to include the number of consecutive packets lost, and the amount jitter (difference in time it takes packets to arrive). Calculations then factor anR Factor that can be used to estimate a MOS score. Propagation delay which is is the time required for a digital signal to travel end-to-end across the entire network. The greater the distance the greater the propagation delay. Additionally the data has to travel through network routers, switches and other devices like firewalls, each adding its own (transport) delay. Packetization delay which is the time required to digitize the signal for the codec used for sending over the internet and decode it at the far end. A more compressed codec like G.729 has a higher packetization delay than a non-compressed codec like G.711 codec. Jitter buffer is the delay introduced by the ATA device to hold one or more datagrams, to compensate in variations of arrival times. In VoIP a jitter buffer is an area where voice packets can be collected, stored, and then sent to the processor in more evenly spaced intervals. Variations in packet arrival time (jitter) is usually the result of network congestion or route changes. The jitter buffer, which is located at the receiving end device of the voice connection, intentionally delays the packets so that received voice is presented correctly with less distortion. The following items can all affect call quality: Bandwidth Codec in use. Hardware Jitter Latency Packet Loss

Codecs- how they affect MOS- Mean Opinion Score A non-compressed codec, G711, will give the best voice quality, as no compression and decompression is required. This in turn makes this G711 less susceptible to packet loss, which even in small amounts will quickly degrade voice quality. Other codecs which use compression techniques consume less bandwidth, a good thing, but this compression process in itself lowers the voice clarity and introduces a delay. Additionally, compressed codecs are even more susceptible to packet loss. In addition G711 will maintain better quality with more latent connections, whereas compressed codecs' voice quality can quickly degrade as latency increase, as the chart below reflects.

Figure3:Comparison of voice quality for G711 & G729 codecs as latency increases.

Chapter 4: Analysis of SIP and RTP details

For any voip call , we need to analyze the for SIP and RTP including RTPEvent (DTMF) to find out call details record. I am using tshark and lua programming for extracting the SIP and RTP details from the capture file.

Figure 4: SIP Summary

Figure 5: RTP Summary

SIP packet:- 1487248464.977806000 UDP <src_ip>52.205.63.210</src_ip> <src_port>5080</src_port> <dst_ip>172.31.18.204</dst_ip> <dst_port>5060</dst_port> <sip_call_id>1beb391e-5795-4a9d-b0e8-ccf636a7c842</sip_call_id> <sip_cseq_method>ACK</sip_cseq_method> <sip_status_code>nil</sip_status_code> <sip_request>ACK sip:35.154.101.16:5060;transport=UDP SIP/2.0</sip_request> <sip_reply>nil</sip_reply>

RTP packet:- 1487248464.998570000 UDP <src_ip>52.205.63.210</src_ip> <src_port>24016</src_port> <dst_ip>172.31.18.204</dst_ip> <dst_port>6000</dst_port> <seq_no>63563</seq_no> 0x76349b6b g711a <rtp_timestamp>160</rtp_timestamp>

RTPEvent packet:-

1487248470.898571000 UDP 52.205.63.210 24016 172.31.18.204 6000 1 160 0 Chapter 4: Reading and Decoding RTP Payload

Pyshark allows parsing from a capture file or a live capture, using all wireshark dissectors you have installed. Using pyshark module filter the UDP packet and decode them as RTP. Save the RTP payload in the raw audio file.

rtp_list = [] cap = pyshark.FileCapture(pcapfile,display_filter='udp',decode_as={'udp.port==10000-65536': 'rtp'}) self.get_rtp_streams_info() // Retreive all the RTP stream in the pcap file) for rtp in self.rtp_stream_report: raw_audio = open(rtp+'.raw', 'wb') for i in cap: try: rtp = i[3] // should be RTP payload or message if rtp.payload: rtp_list.append(rtp.payload.split(":")) except: pass for rtp_packet in rtp_list: packet = " ".join(rtp_packet) audio = bytearray.fromhex(packet) raw_audio.write(audio)

Chapter 5: Converting into wav/mp3 format

Using SoX(Sound Exchange) , I am converting the raw audio file into wav file format and mp3 format.SoX reads and writes audio files in most popular formats and can optionally apply effects to them. Even It can combine multiple input sources, synthesise audio, and, on many systems, act as a general purpose audio player or a multi-track audio recorder. It also has limited ability to split the input into multiple output files.

for raw_file in raw_files: audio_file = '%s'%(raw_file.split('/')[-1][:-3] + 'wav') mp3_audio_file='%s'%(raw_file.split('/')[-1][:-3] + 'mp3') subprocess.call('sox -r 8k -e a-law %s -e signed %s'%(raw_file, audio_file), shell = True) subprocess.call('sox -t wav %s -t wav -e signed-integer -c 1 -r 8000 - rate | lame -b 16 - %s ' % (audio_file,mp3_audio_file), shell=True)

Example:- sox -r8000 -c1 -t ul out/rtp.0.0.raw -t wav out/0.wav > /dev/null 2>&1 sox -r8000 -c1 -v 5 -t ul out/rtp.0.1.raw -t wav out/1.wav > /dev/null 2>&1 sox -m out/0.wav out/1.wav out/call.wav > /dev/null 2>&1 sox -t wav out/call.wav -t wav -e signed-integer -c 1 -r 8000 - rate | lame -b 16 - out/call.mp3 > /dev/null 2>&1

Chapter 6:Quality Checking Using PESQ MOS

Quality Checking Using Mean Opinion Score (MOS) ,we need to check the quality of audio RTP flow. There are many alternatives available to check the quality of RTP flow, i.e., we can measure throughput, average latency, jitter, etc. One standard measurement is MOS (Mean Opinion Score). MOS score value ranges between 1 to 5, with 5 being excellent quality and 1 being the worst quality. MOS score depends on the various parameters, i.e., link speed, codec used, jitter, round trip time (RTT), packet loss percentage etc.

PESQ is a full-reference algorithm and analyzes the speech signal sample-by-sample after a temporal alignment of corresponding excerpts of reference and test signal. PESQ can be applied to provide an end-to-end (E2E) quality assessment for a network, or characterize individual network components.

PESQ Output:-

Reading reference file 0x76349B6B_52.205.63.210_172.31.18.204.wav...done. Reading degraded file 0x7698771D_52.205.63.210_172.31.18.204.wav...done. Level normalization... IRS filtering... Variable delay compensation... Acoustic model processing...

P.862 Prediction (Raw MOS, MOS-LQO): = 4.500 4.549

Chapter 7: RTP Analyser Server

A RTP Analyser Server provides Web GUI for your scripts and remote execution facility.We will be able to access your scripts via web-browser and execute them. Everything will run on your machine, so users shouldn't care about setting up an environment or working via ssh.

Chapter 8: MOS Server

A MOS Server provides Web GUI for your MOS score calculation facility.We will be see MOS score in web-browser after execute it. Everything will run on your remote machine, so users shouldn't care about setting up an environment or working via ssh.

Chapter 8: Audio Server

A Audio Server provides Web GUI to listen the extracted audio server.You will be hear the audio file from the web-browser. Everything will run on your remote machine, so users shouldn't care about setting up an environment or working via ssh.