colleagues, I could not find a description of this option

Hello! On my Orange Pi Prime i got error, here's syslog part:
calls[0,r:0][0,r:0] SQLq[C:0 M:0] heap[0|0|0] tarQ[0] t0CPU[0.1%] t1CPU[2.2%] t2CPU[pb:2.2%] tRTP_CPU[1.1%/1.1m/1t] tacCPU[0.2%] RSS/VSZ[89|288]MB LA[1.70 1.37 1.17] v22.8.1
Jul 25 03:34:19 orangepi kernel: [418215.506410] Unhandled fault: alignment fault (0x92000021) at 0x00000000e7eaa29b
Jul 25 03:34:20 orangepi kernel: [418216.521922] device eth0 left promiscuous mode
Jul 25 03:34:23 orangepi voipmonitor[7459]: set buffer memory limit to 1042364416
Jul 25 03:34:23 orangepi voipmonitor[7459]: set buffer memory limit to 1042364416
Jul 25 03:34:23 orangepi voipmonitor[7459]: local time 2018-07-25 03:34:23
Jul 25 03:34:23 orangepi voipmonitor[7459]: for rrd graph you need install rrdtool
Jul 25 03:34:23 orangepi voipmonitor[7463]: start voipmonitor - version 22.8.1

During initial install of the sniffer WITH mysql database, there seems to be no way to create the database without setting disable_dbupgradecheck = no in the configuration file.

The --update-schema option seems to only output the list of options for help. It never does anything.

For example, when I do something like:
voipmonitor -b voipmonitor -p <password> -h 127.0.0.1 -O 3306 -u voipmonitor -v 9 --update-schema

It does not create the database schema.

If I simply start voipmonitor as a service, as the installation documentation mentions, it does not create the schema.

Is there a way to issue a command that only creates the mysql schema so that disable_dbupgradecheck can be left as the default "yes" ?

Hello,

I'm packaging voipmonitor sniffer for openSUSE and SLES 12 in the Open Build Server and the check_gcc_output check which checks the compiler output for errors has found buffer overflows in the compiler output.

[ 279s] I: Statement is overflowing a buffer
[ 279s] E: voipmonitor bufferoverflow sniff.cpp:3486:71
[ 279s] E: voipmonitor bufferoverflow sniff.cpp:4385:69

Packaging:
https://build.opensuse.org/package/show/home:deadpoint/voipmonitor

Build Log for SLE 12:
https://build.opensuse.org/package/live_build_log/home:deadpoint/voipmonitor/SLE_12/x86_64

There is something about WebRTC Monitoring in the Source, but nothing in the Documentation and nothing in the Config File. Is there a Reason?

Testing new MGCP beta, but I am not having success.
I guess that i should see MGCP traffic at the pcap.

# MGCP protocol                                                               #
###############################################################################

# mgcp protocol is disabled by default
mgcp = yes

# default MGCP ports (change it only if it differs)
tcp_port_mgcp_gateway = 2427
udp_port_mgcp_gateway = 2427
tcp_port_mgcp_callagent = 2727
udp_port_mgcp_callagent = 2727

Do I miss something?

Thank you.

Hello,

We have got a strange issue with voipmonitor server. We have got 20+ server with sniffer and one server. There are 2300-2500 parallel calls. We are using Ubuntu Trusty 14.04 and compiling voipmonitor/sniffer from git source code.

Sample log from server:

2018-03-12T09:00:57+01:00 dumper2 voipmonitor[29144]: calls[2518,r:15][2518,r:21] PS[C:48/-28 r:12/-11 S:442/442 SR:28 SM:- R:79000 A:151280] SQLq[C:0] heap[0|1|0] comp[62] [231.8Mb/s] cdq[0][4.8 MB/s] t0i_vmbr0_CPU[0.1Mb/s;0.0%/4.7%/4.8%/4.8%/4.7%] t0CPU[4.8/4.7%] t1CPU[0.0%/0.0%/0.0%/0.0%/0.2%/0.4%/0.0%/0.6%/0.6%/0.0%/1.1%/0.0%/0.2%/0.3%/0.0%/0.1%/1.4%/0.6%/0.8%/1.6%/0.8%/0.2%/0.5%/0.1%/1.9%/1.8%/0.5%/0.2%/0.0%/0.0%/0.0%/0.0%/0.0%/0.0%/0.0%] t2CPU[pb:13.5/d12.3/rm:10.2/rh:4.2/rd:12.1/S:52.3%] tRTP_CPU[151.3%/44.2m/4t] tsip_tcpCPU[625l|0/0s|0/0p] tacCPU[62.2|54.4|50.9|50.8|42.1%] RSS/VSZ[2964|7727]MB LA[5.25 3.88 3.15] v22.0.2 

Server has got 48 GB RAM and two Intel Xeon E5645 CPUs. Server is crashing more than 12-15 times in one hour. Here is the gdb bt full outoput:

#0  0x00007ff75569cc37 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
        resultvar = 0
        pid = 17483
        selftid = 21531
#1  0x00007ff7556a0028 in __GI_abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x2d34365f3638782f, 
            sa_sigaction = 0x2d34365f3638782f}, sa_mask = {__val = {
              7955377262162766188, 7526764445220745077, 3543825127326180722, 
              7378645557452156473, 3472334915645289783, 4122261946868641072, 
              8223625903104013668, 3544385890001366391, 4195437442677878841, 
              3906364935141077040, 2314885530818453553, 2314885530818453536, 
              7795484802351636512, 3917909816998060649, 3276497845987585332, 
              0}}, sa_flags = 67, sa_restorer = 0x7ff5e67fb800}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007ff7556d92a4 in __libc_message (do_abort=do_abort@entry=2, 
    fmt=fmt@entry=0x7ff7557e8db0 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:175
        ap = {{gp_offset = 32, fp_offset = 0, 
            overflow_arg_area = 0x7ff5e67fb810, 
            reg_save_area = 0x7ff5e67fb7a0}}
        fd = 2
        on_2 = <optimized out>
        list = <optimized out>
        nlist = <optimized out>
        cp = <optimized out>
        written = <optimized out>
#3  0x00007ff75577487c in __GI___fortify_fail (msg=<optimized out>, 
    msg@entry=0x7ff7557e8d47 "buffer overflow detected") at fortify_fail.c:38
        do_abort = 2
#4  0x00007ff755773750 in __GI___chk_fail () at chk_fail.c:28
No locals.
#5  0x00007ff7557747c7 in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:25
No locals.
#6  0x000000000054932b in PcapQueue_readFromFifo::_socketRead (
    this=this@entry=0x292e260, socket=1095, 
    data=data@entry=0x7ff5c4000b50 "h\005", 
    dataLen=dataLen@entry=0x7ff5e67fbab8, timeout=timeout@entry=1)
    at pcap_queue.cpp:6547
        __d = 1095
        rfds = {fds_bits = {0 <repeats 16 times>}}
        tv = {tv_sec = 31, tv_usec = 79}
        rsltSelect = <optimized out>
        maxDataLen = 1000
#7  0x000000000055643b in PcapQueue_readFromFifo::socketRead (
    this=this@entry=0x292e260, data=data@entry=0x7ff5c4000b50 "h\005", 
    dataLen=dataLen@entry=0x7ff5e67fbab8, idConnection=<optimized out>)
    at pcap_queue.cpp:6538
No locals.
#8  0x0000000000556feb in PcapQueue_readFromFifo::threadFunction (
    this=0x292e260, arg=<optimized out>, arg2=44) at pcap_queue.cpp:5461
        detectSensorName = false
        detectSensorTime = false
        sensorId = <optimized out>
        sensorName = ""
        sensorTime = ""
        require_confirmation = -1
        counterEmptyData = 0
        buffer = 0x7ff5c4000b50 "h\005"
        offsetBuffer = 0
        countErrors = 0
        readLen = 0
        forceStop = false
        lastTimeErrorLogMS = 0
        blockStore = 0x7ff5c4000aa0
        bufferSize = 1000
        bufferLen = 0
        offsetBufferSyncRead = 0
        syncBeginBlock = true
        error = ""
#9  0x000000000066cbaf in vm_pthread_create_start_routine (arg=0x7ff700000ee0)
    at tools.cpp:5662
        thread_data = {
          start_routine = 0x53ea50 <_PcapQueue_readFromFifo_connectionThreadFunction(void*)>, arg = 0x7ff7000071e0, description = "pb - client 10.59.17.194"}
#10 0x00007ff759b45184 in start_thread (arg=0x7ff5e67fc700)
    at pthread_create.c:312
        __res = <optimized out>
        pd = 0x7ff5e67fc700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140694110848768, 
                3075006131295898178, 0, 0, 140694110849472, 140694110848768, 
                -3078402520661734846, -3079847928684066238}, 
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, 
            data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x00007ff75576403d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Here is our server config:

[general]
pcap_dump_zip = yes
pcap_dump_ziplevel = 6
pcap_dump_bufflength = 8184
pcap_dump_writethreads = 1
pcap_dump_writethreads_max = 32
pcap_dump_asyncwrite = yes
pcap_dump_zip_rtp = gzip
mysqlloadconfig = no
tar = no
tar_compress_sip = no
tar_compress_rtp = no
tar_compress_graph = no
interface = vmbr0
threading_mod = 4
mirror_bind_ip = 192.168.47.83
mirror_bind_port = 60000
managerport = 5029
sipport = 5060
sipport = 5555
sipport = 6000
cdr_sipport = yes
rtptimeout = 3600
ringbuffer = 2000
packetbuffer_enable             = yes
packetbuffer_compress           = no
max_buffer_mem                  = 12288
cdrproxy = yes
rtp-firstleg = no
deduplicate = no
deduplicate_ipheader = no
sipoverlap = no
sip-register = yes
sip-register-active-nologbin = yes
nocdr = yes
savesip = yes   
savertp = yes
savertcp = yes
savegraph = none
mos_g729 = no
mos_lqo = no
mos_lqo_bin = pesq
mos_lqo_ref = /usr/local/share/voipmonitor/audio/mos_lqe_original.wav
dscp = no
spooldir = /storage/voipmonitor
cachedir = /var/tmp/ramfs
promisc = yes
vm-buffer = 500

Thank you and please let me known if you need more details.

Hi,

I'm using the last git sniffer version.
I want to split RTP and SIP pcap by enabling :

pcap_dump_zip = yes
pcap_dump_ziplevel_sip = 6
pcap_dump_zip_rtp = lzo
tar = yes
tar_maxthreads = 8
tar_compress_sip = gzip
tar_sip_level = 6
tar_compress_rtp = lzo
tar_rtp_level = 1
pcapsplit = yes

No problem for SIP pcap, but for rtp, in the tar file I have several rtp files, for exemple :

0770afa6a216425d8fc8b7ae448a0d02.pcap
0770afa6a216425d8fc8b7ae448a0d02.pcap#1
0770afa6a216425d8fc8b7ae448a0d02.pcap#3
0770afa6a216425d8fc8b7ae448a0d02.pcap#5
0770afa6a216425d8fc8b7ae448a0d02.pcap#7
0770afa6a216425d8fc8b7ae448a0d02.pcap#9

When I try to open the first pcap, Wireshark says :
"The file 0770afa6a216425d8fc8b7ae448a0d02.pcap isn't a capture file in a format Wireshark understands."
The strange thing is that I can open the second one finishing by #1, BUT remains error "The capture file appears to have been cut short in the middle of a packet."

I don't know what to do with the others files.

Is this the right behaviour of the RTP spliting ? How to get rid of these issues ?

I also noticed that when setting pcapsplit = no , the pcap file format seems to be correct for wireshirk but don't be compressed in a tar file ?

Thanks for your help.

Just compiled version 17.4 and can not connect to psql via odbc.

Console output looks like this:
$sudo /usr/local/sbin/voipmonitor --config-file /etc/voipmonitor.conf --pid-file /var/run/voipmonitorinitscript.pid -n -i eth0 -k
Loading configuration from file /etc/voipmonitor.conf OK
voipmonitor version 17.4
voipmonitor[18773]: start voipmonitor version 17.4
local time 2016-10-26 15:43:29
voipmonitor[18773]: local time 2016-10-26 15:43:29
voipmonitor[18773]: detected rrdtool version 10308
voipmonitor[18773]: odbc query error: ERROR: syntax error at or near "like";
Error while executing the query
voipmonitor[18773]: odbc query error: ERROR: syntax error at or near "like";
...

Odbc test is successfull:
$ sudo isql -v voipmonitor voipmonitor
+---------------------------------------+
| Connected! |

Database remains clean, no tables.

Software versions:
unixODBC-devel-2.2.14-14.el6.x86_64
unixODBC-2.2.14-14.el6.x86_64

odbc.ini file:
[voipmonitor]
Description = PostgreSQL
Driver = PostgreSQL
Database = voipmonitor
Server = 10.0.X.X
Port = 5432
Protocol = 9.4
ReadOnly = No

odbcinst.ini:
[PostgreSQL]
Description = ODBC for PostgreSQL
Driver = /usr/pgsql-9.4/lib/psqlodbc.so
Setup = /usr/lib/libodbcpsqlS.so
Driver64 = /usr/pgsql-9.4/lib/psqlodbc.so
Setup64 = /usr/lib64/libodbcpsqlS.so
FileUsage = 1

Hi,

We are having some issues downloading some PCAP files. Although at the UI we can see that there is a pcap file available, and the link to download it is enabled, when trying to download the pcap we get following error:
File 2017-10-13/13/46/[SIP|RTP|ALL|REG]/1507901477844.pcap not found

Just to comment this specific error is not happening with all calls, but at some of them. At the moment we can not locate, to which calls we have that problem. It seems a bit random.

If possible to guide us, how to troubleshoot in order to understand why this is happening.

Thank you.

We need to make a tiny change in SipHeader parsing.
Can you tell me how can I open project in any IDE and compile?
is there any documentation on this project to understand the structure and classes?

Thank you

Hi!

I have some questions:

1. Is this reporsitory an "official" one, becuase there are different other repos in *.md files refrenced.
2. What is branching/tagging policy? Which branch/tag is "stable"? How to determine a branch of paticular version?

Following the instructions in README.freebsd on a fresh copy of the FreeBSD-provided VHD for FreeBSD-10.3-RELEASE I have yet to produce a usable binary.

Among other things, "lzo2" should be added to the list of packages to install, use of malloc.h instead of stdlib.h creates an error, malloc_trim() doesn't exist outside of glibc.

I am currently trying to bodge my way through it to see if I can make something useful build but I'm running in to a lot of "error: declaration of 'HeapSafeCheck' has a different language linkage" in the jitter buffer code which isn't making sense to me because your extern "C" entries seem to be where they need to be. I'm by no means familiar with integrating C and C++ code though so I'm just going by Google and guessing here.

I have two sensor - asterisk A and asterisk B. Also kamailio sip proxy without sensor. In pcap of side B at first leg i have corrupted pcap. Is it bug?
(rtp-firstleg = no option didn't help. should it?)

[email protected]_5060.zip

Hi,
This is what happens if I run make for the ssl_keylogger:

[root@Q01PBX002 ssl_keylogger]# pwd
/usr/local/src/voipmonitor-git/tools/ssl_keylogger
[root@Q01PBX002 ssl_keylogger]# make
gcc -c -fPIC -g3 sslkeylog.cpp -o sslkeylog.o
sslkeylog.cpp: In function ‘void create_write_thread()’:
sslkeylog.cpp:399: error: ‘pthread_create’ was not declared in this scope
make: *** [sslkeylog.o] Error 1

Any suggestions?

On CentOS 6.5, there is no json/json.h available in any package, and README does not indicate where to find it, or which-if any third party package to install to satisfy dependency.

make

g++ -c tools.cpp -g3 -Wall -march=native -mtune=native -O2 -DQUEUE_NONBLOCK2 -I/usr/local/include -I/usr/include/mysql/ -Wall -I jitterbuffer/ -L/usr/local/lib/mysql -L/usr/lib/mysql -L/usr/local/lib/ -L/usr/lib64/mysql -fPIC -g3 -O2
tools.cpp:28:23: error: json/json.h: No such file or directory

I cannot find the release to check out from the repo

Hi,
we experience a weird issue when setting skipdefault = yes on a remote sensor: calls that match a filter rule take up to 30 min to process. It seems as if voipmonitor only starts processing calls at half hour intervals, at a quarter to or a quarter past full hours (e.g. 12:15, 12:45, etc.). Could this just be a coincidence?
The other time voipmonitor starts processing the first call that matches a filter rule, is when there is a second matched call. It then processes the first, but not the second. In order for the second call to be processed, a third call would have to be matched to a filter rule (or one would have to wait up to half an hour).
The following is an example of a call from our logs, which took more than 6 minutes to start processing.

This is the last log entry before the call:

Sep 16 13:38:48 x.x.x.x voipmonitor[32585]: calls[0,r:0][0,r:0] PS[C:0/-0 r:-/- S:27/20 SR:- SM:- R:0/0 A:17280] SQLq[C:0 M:0 Cl:0] heap[0|0|0] [28.3Mb/s] t0CPU[0.6%] t1CPU[1.0%] t2CPU[pb:1.4/d3.2/s27.0/rm:3.1/rh:0.1/rd:0.5/S:35.3%] tRTP_CPU[0.1%/0.1m/1t] tacCPU[0.0%] RSS/VSZ[767|1012]MB LA[0.21 0.42 0.49|8h] TLB[1] v26.21.2

Here is the next entry with the two legs of the call that matched a filter rule:

Sep 16 13:38:58 x.x.x.x voipmonitor[32585]: calls[2,r:0][2,r:0] PS[C:0/-0 r:-/- S:29/21 SR:- SM:- R:169/169 A:17580] SQLq[C:0 M:0 Cl:0] heap[0|0|0] [29.0Mb/s] t0CPU[0.6%] t1CPU[0.9%] t2CPU[pb:1.3/d3.2/s28.0/rm:3.1/rh:0.2/rd:0.9/S:36.8%] tRTP_CPU[0.2%/0.2m/1t] tacCPU[0.2%] RRD[0.1%] RSS/VSZ[767|1012]MB LA[0.25 0.42 0.49|8h] TLB[6] v26.21.2

The call ends after a couple of seconds, but both legs are still in limbo six minutes later:

Sep 16 13:45:00 x.x.x.x voipmonitor[32585]: calls[2,r:0][2,r:0] PS[C:0/-0 r:-/- S:24/19 SR:- SM:- R:0/0 A:9327] SQLq[C:0 M:0 Cl:0] heap[1|1|0] [26.2Mb/s] t0CPU[0.6%] t1CPU[0.8%] t2CPU[pb:1.1/d2.4/s48.5/rm:2.1/rh:0.1/rd:0.6/S:54.8%] tRTP_CPU[0.1%/0.1m/1t] tacCPU[0.0%] RRD[0.1%] RSS/VSZ[767|1012]MB LA[0.90 0.61 0.53|8h] TLB[5] v26.21.2

We then get failed connection with the central sensor regarding sql. It seems unrelated, as we experience these issues even without skipdefault and it does not break our setup. Anyway, it is included here for completeness.

Sep 16 13:45:08 x.x.x.x voipmonitor[32585]: sql store - y.x.x.x : 6666 - loss connection - failed read()
Sep 16 13:45:08 x.x.x.x voipmonitor[32585]: send store query error: failed read query response
Sep 16 13:45:08 x.x.x.x voipmonitor[32585]: sql store - y.x.x.x : 6666 - loss connection - failed read()
Sep 16 13:45:08 x.x.x.x voipmonitor[32585]: send store query error: failed read query response

Voipmonitor now starts processing the call:

Sep 16 13:45:10 x.x.x.x voipmonitor[32585]: start PreProcessPacket out thread extend/2041
Sep 16 13:45:10 x.x.x.x voipmonitor[32585]: calls[0,r:0][2,r:0] PS[C:0/-0 r:-/- S:19/19 SR:- SM:- R:0/0 A:41] SQLq[C:0 M:0 Cl:0] heap[3|1|0] [26.3Mb/s] t0CPU[0.5%] t1CPU[0.8%] t2CPU[pb:0.4/d0.4/s100.6/rm:0.6/rh:0.0/rd:0.3/S:102.3%] tRTP_CPU[0.1%/0.1m/1t] tacCPU[0.1%] RRD[0.1%] RSS/VSZ[767|1012]MB LA[0.92 0.62 0.54|8h] TLB[6] v26.21.2
Sep 16 13:45:11 x.x.x.x voipmonitor[32585]: next attempt 1 - query: L187:INSERT INTO files #011#011SET datehour = 2020091613, #011#011    spool_index = 0, #011#011    id_sensor = 9300,
Sep 16 13:45:11 x.x.x.x voipmonitor[32585]: next attempt 1 - query: L418::MIG:INSERT IGNORE INTO rtp_stat ( `id_sensor`,`time`,`saddr`,`mosf1_min`,`mosf1_avg`,`mosf2_mi`

Voipmonitor is done processing the call:

Sep 16 13:45:20 x.x.x.x voipmonitor[32585]: calls[0,r:0][0,r:0] PS[C:0/-0 r:-/- S:76/58 SR:- SM:- R:0/0 A:38590] SQLq[C:0 M:0 Cl:0] heap[0|0|0] [26.3Mb/s] t0CPU[0.6%] t1CPU[0.7%] t2CPU[pb:2.0/d2.4/s2.5/rm:2.5/rh:0.4/rd:0.4/S:10.2%] tRTP_CPU[0.2%/0.2m/1t] tacCPU[0.1%] RSS/VSZ[767|1020]MB LA[0.85 0.62 0.54|8h] TLB[34] v26.21.2

edit: code formatting

I'm currently deploying the sniffer as a Docker container in order to monitor calls being made by sipp. For this, I'm using service:sipp networking mode and sniffing outgoing traffic from the sipp container. This works well for recording jitter and delay which appear to reflect conditions well.

The calls are ca. 2min in length and go to echo or to me for testing. It's just one at a time for now - I may sniff our production calls later. The codec is G711a and I'm just playing back the well-known wurlitzer sample in a loop.

However, no matter what I do, my MOS is at a stable 4.5. I've tried introducing massive packet loss (10%) with emnet and iptables on the Docker host, reordering packets a lot and introducing large amounts of jitter. In order to make sure it wasn't a local effect, I also limited the bandwidth to 1 kbit/s on the firewall (we have a cloud PBX). All of these produce clearly audible distortions, delays, reordering, stuttering etc. so the actual MOS was very low.

However, with -v 999 sniffer still reports:

elastic-helper0-voipmonitor | -call dump 0x5eb8000---------------------------------
elastic-helper0-voipmonitor | callid:[email protected]
elastic-helper0-voipmonitor | last packet time:1570637444
elastic-helper0-voipmonitor | last SIP response [200] [200 OK]
elastic-helper0-voipmonitor | ipport_n:2
elastic-helper0-voipmonitor | addr: 172.27.0.3, port: 6000
elastic-helper0-voipmonitor | addr: <snip>, port: 15004
elastic-helper0-voipmonitor | From:99977
elastic-helper0-voipmonitor | To:40
elastic-helper0-voipmonitor | First packet: 1570637343, Last packet: 1570637444
elastic-helper0-voipmonitor | ssrc_n:1
elastic-helper0-voipmonitor | Call statistics:
elastic-helper0-voipmonitor | SSRC:ca110000 3390111744 ssrc_index[0]
elastic-helper0-voipmonitor | codec:8
elastic-helper0-voipmonitor | src ip:172.27.0.3
elastic-helper0-voipmonitor | dst ip:<snip>
elastic-helper0-voipmonitor | dst port:15004
elastic-helper0-voipmonitor | Packetization:20
elastic-helper0-voipmonitor | s->received: 3438
elastic-helper0-voipmonitor | total loss:0
elastic-helper0-voipmonitor | loss ratio:0.000000
elastic-helper0-voipmonitor | serial loss: 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0
elastic-helper0-voipmonitor | d50: 0, d70: 0, d90: 0, d120: 0, d150: 0, d200: 0, d300: 0
elastic-helper0-voipmonitor | jitter stats:
elastic-helper0-voipmonitor | fix(50/50)	loss rate:	0.000000
elastic-helper0-voipmonitor | fix(50/50)	burst rate:	0.000000
elastic-helper0-voipmonitor | fix(200/200)	loss rate:	0.000000
elastic-helper0-voipmonitor | fix(200/200)	burst rate:	0.000000
elastic-helper0-voipmonitor | adapt(500/500)	loss rate:	0.000000
elastic-helper0-voipmonitor | adapt(500/500)	burst rate:	0.000000
elastic-helper0-voipmonitor | ---
elastic-helper0-voipmonitor | -end call dump  0x5eb8000----------------------------

voipmonitor.conf:

[general]
timezone = /usr/share/zoneinfo/Europe/Berlin
id_sensor = 1

sqldriver = mysql
mysqlhost = elastic-helper0-mysql
mysqlport = 3306
mysqlusername = root
mysqlpassword = my-secret-pw
mysqldb = voipmonitor
cdr_partition = yes
mysqlcompress = yes
mysqlloadconfig = no
sqlcallend = yes

cleandatabase = 7

interface = eth0
promisc = yes
#filter = udp or (vlan and udp)

managerport = 5029
sipport = 5060
cdr_sipport = yes
cdr_rtpport = yes
cdr_rtpsrcport = yes

absolute_timeout = 120
destroy_call_at_bye = 120
onewaytimeout = 120
sipwithoutrtptimeout = 120
rtptimeout = 120

ringbuffer = 50
packetbuffer_enable             = yes
packetbuffer_compress           = no
max_buffer_mem			= 1000

jitterbuffer_f1 = yes
jitterbuffer_f2 = yes
jitterbuffer_adapt = yes
plcdisable = no
callslimit = 5

cdrproxy = yes
cdr_ua_enable = yes

# ????
# this is important option if voipmonitor is sniffing on SIP proxy and see both RTP leg of CALL.
# in that case use this option. It will analyze RTP only for the first LEG and not each 4 RTP
# streams which will confuse voipmonitor. Drawback of this switch is that voipmonitor will analyze
# SDP only for SIP packets which have the same IP and port of the first INVITE source IP
# and port. It means it will not work in case where phone sends INVITE from a.b.c.d:1024 and
# SIP proxy replies to a.b.c.d:5060. If you have better idea how to solve this problem better
# please contact [email protected]
rtp-firstleg = no

deduplicate = no

sipoverlap = yes
sip-register = yes
sip-register-timeout = 5
sip-register-active-nologbin = yes
nocdr = no
cdronlyanswered = no
cdronlyrtp = no

skinny = no

maxpcapsize = 50
spooldir = /var/spool/voipmonitor
pcap_dump_bufflength = 8184
pcap_dump_zip = yes
pcap_dump_zip_rtp = lzo
pcap_dump_ziplevel_rtp = 1
pcap_dump_writethreads = 1
pcap_dump_writethreads_max = 32
pcap_dump_asyncwrite = yes

cachedir = /dev/shm/voipmonitor
savesip = yes
savertp = header
pcapsplit = yes
savertcp = yes
saveaudio_stereo = yes
silencedetect = yes
silencethreshold = 512
clippingdetect = yes
savegraph = yes

maxpoolsize		= 501200
maxpooldays		= 7
autocleanspool = yes
autocleanspoolminpercent = 1
autocleanmingb = 5
mos_g729 = yes

mos_lqo = yes
mos_lqo_bin = pesq
mos_lqo_ref = /usr/local/share/voipmonitor/audio/mos_lqe_original.wav
mos_lqo_ref16 = /usr/local/share/voipmonitor/audio/mos_lqe_original_16khz.wav

dscp = yes

Is this a bug or am I not getting something?

Upgrading central voipmonitor sniffer, web gui reports an incomplete configuration for remote sensors. Local sensor reports Connection refused.

Updated central server to use mirror_use_checksum = yes and mirror_require_confirmation = yes
Rebooted central server, everything seems to connect back up properly.

I didnt have these set before but with the upgrade I needed to turn it on. One of the sniffers had it enabled. I enabled it across all other sniffers and now the problem is gone.

Hey ,

I was wondering how I could compile the sniffer to MIPS64. I'm using the Debian Cross ToolChain but I'm having trouble getting a binary that actually executes.

Hi There. I've been trying to find the license files for this but I am unable to find any.
Can you direct me to where it is please?

The following commit broke our automated install environment, such as Ansible/Chef/Salt etc.

b47397a#diff-fbd9a43367ca2a7abeee7be783b3326b

Could you please provide a way to pass arguments to your install script so the Voipmonitor Sniffer can be installed via CLI without requiring user input?

We are a paying customer of Voipmonitor if that makes any difference.

When an rtp stream starts with an out-of-order first packet (with seq=0), any future packets which are out-of-order are not counted as packet loss. However, if the first packet (with seq=0) is received properly, then future packets which are out-of-order (caused by jitter), are counted as packet loss.

This can easily be reproduced by injecting jitter between two endpoints (sipp uac -> uas) using linux "tc" command. For calls which have their first packet received late, there is no packet loss but for calls which have their first packet received as expected, there is large packet loss (because of the jitter causing packets out-of-order).

I tend to think the desired behavior for "packet loss" should not include packets received out-of-order since they could be handled by jitter buffers (as reflected by the MOS score).

Also, in both scenarios the MOS scores are the same and not impacted.

We're noticing an issue since approx 19.3 where CDRs will stop writing to the SQL database. The SQLq counters increment for the C, C1, C2 and C3 variables, but no records appear to write down to MySQL.

We've tried a few config options, and also tried both MySQL and Percona, and tuned this. MySQL shows no process locks or deadlocks. The timing appears random, but it does seem like the locks may start under higher load.

Under normal load we'll see:

calls[237,r:172][237,r:172] PS[C:1/-0 r:17/-12 S:207/207 SR:71 SM:- R:25920 A:27460] SQLq[C:36480 C2:7799 C3:1610 M:0 R:0 Cl:0] heap[0|1|0] comp[42] [47.5Mb/s] tarQ[642] tarB[44MB] tarCPU[0.2|0.2|0.1|0.1|0.3|0.2%] t0i_ens3_CPU[4.4Mb/s;0.1%/2.3%] t0CPU[2.3%] t1CPU[0.1%/0.1%/0.8%/0.0%/0.2%] t2CPU[pb:2.8/d4.0/rm:3.4/rh:0.5/rd:3.6/S:14.2%] tRTP_CPU[16.6%/16.6m/1t] tsip_tcpCPU[8l|0/0s|0/0p] tacCPU[2.4%] RSS/VSZ[663|1312]MB LA[4.15 3.96 3.85] v19.5

but when it's not inserting we'll see:

Jun 8 15:50:23 voipmonitor voipmonitor[13185]: calls[191,r:94][191,r:94] PS[C:0/-1 r:12/-16 S:158/158 SR:50 SM:- R:20600 A:21720] SQLq[C:36403 C2:7722 C3:1532 M:0 R:0 Cl:0] heap[0|1|0] comp[42] [35.3Mb/s] tarQ[539] tarB[39MB] tarCPU[0.1|0.1|0.1|0.2|0.3|0.1|0.1%] t0i_ens3_CPU[3.1Mb/s;0.0%/2.6%] t0CPU[4.5%] t1CPU[0.1%/0.0%/0.7%/0.0%/0.2%] t2CPU[pb:1.6/d4.1/rm:2.5/rh:0.3/rd:2.6/S:11.2%] tRTP_CPU[11.7%/11.7m/1t] tsip_tcpCPU[9l|0/0s|0/0p] tacCPU[1.3%] RSS/VSZ[648|1312]MB LA[4.04 3.83 3.80] v19.5

The PCAPs appear to still write down.

Data is being sent across the mirror protocol from a number of distributed probes.

Currently testing develop b1e0ed3 and can see the issue, however have observed the issue with stock built 19.5, 19.4.2, 19.4.1, 19.3.

Base OS is Ubuntu 16 Linux voipmonitor 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux and we think we've ruled out OS issues. MySQL tables are healthy.

Hi,

I'm experiencing out-of-bound (i.e. less than 1.0) MOS values in the database, which shouldn't be possible. I patched the source to see where those values are coming from and they doesn't seem to originate from calculate_mos_fromrtp(). This is the patch I'm using:

diff --git a/rtp.cpp b/rtp.cpp
index a937bfd..efc8264 100644
--- a/rtp.cpp
+++ b/rtp.cpp
@@ -356,6 +356,7 @@ RTP::save_mos_graph(bool delimiter) {
        // reset 10 second MOS stats
        memcpy(channel_fix1->last_interval_loss, channel_fix1->loss, sizeof(unsigned short int) * 128);
        if(mosf1_min > last_interval_mosf1) {
+           if(last_interval_mosf1 != 45) printf("!last_interval_mosf1: %u (ssrc: %x)\n", last_interval_mosf1, getSSRC());
            mosf1_min = last_interval_mosf1;
        }
        mosf1_avg = ((mosf1_avg * mos_counter) + last_interval_mosf1) / (mos_counter + 1);
@@ -377,6 +378,7 @@ RTP::save_mos_graph(bool delimiter) {
        // reset 10 second MOS stats
        memcpy(channel_fix2->last_interval_loss, channel_fix2->loss, sizeof(unsigned short int) * 128);
        if(mosf2_min > last_interval_mosf2) {
+           if(last_interval_mosf2 != 45) printf("!last_interval_mosf2: %u (ssrc: %x)\n", last_interval_mosf2, getSSRC());
            mosf2_min = last_interval_mosf2;
        }
        mosf2_avg = ((mosf2_avg * mos_counter) + last_interval_mosf2) / (mos_counter + 1);
@@ -398,6 +400,7 @@ RTP::save_mos_graph(bool delimiter) {
        // reset 10 second MOS stats
        memcpy(channel_adapt->last_interval_loss, channel_adapt->loss, sizeof(unsigned short int) * 128);
        if(mosAD_min > last_interval_mosAD) {
+           if(last_interval_mosAD != 45) printf("!last_interval_mosAD: %u (ssrc: %x)\n", last_interval_mosAD, getSSRC());
            mosAD_min = last_interval_mosAD;
        }
        mosAD_avg = ((mosAD_avg * mos_counter) + last_interval_mosAD) / (mos_counter + 1);

If I start the application I see those printfs:

$ sudo ./voipmonitor -k -P /tmp/voipmonitor.pid --config-file /etc/voipmonitor.conf 
Loading configuration from file /etc/voipmonitor.conf OK
voipmonitor version 16.0
voipmonitor[25768]: start voipmonitor version 16.0
local time 2016-06-06 11:45:28
voipmonitor[25768]: local time 2016-06-06 11:45:28
voipmonitor[25768]: detected rrdtool version 10408
voipmonitor[25768]: connect - db version 5.5
voipmonitor[25768]: creating and upgrading MySQL schema...
voipmonitor[25768]: create procedure create_partition
voipmonitor[25768]: create procedure create_partition_v2
voipmonitor[25768]: create function getIdOrInsertUA
voipmonitor[25768]: create function getIdOrInsertSIPRES
voipmonitor[25768]: create function getIdOrInsertSIPREQUEST
voipmonitor[25768]: create function getIdOrInsertREASON
voipmonitor[25768]: create function getIdOrInsertCONTENTTYPE
voipmonitor[25768]: create procedure PROCESS_SIP_REGISTER
voipmonitor[25768]: done
voipmonitor[25768]: create cdr partitions - begin
voipmonitor[25768]: create cdr partitions - end
voipmonitor[25768]: create rtp_stat partitions - begin
voipmonitor[25768]: start PreProcessPacket out thread detach/25806
voipmonitor[25768]: start ProcessRtpPacket hash out thread 25807
voipmonitor[25768]: start ProcessRtpPacket hash next thread 25808
voipmonitor[25768]: start ProcessRtpPacket distribute out thread 25809
voipmonitor[25768]: create rtp_stat partitions - end
voipmonitor[25768]: drop old partitions rtp_stat - begin
voipmonitor[25768]: drop old partitions - end
detect oneshot buffer
method 1 success
oneshot buffer: 7f6c28000d50
packet: 7f6c28000d50
device: eno2
offset: 744
voipmonitor[25768]: find oneshot libpcap buffer : success
!last_interval_mosAD: 38 (ssrc: 241cc7cd)
!last_interval_mosf1: 41 (ssrc: 8d48f0)
^C
voipmonitor[25768]: SIGINT received, terminating
voipmonitor[25768]: packetbuffer terminating: pcap_close pcapHandle (eno2)
voipmonitor[25768]: packetbuffer terminating (queue): cleanupBlockStoreTrash
voipmonitor[25768]: terminated - cleanup calls
voipmonitor[25768]: terminated - call cleanup
voipmonitor[25768]: stop PreProcessPacket out thread detach/25806
voipmonitor[25768]: terminated - async
voipmonitor[25768]: terminated - tar - flush queue
voipmonitor[25768]: terminated - tar
voipmonitor[25768]: terminated - sql store 11
voipmonitor[25768]: terminated - sql store 41

However they only partly correspond to the database entries:

MariaDB [(none)]> SELECT ID,calldate,callend,a_mos_min_mult10,a_mos_f1_min_mult10,a_mos_f2_min_mult10,a_mos_adapt_min_mult10,b_mos_min_mult10,b_mos_f1_min_mult10,b_mos_f2_min_mult10,b_mos_adapt_min_mult10 FROM voipmonitor.cdr WHERE connect_duration IS NOT NULL;
+----+---------------------+---------------------+------------------+---------------------+---------------------+------------------------+------------------+---------------------+---------------------+------------------------+
| ID | calldate            | callend             | a_mos_min_mult10 | a_mos_f1_min_mult10 | a_mos_f2_min_mult10 | a_mos_adapt_min_mult10 | b_mos_min_mult10 | b_mos_f1_min_mult10 | b_mos_f2_min_mult10 | b_mos_adapt_min_mult10 |
+----+---------------------+---------------------+------------------+---------------------+---------------------+------------------------+------------------+---------------------+---------------------+------------------------+
|  3 | 2016-06-06 11:48:14 | 2016-06-06 11:49:45 |               45 |                  45 |                  45 |                     45 |               45 |                   1 |                  45 |                     45 |
|  4 | 2016-06-06 11:49:21 | 2016-06-06 11:50:35 |               45 |                  45 |                  45 |                     30 |               45 |                  45 |                  45 |                     45 |
|  6 | 2016-06-06 11:51:06 | 2016-06-06 11:51:36 |               45 |                  45 |                  45 |                     45 |               45 |                  45 |                  45 |                     45 |
|  7 | 2016-06-06 11:49:41 | 2016-06-06 11:51:37 |               45 |                  41 |                  45 |                     45 |               45 |                  45 |                  45 |                     45 |
|  8 | 2016-06-06 11:51:13 | 2016-06-06 11:51:30 |               45 |                   1 |                  45 |                     45 |               45 |                  45 |                  45 |                     45 |
| 10 | 2016-06-06 11:51:49 | 2016-06-06 11:52:26 |               45 |                  45 |                  45 |                     45 |               45 |                  45 |                  45 |                     45 |
+----+---------------------+---------------------+------------------+---------------------+---------------------+------------------------+------------------+---------------------+---------------------+------------------------+
6 rows in set (0.00 sec)

I'm especially curious about the values 1, which would correspond to a MOS value of 0.1! I tried disabling threading, as I thought there might be a race condition, but that didn't help either.
Looking at the corresponding *.graph files the MOS values are 45 (0x2d).

BR,
Ole

Hi,

There is a typo in debian/docs file (in develop branch): README_raspian.md

The correct filename is README_raspbian.md

Thank you

Hi!

What is a reference OS for voipmonitor sniffer?

Hi,

We are testing the sniffer for some time now. We've got set:
savertp=yes
pcapsplit=no

For some reason only SIP packets are being written to the pcap file. If we switch to pcapsplit=yes, sniffer writes SIP and RTP to the separate files. Am I missing something or it's a bug?

Hello,

I see here https://github.com/voipmonitor/sniffer/releases that at one point releases were being tagged, but nowadays they are not.

Can you please tag the releases again so it is easy to integrate with automation tools?

Thank you!
Joel.

voipmonitor-amd64-17.0.1-static
openSUSE 13.2 (x86_64)

Reindexfiles is not working correctly.
If I start the sniffer, the sipsize column will be populated for new captures.
However if I telnet localhost 5029 then reindexfiles, the sipsize column is set to 0.
If voipmonitor is restarted, all prior sipsize are set to 0

We have 2 sniffers using the same database, and pcapsplit = no
Attached is config for sniffer1
voipmonitor1.conf.txt

Two asterisks are connected by IAX2 Trunk , and voipmonitor records calls between SIP extensions,
but if an extensions dials an IVR extension on asterisk, no CDR is saved and voipmonitor does not record the call.
I guess it is because in this case there is no Ringing event generated by asterisk and directly 200 OK response is generated.
Is there any way to say voipmonitor to record all calls, even those which are routed to IVR.

Hi Team,

Do you have any plans to add support for video codecs in the future?

Thanks,

John.

Is custom_header handling broken or I just doing something wrong?

I set custom_headers_cdr option in my config (I see it can be set as custom_headers also); voipmonitor creates additional columns in cdr_next table, but does not populate them.

I checked the code - it seems writing them into cdr_next was obsoleted, and they should go into cdr_custom_headers instead, but that table does not get created and so this all does not work.

Is it really a bug or I am missing something?

My version is voipmonitor version 17.14, downloaded directly as binary from your website.

I have a technical question about the voipmonitor sniffer. I'm trying to use the SSL decoder (libdssl) in the sniffer, and I'm having an issue when only one call direction is decoded. Can I somehow set this up in a way to view both directions? I think the issue is that I don't have the remote party's private key.

Perviously I got error -28: CERTIFICATE_KEY_MISMATCH. However my PBX has certificate verification disabled, so I've removed this error. Now I've hot error -13: CORRUPTED_PMS (Pre-master secret).

Hi There,

The voipmonitor process is down again and again on centos7.How i can trace this problem?I really appreciate this if you help me

Thanks
ALi

The voipmonitor.sip_msg table isn't being propagated with data. The team here has previously reported that there was data there, but we can no longer select that data. I've verified that every partition has zero rows.

Hi,

Is it possible to monitor as well http traffic? IF possible, is there something that we need to enable at the sniffer configuration file?

I can see at the UI, that there are some filters that can be applied for HTTP, so I guess that it is possible to monitor HTTP as well.

Thank you.

Some time ago I successfully compiled v17.0 static binary. I'm not sure if it's something with my setup, or with later versions of voipmonitor that cause static binaries to "abort", while dynamically linked binaries work fine. Could you provide the build scripts you use to create the static binaries you distribute on your website? Since you are creating static binaries, are you using uclibc or musl?

Hi,

I'm trying to compile on an armbian based machine, configure has run successfsully but make doesn't know what to do.

root@espressobin:/sniffer# uname -m
aarch64
root@espressobin:/sniffer# uname -a
Linux espressobin 4.19.14-mvebu64 #5.69 SMP PREEMPT Thu Jan 10 12:03:52 CET 2019 aarch64 GNU/Linux

root@espressobin:~/sniffer# cat /etc/armbian-release

PLEASE DO NOT EDIT THIS FILE

BOARD=espressobin
BOARD_NAME="Espressobin"
BOARDFAMILY=mvebu64
VERSION=5.69
LINUXFAMILY=mvebu64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image

Is there any chance you'll consider updating the build environment to support this architecture? Is there something more you need from me to assist?

Thanks

Mark

Another rpmlint warning produced by the open build service checks.

[ 133s] voipmonitor.x86_64: I: binary-or-shlib-calls-gethostbyname /usr/sbin/voipmonitor
[ 133s] The binary calls gethostbyname(). Please port the code to use getaddrinfo().

Hi,

Tried this on 17.1, and I think it appeared somewhere after 15.0. This is a major bug.
Below is our configuration, pay attention to spooldir and cachedir :

[general]
interface = eth0
sipport = 5060
sipport = 5080
ringbuffer = 20
vmbuffer = 50
jitterbuffer_f1 = yes
jitterbuffer_f2 = yes
jitterbuffer_adapt = yes
rtp-firstleg = no
deduplicate = no
sip-register = no
sip-register-active-nologbin = yes
nocdr = yes
savesize = 9961472
savesip = yes
savertp = yes
pcapsplit = no
spooldiroldschema = yes
savertcp = yes
savegraph = no
mos_g729 = no
matchheader = [Redacted]
custom_headers = [Redacted]
domainport = yes
spooldir = /tmp/spooldir
cachedir = /tmp/cachedir
promisc = yes
sqlcallend = no
sqldriver = mysql
mysqlhost = 127.0.0.1
mysqldb = voipmonitor
mysqltable = cdr
mysqlusername = root
mysqlpassword = [Redacted]
tar = no

We end up with the following files in spooldir (the path is "doubled" /tmp/spooldir/tmp/spooldir)

# find /tmp/spooldir
/tmp/spooldir
/tmp/spooldir/2016-08-25
/tmp/spooldir/tmp
/tmp/spooldir/tmp/spooldir
/tmp/spooldir/tmp/spooldir/2016-08-25
/tmp/spooldir/tmp/spooldir/2016-08-25/41142754-e5a8-1234-8094-842b2b021718.pcap
/tmp/spooldir/tmp/spooldir/2016-08-25/422e9ec8-e5a8-1234-80a2-0026b959a530.pcap
/tmp/spooldir/filesindex
/tmp/spooldir/filesindex/audiosize
/tmp/spooldir/filesindex/rtpsize
/tmp/spooldir/filesindex/sipsize
/tmp/spooldir/filesindex/graphsize
/tmp/spooldir/rrd
/tmp/spooldir/rrd/2db-heap.rrd
/tmp/spooldir/rrd/2db-SQL.rrd
/tmp/spooldir/rrd/2db-drop.rrd
/tmp/spooldir/rrd/2db-callscounter.rrd
/tmp/spooldir/rrd/db-LA.rrd
/tmp/spooldir/rrd/2db-tCPU.rrd
/tmp/spooldir/rrd/2db-PS.rrd
/tmp/spooldir/rrd/2db-tacCPU.rrd
/tmp/spooldir/rrd/db-memusage.rrd
/tmp/spooldir/rrd/2db-speedmbs.rrd

And in cachedir it's even worse, as it becomes a mix of the two (/tmp/cachedir/tmp/spooldir ?)

# find /tmp/cachedir/
/tmp/cachedir/
/tmp/cachedir/tmp
/tmp/cachedir/tmp/spooldir
/tmp/cachedir/tmp/spooldir/2016-08-25
/tmp/cachedir/tmp/spooldir/2016-08-25/422e9ec8-e5a8-1234-80a2-0026b959a530.pcap
/tmp/cachedir/tmp/spooldir/2016-08-25/3f44c3db-e5a8-1234-d988-ecf4bbd16a10.pcap
/tmp/cachedir/tmp/spooldir/2016-08-25/2fb15085-e5a8-1234-c6b7-842b2b6d8199.pcap

I do not see anything in the changelog that was supposed to alter the behavior of these two options, any idea?

Hi,

really trivial issue, using markdown will increase readability.

For the filenames, it could be like this:

• README_debian.md
• README_freebsd.md
• etc...

Here's how it could look:

What is VoIPmonitor

VoIPmonitor is open source live network packet sniffer which analyze SIP
and RTP protocol. It can run as daemon or analyzes already captured pcap
files. For each detected VoIP call voipmonitor calculates statistics about
loss, burstiness, latency and predicts MOS (Meaning Opinion Score) according
to ITU-T G.107 E-model. These statistics are saved to MySQL database and each
call is saved as pcap dump. Web PHP application (it is not part of open
source sniffer) filters data from database and graphs latency and loss
distribution. Voipmonitor also detects improperly terminated calls when
BYE or OK was not seen. To accuratly transform latency to loss packets,
voipmonitor simulates fixed and adaptive jitterbuffer.

Key features

• Fast C++ SIP/RTP packet analyzer
• Predicts MOS-LQE score according to ITU-T G.107 E-model
• Detailed delay/loss statistics stored to MySQL
• Each call is saved as standalone pcap file
• Call recorder

Sponsors and contributors

• Telephonic http://telephonic.ca

• init script, configuration file

Installation

Check README_*.md

In the event of VoIPmonitor crash we'd like to store call details SQL on disk.
Tried to turn this feature on while using version 21.7 of the sniffer and ran into some trouble.

Test environment is CentOS7 kernel 3.10.0-693.17.1.el7.x86_64 DigitalOcean with mysql Ver 15.1 Distrib 5.5.56-MariaDB.

When I enable query_cache = yes in voipmonitor.conf, I get the following error messages:

Feb  6 22:50:55 centos1-tick1-dev-tor2 voipmonitor[2530]: next attempt 124 - query: select * from international_rules
Feb  6 22:50:55 centos1-tick1-dev-tor2 voipmonitor[2530]: query error in [select * from international_rules]:  1146 - Table 'voipmonitor.international_rules' doesn't exist
Feb  6 22:50:56 centos1-tick1-dev-tor2 voipmonitor[2530]: next attempt 125 - query: select * from international_rules
Feb  6 22:50:56 centos1-tick1-dev-tor2 voipmonitor[2530]: query error in [select * from international_rules]:  1146 - Table 'voipmonitor.international_rules' doesn't exist
Feb  6 22:50:57 centos1-tick1-dev-tor2 voipmonitor[2530]: next attempt 126 - query: select * from international_rules
Feb  6 22:50:57 centos1-tick1-dev-tor2 voipmonitor[2530]: query error in [select * from international_rules]:  1146 - Table 'voipmonitor.international_rules' doesn't exist

Fix mos_min_mult10, a_mos_min_mult10, b_mos_min_mult10 being derived from mos*_avg and not from mos*_min, as one would expect: mos.patch

Also, opt_mosmin_f2 should IMHO default to zero. Why is this option available anyway?

After commit 8cb99a5 my Jenkins build failed due to libxml2 and librrd being missing. Obviously that's expected when my system didn't have those libraries, but I believe the configure script is supposed to check for missing libraries and the README files should probably be updated to mention those now being required as well.

Hello,

Hope you don't mind, I would like to suggest some additional improvements on VoIPMonitor's datamodel.

• Tables CDR and CDR_NEXT : on MySQL/Mariadb (5.6) the calldate column lacks of granularity. It seems the DateTime object does not contain Milliseconds , but only saves up to Seconds, which leads that there is no way of getting a true list of CDR events ordered by calldate ASC or DESC. In fact, the way it is set nowadays, and when you have special requirements such as multi-leg calls (in my case, from SIP Trunk to Proxy to B2BUA to SIP Trunk) , most of the time the CDRs will not appear in an ordered way (from 1st Leg to last Leg ordered). Ordering by CDR ID is of no use neither as the order is not strict: I do have CDRs of the last LEG C in between LEG A and LEG B when ordering by CDR ID or Calldate....

• there is no direct way to have a call hierarchy: how can one know which CDR originated the next CDR? i could not find a 100% certain/100% sure way of doing it that apart from JOINing CDR_NEXT and CDR with CallDate and filtering by CALLED and CALLER. The problem is that the ORDER is not correct as the CDRs are not saved in order of coming. Having a hierarchical order in CDR_NEXT (for example) will allow anyone to check the full flow a call, from LEG A to LEG X. If anyone has a suggetion on how to do this, I will be happy to order a pizza and a beer and make it delivered to your home! .... as long as you have Uber Eats nearby :)

Hello fellow developers...

I have followed the instructions and successfully installed voipmaster:
https://github.com/voipmonitor/sniffer/blob/develop/README.debian

But the problem is, it seems voipmonitor is crashing after start...

Where and what I might did wrong? Where I can find logs?

Hi,

In /etc/voipmonitor.conf I set some options regarding maxpoolsize and maxpooldays:

maxpoolsize = 61440
maxpooldays = 7

But my files remain for more than 7 days and take hdd space.

What I actually need to have my files cleaned regularly - running voipmonitor service only or some actions defined in crontab? What process manages files?

Thanks.

mysql-devel is properly installed, but configure script does not locate, and indicates libmysqlclient is missing:

# ./configure
checking for g++... g++
.....
checking for main in -lmysqlclient... no
configure: error: Unable to find libmysqlclient. apt-get install lbmysqlclient-dev | yum install mysql-devel

# rpm -ql mysql-devel
.......
/usr/lib64/mysql/libmysqlclient.so
/usr/lib64/mysql/libmysqlclient_r.so
/usr/share/aclocal/mysql.m4

I am not a pro at writing configure scripts, so maybe the information above will help