# Analysing a SIP call in Wireshark

Systems: Wireshark

For Voice and network engineers diagnosing SIP call failures or media issues.

Canonical: https://warmtransfer.net/guides/sip-call-analysis-wireshark

Last verified: 2026-09-24

This guide steps through capturing and analysing a SIP call with Wireshark to locate call setup failures, one-way audio, and stream quality faults[^54][^36]. The procedure covers session signalling ladder graphs, Session Description Protocol (SDP) negotiation, and Real-Time Transport Protocol (RTP) packet metrics[^55][^29].

## Before you start

An IOS XE Embedded Packet Capture buffer is allocated in DRAM and does not persist across a reload, requiring captures to be saved before rebooting[^16]. On Catalyst 9300 switches, configuring an interface as a SPAN destination reserves that port exclusively for monitored traffic and disables general network communication[^45]. IANA registers port 5060 for service name `sip` (TCP, UDP, SCTP) and port 5061 for service name `sips` (SIP-TLS)[^22][^23].

## What changes by situation

- Where will you capture the call? On the SBC (Cisco IOS XE / CUBE); On a switch SPAN port (Cisco Catalyst 9300).
- Is the SIP signalling carried over TLS? Cleartext SIP (UDP or TCP); SIP over TLS.
- Is the media plain RTP or SRTP? Plain RTP; SRTP (encrypted media).

## Step 1: Set up the capture

**On the SBC (Cisco IOS XE / CUBE)**

### Do
On Cisco IOS XE, attach an Embedded Packet Capture to the target interface in both directions using `monitor capture <name> interface <interface> both`[^17]. Filter traffic to the relevant endpoints using `monitor capture <name> access-list <acl-name>`[^14]. Define the buffer with `monitor capture <name> buffer circular size <n>`, selecting a size between 1 MB and 100 MB[^15]. Start capturing with `monitor capture <name> start`[^18].

### Verify
Suggested check: inspect the referenced access list to confirm it allows both the SIP port and RTP media ranges between the endpoints.

### Rollback
Halt the running capture using `monitor capture <name> stop`[^18]. Captured buffer contents reside in DRAM and do not persist across a reload[^16].

**On a switch SPAN port (Cisco Catalyst 9300)**

### Do
On Catalyst 9300, configure the traffic source using `monitor session <n> source {interface <id> | vlan <id>} [both | rx | tx]`, where omitting the direction monitors both sent and received traffic[^50]. Set the destination using `monitor session <n> destination interface <id>`, designating a physical port rather than an EtherChannel or a VLAN[^46]. If applying capture filters in Wireshark, construct libpcap primitives such as `host <ip>`, `[src|dst] host <ip>`, or port primitives joined by `and`, `or`, or `not`[^2][^1].

### Verify
Display the active session configuration using `show monitor`[^49]. Ensure the destination interface is sized to avoid oversubscription, which can drop or lose packets[^48].

### Rollback
Remove the SPAN configuration using `no monitor session {<n> | all | local | remote}`, noting that entering new parameters does not clear prior settings[^47].

## Step 2: Reproduce the call and collect the capture file

**On the SBC (Cisco IOS XE / CUBE)**

### Do
Run `monitor capture <name> stop` and save the file with `monitor capture <name> export <location>` once the call is reproduced[^18].

### Verify
Suggested check: open the exported packet trace in Wireshark to confirm packets between the test endpoints were written to the export destination. Export the file before any device reload because DRAM buffers do not persist across reboots[^16].

### Rollback
Suggested rollback: delete the exported capture file from the target storage location if it is no longer required.

**On a switch SPAN port (Cisco Catalyst 9300)**

### Do
Wireshark captures on the dedicated physical monitor port while the test call is active[^46].

### Verify
Suggested check: review the Wireshark packet list to confirm traffic from both source and destination appears. Captures configured without specifying a direction monitor both sent and received traffic[^50].

### Rollback
Suggested rollback: delete the saved packet trace file if testing is abandoned.

## Step 3: Make the SIP signalling readable

**Cleartext SIP (UDP or TCP)**

### Do
If the session uses a non-standard port instead of standard SIP UDP or TCP port 5060, configure an override in Analyze > Decode As to instruct Wireshark to dissect that traffic as SIP[^22][^8]. Not every protocol or field supports Decode As[^8].

### Verify
Apply the display filter `sip.Method` and confirm matching SIP request frames appear in the packet list[^11].

### Rollback
Suggested rollback: open Analyze > Decode As, select the custom port entry, and remove it.

**SIP over TLS**

### Do
Provide Wireshark with the TLS secrets required to decrypt the session; WarmTransfer's reading of the sources is that if Wireshark has no usable key, SIP and SDP remain hidden, preventing the VoIP Calls interface from detecting calls or linking RTP to signalling[^53]. When SDP carries SRTP keying material inside an `a=crypto` attribute, the SDP carrying it must be protected by S/MIME, TLS, or IPsec[^38].

### Verify
Apply the display filter `sip.Method` and confirm decrypted SIP frames are visible[^11].

### Rollback
Suggested rollback: navigate to Wireshark preferences, clear the configured TLS secrets file path, and apply the changes.

## Step 4: Find the call

### Do
Navigate to Telephony > VoIP Calls, which lists calls detected from signalling protocols including SIP, H.323, IAX2, ISUP, MGCP/MEGACO, SKINNY, and UNISTIM, along with associated RTP streams[^54]. Highlight the test call and click Prepare Filter to apply a display filter matching the call and its streams[^57]. Alternatively, locate transactions manually by applying display filters on `sip.Call-ID`, `sip.from.user`, `sip.to.user`, or `sip.CSeq`[^11][^42]. To inspect non-call SIP transactions such as registrations or messages, open the SIP Flows window[^43].

### Verify
Suggested check: inspect the filtered packet list to ensure the test call's INVITE dialog and its unique Call-ID are displayed[^42].

### Rollback
Suggested rollback: clear the display filter bar in the main Wireshark interface.

## Step 5: Read the SIP ladder

### Do
In the VoIP Calls window, select the call and click Flow Sequence to open the Flow Graph[^55]. The Flow Graph represents each host as a vertical line and each packet as an arrow indicating direction, accompanied by timestamps and port numbers[^20]. Selecting an arrow selects the corresponding frame in the packet list[^20]. Check the first digit of the SIP status codes to classify the responses: 1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error, and 6xx global failure[^44]. Wireshark provides the unsigned integer field `sip.Status-Code` and the boolean field `sip.resend` marking a resent packet[^11][^12]. The Flow Graph can be restricted to active filters via the "Limit to display filter" checkbox and exported as PDF, PNG, BMP, JPEG, or ASCII[^21][^19].

### Verify
Suggested check: verify that the sequence of messages follows the expected progression and note any 4xx, 5xx, or 6xx terminal responses[^44].

### Rollback
Suggested rollback: close the Flow Graph window to return to the packet list.

## Step 6: Read the SDP offer and answer

### Do
Inspect the session description protocols embedded in the signalling. Note the following parameters:
- The `c=` line connection address, noting that a media-level `c=` line overrides a session-level `c=` line for that specific media stream[^39].
- The `m=` line, formatted as `m=<media> <port> <proto> <fmt>...`, specifying the media type, transport port, transport protocol, and payload format list[^40].
- The `a=rtpmap` attributes mapping each RTP payload type number from the `m=` line to an encoding name and clock rate[^41].
- Direction attributes: streams without an explicit direction attribute are `sendrecv`, while an offer marked `sendonly` must be answered with `recvonly` or `inactive`[^24]. Placing a stream on hold is achieved by re-offering it as `sendonly`, or via the older, no longer recommended method of setting `c=0.0.0.0`[^25].

### Verify
Verify that the SDP answer contains the exact same number of `m=` lines as the offer[^26]. Confirm that desired media streams were not rejected with port 0 in the answer's `m=` line[^27].

### Rollback
Suggested rollback: close the packet details pane.

## Step 7: Tie each RTP stream to the SDP

### Do
Open Telephony > RTP > RTP Streams, which enumerates all RTP streams detected in the trace[^36]. Compare each stream's destination address, destination port, and payload type (`rtp.p_type`) against the negotiated `c=`, `m=`, and `a=rtpmap` lines[^39][^40][^41][^9]. Review the stream setup tracking fields `rtp.setup`, `rtp.setup-frame`, and `rtp.setup-method` to identify which signalling frame established the media[^10]. If media streams are only classified as UDP, turn on the heuristic dissectors in Analyze > Enabled Protocols, noting that activating the `rtp_udp` heuristic often labels streams as "RTP <number>" and may obscure their link to the setup frame[^13][^37].

### Verify
Suggested check: confirm the destination IP and port of each RTP stream match the parameters advertised by the receiving endpoint in SDP[^39][^40].

### Rollback
Suggested rollback: open Analyze > Enabled Protocols and clear the `rtp_udp` heuristic checkbox if it was modified.

## Step 8: Check that media flows in both directions

### Do
In the RTP Streams window, execute Find Reverse to match forward and reverse stream pairs, or identify single streams that lack a reverse counterpart[^32]. Differentiate and verify streams by their 32-bit synchronization source (`rtp.ssrc`), which identifies the stream source independently of network addresses[^35][^9].

### Verify
WarmTransfer's reading of the sources is that if a call negotiates `sendrecv` audio but shows RTP in only one direction at the capture point, one-way audio exists at that point because the missing stream was either never transmitted or dropped prior to the capture[^24][^28]. On SPAN captures, confirm the absence of media is not caused by packet loss from an oversubscribed destination port[^48].

### Rollback
Suggested rollback: clear the stream selections in the RTP Streams window.

## Step 9: Measure stream quality

**Plain RTP**

### Do
The RTP Stream Analysis window shows per-packet statistics including packet number, sequence number, delta to previous packet, jitter, skew, and bandwidth[^29]. The side panel summarises overall stream metrics: maximum delta, jitter, packet count, sequence-based packet loss, duration, and clock drift[^30].

### Verify
Sequence numbers increment by 1 for each RTP packet sent, allowing receivers to detect packet loss[^34]. Note that specific statistical columns are only calculated when Wireshark can decode the stream's codec[^31].

### Rollback
Suggested rollback: close the RTP Stream Analysis window.

**SRTP (encrypted media)**

### Do
Because SRTP encrypts only the RTP payload while leaving the header unencrypted, fields such as sequence numbers (`rtp.seq`) and `rtp.ssrc` remain readable without keys[^52][^9]. WarmTransfer's reading of the sources is that sequence-number based loss and arrival timing statistics can still be derived from the clear RTP header, but codec-dependent statistics are unavailable[^51][^31].

### Verify
Suggested check: examine sequence gaps and jitter values while disregarding columns requiring codec payload decoding.

### Rollback
Suggested rollback: close the RTP Stream Analysis window.

## Step 10: Listen to the audio

**Plain RTP**

### Do
From the VoIP Calls window, click Play Streams to open the RTP Player[^56]. The RTP Player displays stream waveforms with indicators for sequence faults, jitter drops, and timestamp errors, and provides audio export options in `.au`, `.wav`, or raw payload formats[^33].

### Verify
Suggested check: listen to the audio stream in the player and verify whether reported acoustic defects correspond to marked sequence or jitter drops[^33].

### Rollback
Suggested rollback: close the player window and remove any exported audio files from disk.

**SRTP (encrypted media)**

### Do
WarmTransfer's reading of the sources is that audio playback is unavailable for encrypted SRTP media without session decryption keys because the payload is encrypted[^52][^51].

### Verify
Suggested check: confirm the RTP Streams list marks the media payload as encrypted.

### Rollback
Suggested rollback: close the window.

## Step 11: Compare with known failure signatures

### Do
Compare captured behavior against documented call path issues:
- **Hairpin no-audio on CUBE:** Some ITSP firewalls disregard SDP address and port information and only send RTP back to the source address of packets they first receive[^7]. On a hairpin call where neither party transmits media before receiving it, the call exhibits no audio in either direction, and running `show call active voice brief` on CUBE reveals 0/0 Rx/Tx across all call legs[^5]. Documented Cisco remedies include configuring a software MTP to send dummy RTP (preferred), media flow-around, media anti-trombone, or locally generated STUN packets[^6].
- **Duplicate `c=` lines:** Cisco documents intermittent one-way audio with certain ITSPs that reject SDP containing both session-level and media-level `c=` lines, even though the SDP specification allows them[^3]. Cisco's workaround applies a voice class SIP profile globally or per dial-peer to strip the `Audio-Connection-Info` SDP header from REINVITE requests and 200 responses[^4].
- **Signalling rejections:** If the call terminated before media, evaluate 4xx, 5xx, or 6xx responses and identify the responding host in the SIP ladder[^44][^20].

### Verify
Suggested check: correlate the trace symptoms with CUBE diagnostic output and dial-peer configuration.

### Rollback
Suggested rollback: if diagnostic SIP profiles were applied to the SBC, remove them from the dial-peers.

## Step 12: Remove the capture

**On the SBC (Cisco IOS XE / CUBE)**

### Do
Stop the capture process using `monitor capture <name> stop`[^18]. Capture buffers in DRAM are wiped when the router reloads[^16].

### Verify
Suggested check: verify that the capture instance is stopped using SBC operational commands.

### Rollback
Restart the packet capture using `monitor capture <name> start`[^18].

**On a switch SPAN port (Cisco Catalyst 9300)**

### Do
Delete the switch SPAN session using `no monitor session <n>`[^47].

### Verify
Run `show monitor` to confirm the session has been cleared from configuration[^49].

### Rollback
Reconfigure the SPAN session on the switch using `monitor session <n> source {interface <id> | vlan <id>} [both | rx | tx]` and `monitor session <n> destination interface <id>`[^50][^46].

## Applicability

Applies to: Wireshark, Cisco Unified Border Element, Cisco IOS XE, IANA port registry, IETF SDP offer, IETF RTP, IETF SDES, IETF SDP, IETF SIP, Cisco Catalyst 9300, and IETF SRTP. Deployments: on-premises and multi-tenant. Sources checked 2026-09-24. The Cisco IOS XE Embedded Packet Capture commands apply to Cisco IOS XE 17.x[^17]. On Catalyst 9300, the SPAN source commands apply to Cisco IOS XE 17.17.x[^50]. The Wireshark display filter fields `sip.Method`, `sip.Status-Code`, `sip.Call-ID`, `sip.CSeq`, `sip.from.user`, and `sip.to.user` exist through Wireshark 4.6.9[^11]. The Wireshark display filter fields `rtp.ssrc`, `rtp.seq`, `rtp.p_type`, `rtp.marker`, and `rtp.timestamp` exist through Wireshark 4.6.9[^9].

## What remains uncertain

Mechanisms for extracting TLS session secrets directly from Cisco IOS XE or CUBE are not covered by the sources below. Decrypting SRTP streams within Wireshark using imported cryptographic keys is not covered by the sources below. Capture commands for SBC platforms other than Cisco IOS XE, and switch SPAN configurations for models other than Catalyst 9300, are not covered by the sources below. Specific diagnostic signatures for NAT traversal failures or private IP addresses appearing in SDP connection fields are not covered by the sources below.

## Sources

[^1]: Wireshark capture filter primitives include 'host <ip>' (source or destination), '[src|dst] host <ip>' and '[tcp|udp] [src|dst] port <port>', combined with and, or and not. Source: [Wireshark User's Guide: Filtering while capturing](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html), Filtering while capturing > capture filter primitives. Checked 2026-09-24.
[^2]: Wireshark capture filters are written in the libpcap filter language and limit which packets are captured, unlike display filters applied afterwards. Source: [Wireshark User's Guide: Filtering while capturing](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html), Filtering while capturing (opening paragraphs). Checked 2026-09-24.
[^3]: Cisco documents intermittent one-way audio with some ITSPs whose equipment does not accept SDP carrying both a session-level and a media-level c= line, although the SDP specification permits it. Source: [Duplicate c= Lines in SDP Cause Intermittent One-way Audio with Various ITSP(s)](https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/116010-dup-c-lines-problem-solution-00.html), Duplicate c= Lines in SDP Cause Intermittent One-way Audio > Problem. Checked 2026-09-24.
[^4]: Cisco's workaround for the duplicate c= line problem is a voice class SIP profile that removes the Audio-Connection-Info SDP header from REINVITE requests and 200 responses, applied globally or per dial-peer. Source: [Duplicate c= Lines in SDP Cause Intermittent One-way Audio with Various ITSP(s)](https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/116010-dup-c-lines-problem-solution-00.html), Duplicate c= Lines in SDP Cause Intermittent One-way Audio > Solution. Checked 2026-09-24.
[^5]: On a CUBE hairpin call to such an ITSP neither party sends media until it receives some, so the call has no audio in either direction and 'show call active voice brief' shows 0/0 Rx/Tx on all legs. Source: [Troubleshoot No-way Audio Issue with Hairpin Calls on CUBE](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/214622-troubleshoot-no-audio-issues-with-hairpi.html), Troubleshoot No-way Audio Issue with Hairpin Calls on CUBE > Problem and Troubleshoot. Checked 2026-09-24.
[^6]: Cisco lists a software MTP that sends dummy RTP, media flow-around, media anti-trombone and locally generated STUN packets as remedies for no-way audio on CUBE hairpin calls, with the software MTP preferred. Source: [Troubleshoot No-way Audio Issue with Hairpin Calls on CUBE](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/214622-troubleshoot-no-audio-issues-with-hairpi.html), Troubleshoot No-way Audio Issue with Hairpin Calls on CUBE > Solution. Checked 2026-09-24.
[^7]: Cisco documents that some ITSPs ignore the IP address and port in SDP because of their firewall design and send media only back to the source of RTP they first receive from the far end. Source: [Troubleshoot No-way Audio Issue with Hairpin Calls on CUBE](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/214622-troubleshoot-no-audio-issues-with-hairpi.html), Troubleshoot No-way Audio Issue with Hairpin Calls on CUBE > Problem. Checked 2026-09-24.
[^8]: Analyze > Decode As lets a user override which dissector Wireshark uses, for example for a protocol on a non-standard port, though not every protocol or field supports it. Source: [Wireshark User's Guide: Control Protocol dissection (Enabled Protocols, Decode As)](https://www.wireshark.org/docs/wsug_html_chunked/ChCustProtocolDissectionSection.html), Control Protocol dissection > User Specified Decodes (Decode As). Checked 2026-09-24.
[^9]: Wireshark display filter fields rtp.ssrc, rtp.seq, rtp.p_type, rtp.marker and rtp.timestamp exist through Wireshark 4.6.9. Source: [Wireshark Display Filter Reference: Real-Time Transport Protocol](https://www.wireshark.org/docs/dfref/r/rtp.html), Display Filter Reference: Real-Time Transport Protocol, field rows. Checked 2026-09-24.
[^10]: Wireshark records how an RTP stream was set up in the fields rtp.setup (Stream setup), rtp.setup-frame (Setup frame) and rtp.setup-method (Setup Method). Source: [Wireshark Display Filter Reference: Real-Time Transport Protocol](https://www.wireshark.org/docs/dfref/r/rtp.html), Display Filter Reference: Real-Time Transport Protocol, rows rtp.setup / rtp.setup-frame / rtp.setup-method. Checked 2026-09-24.
[^11]: Wireshark display filter fields sip.Method, sip.Status-Code (unsigned integer), sip.Call-ID, sip.CSeq, sip.from.user and sip.to.user exist through Wireshark 4.6.9. Source: [Wireshark Display Filter Reference: Session Initiation Protocol](https://www.wireshark.org/docs/dfref/s/sip.html), Display Filter Reference: Session Initiation Protocol, field rows. Checked 2026-09-24.
[^12]: The Wireshark display filter field sip.resend is a boolean marking a resent SIP packet. Source: [Wireshark Display Filter Reference: Session Initiation Protocol](https://www.wireshark.org/docs/dfref/s/sip.html), Display Filter Reference: Session Initiation Protocol, row sip.resend (Resent Packet). Checked 2026-09-24.
[^13]: Analyze > Enabled Protocols lets a user enable or disable individual dissectors, filter the list to heuristic dissectors, and heuristic dissectors identify protocols from packet content rather than port numbers. Source: [Wireshark User's Guide: Control Protocol dissection (Enabled Protocols, Decode As)](https://www.wireshark.org/docs/wsug_html_chunked/ChCustProtocolDissectionSection.html), Control Protocol dissection > The Enabled Protocols dialog box. Checked 2026-09-24.
[^14]: An IOS XE Embedded Packet Capture can be restricted to matching traffic with 'monitor capture <name> access-list <acl-name>'. Source: [Network Services Configuration Guide, Cisco IOS XE 17.x - Embedded Packet Capture Overview](https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_nm-packet-capture-xe.html), Embedded Packet Capture Overview > How to Configure Embedded Packet Capture (access-list filter). Checked 2026-09-24.
[^15]: The IOS XE Embedded Packet Capture buffer is set with 'monitor capture <name> buffer circular size <n>', can be linear or circular, and ranges from 1 MB to 100 MB. Source: [Network Services Configuration Guide, Cisco IOS XE 17.x - Embedded Packet Capture Overview](https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_nm-packet-capture-xe.html), Embedded Packet Capture Overview > buffer configuration. Checked 2026-09-24.
[^16]: The IOS XE Embedded Packet Capture packet buffer is held in DRAM and does not persist across a reload, so a capture must be exported before the device reloads. Source: [Network Services Configuration Guide, Cisco IOS XE 17.x - Embedded Packet Capture Overview](https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_nm-packet-capture-xe.html), Embedded Packet Capture Overview > Restrictions for Embedded Packet Capture. Checked 2026-09-24.
[^17]: On Cisco IOS XE, Embedded Packet Capture attaches a capture to an interface in both directions with 'monitor capture <name> interface <interface> both'. Source: [Network Services Configuration Guide, Cisco IOS XE 17.x - Embedded Packet Capture Overview](https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_nm-packet-capture-xe.html), Embedded Packet Capture Overview > How to Configure Embedded Packet Capture (interface attachment point). Checked 2026-09-24.
[^18]: An IOS XE Embedded Packet Capture is started with 'monitor capture <name> start', stopped with 'monitor capture <name> stop', and saved for analysis with 'monitor capture <name> export <location>'. Source: [Network Services Configuration Guide, Cisco IOS XE 17.x - Embedded Packet Capture Overview](https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_nm-packet-capture-xe.html), Embedded Packet Capture Overview > How to Configure Embedded Packet Capture (start / stop / export). Checked 2026-09-24.
[^19]: A Wireshark Flow Graph can be exported as PDF, PNG, BMP, JPEG or ASCII. Source: [Wireshark User's Guide: The Flow Graph Window](https://www.wireshark.org/docs/wsug_html_chunked/ChStatFlowGraph.html), The Flow Graph Window > Export. Checked 2026-09-24.
[^20]: The Wireshark Flow Graph draws each host as a vertical line and each packet as an arrow between hosts, with timestamps and port numbers, and selecting an item selects the packet in the packet list. Source: [Wireshark User's Guide: The Flow Graph Window](https://www.wireshark.org/docs/wsug_html_chunked/ChStatFlowGraph.html), The Flow Graph Window. Checked 2026-09-24.
[^21]: The Flow Graph 'Limit to display filter' checkbox restricts the diagram to packets matching the active display filter and is ticked automatically when a filter is active on opening. Source: [Wireshark User's Guide: The Flow Graph Window](https://www.wireshark.org/docs/wsug_html_chunked/ChStatFlowGraph.html), The Flow Graph Window > controls (Limit to display filter). Checked 2026-09-24.
[^22]: IANA registers port 5060 as service name 'sip' for TCP, UDP and SCTP. Source: [Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml), registry rows: sip 5060 tcp / udp / sctp. Checked 2026-09-24.
[^23]: IANA registers port 5061 as service name 'sips' with description SIP-TLS. Source: [Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml), registry rows: sips 5061 tcp / udp / sctp. Checked 2026-09-24.
[^24]: With no direction attribute a stream is sendrecv; a stream offered as sendonly must be answered as recvonly or inactive. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 sections 5.1 and 6.1 (unicast streams). Checked 2026-09-24.
[^25]: A sendrecv stream is put on hold by re-offering it as sendonly; the older method of setting the connection address to 0.0.0.0 is no longer recommended. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8.4 Putting a Unicast Media Stream on Hold. Checked 2026-09-24.
[^26]: In SDP offer/answer the answer must contain exactly the same number of m= lines as the offer, one per offered stream. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6 Generating the Answer. Checked 2026-09-24.
[^27]: An answerer rejects an offered media stream by setting the port of the corresponding m= line in the answer to zero. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 6 Generating the Answer. Checked 2026-09-24.
[^28]: A call whose SDP negotiated sendrecv audio but which has an RTP stream in only one direction at the capture point shows one-way audio at that point; the missing direction was either never sent or lost before reaching the capture point (inferred). 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), RTP > RTP Streams Window > Find Reverse, combined with RFC 3264 section 5.1 direction semantics. Checked 2026-09-24.
[^29]: RTP Stream Analysis shows per packet the packet number, sequence number, delta to the previous packet, jitter, skew and bandwidth. 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), RTP > RTP Stream Analysis Window. Checked 2026-09-24.
[^30]: The RTP Stream Analysis side panel summarises each stream's maximum delta, jitter, packet count, lost packets calculated from sequence numbers, duration and clock 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), RTP > RTP Stream Analysis Window (side panel statistics). Checked 2026-09-24.
[^31]: Some RTP Stream Analysis statistic columns are calculated only when Wireshark 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), RTP > RTP Stream Analysis Window (note). Checked 2026-09-24.
[^32]: The RTP Streams Find Reverse function selects forward and reverse stream pairs, or selects single streams that have no reverse counterpart. 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), RTP > RTP Streams Window > Find Reverse. Checked 2026-09-24.
[^33]: The Wireshark RTP Player shows stream waveforms with marks for sequence, jitter-drop and timestamp problems, and can export audio as .au or .wav or the raw payload. 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), RTP > RTP Player Window. Checked 2026-09-24.
[^34]: The RTP sequence number increments by one for each RTP data packet sent and may be used by the receiver to detect packet loss and restore order. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), RFC 3550 section 5.1 RTP Fixed Header Fields (sequence number). Checked 2026-09-24.
[^35]: The RTP SSRC is a 32-bit identifier of a stream's source carried in the RTP header so that it does not depend on the network address. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), RFC 3550 section 3 Definitions (Synchronization source). Checked 2026-09-24.
[^36]: The Wireshark RTP Streams window lists every RTP stream in the capture and lets the user select streams and start analysis tools on them. 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), RTP > RTP Streams Window. Checked 2026-09-24.
[^37]: The Wireshark User's Guide notes that when the rtp_udp heuristic is active, most streams are shown as just 'RTP <number>' even when a setup frame is 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), RTP > RTP Streams / RTP Player note on rtp_udp. Checked 2026-09-24.
[^38]: The SDP a=crypto attribute carries SRTP keying material, and RFC 4568 requires the SDP carrying it to be protected by S/MIME or a lower-layer service such as TLS or IPsec. Source: [RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams](https://www.rfc-editor.org/rfc/rfc4568.html), RFC 4568 Security Considerations. Checked 2026-09-24.
[^39]: An SDP c= line carries the connection data needed to reach the media, and a media-level c= line overrides the session-level one for that media. Source: [SDP: Session Description Protocol](https://www.rfc-editor.org/rfc/rfc8866.html), RFC 8866 section 5.7 Connection Information. Checked 2026-09-24.
[^40]: An SDP media description line has the form m=<media> <port> <proto> <fmt> ..., giving the media type, transport port, transport protocol and format list. Source: [SDP: Session Description Protocol](https://www.rfc-editor.org/rfc/rfc8866.html), RFC 8866 section 5.14 Media Descriptions. Checked 2026-09-24.
[^41]: The SDP a=rtpmap attribute maps an RTP payload type number from the m= line to an encoding name and clock rate. Source: [SDP: Session Description Protocol](https://www.rfc-editor.org/rfc/rfc8866.html), RFC 8866 section 6.6 rtpmap. Checked 2026-09-24.
[^42]: The SIP Call-ID header carries a globally unique identifier for the call, and together with the To and From tags identifies a dialog. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 4 Overview of Operation (Call-ID description). Checked 2026-09-24.
[^43]: The Wireshark SIP Flows window shows all captured SIP transactions, such as registrations, messages and calls, and works like the VoIP Calls window. Source: [Wireshark User's Guide: SIP Flows Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelSIPFlows.html), SIP Flows Window. Checked 2026-09-24.
[^44]: The first digit of a SIP status code defines its class: 1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error and 6xx global failure. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), RFC 3261 section 7.2 Responses. Checked 2026-09-24.
[^45]: When a Catalyst 9300 port is configured as a SPAN destination, only monitored traffic passes through it. Source: [Network Management Configuration Guide, Cisco IOS XE 17.17.x (Catalyst 9300 Switches) - Configuring SPAN and RSPAN](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/nmgmt/b_1717_nmgmt_9300_cg/configuring_span_and_rspan.html), Configuring SPAN and RSPAN > Restrictions / Destination Port. Checked 2026-09-24.
[^46]: On Catalyst 9300 a SPAN destination is set with 'monitor session <n> destination interface <id>' and must be a physical port, not an EtherChannel or a VLAN. Source: [Network Management Configuration Guide, Cisco IOS XE 17.17.x (Catalyst 9300 Switches) - Configuring SPAN and RSPAN](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/nmgmt/b_1717_nmgmt_9300_cg/configuring_span_and_rspan.html), Configuring SPAN and RSPAN > Creating a Local SPAN Session. Checked 2026-09-24.
[^47]: New SPAN commands do not remove previously configured SPAN parameters; 'no monitor session {<n> | all | local | remote}' deletes them. Source: [Network Management Configuration Guide, Cisco IOS XE 17.17.x (Catalyst 9300 Switches) - Configuring SPAN and RSPAN](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/nmgmt/b_1717_nmgmt_9300_cg/configuring_span_and_rspan.html), Configuring SPAN and RSPAN > Creating a Local SPAN Session (step notes). Checked 2026-09-24.
[^48]: An oversubscribed SPAN destination, such as a slower port monitoring a faster one, can drop or lose packets. Source: [Network Management Configuration Guide, Cisco IOS XE 17.17.x (Catalyst 9300 Switches) - Configuring SPAN and RSPAN](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/nmgmt/b_1717_nmgmt_9300_cg/configuring_span_and_rspan.html), Configuring SPAN and RSPAN > Restrictions for SPAN. Checked 2026-09-24.
[^49]: On Catalyst 9300 'show monitor' displays the current SPAN and RSPAN configuration. Source: [Network Management Configuration Guide, Cisco IOS XE 17.17.x (Catalyst 9300 Switches) - Configuring SPAN and RSPAN](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/nmgmt/b_1717_nmgmt_9300_cg/configuring_span_and_rspan.html), Configuring SPAN and RSPAN > Monitoring SPAN and RSPAN Operations. Checked 2026-09-24.
[^50]: On Catalyst 9300 a SPAN source is set with 'monitor session <n> source {interface <id> | vlan <id>} [both | rx | tx]', and with no direction given both sent and received traffic are monitored. Source: [Network Management Configuration Guide, Cisco IOS XE 17.17.x (Catalyst 9300 Switches) - Configuring SPAN and RSPAN](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/nmgmt/b_1717_nmgmt_9300_cg/configuring_span_and_rspan.html), Configuring SPAN and RSPAN > Creating a Local SPAN Session. Checked 2026-09-24.
[^51]: For SRTP media captured without keys, sequence-number based loss and timing statistics can still be derived from the clear RTP header, but codec-dependent statistics and audio playback are not available (inferred). Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), RFC 3711 section 3.1, combined with Wireshark User's Guide RTP Stream Analysis note on codec-dependent columns. Checked 2026-09-24.
[^52]: In SRTP the encrypted portion is the RTP payload; the RTP header, including sequence number and SSRC, is authenticated but not encrypted. Source: [RFC 3711: The Secure Real-time Transport Protocol (SRTP)](https://www.rfc-editor.org/rfc/rfc3711.html), RFC 3711 section 3.1 SRTP Packet Format. Checked 2026-09-24.
[^53]: If SIP is carried over TLS and Wireshark has no usable key, the SIP and SDP are not visible, so VoIP Calls cannot list the call and RTP streams cannot be tied to it through signalling (inferred). Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), VoIP Calls window (calls are detected from signalling protocols), combined with TLS wiki on decryption requirements. Checked 2026-09-24.
[^54]: The Wireshark VoIP Calls window lists calls detected from H.323, IAX2, ISUP, MGCP/MEGACO, SIP, SKINNY and UNISTIM signalling together with their related RTP streams. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), VoIP Calls Window (introductory paragraph). Checked 2026-09-24.
[^55]: In the VoIP Calls window the Flow Sequence button opens a Flow Graph of the selected calls. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), VoIP Calls Window > controls (Flow Sequence). Checked 2026-09-24.
[^56]: In the VoIP Calls window the Play Streams button sends the selected calls' RTP streams to the RTP Player window. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), VoIP Calls Window > controls (Play Streams). Checked 2026-09-24.
[^57]: In the VoIP Calls window the Prepare Filter button builds and applies a display filter matching the selected calls and their streams. Source: [Wireshark User's Guide: VoIP Calls Window](https://www.wireshark.org/docs/wsug_html_chunked/ChTelVoipCalls.html), VoIP Calls Window > controls (Prepare Filter). Checked 2026-09-24.