# One-way and no-way audio diagnosis

Canonical: https://warmtransfer.net/knowledge/one-way-audio

Last verified: 2026-09-24

One-way audio occurs when traffic travels in one direction but is lost in the opposite direction because RTP runs over UDP without an underlying connection to enforce symmetric delivery[^60][^36]. Cisco states that one-way audio, defined as a conversation between 2 people where only one person hears anything, does not actually represent a voice-quality issue despite being covered in voice-quality troubleshooting documentation[^58].

## Failure mechanisms and causes

Cisco frames one-way audio as an issue occurring on calls established from an IP station through a Cisco IOS voice gateway or on toll-bypass calls between 2 Cisco gateways, attributing it to an improperly configured Cisco IOS gateway, a firewall, or a routing or default gateway problem[^53]. For instance, certain Cisco IOS gateways like the VG200 disable IP routing by default, causing one-way voice unless the global `ip routing` command is enabled[^57][^27].

When a Cisco IOS H.323 gateway runs multiple active IP interfaces, signalling components can reference different source addresses, which Cisco lists as a source of one-way audio[^59][^17]. Cisco directs administrators to bind H.323 signalling to a specific physical or loopback address using `h323-gateway voip bind srcaddr`[^59][^17]. However, on Cisco IOS 12.2(6), this binding remedy causes a one-way audio defect tracked under bug ID CSCdw69681[^59][^16].

On a Cisco IOS gateway, the backward voice path opens immediately when the RTP stream starts[^11]. Conversely, the gateway does not cut through the forward audio path until it receives answer supervision via a Connect message from the remote telco or switch, and missing supervision results in one-way audio[^52][^15]. Applying the `voice rtp send-recv` command bypasses this wait, establishing a two-way path as soon as the RTP channel opens[^52][^47].

In SIP trunk environments, Twilio identifies specific directional breakdowns between PBX deployments and the PSTN:
- When a PSTN party hears the PBX user but the PBX user hears nothing, Twilio attributes the issue to the PBX inserting its private LAN IP into the SDP or a firewall blocking incoming RTP from Twilio[^43]. Twilio prescribes advertising the WAN IP in SDP and permitting Twilio's IP ranges and ports through the firewall[^43].
- When the PBX user hears the PSTN caller but the PSTN caller hears nothing, Twilio attributes the failure to a firewall blocking outbound RTP from the PBX, an internet provider filtering RTP, or routing issues reducing the packet time-to-live (TTL) to 10 or less[^42].
- On origination calls from the PSTN to a PBX, an absence of audio followed by a call drop after 20 or 30 seconds occurs when customer SIP infrastructure rewrites IP addresses in the Via headers sent in responses to Twilio's INVITE[^46].

## NAT, latching, and hairpin deadlocks

RFC 7362 describes latching: a media relay takes the source address and port of the media packets it receives and uses them as the destination for media going the other way[^28]. Latching requires the relay to receive media before it begins transmitting[^31]. Relays generally perform latching once per peer, locking the destination until a new offer/answer exchange occurs[^30]. Latching introduces security exposures, such as port flooding or spoofed media injection to hijack a session, which RFC 7362 notes SRTP helps mitigate[^29].

Twilio offers a per-trunk Symmetric RTP setting that causes Twilio to send RTP back to the received source address rather than the SDP target[^44]. However, Twilio recommends leaving Symmetric RTP disabled, considering delivery to the negotiated SDP address more secure[^45]. In Asterisk, the `res_pjsip` module provides the `rtp_symmetric` setting to return RTP to the received source IP and port, `external_media_address` to translate SDP media IPs for destinations outside `local_net`, and `direct_media` to govern whether media routes directly between endpoints rather than anchoring locally[^10][^9][^8].

On hairpin calls where an incoming call from an internet telephony service provider (ITSP) forwards or transfers directly back out to that provider, no-way audio can occur[^56]. This occurs because providers behind firewalls may discard SDP addresses and wait to latch onto incoming RTP, but neither leg transmits first because endpoints like IP phones that emit dummy RTP are absent[^56][^20]. Cisco documents 4 remedies for hairpin no-way audio on Cisco Unified Border Element (CUBE)[^55][^22]:
- A software media termination point (MTP), which is designated as the preferred remedy because it transmits dummy RTP to both legs to resolve the deadlock, though it only functions on G.711 calls because hardware MTPs cannot generate dummy streams[^26][^25].
- Media flow-around mode, which allows media to bypass CUBE while signalling terminates on the border element, unlike flow-through mode where both terminate on CUBE[^12].
- Media anti-tromboning, which detects loops created by transfers or forwards and prunes them from the RTP path while maintaining the SIP loop[^3]. Anti-tromboning only fixes hairpin no-way audio if supported on both CUBE and the ITSP, does not support H.323, and fails if one leg uses flow-through while the other uses flow-around, or if SDP handling modes mismatch between pass-through and normal processing[^18][^2][^1][^4].
- Configuring CUBE to transmit STUN packets directly to the negotiated media address and port[^55][^22].

## Signalling and endpoint diagnostics

Under RFC 3264 offer/answer rules, directional attributes restrict media flow: an offer containing `sendonly` requires an answer of `recvonly` or `inactive`, while an offer of `recvonly` necessitates `sendonly` or `inactive`[^38]. RFC 3264 dictates that endpoints continue sending and receiving RTCP during `sendonly`, `recvonly`, and `inactive` sessions; the presence of RTCP does not prove bidirectional RTP flow[^35]. Although RFC 3264 advises against using `0.0.0.0` connection addresses for call hold, endpoints receiving this legacy RFC 2543 formatting must cease transmitting both RTP and RTCP to the peer[^39].

In debug outputs, separate START RX and START TX log lines, each with the remote IPv4 address and codec, show whether a phone opened each direction of the stream and which address it is using[^34]. If endpoint stream metrics report Rx Count=0 while the local encoder registers outbound packets, the diagnostic logs confirm a failure in the endpoint's receive path[^33].

In the field, Cisco's primary one-way audio troubleshooting material sits in the Unified Communications Manager 12.5(1) guide, last updated 24 November 2023, which focuses on H.323, SCCP, and Cisco IOS commands rather than SIP trunks or session border controllers[^54][^14]. WarmTransfer's reading of the sources is that this Unified CM guide is probably of limited direct use for modern SIP trunk or SBC topologies, as mechanisms like SDP addressing, latching, and hairpin deadlocks are addressed in separate documents[^13].

## Applicability

Applies to: Cisco Unified Communications Manager, Cisco IOS voice gateways, Cisco IOS H.323 gateways, Twilio Elastic SIP Trunking, IETF SBCs, Asterisk res_pjsip, Cisco Unified Border Element, Cisco Unified Border Element with Unified CM MTP, IETF SDP offer-answer, and Cisco IP Phone 7800. Deployments: on-premises and multi-tenant. Sources checked 2026-09-24. In the field, Cisco's canonical one-way audio guidance sits in the Unified Communications Manager 12.5(1) troubleshooting guide last updated 24 November 2023[^54]. The Cisco one-way audio guidance in that guide covers Unified CM Release 12.5(1) on Cisco IOS, H.323, and SCCP gateway platforms[^14]. Cisco IOS version 12.2(6) is specifically affected by bug CSCdw69681[^59][^16]. Cisco's phone debug stream statistics and START RX and START TX lines apply to Cisco IP Phone 7800/8800 series devices[^33][^34]. In Cisco IOS 15M&T, media anti-tromboning does not support H.323[^2]. Asterisk configuration options apply to the `res_pjsip` module[^10][^9][^8]. Twilio Elastic SIP Trunking settings apply to Twilio trunks[^43][^44].

## What remains uncertain

- What is documented about one-way audio on Teams Direct Routing and media bypass is not covered by the sources below.
- Whether the one-way audio guidance has been reissued for a current Unified CM release is not covered by the sources below.
- How enabling CUBE to send STUN packets to the negotiated media address is configured and when it is safe is not covered by the sources below.
- SIP ALG on customer firewalls as a cause of one-way audio is not covered by the sources below.
- Whether CUBE anti-tromboning supports SRTP and from which release is not covered by the sources below.
- The fixed-in release for CUBE anti-trombone bug CSCwh51083 causing no-way audio after consult transfer is not covered by the sources below.
- The default Symmetric RTP state on a new Twilio trunk is not covered by the sources below.
- The standards basis for media keepalives that hold NAT bindings open is not covered by the sources below.

## Sources

[^1]: CUBE anti-tromboning does not work when one call leg uses media flow-through and the other uses media flow-around. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Path](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_media-path.html), Media Path > Media Anti-Tromboning > Restrictions. Checked 2026-09-24.
[^2]: The IOS 15M&T CUBE media path guide says media anti-tromboning does not support H.323. Source: [Cisco Unified Border Element Fundamentals and Basic Setup, Cisco IOS Release 15M&T - Configuring Media Path](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_fund/configuration/15-mt/cube-fund-15-mt-book/media-path.html), Configuring Media Path > Media Anti-Tromboning > Restrictions. Checked 2026-09-24.
[^3]: Cisco documents media anti-tromboning as a CUBE media path mode that detects media loops created by call transfers or forwards and removes them from the RTP path, leaving the loop only in SIP signalling. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Path](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_media-path.html), Media Path > Media Anti-Tromboning, introduction. Checked 2026-09-24.
[^4]: CUBE anti-tromboning does not work when one call leg uses SDP pass-through and the other uses normal SDP handling. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Path](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_media-path.html), Media Path > Media Anti-Tromboning > Restrictions. Checked 2026-09-24.
[^5]: According to the IOS 15M&T CUBE media path guide, CUBE does not perform REFER-based transfers or SRTP while media anti-tromboning is active (disputed). Source: [Cisco Unified Border Element Fundamentals and Basic Setup, Cisco IOS Release 15M&T - Configuring Media Path](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_fund/configuration/15-mt/cube-fund-15-mt-book/media-path.html), Configuring Media Path > Media Anti-Tromboning > Restrictions. Checked 2026-09-24.
[^6]: The CUBE guide for IOS XE 17.6 onwards says anti-tromboning is possible for SRTP calls, but only when SDP pass-through is enabled (disputed). Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Media Path](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_media-path.html), Media Path > Media Anti-Tromboning > Restrictions. Checked 2026-09-24.
[^7]: On AS5350 and AS5400 gateways, voice-fastpath caches RTP stream information, so the logical channel is not updated after hold or transfer, causing one-way audio. The guide's fix is no voice-fastpath enable. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > voice-fastpath subsection. Checked 2026-09-24.
[^8]: Asterisk's direct_media option controls whether media may flow directly between endpoints, rather than being anchored on Asterisk. Source: [Configuring res_pjsip to work through NAT](https://docs.asterisk.org/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Configuring-res_pjsip-to-work-through-NAT/), Option: direct_media. Checked 2026-09-24.
[^9]: Asterisk's external_media_address option rewrites the SDP media address to the configured external address when the message goes to a destination outside local_net and the media address in the SDP is inside local_net. Source: [Configuring res_pjsip to work through NAT](https://docs.asterisk.org/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Configuring-res_pjsip-to-work-through-NAT/), Options: external_media_address; local_net. Checked 2026-09-24.
[^10]: Asterisk's res_pjsip rtp_symmetric option makes RTP symmetric: Asterisk sends RTP back to the address and port it received RTP from. Source: [Configuring res_pjsip to work through NAT](https://docs.asterisk.org/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/Configuring-res_pjsip-to-work-through-NAT/), Option: rtp_symmetric. Checked 2026-09-24.
[^11]: On a Cisco IOS gateway, the backward voice path opens as soon as the RTP stream starts. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > answer supervision subsection. Checked 2026-09-24.
[^12]: In CUBE media flow-around mode, signalling terminates and originates on CUBE while media bypasses it. In flow-through mode, both media and signalling terminate and originate on CUBE. Source: [Cisco Unified Border Element Fundamentals and Basic Setup, Cisco IOS Release 15M&T - Configuring Media Path](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_fund/configuration/15-mt/cube-fund-15-mt-book/media-path.html), Configuring Media Path > Media Flow-Through; Media Flow-Around. Checked 2026-09-24.
[^13]: Cisco's Unified CM one-way audio section is probably of limited direct use for a current SIP-trunk or SBC estate. Its remedies are IOS, H.323 and SCCP commands, while the SIP-era causes in this packet (SDP address, latching, hairpin deadlock) come from other documents (inferred). Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio (whole subsection). Checked 2026-09-24.
[^14]: The Cisco one-way audio guidance held here is in the Unified CM Release 12.5(1) troubleshooting guide, Device Issues chapter, last updated 2023-11-24. Its causes are H.323, SCCP and IOS-platform issues; none is specific to SIP trunks or SBCs. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio (whole subsection); page update date. Checked 2026-09-24.
[^15]: A Cisco IOS gateway does not open the forward audio path until it receives a Connect message (answer supervision) from the remote end. If answer supervision never arrives, the result is one-way audio. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > answer supervision subsection. Checked 2026-09-24.
[^16]: The same guide says the H.323 bind remedy can itself cause one-way audio on Cisco IOS 12.2(6), and gives bug ID CSCdw69681. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > H.323 signalling bind subsection, note. Checked 2026-09-24.
[^17]: When a Cisco IOS H.323 gateway has more than one active IP interface, the Unified CM 12.5(1) guide says to bind H.323 signalling to one source address with h323-gateway voip bind srcaddr, so the gateway always uses the same source address. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > H.323 signalling bind subsection. Checked 2026-09-24.
[^18]: Technote 214622 says media anti-trombone only fixes hairpin no-way audio if both CUBE and the ITSP support the anti-trombone feature. 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), Technote 214622, Solution > Media Anti-Trombone. Checked 2026-09-24.
[^19]: Technote 214622 lists a fourth remedy: CUBE sends locally generated STUN packets to the negotiated media address, which can open the far-end firewall. It is configured at dial-peer level. 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), Technote 214622, Solution > Enable CUBE to send STUN packets. Checked 2026-09-24.
[^20]: In a hairpin call through CUBE, neither the caller nor the called party sends RTP until it receives RTP from something in the call path. Cisco calls this a deadlock, and the result is no-way audio. 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), Technote 214622, Problem section. Checked 2026-09-24.
[^21]: Technote 214622 warns that with media flow-around, RTP bypasses CUBE, so CUBE cannot terminate media on those calls. 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), Technote 214622, Solution > Media Flow-Around. Checked 2026-09-24.
[^22]: Technote 214622 documents four remedies for no-way audio on hairpin calls through CUBE: a software MTP, media flow-around, media anti-trombone, and having CUBE send STUN packets. 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), Technote 214622, Solution section headings. Checked 2026-09-24.
[^23]: Technote 214622 notes that if media flow-around is configured globally, a media flow-through setting on a dial-peer has no effect. 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), Technote 214622, restrictions note under the media path remedies. Checked 2026-09-24.
[^24]: Technote 214622 attributes the hairpin deadlock to ITSPs that ignore the SDP media address because of firewall restrictions and wait to receive RTP first. That leaves CUBE needing to send RTP first. 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), Technote 214622, Problem section. Checked 2026-09-24.
[^25]: The software MTP remedy only works for G.711 calls, because a software MTP can only bridge G.711. Hardware MTPs cannot send the dummy RTP stream. 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), Technote 214622, Solution > Software MTP, requirements. Checked 2026-09-24.
[^26]: Technote 214622 calls a software MTP the preferred remedy for hairpin no-way audio, because the software MTP sends dummy RTP packets to both parties and breaks the deadlock. 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), Technote 214622, Solution > Software MTP. Checked 2026-09-24.
[^27]: Some Cisco IOS gateways, such as the VG200, have IP routing disabled by default, which the Unified CM 12.5(1) guide lists as a cause of one-way audio. The fix it gives is the global ip routing command. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > IP routing subsection. Checked 2026-09-24.
[^28]: RFC 7362 (Informational) describes latching: a media relay takes the source address and port of the media packets it receives and uses them as the destination for media going the other way. Source: [Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication](https://www.rfc-editor.org/rfc/rfc7362.html), RFC 7362 section 4. Checked 2026-09-24.
[^29]: RFC 7362 lists security risks in latching: an attacker can flood latching ports to exhaust resources, or send spoofed packets to a relay port to capture a session's media. It says SRTP helps mitigate these threats. Source: [Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication](https://www.rfc-editor.org/rfc/rfc7362.html), RFC 7362 section 5. Checked 2026-09-24.
[^30]: RFC 7362 says latching is usually done once per peer and is not allowed to change until a new offer/answer exchange takes place. Source: [Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication](https://www.rfc-editor.org/rfc/rfc7362.html), RFC 7362 section 4. Checked 2026-09-24.
[^31]: RFC 7362 says that for latching to work, a media relay must start receiving media before it starts sending. Source: [Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication](https://www.rfc-editor.org/rfc/rfc7362.html), RFC 7362 section 4. Checked 2026-09-24.
[^32]: The guide gives minimum software for NAT to translate Skinny (SCCP) signalling for voice: Cisco IOS 12.1(5)T on IOS gateways and PIX firewall 6.0. If Skinny runs on a non-default TCP port, it also needs ip nat service skinny tcp port. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > NAT subsection. Checked 2026-09-24.
[^33]: In Cisco's 7800/8800 phone debug method, stream statistics showing Rx Count=0 while the encoder reports packets sent mean the phone transmitted but received no RTP. That confirms a one-way failure in the phone's receive direction. Source: [Troubleshoot One Way Audio Issue Using CLI Debug Outputs from Cisco IP Phone 7800/8800 Series](https://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/ip-phone-7800-series/200903-Troubleshoot-One-Way-Audio-Issue-Using-C.html), Technote 200903, Troubleshoot section, final stream statistics. Checked 2026-09-24.
[^34]: In the same phone debug output, separate START RX and START TX log lines, each with the remote IPv4 address and codec, show whether the phone opened each direction of the stream and which address it is using. Source: [Troubleshoot One Way Audio Issue Using CLI Debug Outputs from Cisco IP Phone 7800/8800 Series](https://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/ip-phone-7800-series/200903-Troubleshoot-One-Way-Audio-Issue-Using-C.html), Technote 200903, Troubleshoot section, RX and TX log lines. Checked 2026-09-24.
[^35]: RFC 3264 says RTCP is still sent and received on sendonly, recvonly and inactive RTP streams. Seeing RTCP therefore does not mean media is flowing in both directions. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 5.1. Checked 2026-09-24.
[^36]: Cisco's Unified CM 12.5(1) troubleshooting guide says RTP streams have no connection because they run over UDP, so traffic can get through in one direction and be lost in the other. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio (opening paragraphs). Checked 2026-09-24.
[^37]: Under RFC 3264, a media stream with no direction attribute is treated as sendrecv. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 5.1. Checked 2026-09-24.
[^38]: Under RFC 3264, if an offer marks a stream sendonly, the answer must mark it recvonly or inactive. If the offer marks it recvonly, the answer must mark it sendonly 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 section 6.1. Checked 2026-09-24.
[^39]: RFC 3264 no longer recommends setting the connection address to 0.0.0.0 to signal hold (the RFC 2543 method), but agents must still handle it. When it is received, neither RTP nor RTCP should be sent to the peer. 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. Checked 2026-09-24.
[^40]: RFC 4961 gives the reason: NATs without an application layer gateway, and SBCs or media relays behind address-dependent or port-dependent NATs, need endpoints to use symmetric UDP ports to set up bidirectional traffic. Source: [Symmetric RTP / RTP Control Protocol (RTCP)](https://www.rfc-editor.org/rfc/rfc4961.html), RFC 4961 section 4 (motivation). Checked 2026-09-24.
[^41]: RFC 4961 (BCP 131) recommends always using symmetric RTP and symmetric RTCP for bidirectional media streams. Symmetric means sending from the same UDP port the endpoint receives on. Source: [Symmetric RTP / RTP Control Protocol (RTCP)](https://www.rfc-editor.org/rfc/rfc4961.html), RFC 4961 section 5 (recommendation) and section 3 (definition). Checked 2026-09-24.
[^42]: For the opposite case, where the PBX user hears the PSTN party but not vice versa, Twilio gives three causes: a firewall blocking RTP from the PBX to Twilio, the internet provider filtering RTP, and routing that brings the packets' TTL down to 10 or less. Source: [Troubleshooting your Trunk](https://www.twilio.com/docs/sip-trunking/troubleshooting), Heading: The person on your PBX can hear the person on the PSTN end of the call, but not vice-versa. Checked 2026-09-24.
[^43]: Twilio's trunk troubleshooting page covers the case where the PSTN party hears the PBX user but the PBX user cannot hear the PSTN party. The causes it gives are the PBX putting its LAN IP in the SDP, and a firewall blocking RTP from Twilio. The remedies are to advertise the WAN IP in SDP and to allow RTP from Twilio's published IP ranges and ports. Source: [Troubleshooting your Trunk](https://www.twilio.com/docs/sip-trunking/troubleshooting), Heading: The person out on the PSTN can hear the person on your PBX but not vice versa. Checked 2026-09-24.
[^44]: Twilio Elastic SIP Trunking has a per-trunk Symmetric RTP setting. When enabled, Twilio latches onto the incoming RTP stream and sends RTP back to where it came from, not to the SDP-negotiated address. Twilio offers this for customers behind a non-SIP-aware NAT whose SDP carries a private IP. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Media Settings > Symmetric RTP. Checked 2026-09-24.
[^45]: Twilio says that with Symmetric RTP disabled it sends RTP to the destination negotiated in the SDP, and that this setting is considered more secure and is therefore recommended. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Media Settings > Symmetric RTP. Checked 2026-09-24.
[^46]: On Twilio origination calls, Twilio's page gives the symptom of no audio followed by the call dropping after 20 or 30 seconds. The cause it names is the customer's SIP infrastructure rewriting IP addresses in the Via headers of its response to Twilio's INVITE. Source: [Troubleshooting your Trunk](https://www.twilio.com/docs/sip-trunking/troubleshooting), Heading: On Origination calls (from PSTN to your PBX): there is no audio and the call drops after 20 or 30 seconds. Checked 2026-09-24.
[^47]: When the gateway gets no answer supervision from the telco or switch, the guide's fix is voice rtp send-recv. It makes a Cisco IOS gateway open two-way audio as soon as the RTP channel opens, without waiting for Connect. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > answer supervision subsection, recommended action. Checked 2026-09-24.
[^48]: For a softphone on VPN, the guide attributes one-way audio to the softphone choosing the wrong network adapter address. The fix is to set the VPN IP address in the softphone's Network Audio Settings. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Device Issues > Voice Quality > One-Way Audio or No Audio > VPN softphone subsection. Checked 2026-09-24.
[^49]: Webex Calling troubleshooting classifies media paths as on-net optimized (direct via ICE), on-net unoptimized (through the Webex cloud when ICE fails), on-net cloud hosted, off-net via Cloud Connected PSTN provider, and off-net via Local Gateway. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Troubleshoot Webex Calling calls, media path section. Checked 2026-09-24.
[^50]: The Webex Calling troubleshooting article says media quality metrics and network-side originating and terminating flows are not available for analog phones or IPv6 endpoints. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Troubleshoot Webex Calling calls, limitations note. Checked 2026-09-24.
[^51]: The Webex Calling call troubleshooting view in Control Hub flags calls with no media and gives causes such as Webex not receiving media from the sender, from the receiver, or from the Local Gateway. It also shows which party is liable. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Troubleshoot Webex Calling calls, no-media section of the call details. Checked 2026-09-24.
[^52]: Cisco states that a Cisco IOS gateway does not cut through the audio path in the forward direction until it receives a Connect message from the remote end, that failure to receive answer supervision from the telco or switch therefore causes one-way voice, and that the voice rtp send-recv command establishes a two-way path as soon as the RTP channel opens. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Check that Answer Supervision Is Being Sent and Received Correctly, and Cut-through Two-Way Audio Early. Checked 2026-09-16.
[^53]: Cisco frames one-way audio as a call established from an IP station through a Cisco IOS voice gateway or as a toll-bypass call between 2 Cisco gateways in which only one party receives audio, and names an improperly configured Cisco IOS gateway, a firewall, and a routing or default gateway problem as possible causes. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), One-Way Audio or No Audio, Symptom and Possible Cause. Checked 2026-09-16.
[^54]: Cisco's canonical one-way audio guidance sits in the Unified Communications Manager 12.5(1) troubleshooting guide last updated 24 November 2023, and its remedies are written for H.323 signalling and Cisco IOS gateway commands (field report). Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), document header date against the release the guide covers. Checked 2026-09-16.
[^55]: 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.
[^56]: 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.
[^57]: Cisco states that some Cisco IOS gateways such as the VG200 have IP routing disabled by default, that this leads to one-way voice problems, and directs the administrator to check for the global configuration command no ip routing before going any further. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Make Sure IP Routing is Enabled on Cisco IOS Gateway slash Routers. Checked 2026-09-16.
[^58]: Cisco states that one-way audio, a conversation between 2 people where only one person can hear anything, does not actually represent a voice-quality issue, while covering it in the voice quality section of the troubleshooting guide. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Voice Quality introduction. Checked 2026-09-16.
[^59]: Where a Cisco IOS gateway has multiple active IP interfaces, parts of the H.323 signalling may reference different source addresses and Cisco names one-way audio among the resulting problems, with the remedy being to bind the signalling to a specific physical or loopback source address, and Cisco records a bug in IOS version 12.2(6) in which that remedy itself causes a one-way audio problem. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), Bind the H.323 Signaling to a Specific IP Address on Cisco IOS Gateway slash Routers. Checked 2026-09-16.
[^60]: Cisco states that because RTP streams have no connections and are transported over UDP, traffic may travel successfully in one direction but get lost in the opposite direction, which is the mechanism that makes one-way audio possible at all. Source: [Troubleshooting Guide for Cisco Unified Communications Manager Release 12.5(1) — Device Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_0100.html), One-Way Audio or No Audio, Check Basic IP Routing. Checked 2026-09-16.