Technical Tip: How to decode DTMF in-band tones in FortiGate

omontanez · ‎01-16-2017

Description

This article describes the troubleshooting of DTMF tones through a FortiGate, in order to check if there are passed and received from local or remote endpoint.

Scope

FortiGate, DTMF in-band method.

Solution

A voice call has two legs, when troubleshooting it is recommended to analyze each leg.

In this way it is possible to identify if there are voice problems in the internal or external FortiGate network.

1) Open a putty sessions in Firewall (save all session output in session login), and run sniffer setting IPPBX as host, and interface as “any”

# diag sniffer packet any ‘host [IP IPPBX]’ 6 0 l <----- If a support case is opened with us, attach this capture as text.

To analyze this capture, the text file can be converted to PCAP (for Wireshark) with the converter available here for download: https://kb.fortinet.com/kb/documentLink.do?externalId=11186

or with the open-source one (providing more options) available at: https://github.com/ondrejholecek/sniftran

There are two methods for transmit DTMF tones, in-band and out-band, this section describes the 'in-band' method.

The other method is becoming more popular and used by softphones or SIP calls using TCP for negotiation.

Visibility of DTMF codes in this case is more difficult and involves decrypting the secure communication.

DTMF tones that use in-band method are based on standard RFC 2833, signals are encapsulated into RTP packets using a Payload Type.

These packets can be found by filtering in Wireshark by protocol 'RTP event'.

Usually if packet capture was using interface 'any' in sniffer, two packets will be shown, the first of them is from endpoint to internal interface (LAN) and the second packet is from the external interface (WAN) to SIP proxy.

It is possible to see in this capture that the DTMF code is sent as 'RTP EVENT' and using the same ports as the regular audio traffic (RTP):

Troubleshooting.

In the example there are two packets, first packet means that DTMF tone is coming to FortiGate from endpoint to internal interface and second is the same packet now from external to PBX (NAT IP will be shown as source).

Open RTP packet to check what Payload Type was negotiated for both sides (it is not always the same, it depends upon the negotiation of far-end SIP units).

With this capture, confirm and validate that the DTMF packet is passing through the FortiGate correctly (same content), then if the DTMF tones are not recognized, check in the SIP endpoints that:

1) In-band method (RFC 2833/4733) is supported by both sides (SIP endpoints).

2) RFC 2833/4733 is compliant in both sides (SIP endpoints).

3) Payload type is using the same for both sides (SIP endpoints).

Remember that DTMF tones are encapsulated into RTP packets, then if the call has voice in both sides (RTP) then DTMF should pass in the same channel (source/destination port).

The purpose of this procedure is only to show these packets.

FortiGate cannot do any action over these packets, the DTMF tones are treated as RTP events in a call.

In other words, if a voice call is passing and audible both ways, the DTMF codes should also pass.