Cellular failover for voice at branch sites

See also

Sources

1. 1
   If a branch router's cellular backup keeps Webex Calling endpoints reachable to the cloud, the survivability trigger (loss of connection to Webex) is not met, so calls stay on the cloud over cellular rather than moving to the local Survivability Gateway and PSTN.inferred

   Site survivability for Webex Calling · Overview (Active and Survivability modes) · Checked 2026-10-14
2. 2
   RFC 6598 notes that a CPE outside address that is not special-use is still not always reachable from the Internet, for example when that address sits behind a CGN.

   RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space · Section 5.1 · Checked 2026-10-14
3. 3
   RFC 6888 states that subscribers have limited or no control over the CGN and that some applications may not function at all behind CGNs.

   RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) · Section 1 and Section 2 · Checked 2026-10-14
4. 4
   RFC 6888 REQ-1 requires a carrier-grade NAT that forwards a transport protocol to meet that protocol's behavioural requirements, which for UDP are those of RFC 4787.

   RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) · Section 3, REQ-1 · Checked 2026-10-14
5. 5
   RFC 6598 reserves the IPv4 block 100.64.0.0/10 as Shared Address Space.

   RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space · Section 7 (IANA Considerations); Abstract · Checked 2026-10-14
6. 6
   RFC 6598 Shared Address Space is intended to number the interfaces that connect carrier-grade NAT devices to customer premises equipment.

   RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space · Section 1 (Introduction) · Checked 2026-10-14
7. 7
   Like RFC 1918 space, RFC 6598 Shared Address Space is not globally routable.

   RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space · Section 1 (Introduction) · Checked 2026-10-14
8. 8
   RFC 6888 REQ-9 requires a CGN to implement a protocol giving subscribers explicit control over NAT mappings, with PCP (RFC 6887) the preferred protocol.

   RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) · Section 3, REQ-9 · Checked 2026-10-14
9. 9
   On Cisco IOS XE SD-Routing 17.16.x cellular profiles the APN is optional, and if none is specified the cellular module picks the APN based on the SIM card's operator.

   Cellular Interfaces for SD-Routing Devices, Release 17.16.x · Configure Cellular Profile section · Checked 2026-10-14
10. 10
    Cisco IOS XE SD-Routing 17.16.x cellular profiles let the packet data network type be set to IPv4, IPv6 or IPv4v6.

    Cellular Interfaces for SD-Routing Devices, Release 17.16.x · Configure Cellular Profile section · Checked 2026-10-14
11. 11
    In Cisco IOS XE SD-Routing 17.16.x, tracker objects can be configured on the cellular interface but do not track the cellular interface's status.

    Cellular Interfaces for SD-Routing Devices, Release 17.16.x · Limitations section · Checked 2026-10-14
12. 12
    Datto's knowledge base states that multiple NAT layers, or an ALG at the LTE carrier or ISP level (CG-NAT), can cause timeouts or loss of return-path connectivity for clients with long-lived sessions such as SIP after failover.

    SIP Registration Failures on Failover · Cause section · Checked 2026-10-14
13. 13
    Datto's failover guidance also says to turn SIP keep-alive on, turn SIP Outbound on, and set NAT traversal to either, Auto or ICE on the phones.

    SIP Registration Failures on Failover · Resolution list, items 4-6 · Checked 2026-10-14
14. 14
    Datto states that SIP ALG is not implemented on the Datto Networking Appliance.

    SIP Registration Failures on Failover · Cause section · Checked 2026-10-14
15. 15
    Datto recommends a SIP registration timer of at least 600 seconds for endpoints behind a Datto Networking Appliance that fails over.

    SIP Registration Failures on Failover · Resolution list, item 3 · Checked 2026-10-14
16. 16
    For SIP registration failures on failover, Datto recommends moving SIP to an alternate port (5061 or 5062) and setting SIP transport to TCP.

    SIP Registration Failures on Failover · Resolution list, items 1-2 · Checked 2026-10-14
17. 17
    Behind a mobile carrier's CGN, inbound calls to a registered SIP endpoint can only arrive over the endpoint's own outbound flow, so they fail once that flow's carrier NAT mapping expires between keep-alives or registration refreshes.inferred

    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Abstract and Section 1, read with RFC 4787 Section 4.3 and RFC 6888 Section 2 · Checked 2026-10-14
18. 18
    A SIP trunk that the provider routes or authenticates by the branch's fixed public IP cannot receive inbound calls after failover to a cellular link whose address differs and sits behind carrier NAT, unless the carrier supplies a reachable static public IP.inferred

    RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space · Section 1 and Section 5.1, read with RFC 6888 Section 2 · Checked 2026-10-14
19. 19
    Under Meraki Graceful failback, a SIP endpoint or trunk that refreshes registration or keep-alives more often than every 300 seconds keeps its flow mapping alive, so its signalling can stay on the cellular uplink after the primary WAN has recovered.inferred

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Failback section (Graceful) and existing-flows paragraph · Checked 2026-10-14
20. 20
    In the Meraki dashboard a cellular uplink shows Ready when it has exchanged data with the dashboard and can take failover, and Active when failover has occurred and it is carrying the Internet connection.

    How to Configure MX and Z-Series Uplink Settings - Cisco Meraki Documentation · Cellular interface states section · Checked 2026-10-14
21. 21
    To limit data use, a Meraki cellular uplink acting as backup runs its ICMP, DNS and HTTP connection-monitoring tests only every 4 hours, plus periodic ARP.

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Cellular uplinks section · Checked 2026-10-14
22. 22
    Meraki documentation identifies the MX67C and MX68CW as the MX models with an embedded LTE module for cellular failover.

    How to Configure MX and Z-Series Uplink Settings - Cisco Meraki Documentation · Cellular failover section · Checked 2026-10-14
23. 23
    When the preferred uplink recovers, a Meraki MX waits about 15 seconds before switching back to it, to avoid flapping.

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Failback section · Checked 2026-10-14
24. 24
    A Meraki MX maps flows to an uplink by source and destination IP and port, each mapping expires after 300 seconds without matching traffic, and Meraki support cannot clear these mappings.

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Existing flows paragraph under Failback · Checked 2026-10-14
25. 25
    On MX 17 and later the default Graceful failback sends new flows over the recovered primary uplink while existing flows stay on the backup uplink until they expire.

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Failback section (Graceful) · Checked 2026-10-14
26. 26
    The MX 17+ Immediate failback option moves existing and new flows to the primary uplink at once, which disrupts the existing flows.

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Failback section (Immediate) · Checked 2026-10-14
27. 27
    A Meraki MX fails over immediately when the primary uplink's physical link goes down.

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Failover timing section · Checked 2026-10-14
28. 28
    When a Meraki MX uplink stays physically up but loses Internet reachability, the MX fails it over only after more than 300 seconds without a successful connection-monitoring test, about five minutes.

    Connection Monitoring for WAN Failover - Cisco Meraki Documentation · Failover timing section (soft failure) · Checked 2026-10-14
29. 29
    RFC 4787 REQ-1 requires a NAT to have Endpoint-Independent Mapping behaviour.

    RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (BCP 127) · Section 4.1, REQ-1 · Checked 2026-10-14
30. 30
    RFC 4787 REQ-6 requires that outbound packets refresh a NAT UDP mapping, which is what lets an inside client keep a mapping alive; inbound refresh is optional.

    RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (BCP 127) · Section 4.3, REQ-6 · Checked 2026-10-14
31. 31
    RFC 4787 REQ-5c recommends a default NAT UDP mapping timer of five minutes or more.

    RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (BCP 127) · Section 4.3, REQ-5c · Checked 2026-10-14
32. 32
    RFC 4787 REQ-5 says a NAT UDP mapping timer must not expire in less than two minutes, unless the well-known-port exception (REQ-5a) applies.

    RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (BCP 127) · Section 4.3, REQ-5 (repeated in Section 12) · Checked 2026-10-14
33. 33
    RFC 4787 REQ-5a allows a NAT to use shorter UDP mapping timers for specific destination ports in the well-known range 0-1023.

    RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (BCP 127) · Section 4.3, REQ-5a · Checked 2026-10-14
34. 34
    SIP and RTP from a branch router on an ordinary data APN normally ride the best-effort default bearer (typically QCI 9, 300 ms delay budget), not the QCI 1 voice bearer that carrier VoLTE uses, so the radio network gives branch voice no voice-specific priority.inferred

    3GPP TS 23.203 clause 6.1.7.2 Standardized QCI characteristics (iTecSpec mirror) · Clause 6.1.7.2, Table 6.1.7-A rows QCI 1 and QCI 9; NOTE 6 · Checked 2026-10-14
35. 35
    In 3GPP TS 23.203, QCI 1 is a GBR class at priority 2 with a 100 ms packet delay budget and 10^-2 packet error loss rate, with conversational voice as the example service.

    3GPP TS 23.203 clause 6.1.7.2 Standardized QCI characteristics (iTecSpec mirror) · Clause 6.1.7.2, Table 6.1.7-A, QCI 1 row · Checked 2026-10-14
36. 36
    In 3GPP TS 23.203, QCI 9 is a non-GBR class at priority 9 with a 300 ms packet delay budget, and NOTE 6 says it is typically used for the default bearer of non-privileged subscribers.

    3GPP TS 23.203 clause 6.1.7.2 Standardized QCI characteristics (iTecSpec mirror) · Clause 6.1.7.2, Table 6.1.7-A, QCI 9 row and NOTE 6 · Checked 2026-10-14
37. 37
    RFC 5626 flow-recovery backoff is W = min(max-time, base-time x 2^failures), with base-time 30 s if all flows failed or 90 s if one still works, max-time 1800 s, and the actual wait drawn between 50% and 100% of W.

    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.5 · Checked 2026-10-14
38. 38
    Under RFC 5626, a UA on a TCP or TLS flow treats the flow as failed if no CRLF pong arrives within 10 seconds of its double-CRLF ping.

    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.4.1 · Checked 2026-10-14
39. 39
    SIP Outbound (RFC 5626) lets a UA behind a NAT or firewall open a flow to its registrar or edge proxy and have the network deliver incoming requests back over that same UA-initiated flow.

    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Abstract; Section 1 · Checked 2026-10-14
40. 40
    When an RFC 5626 flow fails, the UA forms a new flow and re-registers over it with the same reg-id, replacing the bindings of the failed flow.

    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.5 · Checked 2026-10-14
41. 41
    For TCP or TLS flows with no server Flow-Timer, RFC 5626 has the UA send CRLF keep-alives at a random interval of 95 to 120 seconds, or 672 to 840 seconds when battery use matters.

    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.4.1 · Checked 2026-10-14
42. 42
    For UDP flows with no server Flow-Timer, RFC 5626 has the UA send STUN keep-alives at a random interval of 24 to 29 seconds.

    RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) · Section 4.4.2 · Checked 2026-10-14
43. 43
    Teams makes location requests based on Ethernet switch (PortID or ChassisID) and wireless access point (BSSID) regardless of whether the external IP address matches a trusted IP address.

    Configure dynamic emergency calling · Configure network settings section, Note after trusted IP paragraph · Checked 2026-10-14
44. 44
    When a branch fails over to cellular, its Teams clients egress from a carrier address that is normally not in the trusted IP list, so subnet-based emergency locations and network-site policies stop resolving while BSSID and LLDP lookups still run.inferred

    Configure dynamic emergency calling · Configure network settings section, trusted IP paragraph and following Note · Checked 2026-10-14
45. 45
    Teams LIS location matching uses the first match in the order WAP, Ethernet switch/port, Ethernet switch, then subnet.

    Configure dynamic emergency calling · Plan for emergency calling section, step 2 sub-list · Checked 2026-10-14
46. 46
    The Teams client sends a location request with its network connectivity information at startup, periodically after that, and when a network connection changes.

    Configure dynamic emergency calling · Plan for emergency calling section, step 2 · Checked 2026-10-14
47. 47
    Microsoft says some Teams network settings changes, such as a new address or network identifier, can take up to four hours to reach Teams clients.

    Configure dynamic emergency calling · Configure network settings section, propagation sentence · Checked 2026-10-14
48. 48
    Teams attempts to get a dynamic emergency policy or location based on the endpoint's IP address only if the user's external IP address matches an address in the tenant's trusted IP addresses.

    Configure dynamic emergency calling · Configure network settings section, trusted IP addresses paragraph · Checked 2026-10-14
49. 49
    Cisco recommends switching off SIP ALG on firewalls and NAT devices in the path of Webex Calling traffic.

    Port Reference Information for Webex Calling · SIP Application Layer Gateway section · Checked 2026-10-14
50. 50
    Cisco states that TCP and TLS as media transports are not supported for Webex Calling in production and recommends SRTP over UDP.

    Port Reference Information for Webex Calling · Webex Calling traffic through proxies and firewalls section · Checked 2026-10-14
51. 51
    Cisco states that when NAT is deployed for Webex Calling, opening an inbound port on the firewall is not mandatory.

    Port Reference Information for Webex Calling · Network Address Translation (NAT) section · Checked 2026-10-14
52. 52
    Cisco states that its phones send a REGISTER refresh every 1 to 2 minutes and asks that NAT devices keep bindings at least long enough for devices to operate properly.

    Port Reference Information for Webex Calling · Network Address Translation (NAT) section · Checked 2026-10-14
53. 53
    In Webex Calling Survivability mode, inbound and outbound external calls and emergency calls need a local PSTN circuit or SIP trunk on the Survivability Gateway.

    Site survivability for Webex Calling · Supported call types table · Checked 2026-10-14
54. 54
    Cisco notes that during a site outage, Webex mobile clients on 4G or 5G may stay registered to Webex and be unable to reach other numbers at the same site.

    Site survivability for Webex Calling · Limitations section · Checked 2026-10-14
55. 55
    Webex Calling endpoints return registration and call control to the cloud once the Webex connection has been restored for at least 30 seconds.

    Site survivability for Webex Calling · Survivability mode behaviour, return to Active mode · Checked 2026-10-14
56. 56
    Webex Calling endpoints switch to Survivability mode automatically when their network connection to Webex is lost.

    Site survivability for Webex Calling · Overview (Active and Survivability modes) · Checked 2026-10-14

Documents

Cite this page

WarmTransfer. (2026, October 14). Cellular failover for voice at branch sites. WarmTransfer. https://warmtransfer.net/knowledge/lte-5g-voice-failover

@misc{warmtransfer-lte-5g-voice-failover,
  title  = {Cellular failover for voice at branch sites},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/lte-5g-voice-failover},
  note   = {Verified 2026-10-14}
}