# NAT traversal ICE STUN and TURN Canonical: https://warmtransfer.net/knowledge/nat-traversal-ice Last verified: 2026-09-16 Interactive Connectivity Establishment (ICE), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN) define protocol mechanisms for discovering network paths and traversing firewalls[^6][^5][^7]. In the field, Cisco devices use STUN alongside specific media flow patterns and transport preferences to establish voice and video paths across enterprise boundaries[^2][^1][^3]. ## Specifications and Standards Baseline RFC 8445 of July 2018 is the current Interactive Connectivity Establishment specification, and its header records that it obsoletes RFC 5245[^6]. RFC 8489 of February 2020 is the current Session Traversal Utilities for NAT specification, obsoleting RFC 5389, which had itself obsoleted RFC 3489[^5]. RFC 8656 of February 2020 is the current Traversal Using Relays around NAT specification, defined as relay extensions to STUN, and its header records that it obsoletes RFC 5766 and RFC 6156[^7]. In the field, Cisco's Network Requirements for Webex Services article dated 9 September 2026 states that the Webex app and Cisco Video devices use STUN (RFC 5389) for firewall traversal and media node reachability testing, citing a specification that RFC 8489 obsoleted in February 2020[^3]. ## Media Transport and Firewall Traversal Cisco states that Webex media flows in both directions using a symmetric inside-initiated 5-tuple stream outbound to the Webex cloud[^1]. This 5-tuple consists of source IP address, destination IP address, source port, destination port, and protocol[^1]. For transport, Cisco states that in preference order Webex apps and Cisco Video devices support UDP, TCP, and TLS as media transport protocols[^2]. They fall back to TCP if UDP ports are blocked by the firewall and to TLS if TCP ports are blocked[^2]. Cisco prefers and strongly recommends UDP for all Webex voice and video media streams in line with RFC 3550[^2]. In the field, the word TURN occurs 0 times in the Webex Calling port reference article and 0 times in the Webex Calling media optimization article[^4]. In the field, no Cisco source in the corpus names a relay candidate or a TURN server for Webex Calling, even though both articles describe a media relay in the cloud that ICE removes[^4]. ## Hairpin Traversal and STUN Remedies Cisco describes a no-way audio failure specific to hairpin calls, where a call arriving from an internet telephony service provider is forwarded or transferred back to that provider[^9]. Some providers disregard the IP address and port in the SDP because of their firewall implementation and transmit only to the source address of RTP they have already received[^9]. On a hairpin call, neither end sends first because the IP phone that would normally send dummy RTP after opening its ports is not in the path[^9]. Cisco provides 4 remedies for hairpin no-way audio on Cisco Unified Border Element[^8]: - A software media termination point[^8]. - Media flow-around[^8]. - Media anti-trombone[^8]. - Enabling the border element to send STUN packets to the negotiated media IP address and port[^8]. ## See also See also [Webex Calling ICE media path optimization](https://warmtransfer.net/knowledge/webex-calling-media-optimization). See also [One-way and no-way audio diagnosis](https://warmtransfer.net/knowledge/one-way-audio). See also [Firewall ports and IP ranges for cloud calling](https://warmtransfer.net/knowledge/firewall-ports-uc). ## Applicability Applies to: Cisco Webex, Internet Engineering Task Force SIP, Cisco Webex Calling, and Cisco Unified Border Element. Sources checked 2026-09-16. ## What remains uncertain Whether Webex uses a TURN relay and where it sits is not covered by the sources below. Which STUN specification Webex actually implements given that it cites an obsoleted one is not covered by the sources below. Which ICE candidate types Webex Calling gathers and in what priority is not covered by the sources below. Which addresses the Webex Calling STUN servers answer on is not covered by the sources below. What RFC 8863 changes about ICE is not covered by the sources below. ## Sources [^1]: Cisco states that Webex media flows in both directions using a symmetric inside-initiated 5-tuple stream outbound to the Webex cloud, where the 5-tuple is source IP address destination IP address source port destination port and protocol. Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Webex media flows paragraph. Checked 2026-09-16. [^2]: Cisco states that in preference order Webex apps and Cisco Video devices support UDP TCP and TLS as media transport protocols, that they fall back to TCP if UDP ports are blocked by the firewall and to TLS if TCP ports are blocked, and that it prefers and strongly recommends UDP for all Webex voice and video media streams in line with RFC 3550. Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Webex media transport protocols, UDP preference paragraph. Checked 2026-09-16. [^3]: Cisco's Network Requirements for Webex Services article dated 9 September 2026 states that the Webex app and Cisco Video devices use STUN (RFC 5389) for firewall traversal and media node reachability testing, citing a specification that RFC 8489 obsoleted in February 2020 (field report). Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Webex media flows paragraph, the STUN citation. Checked 2026-09-16. [^4]: The word TURN occurs 0 times in the Webex Calling port reference article and 0 times in the Webex Calling media optimization article, so no Cisco source the corpus holds names a relay candidate or a TURN server for Webex Calling even though both describe a media relay in the cloud that ICE removes (field report). Source: [Port Reference Information for Webex Calling](https://help.webex.com/article/b2exve/port-reference-information-for-cisco-webex-calling), whole article, and the Webex Calling media optimization article, counted against the rendered text. Checked 2026-09-16. [^5]: RFC 8489 of February 2020 is the current Session Traversal Utilities for NAT specification and its own header records that it obsoletes RFC 5389, which had itself obsoleted RFC 3489. Source: [RFC 8489 — Session Traversal Utilities for NAT (STUN)](https://www.rfc-editor.org/rfc/rfc8489.txt), RFC 8489 document header, Obsoletes line. Checked 2026-09-16. [^6]: RFC 8445 of July 2018 is the current Interactive Connectivity Establishment specification and its own header records that it obsoletes RFC 5245. Source: [RFC 8445 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal](https://www.rfc-editor.org/rfc/rfc8445.txt), RFC 8445 document header. Checked 2026-09-16. [^7]: RFC 8656 of February 2020 is the current Traversal Using Relays around NAT specification, defined as relay extensions to STUN, and its own header records that it obsoletes RFC 5766 and RFC 6156. Source: [RFC 8656 — Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)](https://www.rfc-editor.org/rfc/rfc8656.txt), RFC 8656 document header. Checked 2026-09-16. [^8]: Cisco gives 4 remedies for hairpin no-way audio on Cisco Unified Border Element: a software media termination point, media flow-around, media anti-trombone, and enabling the border element to send STUN packets to the negotiated media IP address and port. 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), Solution section headings. Checked 2026-09-16. [^9]: Cisco describes a no-way audio failure specific to hairpin calls, where a call arriving from an internet telephony service provider is forwarded or transferred back to that provider: some providers disregard the IP address and port in the SDP because of their firewall implementation and transmit only to the source address of RTP they have already received, and on a hairpin call neither end sends first because the IP phone that would normally send dummy RTP after opening its ports is not in the path. 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), Problem section. Checked 2026-09-16.