Fortinet Document Library

Version:

Version:

Version:

Version:


Table of Contents

FortiVoice Cookbook

Download PDF
Copy Link

FortiFone softclient for mobile – best practices

Note

Topics in this section apply to the FortiFone softclient for mobile, not for desktop.

In a typical deployment scenario, the FortiVoice phone system is located behind an internet facing firewall. If a customer has deployed a FortiFone softclient, this softclient is usually behind another firewall when the customer’s cell phone is using the data service of a cellular network or the Wi-Fi of a home network. Signaling and two-way audio through a firewall requires the network address translation (NAT) traversal for the session initiation protocol (SIP). When the deployment is using either SIP over the transmission control protocol (TCP) or the user datagram protocol (UDP), the SIP application layer gateway (ALG) with hosted NAT traversal enabled on FortiGate can translate the internal IP address of a session description protocol (SDP) payload properly to allow media flow. If the deployment is using SIP over transport layer security (TLS), the SIP traffic is encrypted end-to-end. With this encryption, FortiGate is unable to translate the internal IP address in the SDP payload, which then causes a one-way audio or no audio at all. Fortunately, FortiGate supports SSL inspection and is able to decrypt the encrypted SIP traffic and translate the SDP address to resolve the NAT-traversal issue.

This section describes how to configure the FortiVoice phone system and FortiGate to use the FortiFone softclient as a remote SIP client, and install and configure the FortiFone softclient.

Protocols

The communication between the FortiFone softclient and FortiVoice uses the following protocols and server:

  • HTTPS for softclient login, auto-provisioning, download of contacts, call logs, and voicemails
  • SIP for signaling
  • RTP or secure RTP (SRTP) for audio
  • Android and iOS push server for outbound calls

Call flows

The inbound call flow includes the following steps:

  1. A caller dials an extension to connect to the FortiFone softclient.
  2. FortiVoice sends the push request to the Android or iOS push server which relays the request to the mobile client (cellular phone).
  3. If the mobile client is in sleep mode, the request wakes up the mobile client.
  4. The FortiFone softclient registers with FortiVoice and then receives the inbound call.
  5. After the signaling is complete, FortiVoice sends the audio to the mobile client using RTP or SRTP.

The outbound call flow includes the following steps:

  1. The user initiates an outbound call using the mobile client.
  2. The FortiFone softclient sends a SIP invite directly to FortiVoice.
  3. After the signaling is complete, FortiVoice sends the audio to the destination phone using RTP or SRTP.

Topology

FortiFone softclient for mobile – best practices

Note

Topics in this section apply to the FortiFone softclient for mobile, not for desktop.

In a typical deployment scenario, the FortiVoice phone system is located behind an internet facing firewall. If a customer has deployed a FortiFone softclient, this softclient is usually behind another firewall when the customer’s cell phone is using the data service of a cellular network or the Wi-Fi of a home network. Signaling and two-way audio through a firewall requires the network address translation (NAT) traversal for the session initiation protocol (SIP). When the deployment is using either SIP over the transmission control protocol (TCP) or the user datagram protocol (UDP), the SIP application layer gateway (ALG) with hosted NAT traversal enabled on FortiGate can translate the internal IP address of a session description protocol (SDP) payload properly to allow media flow. If the deployment is using SIP over transport layer security (TLS), the SIP traffic is encrypted end-to-end. With this encryption, FortiGate is unable to translate the internal IP address in the SDP payload, which then causes a one-way audio or no audio at all. Fortunately, FortiGate supports SSL inspection and is able to decrypt the encrypted SIP traffic and translate the SDP address to resolve the NAT-traversal issue.

This section describes how to configure the FortiVoice phone system and FortiGate to use the FortiFone softclient as a remote SIP client, and install and configure the FortiFone softclient.

Protocols

The communication between the FortiFone softclient and FortiVoice uses the following protocols and server:

  • HTTPS for softclient login, auto-provisioning, download of contacts, call logs, and voicemails
  • SIP for signaling
  • RTP or secure RTP (SRTP) for audio
  • Android and iOS push server for outbound calls

Call flows

The inbound call flow includes the following steps:

  1. A caller dials an extension to connect to the FortiFone softclient.
  2. FortiVoice sends the push request to the Android or iOS push server which relays the request to the mobile client (cellular phone).
  3. If the mobile client is in sleep mode, the request wakes up the mobile client.
  4. The FortiFone softclient registers with FortiVoice and then receives the inbound call.
  5. After the signaling is complete, FortiVoice sends the audio to the mobile client using RTP or SRTP.

The outbound call flow includes the following steps:

  1. The user initiates an outbound call using the mobile client.
  2. The FortiFone softclient sends a SIP invite directly to FortiVoice.
  3. After the signaling is complete, FortiVoice sends the audio to the destination phone using RTP or SRTP.

Topology