The tool for playing VoIP calls is called <<ChTelRtpPlayer,RTP Player>>. It shows RTP streams and its waveforms, allows play stream and export it as audio or payload to file. Its capabilities depend on supported codecs.
RTP Player is able to play any codec supported by an installed plugin. The codecs supported by RTP Player depend on the version of Wireshark you're using. The official builds contain all of the plugins maintained by the Wireshark developers, but custom/distribution builds might not include some of those codecs. To check your Wireshark installation's installed codec plugins, do the following:
Wireshark can be used for RTP stream analysis. User can select one or more streams which can be played later. RTP Player window maintains playlist (list of RTP streams) for this purpose.
Playlist is created empty when RTP Player window is opened and destroyed when window is closed. RTP Player window can be opened on background when not needed and put to front later. During its live, playlist is maintained.
When RTP Player window is opened, playlist can be modified from other tools (Wireshark windows) in three ways:
* button menu:Play Streams[Set playlist] clears existing playlist and adds streams selected in the tool.
* button menu:Play Streams[Add to playlist] adds streams selected in the tool to playlist. Duplicated streams are not inserted again.
* button menu:Play Streams[Remove from playlist] removes streams selected in the tool from playlist, if they are in the playlist.
.btn:[Play Streams] button with opened action menu
btn:[Play Streams] button can be clicked directly and opens RTP Player window directly with btn:[Set playlist] action. All actions can be selected with the small down arrow next to the button.
When the playlist is empty, there is no difference between btn:[Set playlist] and btn:[Add to playlist]. When the RTP Player window is not opened, all three actions above open it.
btn:[Remove from playlist] is useful e.g. in case user selected all RTP streams and wants to remove RTP streams from specific calls found with menu:VoIPCalls[].
Tools below can be used to maintain content of playlist, they contain btn:[Play Streams] button. You can use one of procedures (Note: btn:[Add to playlist] action is demonstrated):
* Open menu:Telephony[RTP > RTP Streams] window, it will show all streams in the capture. Select one or more streams and then press btn:[Play Streams]. Selected streams are added to playlist.
* Select any RTP packet in packet list, open menu:Telephony[RTP > Stream Analysis] window. It will show analysis of selected forward stream and its reverse stream (if btn:[Ctrl] is pressed during window opening). Then press btn:[Play Streams]. Forward and reverse stream is added to playlist.
** menu:RTP Stream Analysis[] window can be opened from other tools too.
* Open menu:Telephony[VoIP Calls] or menu:Telephony[SIP Flows] window, it will show all calls. Select one or more calls and then press btn:[Play Streams]. It will add all RTP streams related to selected calls to playlist.
* Open btn:[Flow Sequence] window in menu:Telephony[VoIP Calls] or menu:Telephony[SIP Flows] window, it will show flow sequence of calls. Select any RTP stream and then press btn:[Play Streams]. It will add selected RTP stream to playlist.
.Tools for modifying playlist in RTP Player window
Same approach with set/add/remove actions is used for RTP Stream Analysis window. The playlist is there handled as different tabs in the window, see <<ChTelRTPAnalysis,RTP Stream Analysis>> window.
Decoding RTP payload and showing waveforms is a time consuming task. To speed it up, the RTP Player window uses a copy of packet payload for all streams in the playlist. During live capture the dialog is not refreshed automatically as other Wireshark dialogs - the user must initiate it.
The copy is created or refreshed and dialog updated:
* Every time window is opened.
* Every time a new stream is added or set.
* During live capture, when btn:[Refresh streams] is pressed.
* Every time live capture is finished/stopped by a user.
When capture file is opened (no live capturing), streams are read complete, no user action is required. Button btn:[Refresh streams] is disabled as it is useless.
When live capture is running, streams are read only till "now" and are shown. When stream is continuous and user would like to see additional part, they must press btn:[Refresh stream]. When the user ends live capture, view is refreshed and button is disabled.
RTP Player dialog stays open even when live capture is stopped and then started again. Play list stays unchanged. Therefore, btn:[Refresh stream] tries to read same streams as before and shows them if they are still running. Past part of them (from previous live capture) is lost.
RTP is carried usually in UDP packets with random source and destination ports. Therefore, Wireshark can only recognize RTP streams based on VoIP signaling, e.g., based on SDP messages in SIP signaling. If signaling is not captured, Wireshark shows just UDP packets. However, there are multiple settings which help Wireshark recognize RTP even when there is no related signaling.
You can use <<ChAdvDecodeAsFig,Decode As...>> function from menu:Analyze[Decode As...] menu or in mouse context menu. Here you can set that traffic on specific source or destination should be decoded as RTP. You can save settings for later use.
You can enable heuristic dissector menu:rtp_udp[] in menu:Analyze[Enabled Protocols...]. See <<ChCustProtocolDissectionSection>> for details. Once menu:rtp_udp[] is enabled, Wireshark tries to decode every UDP packet as RTP. If decoding is possible, packet (and entire UDP stream) is decoded as RTP.
When an RTP stream uses a well-known port, the heuristic dissector ignores it. So you might miss some RTP streams. You can enable setting for udp protocol menu:Preferences[Protocols > udp > Try heuristic sub-dissectors first], see <<ChCustPreferencesSection>>. In this case heuristics dissector tries to decode UDP packet even it uses a well-known port.
Take into account that heuristics is just a simple "test" of whether a packet can be read as RTP. Because of false positives, you can see decoded as RTP more UDP packets than expected.
When you enable menu:udp[Try heuristic sub-dissectors first], it increases the possibility of false positives. If you capture all traffic in network, false positives rate can be quite high.
RTP Player must store decoded data somewhere to be able to play it. When data are decoded, there are audio samples and dictionary for fast navigation. Both types of data are stored in memory for default, but you can configure Wireshark to store it on disk. There are two settings (which you may access from menu:Edit[Preferences] Advanced from the main menu).
* ui.rtp_player_use_disk1 - When set to FALSE (default), audio samples are kept in memory. When set to TRUE, audio samples are stored on temporary file.
* ui.rtp_player_use_disk2 - When set to FALSE (default), dictionary is kept in memory. When set to TRUE, dictionary is stored on temporary file.
When any data are configured to be stored on disk, one file is created for each stream. Therefore, there might be up to two files for one RTP stream (audio samples and dictionary). If your OS or user has OS enforced limit for count of opened files (most of Unix/Linux systems), you may see fewer streams than were added to playlist. Warnings are printed on console - in this case and you will see fewer streams in the playlist than you send to it from other tools.
For common use you can use default settings - store everything in memory. When you will be out of memory, switch ui.rtp_player_use_disk1 to TRUE first - it saves much more memory than ui.rtp_player_use_disk2.
RTP Player plays audio by OS sound system and OS is responsible for mixing audio when multiple streams are played. In many cases OS sound system has limited count of mixed streams it can play/mix. RTP Player tries to handle playback failures and show warning. If it happens, just mute some streams and start playback again.
RTP Analysis window can handle 1000+ streams, but it is difficult to use it with so many streams - it is difficult to navigate between them. It is expected that RTP Analysis window will be used for analysis of lower tens of streams.
VoIP Calls window can be opened as window showing all protocol types (menu:Telephony[VoIP Calls] window) or limited to SIP messages only (menu:Telephony[SIP Flows] window).
* btn:[Limit to display filter] filters calls just to ones matching display filter. When display filter is active before window is opened, checkbox is checked.
* btn:[Time of Day] switches format of shown time between relative to start of capture or absolute time of received packets.
* btn:[Flow Sequence] opens <<ChStatFlowGraph,Flow Sequence>> window and shows selected calls in it.
* btn:[Prepare Filter] generates display filter matching to selected calls (signaling and RTP streams) and apply it.
The A-Interface Base Station Management Application Part (BSMAP) Statistics window shows the messages list and the number of the captured messages. There is a possibility to filter the messages, copy or save the date into a file.
The A-Interface Direct Transfer Application Part (DTAP) Statistics widow shows the messages list and the number of the captured messages. There is a possibility to filter the messages, copy or save the date into a file.
The Global System for Mobile Communications (GSM) is a standard for mobile networks. This menu shows a group of statistic data for mobile communication protocols according to ETSI GSM standard.
Integrated Service User Part (ISUP) protocol provides voice and non-voice signaling for telephone communications. ISUP Messages menu opens the window which shows the related statistics. The user can filter, copy or save the data into a file.
The RLC Graph menu launches a graph which shows LTE/NR Radio Link Control protocol sequence numbers changing over time along with (for AM) acknowledgements
The Message Transfer Part level 3 (MTP3) protocol is a part of the Signaling System 7 (SS7). The Public Switched Telephone Networks use it for reliable, unduplicated and in-sequence transport of SS7 messaging between communication partners.
This menu shows MTP3 Statistics and MTP3 Summary windows.
OSmux is a multiplex protocol designed to reduce bandwidth usage of satellite-based GSM systems's voice (RTP-AMR) and signaling traffic. The OSmux menu opens the packet counter window with the related statistic data. The user can filter, copy or save the data into a file.
* delta - time difference from reception of previous packet
for every stream. Checkboxes below graph are enabling or disabling showing of a graph for every stream. btn:[Stream X] checkbox enables or disables all graphs for the stream.
[NOTE]
====
Stream Analysis window contained tool for save audio and payload for analyzed streams. This tool was moved in Wireshark 3.5.0 to <<ChTelRtpPlayer,RTP Player>> window. New tool has more features.
** SETUP <number> is shown, when there is known signaling packet. Number is packet number of signaling packet. Note: Word SETUP is shown even RTP stream was initiated e. g. by SKINNY where no SETUP message exists.
** RTP <number> is shown, when no related signaling was found. Number is packet number of first packet of the stream.
* Packets - Count of packets in the stream.
* Time Span - Start - Stop (Duration) of the stream
menu:Export[] was moved from menu:RTP Stream Analysis[] window to menu:RTP Player[] window in 3.5.0.
Wireshark is able to export decoded audio in .au or .wav file format. Prior to version 3.2.0, Wireshark only supported exporting audio using the G.711 codec. From 3.2.0 it supports audio export using any codec with 8000 Hz sampling. From 3.5.0 is supported export of any codec, rate is defined by Output Audio Rate.
** From cursor - Streams are saved from play start cursor. If some streams are shorter, they are removed from the list before save and count of saved streams is lower than count of selected streams.
** Stream Synchronized Audio - File starts at the begin of earliest stream in export, therefore there is no silence at beginning of exported file.
** File Synchronized Audio - Streams starts at beginning of file, therefore silence can be at start of file.
Audio is exported as multi-channel file - one channel per RTP stream. One or two channels are equal to mono or stereo, but Wireshark can export e.g., 100 channels. For playing a tool with multi-channel support must be used (e.g., https://www.audacityteam.org/).
Default value of btn:[Output Audio Rate] is btn:[Automatic]. When multiple codecs with different codec rates are captured, Wireshark decodes each stream with its own play audio rate. Therefore, each stream can have a different audio rate. If you attempt to export audio when there are multiple audio rates, it will fail because .au or .wav require a fixed audio rate.
In the Real Time Streaming Protocol (RTSP) menu the user can check the Packet Counter window. It shows Total RTCP Packets and divided into RTSP Response Packets, RTSP Request Packets and Other RTSP packets. The user can filter, copy or save the data into a file.
Stream Control Transmission Protocol (SCTP) is a computer network protocol which provides a message transfer in telecommunication in the transport layer. It overcomes some lacks of User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). The SCTP packets consist of the _common header_ and the _data chunks_.
The SCTP Analyze Association window shows the statistics of the captured packets between two Endpoints. You can check the different chunk types by pressing btn:[Chunk Statistics] button in the `Statistics` tab. In the `Endpoint` tabs you can see various statistics, such as IP addresses, ports and others. You can also check different graphs here.
The SCTP Associations window shows the table with the data for captured packets, such as port and counter. You can also call for the SCTP Analyze Association window by pressing the btn:[Analyze] button.
Short Message Peer-to-Peer (SMPP) protocol uses TCP protocol as its transfer for exchanging Short Message Service (SMS) Messages, mainly between Short Message Service Centers (SMSC). The dissector determines whether the captured packet is SMPP or not by using the heuristics in the fixed header. The SMPP Operations window displays the related statistical data. The user can filter, copy or save the data into a file.
The Universal Computer Protocol (UCP) plays role in transferring Short Messages between a Short Message Service Centre (SMSC) and an application, which is using transport protocol, such as TCP or X.25. The UCP Messages window displays the related statistical data. The user can filter, copy or save the data into a file.
F1AP is used to exchange signaling and user-plane data between CU and DU nodes as part of an O-RAN network. This window counts how many messages of each type are seen.
[#ChTelNGAPMessages]
=== NGAP Messages Window
NGAP messages are exchanged between a gNB and core network. This window counts how many messages of each type are seen.
[#ChTelE2APMessages]
=== E2AP Messages Window
E2AP is used to configure and query nodes in an O-RAN network. This window counts how many messages of each type are seen.
H.225 telecommunication protocol which is responsible for messages in call signaling and media stream packetization for packet-based multimedia communication systems. The H.225 window shows the counted messages by types and reasons. The user can filter, copy or save the data into a file.
Session Initiation Protocol (SIP) Flows window shows the list of all captured SIP transactions, such as client registrations, messages, calls and so on.
SIP Statistics window shows captured SIP transactions. It is divided into SIP Responses and SIP Requests. In this window the user can filter, copy or save the statistics into a file.
The WAP-WSP Packet Counter menu displays the number of packets for each Status Code and PDU Type in Wireless Session Protocol traffic. The user can filter, copy or save the data into a file.
