VoIP.infoThe independent guide to business communications.
VoIP.info Diagnostic

Linphone ICE fails or a TURN relay is not selected

Trace one Linphone media failure from effective NatPolicy through server resolution, candidate gathering, SDP exchange, ICE checks, selected pair and RTP before changing the account.

Reviewed 2026-10-14Current Liblinphone NatPolicy API, Liblinphone 5.5 network-parameter reference and Linphone ICE feature documentation reviewed October 14, 2026 with RFC 8445, RFC 8489, RFC 8656 and RFC 8839; library capabilities do not prove that one distributed Linphone application exposes the same controls, that an account or peer accepts ICE, that a server resolves or authenticates, that a relay was allocated or selected, or that media was delivered, and no application, SDK build, account, device, network, NAT, firewall, STUN or TURN service, DNS result, credential, candidate, SDP body, connectivity check, relay allocation, packet, media stream or call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one call, one client and one network

Record the exact Linphone or Liblinphone build, operating system, account, peer, call direction, timestamp, interface, address family and network class. Classify the first observed symptom: no candidates, only host candidates, no relay candidate, a failed TURN allocation, candidates missing from peer SDP, all pairs failed, a direct pair selected but silent, a relay pair selected but silent, or media lost after a network or session change.

Do not collapse those states into “NAT problem.” Registration, server discovery, STUN binding, TURN authentication, allocation, candidate signaling, ICE checks, selected pair, packet flow and audible media have different owners. Preserve the failed state before clearing configuration, reinstalling the client or swapping public services.

Read the effective NatPolicy before testing servers

Confirm whether ICE, STUN, TURN or UPnP is effectively enabled for the affected account and runtime. Liblinphone permits ICE with local candidates only, gives TURN precedence over STUN when both are enabled and documents UPnP as disabling the other policies. A remembered screen value or provisioning file is not proof that the running account uses the same object.

Record the server, username lookup, TURN transport, any fixed NAT address and the configuration owner. If several accounts exist, prove which policy the call uses. Do not enable every mechanism as a diagnostic shortcut; that changes candidate generation, credentials and gateway state at once.

Prove discovery, authentication and allocation in order

Resolve the configured hostname from the affected network and preserve the returned address family and time. For STUN, distinguish a DNS result from a successful binding response. For TURN, retain the selected UDP, TCP or TLS transport, certificate result when applicable, authentication challenge, authorized credential lookup, allocation response and lifetime.

A successful STUN binding proves only that traffic exchanged with that server and an observed mapped address was returned. It does not prove peer reachability. A TURN credential error is not an ICE checklist failure, while a valid allocation that never becomes a candidate or selected pair is not a media result.

Compare gathered candidates with both SDP bodies

Capture sanitized local diagnostics plus the exact offer and answer for the failed session. Confirm which host, server-reflexive and relayed candidates were gathered, whether the complete set reached the peer and whether ICE credentials and media components align. RFC 8839 keeps candidate signaling and offer-answer procedures explicit; an application can gather a candidate that an intermediary or peer never receives.

Do not publish private addresses, ICE passwords or TURN credentials. Use bounded identifiers, candidate types, foundations, priorities, transport and address family to correlate the transaction. If the peer does not support the selected ICE behavior, record that interoperability boundary rather than forcing a general compatibility claim.

Follow checks to the selected pair and actual RTP path

Inspect checklist progression, pair state, nomination and the final selected local and remote candidates. Then compare them with packet source and destination, bidirectional byte counters, media-protection state and decoded audio. A relayed candidate in SDP is not evidence that TURN carried the call; a selected direct pair is not evidence that both directions passed the firewall.

If ICE succeeds but protected media or decoding fails, continue at the DTLS, SRTP, codec or audio-device boundary instead of rotating the STUN server. If the pair changes after hold, transfer or network handover, treat the new path as a new evidence interval.

Correct one owner and repeat direct and relay controls

Correct only the demonstrated failure: policy assignment, DNS, server reachability, credential, TURN transport, allocation, candidate delivery, peer handling, firewall rule, security negotiation or audio rendering. Keep the previous configuration and repeat the original network, a known-good network and an authorized relay-required control where practical.

Acceptance requires the expected candidate types, successful checks, intended selected path, increasing bidirectional media counters and an audible two-way result. Repeat after restart and the original network or session transition. No client, account, network, server, credential, candidate, SDP exchange, packet, relay path or call was inspected or tested for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →
Networking guide · Current Liblinphone NatPolicy API, Liblinphone 5.5 network-parameter reference and Linphone ICE feature documentation reviewed October 14, 2026 with RFC 8445, RFC 8489, RFC 8656 and RFC 8839; library capabilities do not prove that one distributed Linphone application exposes the same controls, that an account or peer accepts ICE, that a server resolves or authenticates, that a relay was allocated or selected, or that media was delivered, and no application, SDK build, account, device, network, NAT, firewall, STUN or TURN service, DNS result, credential, candidate, SDP body, connectivity check, relay allocation, packet, media stream or call was inspected or tested

Linphone NAT traversal: ICE, STUN and TURN policy

Keep Linphone NAT policy, candidate gathering, TURN allocation, ICE checks, selected media path and audible result separately observable.

Read guide →
Client research · Current Linphone product, download, 6.2 release, stable desktop archives, third-party account, provisioning, push and security documentation rechecked October 7, 2026; the Windows, macOS and GNU/Linux stable archives all remained at desktop 6.2.3 dated September 22, 2026; no app, build, provisioning service, SIP account, Flexisip service, PBX, push, protected-media, message or call test

Linphone softphone: platform, provisioning and third-party SIP limits

Research the installable desktop and mobile clients, remote configuration and documented push boundary.

Read guide →
Guide · WebRTC standards; browser and server behavior must be checked by version

ICE: candidate gathering, checks and the selected path

Understand how WebRTC finds a usable media route and what an ICE failure actually narrows down.

Read guide →
Guide · WebRTC standards; browser and server behavior must be checked by version

STUN: discovering an address is not relaying a call

Use STUN observations correctly when troubleshooting NAT and WebRTC connectivity.

Read guide →
Guide · WebRTC standards; browser and server behavior must be checked by version

TURN relays: reliability, credentials and capacity

Plan a media fallback that works on restrictive networks and does not become an open relay.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

VoIP call connects but has no audio

Separate endpoint audio selection from a media path that fails in both directions.

Read guide →
Troubleshooting · RFC 3264 offer/answer behavior, current Asterisk res_pjsip media controls and Wireshark RTP analysis documentation reviewed October 5, 2026; no PBX, endpoint, trunk, firewall, packet stream, media transition or call tested

Intermittent one-way audio after hold, transfer or idle time

Compare the exact working and failing call phase, SDP direction and RTP path across hold, resume, transfer or idle time before changing NAT, direct-media or timeout controls.

Read guide →
Diagnostic · RFC 5626 SIP Outbound, RFC 6314 NAT traversal, current Android connectivity guidance and Apple NWPathMonitor reference reviewed October 7, 2026; no device, application, operating-system callback, Wi-Fi or mobile network, VPN, DNS response, NAT mapping, SIP flow, keepalive, registration, push service, PBX, provider, media path, availability, battery result or call was inspected or tested

Softphone loses registration after Wi-Fi or mobile-network change

Trace the old network path, SIP flow, keepalive, detected failure, replacement flow, REGISTER result and inbound route after a device changes connectivity.

Read guide →