È una situazione in cui molti di noi si sono ritrovati - hai due file separati, uno con il contenuto video che desideri, e l'altro che contiene l'audio corrispondente. Forse hai scaricato un film muto e una traccia di commento separata, o hai registrato una presentazione e l'audio separatamente. Qualunque sia il caso, ora ti trovi di fronte al compito di unire questi due in un unico file coeso. In questo post, esploreremo come fare esattamente questo utilizzando lo strumento FFmpeg.

L'analisi

FFmpeg è un software libero e open source che consente di manipolare file multimediali. Può convertire audio e video in quasi qualsiasi formato, ed è molto utilizzato per lo streaming di video e audio.

La soluzione

Il comando che utilizzeremo oggi è il seguente:

ffmpeg -i video.mp4 -i audio.mp4 -c:v copy -c:a aac -map 0:v:0 -map 1:a:0 output.mp4

Ora, facciamo un'analisi dettagliata di questo comando:

1. ffmpeg: È il comando che avvia il programma FFmpeg.

2. -i video.mp4 -i audio.mp4: Questi sono i file di input. Il primo -i video.mp4 indica a FFmpeg che video.mp4 è il nostro file video di input, mentre il secondo -i audio.mp4 indica che audio.mp4 è il nostro file audio di input.

3. -c:v copy -c:a aac: Queste opzioni definiscono i codec che vogliamo utilizzare. -c:v copy dice a FFmpeg di copiare il codec video originale. -c:a aac dice a FFmpeg di usare il codec audio AAC per il file di output.

4. -map 0:v:0 -map 1:a:0: Questi comandi mappano i flussi di input al file di output. -map 0:v:0 dice a FFmpeg di prendere il primo flusso video (v:0) dal primo file di input (0) e -map 1:a:0 dice di prendere il primo flusso audio (a:0) dal secondo file di input (1).

5. output.mp4: Questo è il nome del file di output. Il file risultante sarà un file .mp4 con il video dal primo file di input e l'audio dal secondo file di input.

Ecco fatto! Con un solo comando, potete unire un video con un audio. Spero che questo post vi sia stato utile. Se avete domande o commenti, non esitate a lasciarli qui sotto.

It's a situation many of us have found ourselves in - you have two separate files, one with the video content you want, and the other containing the corresponding audio. Perhaps you've downloaded a silent film and a separate commentary track, or you've recorded a presentation and the audio separately. Whatever the case may be, you're now faced with the task of merging these two into a single, cohesive file. In this blog post, we'll explore how to do exactly that using the FFmpeg tool.

The analysis

FFmpeg is a free and open-source software that allows you to manipulate multimedia files. It can convert audio and video into almost any format, and it is widely used for video and audio streaming.

The solution

The command we will be using today is as follows:

ffmpeg -i video.mp4 -i audio.mp4 -c:v copy -c:a aac -map 0:v:0 -map 1:a:0 output.mp4

Now, let's do a detailed analysis of this command:

1. ffmpeg: This is the command that starts the FFmpeg program.

2. -i video.mp4 -i audio.mp4: These are the input files. The first -i video.mp4 tells FFmpeg that video.mp4 is our input video file, while the second -i audio.mp4 tells FFmpeg that audio.mp4 is our input audio file.

3. -c:v copy -c:a aac: These options define the codecs we want to use. -c:v copy tells FFmpeg to copy the original video codec. -c:a aac tells FFmpeg to use the AAC audio codec for the output file.

4. -map 0:v:0 -map 1:a:0: These commands map the input streams to the output file. -map 0:v:0 tells FFmpeg to take the first video stream (v:0) from the first input file (0) and -map 1:a:0 tells FFmpeg to take the first audio stream (a:0) from the second input file (1).

5. output.mp4: This is the name of the output file. The resulting file will be a .mp4 file with the video from the first input file and the audio from the second input file.

And there you have it! With a single command, you can merge a video with an audio. I hope this post has been helpful. If you have any questions or comments, don't hesitate to leave them below.

Cheers!

In this article I want to answer this question: How can I restrict the normal user to run only limited set of commands.

So I describe step-by-step the method to create a linux user able to access to the console of a linux server but with limited permission to run commands. This method is useful when, for example, you want to give access to one of your collaborators without risking that he can launch commands as an administrator.

The idea is to use the restricted shell rbash and declare which commands the user are able to run.

The step-by-step guide

1. create the new user

   adduser <username>
   

   compile all the requested fields. The most important is the password that will be used to access the server (for example in SSH).

2. set the rbash as shell for the new user

   chsh -s /bin/rbash <username>
   

3. create a bin directory under the user home directory

   mkdir /home/<username>/bin
   chmod 755 /home/<username>/bin/
   

4. change the user's default PATH to the bin directory

   echo "PATH=$HOME/bin" >> /home/<username>/.bashrc
   echo "export PATH" >> /home/<username>/.bashrc
   

5. create symlinks of the command(s) that the user require to bin directory under the user home directory

   ln -s /bin/ping /home/<username>/bin/
   ln -s /bin/traceroute /home/<username>/bin/
   ln -s /bin/htop /home/<username>/bin/
   ln -s /bin/top /home/<username>/bin/
   ln -s /bin/df /home/<username>/bin/
   ln -s /bin/bmon /home/<username>/bin/
   ln -s /bin/ps /home/<username>/bin/
   ln -s /bin/date /home/<username>/bin/
   ln -s /bin/netstat /home/<username>/bin/
   ln -s /bin/free /home/<username>/bin/
   

6. restrict the user from modifying ~/.bashrc

   chattr +i /home/<username>/.bashrc
   

These are the basic steps to achieve the purpose. However, I want to add one more of non-core but stylistic step: print the list of available commands when the user login in console. For this purpose I user motd.

1. create motd 99-available-commands

   touch /etc/update-motd.d/99-available-commands
   

2. add the list of available commands

   cat << EOF >> /etc/update-motd.d/99-available-commands
   #!/bin/sh
   export TERM=xterm-256color
   echo "$(tput setaf 4)-------------------------------------------------------------------------------
   -- Available commands:
   -------------------------------------------------------------------------------$(tput setaf 7)
   bmon          - Bandwidth monitor and rate estimator
   date          - Display the current time or system date
   df            - Report file system disk space usage
   free          - Display amount of free and used memory in the system
   htop          - Interactive process viewer
   netstat       - Display ethernet and protocol info and statistics
   ping          - Verify IP level connectivity
   ps            - Display information about running processes
   top           - Display Linux processes
   traceroute    - Trace the path/hop from one network to another
   $(tput setaf 4)-------------------------------------------------------------------------------$(tput setaf 7)
   "
   EOF
   

3. set the right permission to the file

   chmod 755 /etc/update-motd.d/99-available-commands
   

Now the user when logging in will see a list of enabled commands like this

Thanks to

• Victor Wong for you comment in this StackOverflow discussion
• my evoseed team

Do you work with asterisk 11.6 and PostgreSQL 9?
Have you decided to upgrade PostgreSQL to version 13 and now Asterisk gives you bad errors at startup and most important no longer saves any lines in the CDRs?

ERROR[12558] res_config_pgsql.c: PostgreSQL RealTime: Query Failed: SELECT a.attname, t.typname, a.attlen, a.attnotnull, d.adsrc, a.atttypmod FROM (((pg_catalog.pg_class c INNER JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace AND c.relname = 'sipfriends' AND n.nspname = current_schema()) INNER JOIN pg_catalog.pg_attribute a ON (NOT a.attisdropped) AND a.attnum > 0 AND a.attrelid = c.oid) INNER JOIN pg_catalog.pg_type t ON t.oid = a.atttypid) LEFT OUTER JOIN pg_attrdef d ON a.atthasdef AND d.adrelid = a.attrelid AND d.adnum = a.attnum ORDER BY n.nspname, c.relname, attnum
ERROR[12558] res_config_pgsql.c: PostgreSQL RealTime: Query Failed because: ERRORE:  the d.adsrc column does not exist
ERROR[12558] res_config_pgsql.c: Failed to query database columns for table sipfriends
ERROR[12558] cdr_pgsql.c: Failed to query database columns: ERRORE:  the d.adsrc column does not exist

I found myself in this situation and I want to tell you how I got out of it.

The analysis

Googling I found the problem: some asterisk files (cdr/cdr_pgsql.c, cel/cel_pgsql.c and res/res_config_pgsql.c) query various system tables (such as pg_class, pg_type, pg_attribute) including in the select also the column d.adsrc (d is pg_attrdef table) but PostgreSQL 12 finally removed column adsrc from table pg_catalog.pg_attrdef (column default values), which has been deprecated since version 8.0.

The problem is well described:

• in the post on this mailing list: cdr_pgsql: accesses obsolete (and finally removed) column
• in the reference asterisk Jira task

As described in the task on gerrit: fortunately, the same information which once was stored in adsrc is accessable via column adbin and function pg_catalog.pg_get_expr, which is the recommended way since PostgreSQL 8.0. So here is the patch: https://gerrit.asterisk.org/c/asterisk/+/13027/

The solution

So for me the possible ways were mainly 3:

1. upgrade Asterisk to the latest version, hoping (or rather, reading all the changelogs) that the problem would not occur there;
2. downgrade PostgreSQL to a version earlier than 11;
3. recompile Asterisk 11.6 with the patch indicated in the asterisk task.

Of course, the best thing is to always have up-to-date systems, maybe not at the latest version but at the latest stable version; so thinking of keeping Asterisk 11.6 or downgrading PostgreSQL are not the best choices.
At the same time, it is true that jumping from Asterisk 11.6 to Asterisk 18 is not easy and before putting the system into production with Asterisk 18 I would have had to do many tests; instead I had little time and I needed to restore the full functionality of the voice system.
I decided to opt for the third choice recompile asterisk 11.6 with the patch indicated in the asterisk task and here I will describe the steps I have successfully followed.

The steps that I followed are easy and with more or less 0 downtime for the customers

# I git clone the asterisk source code in tmp folder 
# and checkout the 11.6 version
cd /tmp
git clone https://github.com/asterisk/asterisk.git
cd asterisk
git checkout certified/11.6
# I install the needed packages
# You can also use the install_prereq (take a look at Linkography section)
apt-get install ncurses-dev libxml2-dev sqlite3 libsqlite3-dev libpq-dev
# I configure the installation
./configure
make menuselect # remember to select all the module and functions you need
# I ran the patch by editing these files
vim cdr/cdr_pgsql.c # https://gerrit.asterisk.org/c/asterisk/+/13027/2/cdr/cdr_pgsql.c
vim cel/cel_pgsql.c # https://gerrit.asterisk.org/c/asterisk/+/13027/2/cel/cel_pgsql.c
vim res/res_config_pgsql.c # https://gerrit.asterisk.org/c/asterisk/+/13027/2/res/res_config_pgsql.c
# I lunch the make
make
# I remove the actual asterisk installation
apt-get remove asterisk asterisk asterisk-config asterisk-core-sounds-en asterisk-core-sounds-en-gsm asterisk-moh-opsound-gsm asterisk-modules
# and in the end I install the compiled and patched version
make install

If your system consists of several asterisk nodes, one clone of the other (i.e. with the same OS), you do not need to compile asterisk on each node to update any additional asterisk nodes, but you can follow these steps

1. go to the asterisk node where you recompiled and create an archive of the asterisk folder

    cd /tmp
    tar -cvzf asterisk11-6-patched.tar.gz asterisk
   

2. move the tar.gz on the asterisk node to be patched

3. decompress the tar.gz, remove the current version of asterisk and install the patched one

    cd /tmp
    tar -xvzf asterisk11-6-patched.tar.gz
    cd asterisk
    apt-get install build-essential
    apt-get remove asterisk asterisk-config asterisk-core-sounds-en asterisk-core-sounds-en-gsm asterisk-moh-opsound-gsm asterisk-modules
    make install
   

Start asterisk, make a call and check your CDR. You will see that the data is there now!

Linkography

• Compile asterisk
• Install the needed software for asterisk compiling
• Mailinglist post
• Asterisk Jira task
• Asterisk patch commit
• PostgreSQL remove adsrc commit

Cheers!

This is an article accompanying code found in this github repo.

The idea and the purpose

The purpose of this article is to explain how to deal with SIP over TSL. In the this github repo the evoseed team explains a simple way to deploy a Kamailio server in a docker container with TLS enabled using Let's Encrypt.

Thanks to Fred Posner's article we have understood that there are 2 ways to deal with TLS in Kamailio:

quoting Fred Posner:

1. Use a purchased certificate

   • Pro: easy to deploy on the client side

   • Cons: expensive, painful acquisition model

2. Use a self-signed certificate

   • Pro: free

   • Cons: difficult to deploy on the client side

• if you use a self-signed certificate (not certified by any authority) on your SIP Server, necessarily on the client side you must use its calist.pem; so free but difficult to deploy on the client side.
  If you want to go down this road here you can find my guide. You can also find the procedure here and here on Kamailio's site):

• if you use a certificate trusted by a guarantor authority recognized by the client then client-side should not need to load the calist.pem; so easy to deploy on the client side but expensive.
  If you want to go down this road you have to buy a certificate and then put it in your Kamailio installation following the same procedure describe for self-signed certificates.

There is, however, an alternative that is free, automatable, easy to use and requires no client-side configuration: Let’s Encrypt.

I wrote this article and created this github repo to take a step forward from Fred's excellent article https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/.
Fred explains how to install Let's Encrypt and create a certificate (using letsencrypt-auto, which unfortunately is no longer supported) and how to configure the certificate in kamailio.
I want to go one step further and explain how to have a recipe and a ready-to-use docker-compose that allows you to:

• pre-configure the TLS certificate for your domain

• pre-configure kamailio to use the certificate

• have a container that checks the validity of the certificate and autonomously performs the renewal when necessary

• have, ready-to-use, an nginx reverse proxy that uses the certificate: HTTP 80 -> HTTPS

The project structure

/doc
/modules/db
/modules/kamailio` 
/modules/nginx
env-template
docker-compose.yml

Step to deploy

1. clone the repository in your deploy machine git clone https://github.com/evoseed/kamailio-tls-letsencrypt .

2. pre-configure the TLS certificate for our domain

   • Install docker-compose.

   • Modify configuration of nginx
     Of course change your.domain.com with you real domain and change 1.2.3.4 with your real IP address.

     • Linux users

         cd modules/nginx/nginx-certbot
         sed -i 's/${DOMAIN}/your.domain.com/g' init-letsencrypt.sh
         sed -i 's/${DOMAIN}/your.domain.com/g' data/nginx/app.conf
         sed -i 's/${IP}/1.2.3.4/g' data/nginx/app.conf
       

     • MacOS users

         cd modules/nginx/nginx-certbot
         sed -i '' 's/${DOMAIN}/your.domain.com/g' init-letsencrypt.sh
         sed -i '' 's/${DOMAIN}/your.domain.com/g' data/nginx/app.conf
         sed -i '' 's/${IP}/1.2.3.4/g' data/nginx/app.conf
       

   • Run the init script and follow the Let's encrypt instructions:

       ./init-letsencrypt.sh
     

     NB It's quite important to compile correctly the conf in this way; in particular Organization Name and Common Name with your domain

3. return in the root of the project and compile the .env file following the env-template file

    cd ../../.. && cp env-template .env
   

   and complete the .env file

4. start all the containers

     docker-compose up -d
   

The running project

When everything has started, what you will see is more or less this:

CONTAINER ID   IMAGE                    COMMAND                  CREATED       STATUS       PORTS     NAMES
48838aee0057   kamailio-test_kamailio   "/etc/kamailio/boots…"   2 hours ago   Up 1 hour                kamailio
8103e16bd845   kamailio-test_db         "docker-entrypoint.s…"   2 hours ago   Up 1 hour                db
e212e6c8241f   certbot/certbot          "/bin/sh -c 'trap ex…"   2 hours ago   Up 1 hour                certbot
3c101597b160   nginx:1.15-alpine        "/bin/sh -c 'while :…"   2 hours ago   Up 1 hour                nginx

The kamailio container, your SIP Server
the db container
the nginx container as reverse proxy for HTTP to HTTPS and the certbot container who will check every 12 hours whether certificates are still valid or need to be renewed (and will renew them independently if necessary)

Technical details

1. NB this project is designed for dev purpose, so it is not optimized for production.

   • docker-compose for example use the build stage

       ...
       build:
         context: ./modules/db
         dockerfile: Dockerfile
       ...
     

     so if you want to have a production ready version you can use built image:

       ...
       image: your.registry.com/project-name/db:latest
       ...
     

2. NB this project is designed to run on a VM to which the domain you configured in init-letsencrypt.sh and in the .env points and with a correct domain.

   If you run the init-letsencrypt.sh on your local private machine and you set ${DOMAIN} = your.domain.com you'll receive an error like this

    Requesting a certificate for your.domain.com
   
    Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
    Domain: your.domain.com
    Type:   dns
    Detail: no valid A records found for your.domain.com; no valid AAAA records found for your.domain.com
   
    Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
   
    Some challenges have failed.
    Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
    ERROR: 1
   

   This happens because Let's Encrypt need to test if you are the admin of the domain.

3. How is the creation of certificates and their use automated in kamailio?

   As you can see in the docker-compose.yaml file, the certbot container and the kamailio container mount both volumes with the same source directory: ./module/nginx/nginx-certbot/data/certbot/conf/.
   So the certbot create (and renew) the certificates and kamailio use them.

Thanks to

• Fred Posner for your article

• Kamailio SIP Server and all your community

• Philipp Schmieder for your nginx-certbot repo

• my evoseed team

In this episode, I'll continue on this trend, talking about the audio problems and quality of communication.

Good customer service includes quality control with proactive monitoring and feedback analysis for continuous improvement.
Proactive monitoring can be somewhat expensive (but we will see that it does not necessarily have to), but it is definitely a long-term investment.
In your opinion is it better to save on proactive monitoring and quality systems and that your customer reports anomalies and poor quality of calls, or is it better that you monitor the quality of services and that you proactively contact the customer (before do him) in case of anomalies?

I am talking about combining the more classic QoS with QoE.

In this article I will talk about:

• which are the parameters to be taken into account to evaluate an audio problems
• which are the parameters to be taken into account to evaluate the goodness of a call
• how to monitor these values

Audio problems

The main audio problems are related to:

• internet connection problems: if your internet connection is poor, or is not dedicated to VoIP audio, you can run into the following problems
  • Packet loss: the packet loss in a VoIP call is recognizable by a robotic or synthetic voice and gaps
  • Jitter: jitter is the divergence of an expected voice packet from its presumed arrival time. For instance, two packets may arrive at the same time, or out of order due to network congestion. These problems can cause audio quality to drop. A jitter buffer then is an intermediary queue that’s used to order packets according to their expected timing values in an attempt to minimize jitter. Using a jitter buffer can potentially improve call quality. The Jitter in a VoIP call is recognizable by a distorted voice
  • Latency: The high latency in a real-time communication risks making the service unusable. The Latency in a VoIP call is recognizable by a collisions when people start to talk at the same time

The tools mentioned in the previous article can help you find out if the call was affected by these network problems.

• other strange audio problems
  • echo: echo problems follow 3 main rules
    • is always generated in the opposite side of who is hearing the echo
    • is frequently caused by the PSTN, use and echo canceller
    • turn-off the speaker phone and use the handset to test

There's an old but interesting CISCO guide titled "Recognizing and Categorizing Symptoms of Voice Quality Problems", that I found thanks to Flavio E. Goncalves, which can be useful for categorizing the audio problem you are having.
You can find it here: https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/30141-symptoms.html

A fundamental metric to analyze the goodness of a VoIP call is the MOS (Mean Opinion Score).
MOS is terminology for audio, video and audiovisual quality expressions as per ITU-T P.800.1. It refers to listening, talking or conversational quality, whether they originate from subjective or objective models.

Very Good: 4.3-5.0
Bad: 3.1-3.6
Not Recommenced : 2.6-3.1
Very Bad: 1.0-2.6

Calculating the MOS of each call could be challenging; fortunately the RTCP protocol comes to our aid: RTCP is a protocol that collects statistics on the quality of service of the RTP protocol and carries information about the participants in a session.

Each VoIP call then uses the SIP to "organize and manage" the call, the RTP to manage the exchange of audio and the RTCP to monitor its quality.

Homer (just to name one at random :) ) makes our life even easier as it traces the RTCP data into a very comfortable graphic format like this

Quality of a call: the journey to QoE

The quality, in a broad sense, of a call is not only given by the goodness of the audio stream.
There are other parameters that those who do business with VoIP traffic must take into consideration.
The ACD and ASR parameter are the most commonly used metrics to indicate VoIP route quality, but there are also other interesting ones:

• ACD (Average call duration): It is the average length of an answered call made over the network:
  ACD = duration of all answered calls / number of answered calls
  For example, if there were 62 answered calls with a total duration of 145 minutes, then:
  ACD = 145 [duration of all answered calls] / 62 [total number of answered calls] = 2.34 minutes
  An ACD of 4–5 minutes is considered okay, whereas anything above 6 minutes is excellent.
• ASR (Answer-Seizure Ratio): ASR is the percentage of the number of successfully connected calls to the number of attempted calls (it is also called the call completion rate):
  ASR % = (total number of answered calls / total number of calls) × 100
  For example, if there were 156 calls dialed of which 62 were successfully connected, then:
  ASR (%) = (62 [successful calls] / 156 [dialed calls]) x 100 = 39.74%
  ASR should be at least 40–50%, and anything above 60% would indicate an excellent quality service.
• NER (Network Effectiveness Ratio): NER measures the ability of a network to deliver a call to the called terminal. Busy signals and other call failure due to user behaviour are counted as "successful call delivery" for NER calculation purposes. Unlike ASR, NER excludes the effects of customer and terminal behaviour. NER(%) = ((answered calls + user busy + ring no answer + terminal reject)/(total number of calls)) x 100
• PDD (Post-Dial Delay) Post-dial delay is the measurement of how long it takes for a calling party to hear a ringback tone after initiating a call. Technically it is the delta between the SIP INVITE and a 180 Ringing or 183 Session Progress response. High PDD values are the main reasons for the low ASR. People don’t want to wait too long before hearing the ringtone, and they close the phone when it’s not connected. This will cause to miss calls. When the caller closes, call ends and there will be no re-route.

How to monitor the call quality

Also in this article I will again mention the Sipcapture team and and their valuable work done in the latest versions of Homer; they integrated Grafana, creating default dashboards that track a lot of very interesting data, for example the datas from RTCP

You can also find the Homer's Grafana dashboard here: https://grafana.com/grafana/dashboards/11764

In my experience, I have combined the use of Homer with a double control based on zabbix&grafana.
I use Homer's Grafana dashboards to monitor the general trend of the call flow passing through our SIP servers, while I use a specific data collection via Zabbix&Grafana to track and graph the specific data of the call quality and quantity with the carriers; I need this to keep constantly monitored our suppliers.
This is an example of one of our Grafana boards to track the quality of the service provided to us by suppliers in real time

The use of tools like grafana are also powerfull to predict the trend of the use of your resources.

So my advice at the end of this article as Hans Rosling says in his book Factfulness is: rely on the data, they are the only antidote to the cliché

That’s all for this episode too. Let me know what you think about it.

Thanks a lot for reading, sharing and comment this article.

Thanks to undraw.co for the beautiful illustration I used in the header

Cheers!

To be continued …

In this episode I'll talk about the main tools to analyze VoIP issues:

• whireshark / tshark
• sngrep
• homer

Whireshark / tshark

Quoting from the official website :

Wireshark is the world’s foremost and widely-used network protocol analyzer. It lets you see what’s happening on your network at a microscopic level and is the de facto (and often de jure) standard across many commercial and non-profit enterprises, government agencies, and educational institutions. Wireshark development thrives thanks to the volunteer contributions of networking experts around the globe and is the continuation of a project started by Gerald Combs in 1998.

On the official website and in general on the internet you will find many tutorials to work to the maximum potential with this special tool.

I will now give you some quick examples (with some screenshots) of using this tool:

1. open the whireshark program and choose, in the main screen, which interface you want to analyze. I choose my wifi interface

2. Now you'll start to see the flow of all the packages flowing through your interface. We set the filter suitable for our purpose: we choose to monitor only SIP packets. It's very easy, just go to the "Apply a display filter" bar and type SIP

3. now let's try to make a SIP call from our client and see what happens in whireshark.
   And voilà, here are all the SIP packets of the call. You can double-click on every package to enter in detail mode and see all the details of the layers of the particular packet

There is an interest section for the VoIP troubleshooting, the Telephony menu; here you can find:

• the VoIP Calls menu with the Flow sequence view
• the RTP/RTSP menu, to analize the MOS and quality of stream
  and so on.

The (very small) limitation of this tool is that if I have to do a realtime analysis on a remote server (which has no graphical environment), I will first have to make a capture with tshark, download the pcap file on my PC and then open the file with wireshark to analyze it thoroughly

Tshark is a network protocol analyzer as wireshark. Is more or less the same tool, but it has no GUI, you drive it from the shell. It is therefore very convenient for servers that do not have a graphical environment.
As you can see the result of capture is the same, but in shell An interest option of tshark is -w

If the -w option is specified when capturing packets or reading from a capture file, TShark does not display packets on the standard output. Instead, it writes the packets to a capture file with the name specified by the -w option.

So the typical use I make of the tshark + wireshark combo is:

• I launch tshark with -w on the remote server where I have to troubleshoot
• when I have captured what I need I interrupt tshark
• I download the pcap locally
• and at this point I open the pcap file with whireshark and proceed to an in-depth analysis of the problem

Sngrep

sngrep is a useful tool for displaying SIP call message flows. It supports live capture to display realtime SIP packets and can also be used as PCAP viewer. sngrep supports UDP, TCP and TLS.

I don't dwell on how to install the tool, there is a lot of material on the net; here are some links:

• https://support.simwood.com/hc/en-us/articles/223811708-Packet-Capturing-sngrep
• http://sipxcom.org/get-to-know-sngrep/

It is very useful when you need to make realtime captures on servers without a graphical environment. Sngrep graphics are very intuitive, its strength is to show the flow of SIP messages in visual form.

When you run sngrep, you star to see the list of calls

Then you can decide to enter in the details of a specific call to see all the packets

With sngrep you can also filter and save in pcap format (so it could be an alternative to tshark to capture calls and then analyze in depth with wireshark)

Thanks to Alex Lane for the images

Homer

Homer from Sipcapture is a magnificent tool that Change the way you Analyze RTC and Debug VoIP Services.

HOMER is part of the SIPCAPTURE stack: A robust, carrier-grade and modular VoIP and RTC Capture Framework for Analysis and Monitoring with native support for all major OSS Voice platforms and vendor-agnostic Capture agents.

With Homer there is no need to activate a capture in realtime as much as your client has a problem, with Homer you have all the call flows ready to use and accessible from a very usable dashboard.

The Homer ecosystem is composed, simplistically speaking, of a capture server and a capture agent.
The agent runs on your VoIP network, captures packets and sends them to the server. The server stores them and makes them usable.

On sipcapture website you will find a lot of more precise details.

I want to conclude with a thought that I have accrued in my experience as a problem solver:

• never skip any of the 4 phases:

  1. symptom collection: interview the customer who reports the problem to you with targeted questions; collect the symptoms and discard the hypotheses of diagnosis that the client brings you.
     When a sick person goes to the doctor, the doctor holds the parts like "I have acute pain here. I ate this yesterday. Every time I do this movement I feel sick. It had already happened to me", and discards phrases like "I think I have indigestion ".
     The diagnosis is up to you and not by your client.

  2. anamnesis: after the client has explained the symptoms to you, collect all the important information that can help you with the diagnosis that you will have to make in the next phase; try to reduce the variables

  3. diagnosis / analysis: with the list of symptoms and anamnesis combined with your experience, do the magic!

  4. resolution: implement the solution to solve the problem that the customer has reported to you. Then call your customer and explain to him, without all the details but with an exhaustive description, what you encountered and how you solved him.

• when you approach a problem, do not discard the simplest reasons in favor of abstruse hypotheses, on the contrary, start from the simplest hypotheses. Usually when we open the problem that a customer reports to us, we immediately start off on the tangent and begin to hypothesize astral conjunctions, abstruse bugs or crazy hackers .. and then most of the time the problem is that the power plug is unplugged.

That’s all for this episode too. Let me know what you think about it.

Thanks a lot for reading, sharing and comment this article.

Thanks to undraw.co for the beautiful illustration I used in the header

Cheers!
We are quite close to the end of this mini-series, but I've some other surprise
To be continued …

In this episode I'll quickly talk about the most common configurations of the PBX, including its security.

A SIP user agent (UA) is a logical network end-point used to create or receive SIP messages and thereby manage a SIP session.
A SIP UA can perform the role of a User Agent Client (UAC), which sends SIP requests, and the User Agent Server (UAS), which receives the requests and returns a SIP response. These roles of UAC and UAS only last for the duration of a SIP transaction.

The most common configurations for a PBX used to make and receive VoIP calls are as follows:

• PBX with public interface: in this case, the PBX will usually have two network interfaces, a private one to communicate with the phones in the LAN, and a public one to communicate with the provider from which it purchases the VoIP numbers.
  In this configuration, the system administrator who manages the PBX will have to pay close attention to its security as it is exposed to attacks from the public network; however, problems related to the presence of private IPs in SIP packets or in the SDP will be rare (if in the SIP packets sent to the provider that provides the VoIP account, there are private IPs, you could run into calls with one-way audio or that do not take place).

• PBX with private interface behind NAT: in this case, the PBX has only 1 network interface with private IP. It is behind the management of a router that will populate the NAT tables and route the packets to and from the PBX.
  This type of configuration could be more secure but can generate NAT traversal problems. The problems of this type are due to the fact that the PBX having only a private interface, if not well configured, could forge its packets with private IP; the SIP proxy that will receive an INVITE with Via, Contact, and SDP with private IP, will have serious difficulties in managing the call in the best possible way.
  Some routers implement SIP ALG mechanisms to parse and rewrite SIP packet headers where necessary; however, these mechanisms usually do not work correctly and therefore it is preferable to disable them.
  Usually SIP proxies implement NAT HELPER mechanisms, which by comparing the IP of origin of the SIP packet with the IPs contained in its headers will understand if the UA that generated the request is behind NAT or not; if it understands that the PBX is behind NAT, it will attempt to correct the private IPs present in the headers.
  Kamailio , a beautiful Open Source SIP Server, for example, has an entire module dedicated to the nathelper , with functions such as fix_nated_contact() that rewrites the "Contact" header.

Some PBXs (for example Asterisk) implement configurations and mechanisms for proper management behind NAT:

1. the externip (external host) parameter, to be added to the asterisk sip.conf indicates the IP that will be used as the source for all SIP messages when the PBX is behind NAT; configuring this parameter will allow asterisk to forge SIP packets correctly.
2. Another tipical mechanisms is the STUN (Simple Traversal of UDP through NAT). STUN is an industry standard approach for traversal of NAT and the technical details are published as RFC 3489.
   This mechanism relies on an external server (STUN server); the PBX, when it has to forge a SIP packet, will contact the STUN server; the STUN server will ask: Is the PBX behind a NAT device? What is the external IP address of the NAT device? It will then find the answers, and the external IP address of the PBX will be returned to the PBX; the PBX can then use it to correctly forge its SIP packets.

Nowadays any service exposed on the internet is subject to attacks by malicious users. If you have a PBX (at home or in the cloud), the illegitimate users and bots will repeatedly attempt to break into yours system trying to authenticate with different credentials.

Security tips:

1. The first thing to do to secure the PBX is to configure a firewall to protect it, inhibiting access to:
   • all unnecessary ports (DENY by default)
   • all unnecessary source IP addresses (put only the IP from which your customer will have to access the switchboard).
2. Apply restrictions at the source IP level
   If you know where the packets will come from (VoIP operator, phones that connect from the outside) enables access only to IP addresses known.
   If, on the other hand, you do not have the possibility to know in advance the IP addresses source or ranges, use the GEOIP functionality to limit access to "your county" / European IPs only.
3. Protect yourself with strong passwords
   Use strong passwords (letters + numbers + special characters) of at least 12 characters for both SIP users and HTTP users (if access the WEB panel they can do what they want).
4. International calls
   If you don't need it, block your PBX from being able to do so calls to international numbers and / or extra-cost numbers.
   A possible alternative, if provided by the switchboard, is that of enable international calls by entering a PIN code.
5. Anti-fraud An additional level of security is to be able to "close the gate when some oxen have escaped ". In this sense, use a VoIP provider which has automatic management within its system anti-fraud allows you to limit the damage; the system will block calls outgoing (or only international ones) when the consumption threshold will be been exceeded.
6. Use Fail2Ban (if you PBX is a linux based machine)
   Fail2ban is a security tool written in Python. It is meant for prevent brute force attacks. Scan log files and block IP addresses that have too many password failures or use of exploits. (source Wikipedia) It is able to read system and PBX service log files and blacklist IP addresses responsible for login attempts repeated.

Here a complete representation of a VoIP call from caller to callee

That’s all for this episode too. Let me know what you think about it.

Thanks a lot for reading, sharing and comment this article.

Thanks to undraw.co for the beautiful illustration I used in the header

Cheers! To be continued in " part #5: the main tools for working with VoIP " …

In this episode I’ll talk about the SDP & RTP:

1. What is SDP
2. Codec
3. What is RTP

As I mentioned in the previous articles, SIP is only one of the protocol engaged in a VoIP call.
The SIP is the protocol that deals with the exchange of messages (on UDP or TCP) to establish, modify and terminate a session. However, it does not deal with the exchange of the audio stream.

The management and exchange of the audio stream is delegated to 2 other protocols: the SDP and the RTP.

What is SDP

The SDP protocol is used to describe the details of the multimedia session.
The details of the session can be found in the body of some SIP messages (such as the INVITE or 200 OK).

This is a screenshot of an INVITE take with Wireshark (one of the useful tools for debugging the SIP; we will see in detail in one of the next episodes)

As you can see, the SIP, as we already know, it’s composed of: Request-Line, Message Header (I talked about the most important headers in the last episode) and Message Body.

Let’s expand the package:

The Request-Line (yellow) is composed by the Method and the Request-URI (the destination of the packet).
The Message Header (green) is made up of all the headers we talked about last episode.
And the Message body (blue) contains the SDP informations.

The most important SDP informations to know are the c and the m lines. In the Connection Data, the c field there is the IP address at which you want to receive the multimedia stream.
The Media Descriptions, the m field describes the port at which the stream is to be received and its encoding (the codecs you are allowed to use).

If you are talking to a SIP switch on the public network and in the c field you put your private IP (instead of your public IP), the call may have one-way audio, because the SIP exchange you want to contact will not know which is your public IP where to send the audio stream; so they will hear you but you don’t hear them.

Codec

Codecs are comparable to languages known to humans. If you have to talk to a person, you have to use a common language, otherwise you will not understand each other. If your mother tongue is different, before starting to converse, you will agree on which language to speak.
It could happen that you say: "I know English, French and Spanish and you?", and your interlocutor replies: "I know Russian, Slovenian and English, so let’s speak in English".
The only language common to you two is English and therefore your communication will take place in English.
This is the mechanism that underlies the management of codecs in a VoIP communication.

Caller and callee declare in the SDP the supported codecs in order of preference.
In the presence of several common codecs between the caller and the callee, the first codec chosen by the callee is generally used.
In any case it is possible to have media streams with any of the supported codecs and they can change during the phone call.
To undo the declaration of support for a given codec (or to declare that a new one is supported) you need to send a new INVITE (RE-INVITE) with a new SDP.

It could happen that the two interlocutors do not have a language, a codec in common; in this case the communication cannot be established, unless there is a B2BUA in the communication that offers the Transcoding service, i.e. it will act as simultaneous translator.

Each codec has a numeric code and a name that identifies it.
The most used voice codecs in Europe are:
8 pcma (or g711-alaw)
18 g 729
9 g722
3 gsm
0 pcmu (or g711-ulaw)
13 comfort noise
101 telephone event

In the example above, you can see that the caller proposed the following codecs: 8, 0, 101 (Look in the Media Description m line).

What is RTP

The RTP (Real-time Transport) application protocol takes care of sending a media stream to the endpoint.
The only transport protocol used is UDP.
The port to which the stream is to be received is communicated in the SDP, in the field m.

In this image, taken with another tool (sngrep) that we will see in the next episode, you can see the SIP packets (red and green) and the RTP stream (white).

That’s all for this episode too.
Let me know what you think about it.

Thanks a lot for reading, sharing and comment this article.

Thanks to undraw.co for the beautiful illustration I used in the header

Cheers!
To be continued in " part #4: UA PBX, standard configurations " …

In this episode I’ll talk about the basic SIP headers:

1. Request-URI
2. From & To
3. Call-ID
4. Via & Contact
5. Record-route & Route
6. P-Asserted-Identity Remote-Party-ID e P-Preferred-Identity

Request-URI

The Request-URI indicates the URI (the address) of the UAS to which the packet is to be sent.

The initial Request-URI (of an INVITE not in dialog) must be equal to the URI present in the To field (except for REGISTERS).

How to write a R-URI? The Request-URI of requests in dialog must follow this rule:

• if there are NO Record-Route header, the Request-URI must be equal to the URI present in the Contact of the response.
• if there are Record-Route headers:
  1. if the first URI of the Record-Route headers contains the parameter lr, then the UAC must use the Contact of the response to populate the Request-URI (plus it must add the routes)
  2. if the first URI of the Record-Route headers does NOT contain the lr parameter, then the UAC must use the first Record-Route header of the response to populate the Request-URI

From & To

The From

From: “0123456” <sip: 0123456@192.0.2.123>; tag = 1234

This header indicates the logical entity from which the request originates; usually it is the AOR (address-of-record) of the user.
It contains a SIP or SIPS URI and can contain the display name (“0123456” in our example). This field is used by the SIP proxy that receives the request, to determine which “processing rule” to apply to this request (for example, that user may not be enabled for calls).

The To

To: “0123456” <sip: 0123456@192.0.2.124>; tag = 1234

This header indicates the logical entity you want to contact, the AOR of the target user of the request.
It contains a SIP or SIPS URI and can contain the display name (“0123456” in our example).

Call-ID

Call-ID: f88f9s8f8fsd898332-fff23fsf-23@192.0.2.234

It is used as a globally unique identifier to group a series of SIP messages.
In all requests and responses exchanged by UA in the same dialog, it must always be the same. It should be the same in all registration requests from a UA. Combined with the from-tag and the to-tag, it uniquely identify a dialog.

Via & Contact

The Via (present in a request) identifies the address at which the person who generated the packet expects to receive the response.
The Contact contains a SIP or SIPS URI and represents a direct way to contact whoever generated the packet.

So the Via says where to send the answers; the contact instead indicates where to send future requests in the same dialog.
To find out where to send a 200OK (which is a response) I will use the address present in the Via, while to send a BYE (which is a request) I will use the address present in the Contact.

Via works with the breadcrumbs mechanism: a new Via is added to the head from each SIP element that packet passes through and the previous hops are left.

Record-route & Route

Only proxies that use the Loose Routing mechanism will add record-routes to the SIP packet.
This mechanism allows a proxy to continue to be “visited” (engaged) for the duration of the dialog.
The loose routing proxy adds the record-route header to a SIP request to force future requests in the thick dialog to always pass through it.
Route headers are used to force the routing of requests through to a list of proxies.

With the Record-routes the path is memorized and with the Routes the routing is managed properly.

Record-routes and routes also work with the breadcrumbs mechanism.

Thanks to https://docplayer.it/2339191-Sip-session-initiation-protocol.html

P-Asserted-Identity Remote-Party-ID e P-Preferred-Identity

The P-Asserted-Identity is used to communicate that the identity of the caller has occurred (for example using Digest Authentication, SSO with token, etc) and it is the one indicated in the P-A-I header.
The recipient will be able to use this information instead of providing authentication, if he considers the generator of that header an entity to be trusted, then he will be able to use that information instead of providing authentication.
If an entity (e.g. a carrier) receives a P-A-I from an entity it does not know (eg not you, someone on the internet), then it will not consider that identity proven, but will use some form of authentication (or simply ignore the call).

The Remote-PID is the old header that was used before in place of the P-A-I, now obsolete (albeit used).

The P-Preferred-Identity is an indication by a User Agent on which identity a receiving proxy that header should use in the P-A-I.
The proxy may decide to use that identity (for example if more than one can be applied), put it in P-A-I, and remove P-P-I from the outgoing INVITE.

This is an INVITE packet. All the green one is an header; the most used we have described above.
In the lower part there is the description of the SDP. We will address this topic in the next episode.

That’s all for this episode too.
Let me know what you think about it.

Thanks a lot for reading, sharing and comment this article.

Thanks to undraw.co for the beautiful illustration I used in the header

Cheers!
To be continued in " part #3: SDP & RTP " …

In this episode I’ll talk about the basic concepts of SIP:

• Session Initiation Protocol
• Transaction, dialog e session
• Request e response
• B2BUA, server e proxy SIP

SIP: Session Initiation Protocol

SIP is an application layer protocol; it can establish, modify and terminate a multimedia session, such as a VoIP call. SIP mainly uses 5 features in managing a communication session:

• user location: to determine the location of the user to communicate with
• user availability: to determine the willingness of the called user to participate in the communication
• user capabilities: to determine the parameters to be used for the media stream
• session setup: to establish the session between two or more users
• session management: to manage transfers, modification of session parameters and session termination.

However, SIP is not a complete communication system, it is only one of the components to be used for complete communication. SIP is usually used together with the SDP protocol (for the description of the multimedia session) and RTP (for the real-time transport of the multimedia streaming). We will discuss about it in part #3: SDP & RTP article.

The main 4 stages of a SIP session are:

• location: search for the location of an endpoint
• signal: signaling the willingness to communicate with it
• negotiation: negotiation of session parameters
• teardown: session closure

The registration of the VoIP account (done through the REGISTER packets) is the way in which SIP servers can acquire the location information (IP addresses, ports and contacts) of their users; during registration, the location server receives the REGISTERS from its users and saves (usually in a database) the association of IP address: port and contact, through a binding operation. This data will be useful to the SIP server when it has to contact the user to route a direct call to him (location stage).

In SIP, therefore, registration is used for the routing of incoming calls while it has no role in the authorization of outgoing calls, which is done with the Proxy-Authorization mechanism inserted within the INVITE.

Transaction, dialog e session

SIP is a transactional protocol based on a REQUEST / RESPONSE model, similar to the HTTP model. Each SIP transaction consists of a single REQUEST and at least one RESPONSE (0 or more provisional and one or more final responses) to it. The transaction will be destroyed after sending the final response.

A SIP dialog is a peer-to-peer relationship between two UA (user agents) that persists for a certain time and it’s a series of transactions between this two SIP peers. The INVITE is the only SIP packet that can establish a dialog and the response can be either 2xx or 101–199 with To tag (a failure response does not establish a dialog). A SIP dialog is uniquely identified by From-tag, To-tag and Call-id.

A SIP session is a collection of participants and media streams between them; it is participated by clients (such as SIP phones, softphones, etc) and by servers (such as SIP registrar, SIP location, SIP proxy).

Request e response

A SIP request is identifiable by the Request-Line as the first line of packet. The Request-Line contains the method name, the Request-URI and the protocol version.

INVITE sip: 0123456@192.0.2.124 SIP / 2.0

The main methods are 6:

• REGISTER: is used by the UA to indicate its physical location to a SIP registrar server
• INVITE: is used to start a session (or to update one in progress)
• ACK: is used to confirm that a final response to an INVITE has been received
• CANCEL: is used to terminate a pending INVITE, which did not receive a final response
• BYE: is used to end the session
• OPTIONS: is used to make a request to servers about their capacity other common methods are SUBSCRIBE, NOTIFY, PUBLISH, INFO.

A SIP response is identifiable by the Status-Line as the first line of packet. The Status-Line contains the protocol version followed by the Status-Code in numerical form, followed by the reason phrasees

SIP / 2.0 200 OK

The are 6 types of responses (divided in 2 macro categories): PROVISIONAL RESPONSE

• 1xx provisional response: show the receipt of the request, its processing and the status of the server

FINAL RESPONSE (indicate to the UAC the final response of the UAS, resulting from the processing of the REQUEST)

• 2xx success: indicate the positive reception, understanding and acceptance of the request
• 3xx redirection: indicate that further actions are required to complete the request
• 4xx client error: tell that the request contains incorrect syntax or that it cannot be satisfied by this server
• 5xx server error: tell that this server cannot fulfill an apparent valid request
• 6xx global error: tell that the request cannot be satisfied by any server

B2BUA, server e proxy SIP

A B2BUA (back to back user agent) is a logical entity that receives SIP requests and processes them as if it were a UAS (user agent server), therefore as if it were the ultimate recipient of the request. To know how to respond to the request, a B2BUA also acts simultaneously as a UAC (user agent client) and generates new requests; it will then manage a dialog with the UAC from which the requests arrive and a dialog with the final UAS that must receive them. A B2BUA maintains the status of the dialog and will have to participate in every request of that dialog. Why use a B2BUA: it is used when you need to have full control of the requests arriving on your SIP server in order to build on it the business logic (for example a billing system).

A SIP server is a network element that receives SIP requests and sends replies. Some examples of SIP servers: proxy, UAS, registrar server.

A SIP proxy is an intermediary entity that acts as a server and client with the purpose of getting requests to clients. The tasks of a proxy are:

• routing management: its job is to find the way to get the request to the right client
• policy compliance management: for example checking that a user can make the call

That’s all for this episode too.
Let me know what you think about it.

Thanks a lot for reading, sharing and comment this article.

Thanks to undraw.co for the beautiful illustration I used in the header

Cheers!
To be continued in " part #2: the basic SIP headers " …

More specifically, VoIP refers to the set of application layer communication protocols that make this type of communication possible.
The information (both the signaling to establish, manage and close the call, and the voice), instead of traveling on an analog telephone line, crosses any network based on an IP protocol.
The communication that the VoIP system allows to obtain is of the real-time audio-video, unicast or multicast type (therefore video calls and videoconferences, for example), and allows you to easily reach any type of user.
It therefore offers the possibility to make and receive calls from other VoIP numbers, analogue numbers, national numbers, international numbers, fixed and mobile users, all toll-free numbers and emergency numbers.

Here , thanks to getvoip.com , you can find a nice and complete article on the birth and evolution of the VoIP, from 1928 to today.

In the last years the development of VoIP has been very fast and its technology is constantly evolving; all of this was possible thanks to the widespread diffusion of high performance and broadband internet connections.

For data transport (the voice), in the vast majority of VoIP implementations, a set of communication protocols such as RTP (Real-time Transport Protocol) over UDP (User Datagram Protocol) over IP (Internet Protocol) are adopted. The use of UDP instead of TCP is justified by the fact that a real-time communication such as voice cannot tolerate additional or too high delays or latencies due to the retransmission of lost packets.
For the signaling (that is everything that concerns the reaching of the user, the establishment of the call, the maintenance of communication and then the closure of the call) there is a vast dominance of the use of the SIP protocol, over both UDP and TCP.

The web is full of article and video about this topic.
One of the most viewed YouTube video is this one

In this mini-series of articles I want to give my contribution on this topic. The series will be divided into the following parts:

• pilot #0: (the article you are reading) a brief introduction to the mini-series
• part #1: basic concepts of SIP
• part #2: the basic SIP headers
• part #3: SDP & RTP
• part #4: UA PBX, standard configurations and some security tips
• part #5: the main tools for working with VoIP
• part #6: audio problems and the quality of a VoIP call
• season finale #7: final conclusions

Let me know if this is an interest topic to you and if you like the lineup or if there are any topics / insights that you would like to speak about.

Writing about a topic is a way to "understand if I understand", to collect contributions (I hope there will be many comments that will confirm what I have written and many comments that will correct me) and to help the sharing of knowledge and I love all of this stuff!

Thanks a lot for reading, sharing and comment this article.

Thanks to undraw.co for the beautiful illustration I used in the header

Cheers!