# SIP capture and analysis with Wireshark and sngrep and HOMER Canonical: https://warmtransfer.net/knowledge/sip-capture-analysis Last verified: 2026-09-24 Packet capture and protocol analysis provide detailed visibility into SIP signaling and associated media streams across network endpoints[^59][^60]. Tools such as Wireshark, sngrep, and the HOMER ecosystem offer distinct methods for capturing, decoding, and troubleshooting voice traffic[^57][^28][^7]. ## Wireshark and TShark Analysis The Wireshark VoIP Calls window detects calls from 7 signaling protocols: H.323, IAX2, ISUP, MGCP/MEGACO, SIP, SKINNY, and UNISTIM[^59]. It lists calls identified from signaling together with the RTP streams associated with them[^60]. The Flow Sequence button in the VoIP Calls window opens a Flow Sequence (flow graph) window showing the selected calls as a ladder of messages[^43]. In the VoIP Calls window, Prepare Filter builds a display filter that matches the selected calls and their RTP streams, and 'Limit to display filter' restricts the call list to packets matching the active display filter[^53]. The VoIP Calls window's Time of Day toggle switches the displayed times between relative to capture start and absolute time of packet receipt[^58]. For dedicated SIP troubleshooting, the SIP Flows window (Telephony > SIP Flows) lists all captured SIP transactions, including registrations, messages and calls, whether complete or in progress, and has the same features as the VoIP Calls window[^57]. Wireshark recognises RTP streams from VoIP signaling such as SDP in SIP; when the signaling is not in the capture, RTP must be decoded manually with Decode As or by enabling the rtp_udp heuristic dissector[^55]. The Wireshark guide warns that the rtp_udp heuristic dissector can produce false positives, especially when UDP is set to try heuristic dissectors first[^54]. When the rtp_udp heuristic is enabled, the RTP Streams window may label streams as 'RTP ' even when the setup frames are present in the capture[^44]. During a live capture the RTP stream dialogs are not refreshed automatically; the user must press Refresh streams[^47]. The Wireshark RTP Streams window lists every RTP stream in the capture with per-stream lost packets, max delta, max jitter and mean jitter, and selected streams can be passed to other tools such as analysis and the player[^56]. The RTP Streams window has a Find Reverse action (key R) that selects the reverse-direction stream for each selected stream[^42]. | Metric / Field | Scope | Description | | --- | --- | --- | | Delta | Per packet | Arrival delta from previous packet in milliseconds[^40] | | Jitter / Skew / Bandwidth | Per packet | Jitter, skew, IP-level bandwidth, and RTP marker bit[^40][^41] | | Status | Per packet | Flags sequence errors and codec changes[^40] | | Lost Packets | Stream summary | Calculated from RTP sequence numbers[^38] | | Drift / Summary Stats | Stream summary | Max/mean jitter, skew, clock drift, and frequency drift[^38] | RFC 3550 defines interarrival jitter as a running estimate, J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, expressed in RTP timestamp units[^15]. Wireshark computes RTP jitter using the RFC 3550 section 6.4.1 interarrival jitter estimator, J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, where D compares arrival-time spacing with RTP-timestamp spacing[^46]. Wireshark needs the sampling clock rate to calculate jitter correctly, which makes jitter for dynamic payload types unreliable unless the rate can be learned, for example from the SDP[^45]. RFC 3550 defines the cumulative number of packets lost relative to the packets expected, so the value can be negative when duplicate packets arrive[^16]. Wireshark's RTP bandwidth figure is measured at the IP level: all octets including IP and UDP headers (20+8 bytes) of the stream's packets over the last second[^41]. Wireshark calculates some RTP Stream Analysis statistic columns only when it can decode the stream's codec[^39]. RTP Stream Analysis results can be exported as CSV and its graphs saved as PDF, PNG, BMP or JPEG images[^37]. The RTP Player can play any codec supported by an installed codec plugin, listed under Help > About Wireshark > Plugins filtered by the codec type[^49]. The RTP Player offers 3 playback modes: Jitter Buffer (packets outside the buffer are discarded), RTP Timestamp (packets ordered by timestamp) and Uninterrupted Mode (gaps removed)[^51]. The Wireshark RTP Player cannot play encrypted SRTP streams[^52]. The Wireshark guide notes that since 3.2.0 the RTP Player supports any codec with 8000 Hz sampling, and from 3.5.0 supports export of any codec with a user-selectable output rate[^48]. From Wireshark 3.5.0 audio export moved from the RTP Stream Analysis window to the RTP Player window, which saves decoded audio as.au or.wav with 1 channel per stream[^50]. For command-line processing, TShark's '-z rtp,streams' option collects statistics for all RTP streams, calculating max delta, max and mean jitter and packet-loss percentage, and '-z sip,stat' counts occurrences of each SIP method and status code[^36]. ## TLS Decryption and SRTP Keys A TLS key log file (for example written through the SSLKEYLOGFILE environment variable) enables Wireshark to decrypt TLS even when a Diffie-Hellman key exchange is used[^33]. Wireshark's key log file is configured at Edit > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename[^32]. editcap --inject-secrets tls, embeds TLS secrets into a pcapng Decryption Secrets Block, so the capture decrypts without separately configuring the key log preference[^31]. Wireshark's RSA private key decryption works only with SSLv3 and TLS 1.0 to 1.2[^35]. Wireshark's RSA private key method cannot decrypt TLS when the cipher suite uses (EC)DHE, when the protocol is TLS 1.3, when the key does not match the server certificate, or when the session was resumed without a ClientKeyExchange[^34]. With SDP Security Descriptions (SDES), the SRTP master key and salt travel inline in the SDP crypto attribute, and RFC 4568 requires the signaling carrying them to be protected for confidentiality and integrity (for example by TLS or S/MIME)[^17]. WarmTransfer's reading of the sources is that recovering SDES-keyed SRTP media from a capture first requires decrypting the SIP-over-TLS signaling that carries the SDP keys, so TLS decryption limits also bound media analysis[^30]. ## Terminal Troubleshooting with sngrep sngrep is a terminal (ncurses) tool that shows SIP call message flows from a live capture or from a PCAP file[^28]. sngrep is licensed under GNU GPL version 3 with an OpenSSL linking exception[^23]. sngrep's interface consists of a Call List window, a Call Flow window (the ladder view), a Call Raw window and a Message Diff window[^29]. Basic operations are handled through command-line flags: - `-I`: Reads a PCAP file[^20]. - `-d`: Selects a capture interface[^20]. - `-O`: Writes captured packets to a PCAP[^20]. - `-r` / `--rtp`: Captures RTP payload only when started with this flag[^25]. - BPF filter expression: Accepts a BPF filter expression such as 'host 192.168.1.1 and port 5060'[^20]. TLS support in sngrep is an optional build feature, compiled with --with-openssl or --with-gnutls[^27]. sngrep's TLS decryption supports only TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA and TLS_RSA_WITH_AES_256_GCM_SHA384, using a server private key given with -k (--keyfile), and needs the initial handshake in the capture[^26]. sngrep cannot decrypt TLS sessions that use Perfect Forward Secrecy (DH or ECDH key exchange), even when the private key is supplied[^24]. When built with EEP support, sngrep can send captured packets to a HOMER collector with -H (--eep-send) and listen for incoming HEP/EEP packets with -L (--eep-listen)[^21]. sngrep 1.8.2 fixed a heap buffer overflow when parsing RTP packet payloads (GitHub issue #481), so older builds should not be used on untrusted traffic[^18]. sngrep 1.8.3 added display of RFC 4733 DTMF events[^19]. ## Centralized Tracing with HOMER and HEP HEP/EEP (Extensible Encapsulation Protocol) duplicates captured IP datagrams to a remote collector by encapsulating the original packet and its header properties as concatenated chunks over UDP, TCP or SCTP; the current generation is HEPv3[^2]. The sipcapture/homer repository presents HOMER 11.x as the active version: a Go single binary for Linux and macOS on x64 and ARM64, licensed AGPL-3.0[^7]. HOMER 11 is built from 4 modules: Ingest (receives HEP over UDP, TCP, TLS, HTTP or HTTPS), Storage (writes to DuckLake, Parquet plus catalog), Node (gRPC and HTTP query, optional FlightSQL) and Coordinator (REST API gateway for the UI)[^8]. The HOMER 11 README's example ingest configuration listens for HEP on UDP port 9060 and TCP port 9061[^9]. HOMER 11 states it is backwards compatible with all HEPv3 capture agents and can optionally collect VQRTCP SIP QoS reports and SIPREC (RFC 7865/7866) signaling[^10]. Traffic is collected using standalone capture daemons or native application modules: - **heplify**: heplify is a single capture-agent binary for Linux, macOS and Windows that captures IPv4 or IPv6 packets (SIP, correlated RTCP, DNS, Diameter, logs and optionally RTP) and sends them to HOMER as HEP[^6]. Configuration parameters include selecting the interface with -i, the HEP server with -hs (default 127.0.0.1:9060), the capture mode with -m (such as SIP, SIPRTCP or SIPRTP), discarding SIP methods with -dim, and setting the SIP port range with -pr (default 5060-5090)[^4]. - **Native SIP Platforms**: The HEP project lists native HEP implementations in Kamailio, OpenSIPS, FreeSWITCH and Asterisk[^3]. Kamailio's siptrace module can store SIP messages in a database and/or duplicate them to a capture server using HEP or plain SIP, with hep_mode_on enabling HEP and hep_version selecting version 1, 2 or 3[^14]. Kamailio's sip_trace() function can trace a single message ('m'), a transaction ('t') or a whole dialog ('d')[^13]. In Kamailio siptrace, HEPv2 and HEPv3 include the timestamp and capture agent ID in the HEP header, and hep_capture_id sets that agent ID[^12]. Asterisk's res_hep (hep.conf) sends to the HOMER server set in capture_address, with options enabled (default yes), capture_id (default 0), capture_password, capture_name (since 18.16.0/20.1.0) and uuid_type (call-id by default, or channel)[^1]. WarmTransfer's reading of the sources is that a packet-sniffing HEP agent such as heplify sees SIP-over-TLS only as ciphertext, so encrypted trunks are best traced in HEP by the SIP stack itself (for example Kamailio siptrace or Asterisk res_hep) after decryption[^5]. ## See also - See also [SIP transactions dialogs and call setup](https://warmtransfer.net/knowledge/sip-transactions-dialogs). - See also [SDP offer answer and codec negotiation](https://warmtransfer.net/knowledge/sdp-offer-answer). - See also [RTP and RTCP quality metrics](https://warmtransfer.net/knowledge/rtp-rtcp-quality). - See also [SRTP and media encryption negotiation](https://warmtransfer.net/knowledge/srtp-media-security). - See also [Kamailio and OpenSIPS SIP proxies](https://warmtransfer.net/knowledge/kamailio-sip-proxy). - See also [FreeSWITCH](https://warmtransfer.net/knowledge/freeswitch-pbx). - See also [DTMF methods and interoperability failures](https://warmtransfer.net/knowledge/dtmf-interop). ## Applicability Applies to: Wireshark Foundation, IETF RTP, Wireshark Foundation TShark, Wireshark Foundation editcap, IETF SDES, Irontec sngrep, SIPCAPTURE HEP, QXIP HOMER, SIPCAPTURE heplify, Kamailio siptrace module, and Sangoma Asterisk res_hep. Deployments: on-premises and any. Sources checked 2026-09-24. The Wireshark guide notes that since 3.2.0 the RTP Player supports any codec with 8000 Hz sampling, and from 3.5.0 supports export of any codec with a user-selectable output rate[^48]. From Wireshark 3.5.0 audio export moved from the RTP Stream Analysis window to the RTP Player window, which saves decoded audio as.au or.wav with 1 channel per stream[^50]. sngrep 1.8.2 fixed a heap buffer overflow when parsing RTP packet payloads (GitHub issue #481), so older builds should not be used on untrusted traffic[^18]. sngrep 1.8.3 added display of RFC 4733 DTMF events[^19]. The sipcapture/homer repository presents HOMER 11.x as the active version: a Go single binary for Linux and macOS on x64 and ARM64, licensed AGPL-3.0[^7]. Asterisk's res_hep (hep.conf) sends to the HOMER server set in capture_address, with options enabled (default yes), capture_id (default 0), capture_password, capture_name (since 18.16.0/20.1.0) and uuid_type (call-id by default, or channel)[^1]. With SDP Security Descriptions (SDES), the SRTP master key and salt travel inline in the SDP crypto attribute, and RFC 4568 requires the signaling carrying them to be protected for confidentiality and integrity (for example by TLS or S/MIME)[^17]. RFC 3550 defines interarrival jitter as a running estimate, J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, expressed in RTP timestamp units[^15]. ## What remains uncertain Embedded packet capture (monitor capture) for SIP trunks on routers is not covered by the sources below. Call manager CLI utils network capture and RTMT packet capture are not covered by the sources below. Earlier HOMER server versions and migration to HOMER 11 are not covered by the sources below. Which SBCs and phones can export TLS session keys for SIP-over-TLS decryption is not covered by the sources below. Tracing Teams Direct Routing SIP on certified SBCs (vendor debug recording and syslog) is not covered by the sources below. Whether current Wireshark can decrypt SRTP from SDES or DTLS-SRTP keys is not covered by the sources below. Legal and consent constraints on capturing and retaining RTP audio are not covered by the sources below. Analysing RFC 4733 telephone-event DTMF in captures is not covered by the sources below. ## Sources [^1]: Asterisk's res_hep (hep.conf) sends to the HOMER server set in capture_address, with options enabled (default yes), capture_id (default 0), capture_password, capture_name (since 18.16.0/20.1.0) and uuid_type (call-id by default, or channel). Source: [res_hep - Asterisk Documentation (Module Configuration)](https://docs.asterisk.org/Latest_API/API_Documentation/Module_Configuration/res_hep/), res_hep module configuration, general section options. Checked 2026-09-24. [^2]: HEP/EEP (Extensible Encapsulation Protocol) duplicates captured IP datagrams to a remote collector by encapsulating the original packet and its header properties as concatenated chunks over UDP, TCP or SCTP; the current generation is HEPv3. Source: [sipcapture/HEP: Extensible Encapsulation Protocol (EEP/HEP)](https://github.com/sipcapture/HEP), README, protocol overview. Checked 2026-09-24. [^3]: The HEP project lists native HEP implementations in Kamailio, OpenSIPS, FreeSWITCH and Asterisk. Source: [sipcapture/HEP: Extensible Encapsulation Protocol (EEP/HEP)](https://github.com/sipcapture/HEP), README, implementations list. Checked 2026-09-24. [^4]: heplify selects the interface with -i, the HEP server with -hs (default 127.0.0.1:9060), the capture mode with -m (such as SIP, SIPRTCP or SIPRTP), discards SIP methods with -dim, and sets the SIP port range with -pr (default 5060-5090). Source: [sipcapture/heplify (README)](https://github.com/sipcapture/heplify), README, usage / flag table. Checked 2026-09-24. [^5]: A packet-sniffing HEP agent such as heplify sees SIP-over-TLS only as ciphertext, so encrypted trunks are best traced in HEP by the SIP stack itself (for example Kamailio siptrace or Asterisk res_hep) after decryption (inferred). Source: [sipcapture/heplify (README)](https://github.com/sipcapture/heplify), README, introduction (packet capture) read together with kamailio-docs-siptrace section 1. Checked 2026-09-24. [^6]: heplify is a single capture-agent binary for Linux, macOS and Windows that captures IPv4 or IPv6 packets (SIP, correlated RTCP, DNS, Diameter, logs and optionally RTP) and sends them to HOMER as HEP. Source: [sipcapture/heplify (README)](https://github.com/sipcapture/heplify), README, introduction. Checked 2026-09-24. [^7]: The sipcapture/homer repository presents HOMER 11.x as the active version: a Go single binary for Linux and macOS on x64 and ARM64, licensed AGPL-3.0. Source: [sipcapture/homer: HOMER - 100% Opensource Telecom Observability](https://github.com/sipcapture/homer), README, introduction and License section. Checked 2026-09-24. [^8]: HOMER 11 is built from four modules: Ingest (receives HEP over UDP, TCP, TLS, HTTP or HTTPS), Storage (writes to DuckLake, Parquet plus catalog), Node (gRPC and HTTP query, optional FlightSQL) and Coordinator (REST API gateway for the UI). Source: [sipcapture/homer: HOMER - 100% Opensource Telecom Observability](https://github.com/sipcapture/homer), README, architecture section. Checked 2026-09-24. [^9]: The HOMER 11 README's example ingest configuration listens for HEP on UDP port 9060 and TCP port 9061. Source: [sipcapture/homer: HOMER - 100% Opensource Telecom Observability](https://github.com/sipcapture/homer), README, all-in-one configuration example, ingest udp/tcp blocks. Checked 2026-09-24. [^10]: HOMER 11 states it is backwards compatible with all HEPv3 capture agents and can optionally collect VQRTCP SIP QoS reports and SIPREC (RFC 7865/7866) signaling. Source: [sipcapture/homer: HOMER - 100% Opensource Telecom Observability](https://github.com/sipcapture/homer), README, capture features list. Checked 2026-09-24. [^11]: The release year of HOMER 11.0.350 could not be established: the release list summary returned September 2024 while the tag page shows '21 Sep' with no year and the README references DuckDB 1.5 (disputed). Source: [sipcapture/homer Releases](https://github.com/sipcapture/homer/releases), Releases list and tag 11.0.350 header. Checked 2026-09-24. [^12]: In Kamailio siptrace, HEPv2 and HEPv3 include the timestamp and capture agent ID in the HEP header, and hep_capture_id sets that agent ID. Source: [The SIPtrace Module (Kamailio stable modules documentation)](https://www.kamailio.org/docs/modules/stable/modules/siptrace.html), Sections 3.14 hep_version and 3.15 hep_capture_id. Checked 2026-09-24. [^13]: Kamailio's sip_trace() function can trace a single message ('m'), a transaction ('t') or a whole dialog ('d'). Source: [The SIPtrace Module (Kamailio stable modules documentation)](https://www.kamailio.org/docs/modules/stable/modules/siptrace.html), Section 4.1 sip_trace(). Checked 2026-09-24. [^14]: Kamailio's siptrace module can store SIP messages in a database and/or duplicate them to a capture server using HEP or plain SIP, with hep_mode_on enabling HEP and hep_version selecting version 1, 2 or 3. Source: [The SIPtrace Module (Kamailio stable modules documentation)](https://www.kamailio.org/docs/modules/stable/modules/siptrace.html), Sections 1 (Overview), 3.13 hep_mode_on, 3.14 hep_version. Checked 2026-09-24. [^15]: RFC 3550 defines interarrival jitter as a running estimate, J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, expressed in RTP timestamp units. Source: [RFC 3550 RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.txt), Section 6.4.1, 'interarrival jitter' field definition. Checked 2026-09-24. [^16]: RFC 3550 defines the cumulative number of packets lost relative to the packets expected, so the value can be negative when duplicate packets arrive. Source: [RFC 3550 RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.txt), Section 6.4.1, 'cumulative number of packets lost' field definition. Checked 2026-09-24. [^17]: With SDP Security Descriptions (SDES), the SRTP master key and salt travel inline in the SDP crypto attribute, and RFC 4568 requires the signaling carrying them to be protected for confidentiality and integrity (for example by TLS or S/MIME). Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Section 3 (applicability), 6.1 (inline key), 8.3 (signaling protection). Checked 2026-09-24. [^18]: sngrep 1.8.2 fixed a heap buffer overflow when parsing RTP packet payloads (GitHub issue #481), so older builds should not be used on untrusted traffic. Source: [sngrep Releases](https://github.com/irontec/sngrep/releases), Release v1.8.2 notes. Checked 2026-09-24. [^19]: sngrep 1.8.3 added display of RFC 4733 DTMF events. Source: [sngrep Releases](https://github.com/irontec/sngrep/releases), Release v1.8.3 notes. Checked 2026-09-24. [^20]: sngrep reads a PCAP file with -I, selects a capture interface with -d, writes captured packets to a PCAP with -O, and accepts a BPF filter expression such as 'host 192.168.1.1 and port 5060'. Source: [irontec/sngrep: Ncurses SIP Messages flow viewer](https://github.com/irontec/sngrep), README, Usage section. Checked 2026-09-24. [^21]: When built with EEP support, sngrep can send captured packets to a HOMER collector with -H (--eep-send) and listen for incoming HEP/EEP packets with -L (--eep-listen). Source: [sngrep Wiki: Home](https://github.com/irontec/sngrep/wiki), Wiki home, EEP/HEP section. Checked 2026-09-24. [^22]: The most recent sngrep release listed on GitHub as of 2026-09-24 is 1.8.4, which changed RTP stream matching to check only active calls. Source: [sngrep Releases](https://github.com/irontec/sngrep/releases), Release v1.8.4 notes. Checked 2026-09-24. [^23]: sngrep is licensed under GNU GPL version 3 with an OpenSSL linking exception. Source: [irontec/sngrep: Ncurses SIP Messages flow viewer](https://github.com/irontec/sngrep), README, License section. Checked 2026-09-24. [^24]: sngrep cannot decrypt TLS sessions that use Perfect Forward Secrecy (DH or ECDH key exchange), even when the private key is supplied. Source: [sngrep Wiki: Home](https://github.com/irontec/sngrep/wiki), Wiki home, TLS support section. Checked 2026-09-24. [^25]: sngrep captures RTP payload only when started with -r (--rtp). Source: [sngrep Wiki: Home](https://github.com/irontec/sngrep/wiki), Wiki home, packet capture options (-r --rtp). Checked 2026-09-24. [^26]: sngrep's TLS decryption supports only TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA and TLS_RSA_WITH_AES_256_GCM_SHA384, using a server private key given with -k (--keyfile), and needs the initial handshake in the capture. Source: [sngrep Wiki: Home](https://github.com/irontec/sngrep/wiki), Wiki home, TLS support section. Checked 2026-09-24. [^27]: TLS support in sngrep is an optional build feature, compiled with --with-openssl or --with-gnutls. Source: [irontec/sngrep: Ncurses SIP Messages flow viewer](https://github.com/irontec/sngrep), README, build / configure options. Checked 2026-09-24. [^28]: sngrep is a terminal (ncurses) tool that shows SIP call message flows from a live capture or from a PCAP file. Source: [irontec/sngrep: Ncurses SIP Messages flow viewer](https://github.com/irontec/sngrep), README, introduction. Checked 2026-09-24. [^29]: sngrep's interface consists of a Call List window, a Call Flow window (the ladder view), a Call Raw window and a Message Diff window. Source: [sngrep Wiki: Home](https://github.com/irontec/sngrep/wiki), Wiki home, interface windows list. Checked 2026-09-24. [^30]: Recovering SDES-keyed SRTP media from a capture first requires decrypting the SIP-over-TLS signaling that carries the SDP keys, so TLS decryption limits also bound media analysis (inferred). Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), Sections 6.1 and 8.3 combined with the Wireshark TLS wiki key log section. Checked 2026-09-24. [^31]: editcap --inject-secrets tls, embeds TLS secrets into a pcapng Decryption Secrets Block, so the capture decrypts without separately configuring the key log preference. Source: [TLS - Wireshark Wiki](https://wiki.wireshark.org/TLS), TLS wiki, embedding decryption secrets section. Checked 2026-09-24. [^32]: Wireshark's key log file is configured at Edit > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename. Source: [TLS - Wireshark Wiki](https://wiki.wireshark.org/TLS), TLS wiki, 'Using the (Pre)-Master-Secret' section. Checked 2026-09-24. [^33]: A TLS key log file (for example written through the SSLKEYLOGFILE environment variable) enables Wireshark to decrypt TLS even when a Diffie-Hellman key exchange is used. Source: [TLS - Wireshark Wiki](https://wiki.wireshark.org/TLS), TLS wiki, 'TLS Decryption' section, key log file method. Checked 2026-09-24. [^34]: Wireshark's RSA private key method cannot decrypt TLS when the cipher suite uses (EC)DHE, when the protocol is TLS 1.3, when the key does not match the server certificate, or when the session was resumed without a ClientKeyExchange. Source: [TLS - Wireshark Wiki](https://wiki.wireshark.org/TLS), TLS wiki, RSA keys section, list of conditions. Checked 2026-09-24. [^35]: Wireshark's RSA private key decryption works only with SSLv3 and TLS 1.0 to 1.2. Source: [TLS - Wireshark Wiki](https://wiki.wireshark.org/TLS), TLS wiki, RSA keys section. Checked 2026-09-24. [^36]: TShark's '-z rtp,streams' option collects statistics for all RTP streams, calculating max delta, max and mean jitter and packet-loss percentage, and '-z sip,stat' counts occurrences of each SIP method and status code. Source: [tshark(1) manual page](https://www.wireshark.org/docs/man-pages/tshark.html), tshark(1), -z option list: 'rtp,streams' and 'sip,stat[,filter]'. Checked 2026-09-24. [^37]: RTP Stream Analysis results can be exported as CSV and its graphs saved as PDF, PNG, BMP or JPEG images. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.2 RTP Stream Analysis Window, export. Checked 2026-09-24. [^38]: In RTP Stream Analysis the lost-packet count is calculated from RTP sequence numbers, and the stream summary also reports max and mean jitter, skew, clock drift and frequency drift. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.2 RTP Stream Analysis Window, stream summary. Checked 2026-09-24. [^39]: Wireshark calculates some RTP Stream Analysis statistic columns only when it can decode the stream's codec. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.2 RTP Stream Analysis Window, note on statistic columns. Checked 2026-09-24. [^40]: RTP Stream Analysis in Wireshark shows per-packet delta from the previous packet in milliseconds, jitter, skew, bandwidth, the RTP marker bit, and a status that flags sequence errors and codec changes. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.2 RTP Stream Analysis Window, per-packet columns. Checked 2026-09-24. [^41]: Wireshark's RTP bandwidth figure is measured at the IP level: all octets including IP and UDP headers (20+8 bytes) of the stream's packets over the last second. Source: [RTP_statistics - Wireshark Wiki](https://wiki.wireshark.org/RTP_statistics), RTP_statistics wiki, bandwidth section. Checked 2026-09-24. [^42]: The RTP Streams window has a Find Reverse action (key R) that selects the reverse-direction stream for each selected stream. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.1 RTP Streams Window, action list. Checked 2026-09-24. [^43]: The Flow Sequence button in the VoIP Calls window opens a Flow Sequence (flow graph) window showing the selected calls as a ladder of messages. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), 9.3 VoIP Calls Window, button list 'Flow Sequence'. Checked 2026-09-24. [^44]: When the rtp_udp heuristic is enabled, the RTP Streams window may label streams as 'RTP ' even when the setup frames are present in the capture. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.1 RTP Streams Window. Checked 2026-09-24. [^45]: Wireshark needs the sampling clock rate to calculate jitter correctly, which makes jitter for dynamic payload types unreliable unless the rate can be learned, for example from the SDP. Source: [RTP_statistics - Wireshark Wiki](https://wiki.wireshark.org/RTP_statistics), RTP_statistics wiki, jitter section, note on dynamic payload types. Checked 2026-09-24. [^46]: Wireshark computes RTP jitter using the RFC 3550 section 6.4.1 interarrival jitter estimator, J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, where D compares arrival-time spacing with RTP-timestamp spacing. Source: [RTP_statistics - Wireshark Wiki](https://wiki.wireshark.org/RTP_statistics), RTP_statistics wiki, jitter section. Checked 2026-09-24. [^47]: During a live capture the RTP stream dialogs are not refreshed automatically; the user must press Refresh streams. Source: [Wireshark User's Guide 9.2 Playing VoIP Calls](https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html), 9.2 Playing VoIP Calls, live capture note. Checked 2026-09-24. [^48]: The Wireshark guide notes that since 3.2.0 the RTP Player supports any codec with 8000 Hz sampling, and from 3.5.0 supports export of any codec with a user-selectable output rate. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.3 RTP Player Window, version notes. Checked 2026-09-24. [^49]: The RTP Player can play any codec supported by an installed codec plugin, listed under Help > About Wireshark > Plugins filtered by the codec type. Source: [Wireshark User's Guide 9.2 Playing VoIP Calls](https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html), 9.2 Playing VoIP Calls, codec paragraph. Checked 2026-09-24. [^50]: From Wireshark 3.5.0 audio export moved from the RTP Stream Analysis window to the RTP Player window, which saves decoded audio as .au or .wav with one channel per stream. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.3 RTP Player Window, export note. Checked 2026-09-24. [^51]: The RTP Player offers three playback modes: Jitter Buffer (packets outside the buffer are discarded), RTP Timestamp (packets ordered by timestamp) and Uninterrupted Mode (gaps removed). Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.3 RTP Player Window, playback timing modes. Checked 2026-09-24. [^52]: The Wireshark RTP Player cannot play encrypted SRTP streams. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.3 RTP Player Window, limitations. Checked 2026-09-24. [^53]: In the VoIP Calls window, Prepare Filter builds a display filter that matches the selected calls and their RTP streams, and 'Limit to display filter' restricts the call list to packets matching the active display filter. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), 9.3 VoIP Calls Window, controls list. Checked 2026-09-24. [^54]: The Wireshark guide warns that the rtp_udp heuristic dissector can produce false positives, especially when UDP is set to try heuristic dissectors first. Source: [Wireshark User's Guide 9.2 Playing VoIP Calls](https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html), 9.2 Playing VoIP Calls, note on rtp_udp heuristic. Checked 2026-09-24. [^55]: Wireshark recognises RTP streams from VoIP signaling such as SDP in SIP; when the signaling is not in the capture, RTP must be decoded manually with Decode As or by enabling the rtp_udp heuristic dissector. Source: [Wireshark User's Guide 9.2 Playing VoIP Calls](https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html), 9.2 Playing VoIP Calls, paragraph on recognising RTP streams. Checked 2026-09-24. [^56]: The Wireshark RTP Streams window lists every RTP stream in the capture with per-stream lost packets, max delta, max jitter and mean jitter, and selected streams can be passed to other tools such as analysis and the player. Source: [Wireshark User's Guide 9.11 RTP (RTP Streams, RTP Stream Analysis, RTP Player windows)](https://www.wireshark.org/docs/wsug_html_chunked/ChTelRTP.html), 9.11.1 RTP Streams Window. Checked 2026-09-24. [^57]: The Wireshark SIP Flows window (Telephony > SIP Flows) lists all captured SIP transactions, including registrations, messages and calls, whether complete or in progress, and has the same features as the VoIP Calls window. Source: [Wireshark User's Guide: SIP Flows Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelSIPFlows.html), 9.20 SIP Flows Window. Checked 2026-09-24. [^58]: The VoIP Calls window's Time of Day toggle switches the displayed times between relative to capture start and absolute time of packet receipt. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), 9.3 VoIP Calls Window, 'Time of Day' option. Checked 2026-09-24. [^59]: The Wireshark VoIP Calls window detects calls from seven signaling protocols: H.323, IAX2, ISUP, MGCP/MEGACO, SIP, SKINNY and UNISTIM. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), 9.3 VoIP Calls Window, opening paragraph. Checked 2026-09-24. [^60]: The VoIP Calls window lists calls identified from signaling together with the RTP streams associated with them. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), 9.3 VoIP Calls Window, opening paragraph. Checked 2026-09-24.