IPv6 for voice and UC platforms

See also

Sources

1. 1
   Microsoft states that Microsoft 365 services can be used from dual-stack and IPv6-only devices, but IPv6-only devices need translation such as DNS64/NAT64, and recommends deploying DNS64/NAT64 for IPv6-only networks.

   IPv6 support in Microsoft 365 services · Paragraphs 1 and 4 · Checked 2026-10-02
2. 2
   Microsoft states it is not planning to require IPv6 or to deprioritize IPv4 in any Microsoft 365 feature or service.

   IPv6 support in Microsoft 365 services · Paragraph 1 · Checked 2026-10-02
3. 3
   Because NAT64 rewrites only IP and transport headers, IPv4 address literals inside SIP headers and SDP c= lines cross a NAT64 untranslated. Without ICE, media latching or an SBC/ALG, an IPv6-only phone behind NAT64 is likely to get one-way or no audio with an IPv4-only SIP peer.inferred

   RFC 6889: Analysis of Stateful 64 Translation · Section 2.2, item 1 (combined with RFC 6146 scope) · Checked 2026-10-02
4. 4
   RFC 4091, which defined the ANAT (Alternative Network Address Types) semantics for SDP grouping in June 2005, is obsoleted by RFC 5245 (ICE).

   RFC 4091 info page: The Alternative Network Address Types (ANAT) Semantics for the SDP Grouping Framework · Info page fields: Status, Obsoleted by · Checked 2026-10-02
5. 5
   RFC 4092 (use of ANAT in SIP) is obsoleted by RFC 5245.

   RFC 4092 info page: Usage of the SDP ANAT Semantics in SIP · Info page field: Obsoleted by · Checked 2026-10-02
6. 6
   RFC 4092 defines the SIP option-tag sdp-anat and says a SIP entity generating an offer that uses ANAT semantics SHOULD put sdp-anat in a Require header field.

   RFC 4092 info page: Usage of the SDP ANAT Semantics in SIP · Info page abstract · Checked 2026-10-02
7. 7
   RFC 5245 states that ICE deprecates RFC 4091 and RFC 4092 (ANAT) and explains the relationship in a dedicated section.

   RFC 5245: Interactive Connectivity Establishment (ICE) · Header (Obsoletes: 4091, 4092); Section 13 Relationship with ANAT · Checked 2026-10-02
8. 8
   RFC 5954 (August 2010) updates RFC 3261 by replacing SIP's flawed IPv6 address ABNF with the RFC 3986 grammar, which removes the extra-colon bug that allowed forms such as [2001:db8:::192.0.2.1].

   RFC 5954: Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 · Sections 3.1 and 4.1 · Checked 2026-10-02
9. 9
   Per RFC 5954, two SIP URIs whose host parts are different text forms of the same IPv6 address match, because the comparison uses the binary address rather than the text.

   RFC 5954: Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 · Section 4.2 · Checked 2026-10-02
10. 10
    RFC 6146 (Standards Track, April 2011) specifies stateful NAT64 translation for unicast UDP, TCP and ICMP between IPv6 clients and IPv4 servers. It works at the network and transport layers.

    RFC 6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers · Abstract and Section 1 · Checked 2026-10-02
11. 11
    Under RFC 6157 each media description in an SDP answer must use the same network/address type as the matching media description in the offer, so an IP4 offer line cannot be answered with IP6 or the reverse.

    RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP) · Section 4.1 · Checked 2026-10-02
12. 12
    RFC 6157 says dual-stack (IPv4/IPv6) SIP user agents SHOULD use ICE procedures to gather both IPv4 and IPv6 addresses for every offer they generate, so that IPv4-only and IPv6-only answerers can both set up a session.

    RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP) · Section 4.2 · Checked 2026-10-02
13. 13
    RFC 6157 uses ICE, not ANAT, as its mechanism for IPv4/IPv6 media interworking and does not reference RFC 4091 or RFC 4092.

    RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP) · Sections 4.1 to 4.2 and References · Checked 2026-10-02
14. 14
    RFC 6157 requires a SIP proxy that relays requests between IPv4 and IPv6 networks to be configured to Record-Route so it stays in the signalling path for the dialog.

    RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP) · Section 3.1.1 · Checked 2026-10-02
15. 15
    RFC 6157 recommends that SIP user agents support the STUN relay usage (TURN) so that, for example, an IPv6-only agent can get an IPv4 relayed address for media.

    RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP) · Section 4.2 · Checked 2026-10-02
16. 16
    RFC 6157 (IPv6 Transition in SIP) is a Standards Track RFC published April 2011 that updates RFC 3264 (the SDP offer/answer model).

    RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP) · RFC header (Category, Updates, date) · Checked 2026-10-02
17. 17
    RFC 6889 identifies referrals as a NAT64 hazard: when a node on the IPv4 side passes the other endpoint's address to a node that cannot reach the NAT64, the referred connection fails.

    RFC 6889: Analysis of Stateful 64 Translation · Section 2.2, item 5 · Checked 2026-10-02
18. 18
    RFC 6889 (Informational, April 2013) concludes that stateful NAT64 creates no SIP-specific problem: the usual NAT traversal techniques (ICE, SIP keepalives, media latching, embedded SIP ALGs) apply when a NAT64 is in the path.

    RFC 6889: Analysis of Stateful 64 Translation · Section 2.2, item 1 · Checked 2026-10-02
19. 19
    RFC 8421 (BCP 217, July 2018) recommends that dual-stack ICE agents intermingle IPv4 and IPv6 candidates in the checklist rather than testing all of one family first, so a broken IPv6 or IPv4 path does not delay call setup.

    RFC 8421: Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) · Section 4 · Checked 2026-10-02
20. 20
    RFC 8445 excludes deprecated IPv4-compatible IPv6 addresses and IPv6 site-local unicast addresses from host candidates, and says IPv4-mapped IPv6 addresses SHOULD NOT be included unless the application does not support IPv4.

    RFC 8445 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal · Section 5.1.1.1 Host Candidates · Checked 2026-10-02
21. 21
    RFC 8445 says a dual-stack ICE agent SHOULD set candidate local preference according to the best practice in RFC 8421.

    RFC 8445 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal · Section 5.1.2.2 Guidelines for Choosing Type and Local Preferences · Checked 2026-10-02
22. 22
    RFC 8445 allows an IPv6-only ICE agent on a network with NAT64 and DNS64 to gather IPv4 server-reflexive or relayed candidates from IPv4-only STUN or TURN servers, and says it SHOULD use IPv6 prefix discovery to learn the NAT64 prefix.

    RFC 8445 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal · Section 5.1.1 (gathering candidates; NAT64 paragraph) · Checked 2026-10-02
23. 23
    RFC 8445 (July 2018) is the current ICE specification and obsoletes RFC 5245.

    RFC 8445 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal · RFC header (Obsoletes: 5245; date) · Checked 2026-10-02
24. 24
    SDP (RFC 8866) defines exactly two address types, IP4 and IP6, used in both the origin (o=) and connection (c=) lines with network type IN; an IPv6 media address therefore appears as c=IN IP6 followed by the address.

    SDP: Session Description Protocol · Sections 5.2 (Origin) and 5.7 (Connection Information) · Checked 2026-10-02
25. 25
    In SDP a TTL value must not be present on an IP6 multicast connection address, because IPv6 multicast does not use TTL scoping.

    SDP: Session Description Protocol · Section 5.7 · Checked 2026-10-02
26. 26
    The Direct Routing planning page documents IPv6 FQDNs and ranges only for Microsoft 365, Office 365 and GCC. GCC High and DoD are shown with IPv4 media ranges only, so IPv6 Direct Routing in those clouds appears undocumented.inferred

    Plan Direct Routing · Sections 'SIP signaling: GCC High', 'SIP signaling: DoD', 'Media processor IP ranges' · Checked 2026-10-02
27. 27
    A Direct Routing SBC's IP version is set with the IPAddressVersion option of New-CsOnlinePSTNGateway, whose values are IPv4 and IPv6. When it is IPv6, the SBC must use IPv6 for both signalling and media.

    What's New Direct Routing · Section 'IPv6 with non media bypass is now supported for Teams Phone', IPAddressVersion paragraph · Checked 2026-10-02
28. 28
    A Direct Routing SBC using IPv6 connects to sip.ipv6.pstnhub.microsoft.com (primary), sip2.ipv6.pstnhub.microsoft.com (secondary) and sip3.ipv6.pstnhub.microsoft.com (tertiary), not to the IPv4 sip/sip2/sip3.pstnhub.microsoft.com names.

    Plan Direct Routing · Section 'SIP signaling: FQDNs', table 'FQDNs in case SBC uses IPv6' · Checked 2026-10-02
29. 29
    For IPv6 Direct Routing media, Microsoft says to allow 2603:1063:400::/40 and 2603:1063:100::/40. Media ports are the same as for IPv4: UDP 3478-3481 and 49152-53247 in both directions.

    Plan Direct Routing · Sections 'Media processor IP ranges' (Microsoft 365 / Office 365) and 'Media ports' · Checked 2026-10-02
30. 30
    Teams Phone Direct Routing does not support media bypass when IPv6 is used for SIP or media, or when the Teams client is on IPv6. IPv6 is supported only for non-media-bypass scenarios.

    What's New Direct Routing · Section 'IPv6 with non media bypass is now supported for Teams Phone', Not supported list and closing sentence · Checked 2026-10-02
31. 31
    Teams Phone Direct Routing supports IPv6-only calls without media bypass, where the SBC uses IPv6 for both SIP signalling and media, alongside existing all-IPv4 calls.

    What's New Direct Routing · Section 'IPv6 with non media bypass is now supported for Teams Phone', Supported list · Checked 2026-10-02
32. 32
    The Direct Routing IPv6 signalling FQDNs resolve to the Microsoft range 2603:1063:400::/40. SIP/TLS from the SBC goes to port 5061, as it does over IPv4.

    Plan Direct Routing · Sections 'SIP signaling: FQDNs' (IPv6 range) and 'SIP signaling ports' · Checked 2026-10-02
33. 33
    Teams Phone Direct Routing does not support mixed-mode trunks where SIP and media use different IP versions, for example IPv6 signalling with IPv4 media.

    What's New Direct Routing · Section 'IPv6 with non media bypass is now supported for Teams Phone', Not supported list · Checked 2026-10-02
34. 34
    Teams Location-Based Routing supports both IPv4 and IPv6 subnets, and an IPv6 match takes precedence when the client's subnet is checked.

    Plan Location-Based Routing for Direct Routing · Section 'Technical considerations for Location-Based Routing' · Checked 2026-10-02
35. 35
    In a January 2023 Microsoft Q&A thread, a moderator relayed an engineering statement that Teams did not then support native IPv6 and that the feature was on the backlog with no ETA.field report

    Is Microsoft Teams and Graph Call Records API support native ipv6? - Microsoft Q&A · Accepted answer dated 2023-01-25 · Checked 2026-10-02
36. 36
    For Teams cloud voice network settings (Location-Based Routing, dynamic emergency calling), an enterprise with both IPv4 and IPv6 internet-facing external addresses must add both as trusted IP addresses, because the match depends on which IP version the client's packet uses.

    Network settings for cloud voice features · Section 'Trusted IP address' · Checked 2026-10-02
37. 37
    Cisco's Webex IPv6-only (DNS64/NAT64) guidance is explicitly scoped to Webex Suite Meetings, and the Webex Calling port reference does not mention IPv6. Current Cisco documentation does not establish IPv6-only or NAT64 support for Webex Calling registration or media.inferred

    Administration guide for Webex Suite Meetings Platform: IPv6 support using customer-provided DNS64 and NAT64 · Article scope statement (overview) · Checked 2026-10-02
38. 38
    For Webex Suite Meetings on IPv6-only networks, the Webex App needs version 43.9 or later on desktop (Windows, macOS, Linux) and mobile (Android, iOS), and RoomOS devices need 11.11.1.9 or later.

    Administration guide for Webex Suite Meetings Platform: IPv6 support using customer-provided DNS64 and NAT64 · Supported clients and devices section · Checked 2026-10-02
39. 39
    Webex Suite Meetings supports Webex App and RoomOS devices on IPv6-only subnets through customer-provided DNS64 and NAT64. Clients detect IPv6-only subnets via DHCPv6, and NAT64 translates to IPv4 for backend communication.

    Administration guide for Webex Suite Meetings Platform: IPv6 support using customer-provided DNS64 and NAT64 · Article overview and requirements sections · Checked 2026-10-02
40. 40
    The Webex Calling Survivability Gateway must use an IPv4 address; IPv6 is not supported for it.

    Site survivability for Webex Calling · Limitations and restrictions · Checked 2026-10-02

Documents

Cite this page

WarmTransfer. (2026, October 2). IPv6 for voice and UC platforms. WarmTransfer. https://warmtransfer.net/knowledge/ipv6-voice

@misc{warmtransfer-ipv6-voice,
  title  = {IPv6 for voice and UC platforms},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/ipv6-voice},
  note   = {Verified 2026-10-02}
}