Skip to main content
Kofax

Analyzing Wireshark Foip traces when using FAX Passthrough mode

Summary

20049

Description

This article gives you a step by step guide for analyzing wireshark traces in case of using Foip with Passthrough mode.

In difference to the T.38 FAX protocol, where the Wireshark function Telephony - Voip calls with the button Flow sequence gives a good overview about the FAX communication protocol (e.g. which transmission speed was used, which FAX pages were confirmed positively and which not, if there had been retransmissions,...) the Wireshark trace for FAX Passthrough mode just shows audio stream of the FAX communication as RTP (Real time Transport protocol) data and some more steps are necessary to get out more detailed information about the FAX protocol itself.

Beside the method described in this article there are also some other methods for analyzing:

  1. Enable binary traces in the Foip configuration and check these traces with the BTRC.exe tool
    These binary traces are enabled in the Foip configuration tool, section Advanced, configuration option BtrTraceLevel.
    KCS Foip provides the possibility to keep only binary traces for failed calls, which is a good option to keep the recorded data small.
    Binary traces are stored in the same folder as used for the Foip log files (default C:\TOPCALL\Foip\00\Trace).
    You can use the BTRC.exe tool to get out the FAX protocol from the captured binary trace files
    (The binary tracer tool is installed if you install Common (Group) - Administrative tools (Group) - Line server diagnostic tool running the KCS Setup program)
    Please consult the Foip manual for details, how to enable the binary traces and please consult the chapter 11.4 The LS1 Data Pump Trace in the TCOSS ISDN Technical manual for details in using the BTRC.exe tool
    2018-07-26_1538.png
  2. Check the Foip traces itself
    The Foip traces also give you a more detailed analysis of the FAX protocol, by default they are located in the folder C:\TOPCALL\Foip\00\trace
    A Foip Tracelevel of 10 gives in most cases already sufficient information, on request of a support engineer or developer the trace level might be increased and they are named Foip_xxx.log. Check the log files for "inbound call" or "outbound call" to locate the call you want to analyze based on timestamp, originator- and recipient number.
    For the example analyzed in this article the corresponding trace line is the following:
    10/13:10:56.214 (09fc/29a0/0024) {"22:UFI"} Inbound Call: RxNum=77111, CallerId=@, TSI=+4318664577, EC= (), Peer=172.20.240.102:30184, G711=3129-0-0-0 28-30-1941-1046, M=e96
    You see some details of the call, e.g. RxNum is the dialed DDI number and you see the sender's CallerID, TSI, IP address and port from where the call was received.
    The EC shows you the error code, if it is blank as shown in the example above, it is a successful call.
    The M parameter at the end of the line shows the transmission parameters, in this case the FAX was received with fine mode (small 'e'), Error correction mode (e and not n), 9600 Bd and T.6 encoding.
    Details about the meaning of this parameter can be found within the TCOSS configuration manual, chapter 4.8 CONFIG PARAMETERS OF THE TRANSPUTER FAX MODULE (UTF) in the description of configuration line 143.
    Interesting is also the "trace context ID", the 3rd value 0024 after ProcessID 09fc and ThreadID 29a0.
    Filtering out all trace lines with the contextID "/0024)" will give you all the details about this specific call.
  3. Analyzing the Wireshark trace and the RTP data

But now coming back to the primary topic of this article, analyzing the Wireshark trace of the Foip Passthrough call.

Tools needed for analysis:

  1. Wireshark (an open source network sniffer tool) to capture and analyze the network traffic
  2. An audio Editor, which can be used to convert the Audio streams (.au files) captured with Wireshark to Wave files.
    We recommend to use Audacity, which is a powerful free and open-source audio editor
  3. The WavToT30 tool included in this Article. This is a small command line tool developed by Kofax, which uses the same FAX datapump engine as included in KCS Fax over IP. This tool will convert the WAV file and will generate a Text file containing all the FAX related communication (T.30 FAX Protocol). So its function is similar like the BTRC.exe tool, which generates WAV and Text files from a binary trace file.
  4. A text editor, which is capable doing advanced search (e.g. listening all lines matching a specific search term, search using regular expressions).
    A good open source editor with these capabilities is Notepad++

Steps to get out the FAX Protocol data from the Wireshark trace

  • Capture the Foip call with Wireshark and save it to a file (typically file extension .pcapng)
  • If analysis is done on another machine, copy the captured file to this machine and load it into Wireshark, if you do it on the local machine, just stop Wireshark packet capturing
  • Use the menu option Telephony - Foip Calls to get a list of all Foip calls recorded in this trace You see the callerID (in this case empty) and the called number (in this case 77211).
    Enable the checkbox Time of Day in the right lower corner to show the real time stamp (instead of getting the time since wireshark was started)
    2018-07-26_1546.png
  • Select the call you want to analyze in detail (in the example above just one call is included) and press the button Flow sequence.
    If it is a Passthrough call you will not see any FAX T.30 communication, only some RTP data streams as shown in the screenshot below.
    Please remember the IP addresses (172.20.240.102 is the gateway, 172.20.242.141 is the Foip server), the FAX communication is shown as RTP streams using port 30184 on the Gateway and using port 10010 on the Foip side
    2018-07-26_1547.png
  • Now you know that it is a Passthrough call, close the dialog and go back to the previous dialog showing the list of all Foip calls.
    Using the button Play Streams brings up a dialog showing the complete audio communication and you can also play the audio stream if you have an output audio device connected to your computer.
    The two directions are shown with different colors and you see again source and destination ports and IP addresses. When listening to the FAX communication you might encounter bad line issues or interruptions in the communication, but in fact you do not know whether a FAX page was confirmed as received good or as bad. Therefore - for a more detailed analysis more steps are necessary.
    2018-07-26_1550.png
  • Close the dialog and return to the main window of Wireshark.
    Use the menu option Telephony - RTP - RTP streams to see all RTP streams captured in this wireshark trace. Locate the RTP stream, which belongs to your specific call based on the port number (in this case the port 30184 or the port 10010). Select the RTP stream in the list and use the button Find Reverse to select also those RTP stream containing the RTP data from the other direction. So at the end both RTP streams should be selected
    2018-07-26_1552.png
  • Now press the Analyze button. A new dialog opens and it contains details about the Forward and the Reverse stream. Save both streams as stereo Audio file to your local computer using the button Save - Stream Synchronized Forward and Reverse Audio.
    In this case the filename was choosen as Saved RTP Audio.au
    2018-07-26_1553.png
  • Before you can analyze the audio stream with the WavToT30 Tool, you have to convert the Audiofile (.au) into a Wav (.wav) file.
    Audio files are missing the WAV file header, which is required for the WAVToT30 tool to recognize the Wave file correctly
    We use Audacity to do this job. Load the .au file into Audacity. It will be shown as a stereo file, one direction is the L channel, the other is the R channel.
    Export the Audio file using the menu option File - Export Audio, selecting the file type "WAV (Microsoft) singed 16-bit PCM" format, in our example the file was exported as Saved RTP Audio.wav2018-07-26_1554.png
  • In some older versions of Wireshark you were not able to export both directions in one step as a stereo audio file, and you could only export the RTP streams of each direction as seperate mono files
    In such a case load both mono files into Audacity and create then one stereo track from these two mono files using the drop down option Make Stereo track as shown in the screenshot below.
    After creating the stereo track you must then Export the file again as Wave file as described in the previous step.
    2018-07-26_15541.png
  • After pressing the Save button, Audacity will open an additional dialog where you can enter some Metadata for the Wave file. You can keep all fields blank and press OK
    2018-07-26_1555.png
  • Now we can analyze the FAX protocol capatured within the Wav file using the WavToT30 command line tool. Copy the WavToT30.exe Tool and the vocallib.dll to the same directory, preferrable a directory, which is included in your PATH environment.
    Then open an administrative command prompt (using the context menu option Run as Administrator) and execute the WavTo30 tool and pass the filename of the WAV file generated in the previous step as command line parameter. If the filename includes blank characters include it in double quotes.

    WavToT30 "C:\Temp\Saved RTP Audio.wav"

    WavToT30 1.00.00
    Converting 'C:\Temp\Saved RTP Audio.wav" to 'C:\Temp\Saved RTP Audio.txt"'
    Detected 501600 samples (62s)
    Conversion successfully completed
  • Afterwards we can open the generated Saved RTP Audio.txt file with an Editor like Notepad++. Filter out all text lines containing the string T30
    For the example above this gives the result shown below. The time stamps on the left side show the time, elapsed since the trace was started. Afterwards you see either a Tx (transmit) or a Rx (receive) indicating the direction. Analyzing the result requires knowledge of the T.30 FAX protocol, which is not covered in this article. But you should get an idea, how to collect and prepare the data and do a basic analysis.
    For the example below a basic analysis is included, for an in-depth analysis the help of a KCS developer is necessary.

0:05.530 Tx HDLC T30: rCSI Fax: +431866457058777211
0:05.810 Tx HDLC T30: rDIS (V.27/29/33/17,ECM) 00 ee f8 44
0:07.770 Rx HDLC T30: tTSI Fax: +43 1 86645 77
0:08.040 Rx HDLC T30: tDCS (V.17-144,ECM) 00 62 f8 44
0:12.760 Tx HDLC T30: rCFR
0:16.490 Rx HDLC T30: tPPS-tMPS 4f 00 00 06
0:18.120 Tx HDLC T30: rMCF
0:53.980 Rx HDLC T30: tPPS-tEOP 2f 01 00 d9
0:56.440 Tx HDLC T30: rPPR 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
00 fc ff ff ff ff
0:59.100 Rx HDLC T30: tPPS-tEOP 2f 01 00 01
1:00.940 Tx HDLC T30: rMCF
1:02.590 Rx HDLC T30: tDCN

You see the Calling station identifier (CSI) of the receiver side and also the reception capabilities of the receiver side in the DIS frame (Digital identification signal):
Based on the capabilities of the receiver side, the sender side defines the transmission speed, modulation and ECM (Error correction mode) capabilities in the DCS frame (Digital command signal). At this time also the Transmitting station identifier (TSI) is transferred. Afterwards the FAX training (1,5 seconds 00 bytes, always without error correction) is done, which is in this case confirmed positively with CFR (Confirmation to receive). After that the FAX page data are transmitted (in ECM mode) and the end is signalled by a PPS-MPS signal (Partial page - Multiple pages signal), where the sender indicates that additional FAX pages will follow. The FAX page is confirmed by the receiver as received OK by sending MCF (Message confirmation). Afterwards the 2nd page is sent, ending with PPS-EOP (Partial page signal - End of Procedure) indicating that this was the page of the FAX message (EOP): In this specific case some page data are confirmed as not being received correctly and the receiver side sends a PPR (Partial page request) to resend those FAX frames where the ECM error correction checksum was not correct. The sender side resends those frames, ending again with PPS-EOP. At this time the 2nd page is also confirmed as received OK (MCF = message confirmation) and the sender side sends a DCN (Disconnect) to close the call. So this was a successful inbound call.

Applies to

  • KCS 10.x Foip Passthrough
  • Wireshark 2.4.0
  • Audacity 2.1.3

Keywords: Passthrough, Pass-Through, Foip, Wireshark, Wav2T30, WavToT30, Audacity, Binary Trace, btr, btrc

  • Was this article helpful?