PVQA Server
PVQA Server
This document describes application purpose, requirements, software architecture and user operations for
PVQA server software from Sevana Ou.
Application purpose.
Application purpose is to provide access for measuring of call traffic quality for cloud services model.
Measuring is based on Sevana Ou’s technology and heuristics for network statistics.
Hardware requirements.
Any modern x64 Intel/AMD CPU from last years. Low-end VPS are able to run the
application even.
CPU
CPU usage is low in idle - about 0%. Of course CPU usage has bursts when application
performs decoding and analyzing.
Memory Memory usage depends on load. But 1GB low end VPS is enough for tests at least.
I/O subsystem I/O subsystem performance must be good balanced.
The multithreading nature of application can cause many simultaneous I/O requests
and stress storage subsystem. Again low end VPS is enough to test purposes.
Software requirements.
Software requirements are not something specific. Any modern 64 bits Linux distribution should be enough.
Server binary is statically linked so no additional setup is needed (except PVQA analyzer).
Server does not require database connection - it does not use dedicated database software.
The root privileges can be needed to run capturing on network interfaces - it depends on configuration.
Operation model.
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
The application is started by launching its server process. It runs in background (or being attached to Linux
console depending in configuration) + records logs + caches operational data.
No specific data structures are used - everything is usual plain text files and audio files.
1. Connect to server
2. Upload RTP stream file
3. Receive answer from server with results of analyzing.
Application consists of 4 main components – network HTTP stack, traffic capturer, decoder and call quality
analyzer. The data flow between them is simple:
- Network stack receives requests from network and pass received dumps to decoder
- Decoder gathers RTP statistics for received dump, decodes RTP streams into PCM .wav files and
sends them to analyzer.
- Analyzer makes MOS estimation and pass results to network stack.
- Network stack packs everything into response and sends back to client.
- Traffic capturer sends data to decoder which sends decoded audio to analyzer. Results are written
to file or custom sink.
- SIP parser listens for SIP traffic (from UDP or UNIX socket) and reconstructs SIP call information.
Network stack.
It is responsible for receiving requests (with RTP stream files) + sending answers to remote clients. Stack can
utilize multiple threads to I/O. Precise number of worker threads is set in configuration parameters from CLI
(command line interface).
Network stack works via plain HTTP. There is no any authorization or TLS scheme used. These things can be
accomplished by running server process behind the nginx server (or any other) which will perform securing
and authorization.
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
The network stack is built on the top of cpp-netlib library (which relies on boost C++ library).
Please see this article to get more details for cpp-netlib: http://cpp-netlib.org/
Traffic capturer.
Decoder.
This component is responsible for decoding uploaded RTP stream files into plain PCM data (.wav files). It is
based on jrtplib + few open source codecs + glue code from rtphone project.
AMR-NB/WB codec data can be encapsulated into IuUP frames which are embedded in RTP stream.
Decoder can parse it.
● Based on network statistics only. This algorithm relies on the same heuristics used in open source
voipmonitor application. It is very roughly estimation but it is very fast (talking about CPU load). It
does not require audio compressed data decoding even. Instead it gathers network statistics from
decoder component and finds estimation using it. It is based on ITU-T G.107. Result value will
depend on packet loss statistics. Also it will be limited by upper value for each codec.
Copyright © Sevana Oü, 2021
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
● Using Sevana Ou PVQA library. Sevana Ou’s algorithm provides good MOS value estimation based
on own proprietary technology. It works with plain audio streams - so media decoder turns received
RTP stream into plain PCM audio stream and sends second one to analyzer. Analyzer detects various
impairments and after splitting the audio under analysis it calculates the ratio between affected
(with impairments) and good quality audio time slots. Based on this information it predicts MOS
score according to ITU-T P.800 standard. For more details please check last chapter “How PVQA
works” in this documentation at page 12. Also there are more details at website
http://sevana.biz/products/pvqa/
Network API.
Application uses HTTP transport to receive requests & answers with responses.
It is subject of "PVQA server network API" document - please check it.
Application can be launched as server process as Linux daemon or being attached to console.
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
--pvqa-thread-pool-size <size> Thread pool size for analyzing tasks. This pool serves
CPU intensive tasks. For multiprocessor systems
default value is number of cores - 1. For single
processor systems default value is 1.
--amrnb-payload-type <pt> Payload type for AMR NB codec. Default is 97.
--amrwb-payload-type <pt> Payload type for AMR WB codec. Default is 96.
--isac16k-payload-type <pt> Payload type for ISAC codec, 16 KHz sample rate.
--isac32k-payload-type <pt> Payload type for ISAC codec, 32 KHz sample rate.
--opus-payload-type <pt-rate-channels> Payload type spec for OPUS codec. It is set as string
payloadtype-samplerate-channels or
payloadtype/samplerate/channels. Example:
120-16000-1 which means payload type 120 for
sample rate 16KHz and mono audio. You can specify
multiple parameters for different OPUS profiles.
--evs-payload-type <pt-encoding-bandwidth> Payload type spec for EVS codec. Spec is set as triple
payloadtype-mime|g192-nb|wb|swb|fb where
payload type is integer payload type number, mime
or g192 are encoding types, nb|wb|swb|fb are
bandwidth names - narrowband / wideband /
superwideband / fullband.
--log-filename <path> Log filename. Default is pvqa-server.log
--daemon <true or false> Runs server as daemon. It detaches process from
console.
--use-srtp <true or false> Interpret RTP streams as SRTP profile.
--report-file <path> Path to report file. It is place where report about
captured media streams is written. It is only about
traffic capturing.
--report-interval <duration> Report interval. It is only about traffic capturing.
Examples: 10200ms or 10s.
--clear-cache <true or false> Clears caches (.pcap and .wav) on start and after
stream processing. True is default value. It means
"do not dump decoded audio to disk". False will
cause decoded audio saving to disk - it is useful for
debugging.
--config <path> Use specified configuration file (instead of default
pvqa-server.cfg).
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
--capture <device> Name of device for capture traffic. eth0 or lo or any.
--capture-src-port-range <port1-port2> Filter UDP packets with range of port numbers for
source address. Default value is 0 - 0 which means
no filtering by source port number. Zero port
number on any side in port range will prevent
filtering by source port number.
--capture-dst-port-range Filter UDP packets with range of port numbers for
destination address. Default value is 0 - 0 which
means no filtering by destination port number. Zero
port number on any side in port range will prevent
filtering by destination port number.
--pvqa-license <path> Path to PVQA analyzer license file. Default is
“pvqa.lic”
--pvqa-settings <path> Path to PVQA analyzer settings file. Default is
“pvqa.cfg”
--dbengine <engine> DB engine string - can be “mysql”, “sqlite”,
“postgresql”. Default is empty which prevents server
DB storage using.
--dbstring <connectionstring> DB connection string. Depends on used engine - soci
C++ library is used for DB connections.
Mysql example: db=rtpmonitoring_db
user=rtpmonitoring password='testpwd'
--rtcp-mux Forces server to expect RTCP muxed with RTP on the
same port. Default value is true.
--hep-listener-port HEP v2/v3 listener’s UDP port. Default value is zero -
HEP is disabled.
--capture-udp-sip If set pvqa-server will capture SIP traffic on UDP
interface. Default value is false - no SIP capture by
itself.
--extension-module Path to extension module .so or .dll.
--dashboard-port Port number for web dashboard.
--dashboard-streams-per-section Maximal number of RTP streams shown in single
section by web dashboard
--rtp-output-dir When running with --pcap parameter (parsing single
file) --rtp-out-dir specifies folder where to put RTP
payload dumps. Initially it was made for debugging
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
purposes.
--wav-output-dir When running with --pcap parameter (parsing single
file) --wav-output-dir specifiesfolder where decoded
audio will be stored.
--pid-file <path_to_file> Path to file where process ID will be written after
server start. Default value is empty - PID is not
written.
--audio-time-report <path_to_file> Path to file where server will read/store number of
processed seconds with PVQA analyzer.
Default value is empty - number of seconds is not
stored.
--delete-old-records <N> N is time duration. Server will delete records older
than N from database.
Default value is zero - this feature is disabled.
Example of values: 2h - 2 hours, 7d - 7 days.
--check-call-end <N> Check only last N milliseconds/seconds of call. Use
this feature if you want to lower CPU usage.
Default value is zero - this feature is disabled.
Again - N is time duration. It can be set in various
ways like 15s - 15 seconds or 2m - 2 minutes.
--alarm-name <counter name> Tracked counter name. Possible values are:
- r_factor - it is Sevana’S R-factor
- sevana_mos - Sevana’s MOS
- network_mos - network MOS
- duration - stream's duration in seconds
- packet_loss - packet loss in percents
- jitter - jitter in milliseconds
--alarm-value <limit> Lower limit of tracked average counter value. Alarm
will be sent if average value goes below the
specified limit (for r_factor / network_mos /
sevana_mos / duration counters) or above specified
(for packet_loss / jitter counters) . For example limit
value for Sevana R-factor can be: --alarm-value 70
which means "send alarm if average R-factor value
goes below 70%".
--alarm-interval <duration> Alarm interval. Server will find average value for the
specified amount of seconds and send alarm if this
value goes below the limit value.
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
Time duration is specified with suffixes. Examples:
20s - 20 seconds, 5m - 5 minutes, 5h - 5 hours, 1d - 1
day.
--alarm-command <shell command> Shell command that will be executed to send alarm.
Example:
--alarm-command=/var/pvqa-server/send-alarm.sh
$limit $r_factor
Server uses default configuration file pvqa-server.cfg as default. Configuration directives is the same
command line directives in format
name1=value1
name2=value2
etc.
Copyright © Sevana Oü, 2021
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
For example (use network API on port 9124 + log level is debug + capturing on eth0 interfaces + use plain
RTP):
daemon=true
server-port=9124
log-level=debug
capture=eth0
use-srtp=false
Path to configuration file can be overridden with --config directive from command line.
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
Extension modules.
Extension modules can be loaded by server to
Modules have to be build with C++ to .so / .dll files. Server configuration directive --extension-module
specifies path to module.
Here is some more information on how to read PVQA report and how the algorithm works.
1.598 : 2.397; 0.005000; 0.000000; 0.500000; 0.000000; 0.000000; 0.025000; 0.000000; Poor
2.397 : 3.196; 0.016204; 0.000000; 0.812500; 0.000000; 0.000000; 0.062500; 0.018519; Poor
3.196 : 3.995; 0.007500; 0.000000; 0.525000; 0.000000; 0.000000; 0.037500; 0.000000; Poor
3.995 : 4.794; 0.005000; 0.000000; 0.187500; 0.000000; 0.000000; 0.025000; 0.000000; Poor
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
PVQA splits audio into 0.68 - 0.8 sec (may vary to achieve better conformance) chunk for analysis. This
number was received empirically during tests to achieve better conformance with intrusively received MOS
scores (AQuA, PESQ, POLQA; we used AQuA in our tests).
Every audio chunk has certain amount of samples (e.g. if we have for 8kHz 8000 samples per second, one
can expect something like 6400 samples for 0.8 chunk). Every detector has minimal number of samples it
can work with to provide metric related to the impairment. Detectors are working with frames, which are
sets of audio samples. For every frame each detector returns a value, f.e. SNR detector returns value in dB,
and others unitary values marking presence or absence of the impairment.
Thus we have 0.8 audio chunk and N frames on it. The number in the report is a ration between the number
of frames containing impairment to the overall number of frames, i.e. X/N, where 0 <= X <=N. There are
thresholds for these values to mark interval Ok or Poor.
For example value 0.500000 means that 50% of all frames had that impairment.
There are different types of Dead Air. We differentiate two of them: “absolute silence” and “silence”.
Absolute silence means zero level signal, this is typical when f.e. a packet is lost and there is no packet loss
correcting that fills in the gap in audio f.e. with natural noise. We turned this impairment off for being used
in MOS calculation because when using reference audio there are naturally silent parts of the signal with
zero level due to high quality of the recording.
So, DeadAir-01 and DeadAir-00 have different thershold for signal level to report detection of impairment.
Clicking or crackling is a single spike of energy in the signal, and when f.e. there is a packet loss the
waveform looks like zero level signal and then spike that may sound like a click. This impairment may occur
in other cases as well.
Dashboard.
Dashboard provides you with information about active & finished RTP streams including MOS estimations +
various network statistics. It is build within hierarchy:
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
Here is example of stream list on test server (accessible via / or /stats path).
This page includes basic information about active & finished RTP streams. Sorting is possible also. Displayed
statistics values are:
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
- computed Sevana’s MOS value. It can be empty if server is configured to skip the decoding
- Sevana’s R-factor - it is ration of number of bad intervals in decoded audio stream to total number
of intervals. Each interval is 0.68 - 0.80 seconds depending on PVQA analyzer configuration.
- network MOS value - it is computed according to G.107. Estimates network quality only (which can
affect audio quality too)
- jitter value
- SIP source address. It can be empty if PBX does not send related SIP information.
- SIP destination address. It can be empty if PBX does not send related SIP information.
Every row has link to stream’s details page also. Clicking on this one will navigate to next level of hierarchy -
overall stream details. Screenshot is below (captured on good quality call - please note MOS values) :
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
It shows basic statistics value from previous page + some new interest things. Among them are:
- computed RTT delay (it can be empty or zero if server is not configured properly)
- used codec
- total number of RTP packets in the stream
- number of lost packets
- counters for AMR bitrate switch event - it shows how much often AMR streams changes their
bitrate
- counters for PVQA analyzer detectors. Shows how much often PVQA detected problem in audio
stream.
This page lists audio chunks including link to detailed statistics to each of them. Please see screenshot (used
audio was captured on call with worse quality - please see Sevana MOS value and detector reports) :
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331
Comparing with previous page there is important info - this pages shows PVQA detector’s report for audio
chunk.
Sevana Oü
Roosikrantsi tn 2
Tallinna linn, Harju maakond, 10119
Estonia
Phone: +3726170331