Attach the NAT policy to the exact client and account
Record the exact Linphone application or Liblinphone build, operating system, account, network interface, address family and call direction. A Liblinphone NatPolicy is an application or account control boundary; it is not proof that every distributed Linphone client exposes the same screen, applies the same default or received the same provisioning. Preserve the configured object, its owner and its effective runtime state separately.
Registration, SIP signaling transport and media traversal solve different problems. A successful REGISTER does not prove that the offer contained usable ICE candidates, that connectivity checks succeeded or that RTP followed the selected pair. Likewise, a reachable STUN or TURN service does not authorize a call or repair a dialplan.
Keep ICE, STUN, TURN and UPnP as distinct controls
Liblinphone documents separate switches for ICE, STUN, TURN and UPnP. Its 5.5 reference says ICE can run without STUN or TURN, in which case it uses local candidates. It also says TURN takes precedence when STUN and TURN are both enabled, while enabling UPnP disables the other NAT policies. Do not treat the four labels as interchangeable ways to enable the same feature.
ICE coordinates candidate gathering and connectivity checks. STUN can provide a server-reflexive address and support checks; it is not a media relay. TURN can allocate a relayed address when a direct path is unavailable. UPnP changes a local gateway mapping and creates a separate administrative and security boundary. Select one supported topology from observed constraints rather than stacking every mechanism.
Bind server, credentials and TURN transport together
The NatPolicy holds the STUN or TURN server, an optional username used to find authentication material, and TURN transport choices. Preserve the configured hostname, resolved addresses, port, address family, username lookup, credential owner, allocation response and lifetime. A DNS answer or successful STUN binding is not a TURN allocation, and a TURN allocation is not proof that ICE selected the relay.
The current Liblinphone API warns that enabling more than one of UDP, TCP and TLS TURN transport at a time is not supported. Choose the provider-supported transport explicitly and verify its certificate and trust boundary when TLS is used. Never substitute an arbitrary public server or reuse SIP credentials unless the service owner documents that authentication model.
Follow candidates through offer-answer and connectivity checks
RFC 8445 distinguishes host, server-reflexive and relayed candidates. RFC 8839 carries ICE information through SDP offer-answer. Preserve candidate type, component, transport, priority, foundation, address family, generation, ICE username fragment and password, then show that the complete candidate set reached the peer. A candidate listed in local diagnostics is only a possibility until the remote agent receives it and a pair succeeds.
Follow the checklist state and nominated or selected pair rather than assuming the first SDP address is active. Compare the selected local and remote candidate types with actual packet source and destination. Protect private addresses and ICE credentials in shared evidence; retain only the minimum sanitized values needed to correlate the call.
Treat relay fallback and protected media as separate results
RFC 8656 defines TURN as a relay and describes its cost, allocation and permission boundaries. ICE normally searches for a direct path and can select a relayed candidate when direct checks fail. A relay candidate that exists but is never selected does not carry the media, while a selected relay still needs increasing packet counters in both directions.
TURN forwarding does not by itself terminate or prove the media-protection scheme. Keep the ICE path, DTLS or SRTP keying, protected packet flow, decoding and audible conversation as distinct observations. A confirmed SIP dialog, selected pair or encrypted packet is narrower than working two-way audio.
Retest the path after network and session changes
Repeat acceptance on each required Wi-Fi, mobile, VPN and restrictive-network class without changing several variables at once. Capture candidate gathering, selected pair, media counters and audible result after application restart, device sleep or wake, network handover, hold, resume and transfer when those workflows matter. A working office call does not establish hotel, mobile or enterprise-firewall behavior.
Change only the demonstrated owner: policy, DNS, server reachability, credential, TURN transport, candidate delivery, peer interoperability, firewall rule or media-security stage. Preserve rollback and a direct-versus-relay control. This guide is documentation-derived; no Linphone client, account, network, NAT, STUN or TURN service, candidate pair, packet path or call was tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Liblinphone latest NatPolicy API ↗
- Liblinphone 5.5 network parameters ↗
- Linphone ICE feature guide ↗
- RFC 8445: Interactive Connectivity Establishment ↗
- RFC 8489: Session Traversal Utilities for NAT ↗
- RFC 8656: Traversal Using Relays around NAT ↗
- RFC 8839: SDP offer-answer procedures for ICE ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.