Fetch the operation logs

By default, all the operation logs are in the directory /var/opt/belledonne-communications/logs/flexisip on the machine that hosts Flexisip. This directory may be changed by the parameter global/log-directory.

There is a plain text log file for each Flexisip service :

flexisip-proxy.log and flexisip-conference.log are enough for the great majority of problems.

How to read Flexisip's log files

Flexisp-proxy.log

Available information on proxy starting

The last starting may be found by the searching the last occurrence of:

 Here are some useful parts of the log on starting :

Content of /etc/hosts

Order of the Flexisip modules and message on their initialization

Version of Mediastreamer (SDK version)

Number of CPU threads

Other debug info on Mediastreamer library initialization

List of the network interfaces and their settings

List of the host aliases

List of the aliases that have been given by global/aliases parameter.

Backend used for the registrar database

See module::Registrar/db-implementation.

Value of the internal transport

See cluster/internal-transport.

Global TLS certificates/key location

List of listening addresses and ports (listening transports)

DoS Protection whitelist

See module::DoSProtection/white-list.

Trusted hosts while authentication

See module::Authentication/trusted-hosts.

Domains that are authorized to operate with the proxy (after authentication)

See module::Authentication/auth-domains.

Push notification clients creation

Available information:

• Directory where APNS client certificates are placed in;
• Creation of each Apple client and the expiration date of the related APNS certificate;
• Creation of each Android/Firebase client and the related ProjectID;
• The TTL used for each Push Notification Request according the kind of event (call or instant message).

Debug the flow of a request

Each incoming/outgoing SIP message are systematically logged but without their body (excepted for call session INVITEs). So, you can easily follow the flow of a given request by searching for its Call-ID. For instance,

Received message:

Forwarded message:

While an incoming request is processed by Flexisip, it goes through a chain of modules that may do the following action on the request:

• Add/remove/alter the headers of the message;
• Pass the request to the next module;
• Suspend the request, which cause the Flexisip to process another incoming request;
• Reply to the request with a terminal SIP response; the request won't go through the next modules.

Flexisip suspends a request when it is waiting for the result of an asynchronous operation (for example the response of a SQL request) to find out which action to do on the request.

Example of request processing:

We see here that the request go through DoSProtection, SanityChecker, NetHelper and is suspended at the end of Authentication. The equal line means that Flexisip is changing context and is probably processing another request.

The processing of this request is resumed later in the log and suspended again while entering in the Router module:

Requests are finally forwarded while entering the Forward module, which is the last one in the chain.

Flexisip-conference.log

The SIP message flow may be easily followed by searching for the Call-ID of the message in the log.

Common issues

Push notifications not received by a SIP client

1. Check whether a Push Notification Request has been actually sent by the proxy

Use the Call-ID and the UUID of the recipient user agent to find the creation of the PNR.

Android/Firebase PNR creation:

Apple PNR creation:

Next, follow the state of the PNR by searching for its pointer, until you find this log:

If the final state is “Successful”, the PNR has successfully been sent and accepted by the Push Notification Server. So, the problem is located on client side.

If the final state is “Failed”, the PNR sending has failed. You should scroll a little back to examine the body of the HTTP/2 response to know the reason of the failure.

Instance of failing response to Apple PNR:

2. iOS client: check the validity of the APNS client certificates

When you follow the PNR pointer, you may find this error message just after the request creation:

That means no PushClient has been created for the given “apns-topic”.

Get the “apns-topic“ in the HTTP/2 header just above the error message, org.example.myapp in this example:

Then, check the push client creation part on flexisip-proxy starting (see Push notification clients creation above). If the apns-topic is not present, that means no certificate for this topic is present in /etc/flexisip/apns, you should check the expiration date otherwise.