# DNS SRV and service discovery for SIP

Canonical: https://warmtransfer.net/knowledge/dns-srv-voice

Last verified: 2026-09-24

DNS SRV and service discovery protocols define how SIP entities locate servers, choose transports, and balance load[^30][^16]. Standards from the IETF establish resolution order, failover behavior, and certificate validation rules that platforms implement across cloud and premises deployments[^30][^39].

## RFC Resolution Standards

RFC 2782 obsoletes RFC 2052 and defines an SRV record's owner name as _Service._Proto.Name, carrying priority, weight, port, and target fields[^15][^16]. Under RFC 2782, a client must attempt the reachable target with the lowest-numbered priority first[^17]. Among records of equal priority, larger weights should receive a proportionately higher probability of selection, and weight-0 records receive a very small chance of selection when others exist[^20]. The SRV target must not be an alias (a CNAME), and a target of '.' indicates that the service is decidedly not available at that domain[^19][^18].

RFC 3263 directs a SIP client resolving a domain-name target to attempt NAPTR records first, then SRV records if no NAPTR records exist, and finally an A or AAAA lookup if no SRV records exist[^30]. A client performs the NAPTR query only when no transport protocol and no port are specified and the target is not a numeric IP address[^24]. Under RFC 3403 NAPTR records are processed in ascending ORDER value, with PREFERENCE selecting among records of equal ORDER, and a client must not simply use the first record with a known service[^34]. RFC 3263 specifies the NAPTR service field values SIP+D2U for UDP, SIP+D2T for TCP, SIP+D2S for SCTP, and SIPS+D2T for TLS over TCP[^25]. When resolving a sips URI, a client must discard any NAPTR services that do not contain SIPS[^32]. For a SIPS NAPTR result, both the queried domain and the NAPTR replacement domain must be valid according to the site certificate[^23].

If no NAPTR records are found, the client constructs SRV queries for the transport protocols it supports, using the labels _sip._udp, _sip._tcp, and _sips._tcp[^26][^33]. If neither NAPTR nor SRV records are found, the client should use UDP for a sip URI and TCP for a sips URI[^28]. If the target is a domain name but the URI contains an explicit port, the client performs an A or AAAA lookup and does not query SRV[^29]. When the target is a numeric IP address or the URI carries an explicit port without a transport parameter, the client uses UDP for a sip URI and TCP for a sips URI[^21]. If no SRV records exist, the client performs an A or AAAA lookup of the domain name and contacts it at the default port for the selected transport[^27].

RFC 7984 (September 2016, Standards Track) updates RFC 3263 for locating SIP servers in dual-stack IPv4/IPv6 networks[^42]. A dual-stack SIP client looks up address records for every address family it supports and adds all resulting addresses to the contact list rather than making one A or AAAA lookup[^40]. RFC 7984 permits RFC 6724 destination address selection to reorder addresses derived from one SRV record, but forbids reordering addresses derived from different SRV records[^41].

Under RFC 3263, a client treats a 503 response, a transport failure, or the expiry of timer B or timer F as a failure and should send a new request to the next element in the resolved list[^22]. RFC 3263 requires retransmissions of a SIP request and the ACK for a non-2xx response to INVITE to be sent to the same host as the original request[^31].

## Certificate Validation Rules

RFC 5922, Domain Certificates in SIP (June 2010, Standards Track), updates RFC 3261[^39]. A SIP TLS client compares the certificate identities against the original domain of the URI passed into RFC 3263 resolution, not against the SRV target host name[^37]. SIP domain identities come from subjectAltName URI entries with the sip scheme and no user part, and from subjectAltName DNS entries only when no SIP URI entries are present[^38]. An implementation may examine the certificate CN field only if the certificate has no subjectAltName[^35]. This is disputed: RFC 5922 states that implementations must not match any form of wildcard such as a leading '*.' when checking SIP domain identities in certificates, whereas Microsoft states that wildcard certificates are supported for the Direct Routing SBC when they comply with RFC 2818[^36][^14].

## Cisco Platforms

CUBE always attempts a DNS SRV lookup first for an FQDN session target and falls back to an A/AAAA lookup if the SRV lookup fails[^3]. If a port number is added to the FQDN in a CUBE session target (for example dns:cisco.com:5060), CUBE performs an A/AAAA lookup instead of an SRV lookup[^2]. CUBE can store local SRV records using the ip host command, for example ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm1.lab.local[^1]. The sip-ua srv version command selects between version 2, the default RFC 2782 underscore format, and version 1 for older systems that do not use the underscore[^4]. When resolving a host name while processing a SIP call, CUBE uses only the VRF associated with that call for DNS resolution[^5].

In Unified CM Release 15 a SIP trunk can have up to 16 destination addresses as IPv4 or IPv6 addresses or FQDNs, or a single DNS SRV record[^7]. In Unified CM Release 15 an administrator marks a SIP trunk destination as SRV by checking 'Destination Address is an SRV' in the trunk configuration[^6]. Cisco's Local Gateway guide shows ip host SRV entries (for example _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com) with session target dns:wxtocucm.io, so the gateway can pick Unified CM hosts and ports without external DNS[^51].

## Cloud Calling Trunks

For a certificate-based Webex Calling trunk, the Local Gateway must be reachable from the internet on a public IPv4 address that resolves from a DNS A or SRV record in a domain claimed and verified in Control Hub[^58][^60][^55]. Registration-based trunks impose no domain claim or DNS requirement[^58]. When a Webex Calling certificate-based trunk uses an SRV address, the SRV service type must have the _sips._tcp prefix[^60][^56]. If an FQDN is used, it must resolve to an A record and not to a CNAME, and Cisco prefers a time to live of 300 seconds or higher on all record types[^60].

Each Webex Calling trunk is created with an FQDN or SRV host address that must be unique across the whole organization, and a different port does not make an address unique: a trunk at london.lgw.cisco.com:5062 cannot be created while any other trunk uses the host address london.lgw.cisco.com, in either FQDN or SRV form[^59][^57]. Control Hub accepts both FQDN and SRV formats for the trunk address, while the Local Gateway's tenant-side configuration toward Webex Calling should use only SRV-based Webex Calling Edge addresses[^54]. For a registration-based Webex Calling Local Gateway, only SRV-based Webex Calling addresses are supported on the tenant side toward Webex Calling, for example sip-server dns: and registrar dns: pointing at the Control Hub registrar domain[^53]. Webex for Government does not support a registration-based Local Gateway, so its trunks are certificate-based and depend on a public A or SRV record[^47]. Control Hub converts trunk FQDN entries to lowercase, so Cisco instructs that the Local Gateway certificate use only lowercase letters[^52]. Whether a Webex Calling certificate-based trunk uses an FQDN or SRV address, the Contact address on new SIP dialogs from the Local Gateway must use the name configured in Control Hub[^50].

For Teams Direct Routing, the SBC FQDN must belong to a domain verified in the Microsoft 365 tenant, and the default *.onmicrosoft.com domain cannot be used[^13]. Microsoft lists a public DNS entry for the SBC FQDN as a Direct Routing infrastructure requirement; the page does not say whether that entry is an A record or an SRV record[^12]. Direct Routing SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061, while the port for traffic from Microsoft to the SBC is whatever is configured on the SBC[^11]. For Microsoft 365, Office 365 and GCC, Direct Routing SBCs connect to sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in primary, secondary and tertiary order, with separate sip*.ipv6.pstnhub.microsoft.com names for IPv6 SBCs[^8]. GCC High Direct Routing uses sip.pstnhub.gov.teams.microsoft.us and DoD uses sip.pstnhub.dod.teams.microsoft.us, and Microsoft says secondary and tertiary FQDNs are not required in those clouds[^10]. Microsoft instructs administrators to allow Direct Routing signaling to and from all Microsoft Teams IP ranges, not only the addresses returned by DNS queries[^9].

Twilio publishes NAPTR and SRV records on the generic localized edge names pstn.[edge].twilio.com (for example pstn.ashburn.twilio.com), which resolve to the same IPs as a customer's personal localized trunk domain[^43]. Twilio states that all customer localized SIP trunk domains resolve to the same A record, so the personal domain both identifies the trunk and controls where traffic is routed[^46]. Twilio recommends putting the personal trunk domain in the Request-URI and setting the generic localized edge domain as the outbound proxy or Route header, so SRV and NAPTR resolution applies[^45]. Twilio Elastic SIP Trunking accepts up to 10 origination SIP URIs whose host is an IP address or FQDN, each with a priority (0-65535, lowest used first) and a weight (1-65535) for sharing load within a priority[^44].

## See also

See also [Local Gateway design and configuration](https://warmtransfer.net/knowledge/webex-calling-local-gateway).

## Applicability

Applies to: IETF SIP, IETF DNS, IETF SIP over TLS, IETF DNS NAPTR, Microsoft Teams Phone Direct Routing, Cisco CUBE on IOS XE, Cisco Unified Communications Manager, Cisco Webex Calling Local Gateway (IOS XE), Cisco Webex Calling, and Twilio Elastic SIP Trunking. Deployments: on-premises, hybrid, multi-tenant, any, government, and premises-based-pstn. Sources checked 2026-09-24. Webex for Government Local Gateway restrictions and Microsoft Teams Direct Routing GCC High and DoD endpoints apply to the United States region[^47][^10]. Unified CM SIP trunk capacity limits apply to Release 15 and SUs[^7][^6].

## What remains uncertain

Whether Microsoft Teams Direct Routing accepts an SRV record instead of an A record for the SBC public DNS entry is not covered by the sources below.

## Sources

[^1]: CUBE can hold local SRV records with the ip host command, for example ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm1.lab.local (priority, weight, port, target). Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure and Troubleshoot DNS Resolution](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/configure-and-troubleshoot-dns-lookup-on-cube.html), Configure and Troubleshoot DNS Resolution, local SRV resource records example. Checked 2026-09-24.
[^2]: If a port number is added to the FQDN in a CUBE session target (for example dns:cisco.com:5060), CUBE performs an A/AAAA lookup instead of an SRV lookup. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure and Troubleshoot DNS Resolution](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/configure-and-troubleshoot-dns-lookup-on-cube.html), Configure and Troubleshoot DNS Resolution, Overview. Checked 2026-09-24.
[^3]: CUBE always attempts a DNS SRV lookup first for an FQDN session target and falls back to an A/AAAA lookup if the SRV lookup fails. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure and Troubleshoot DNS Resolution](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/configure-and-troubleshoot-dns-lookup-on-cube.html), Configure and Troubleshoot DNS Resolution, Overview. Checked 2026-09-24.
[^4]: CUBE's sip-ua srv version command selects between version 2, the default RFC 2782 underscore format, and version 1 for older systems that do not use the underscore. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure and Troubleshoot DNS Resolution](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/configure-and-troubleshoot-dns-lookup-on-cube.html), Configure and Troubleshoot DNS Resolution, SRV format versions. Checked 2026-09-24.
[^5]: When CUBE resolves a host name while processing a SIP call, it uses only the VRF associated with that call for DNS resolution. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure and Troubleshoot DNS Resolution](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/configure-and-troubleshoot-dns-lookup-on-cube.html), Configure and Troubleshoot DNS Resolution, VRF-aware DNS resolution. Checked 2026-09-24.
[^6]: In Unified CM Release 15 an administrator marks a SIP trunk destination as SRV by checking 'Destination Address is an SRV' in the trunk configuration. Source: [System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Trunks](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/systemConfig/cucm_b_system-configuration-guide-15/cucm_b_system-configuration-guide-14_chapter_01000.html), Configure Trunks, Configure SIP Trunks procedure, step 8. Checked 2026-09-24.
[^7]: In Unified CM Release 15 a SIP trunk can have up to 16 destination addresses as IPv4 or IPv6 addresses or FQDNs, or a single DNS SRV record. Source: [System Configuration Guide for Cisco Unified Communications Manager Release 15 and SUs - Configure Trunks](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/systemConfig/cucm_b_system-configuration-guide-15/cucm_b_system-configuration-guide-14_chapter_01000.html), Configure Trunks, SIP Trunk Overview. Checked 2026-09-24.
[^8]: For Microsoft 365, Office 365 and GCC, Direct Routing SBCs connect to sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in primary, secondary and tertiary order, with separate sip*.ipv6.pstnhub.microsoft.com names for IPv6 SBCs. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling: FQDNs. Checked 2026-09-24.
[^9]: Microsoft instructs administrators to allow Direct Routing signaling to and from all Microsoft Teams IP ranges, not only the addresses returned by DNS queries. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling: FQDNs, Important note. Checked 2026-09-24.
[^10]: GCC High Direct Routing uses sip.pstnhub.gov.teams.microsoft.us and DoD uses sip.pstnhub.dod.teams.microsoft.us, and Microsoft says secondary and tertiary FQDNs are not required in those clouds. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling: GCC High; SIP signaling: DoD. Checked 2026-09-24.
[^11]: Direct Routing SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061, while the port for traffic from Microsoft to the SBC is whatever is configured on the SBC. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling ports. Checked 2026-09-24.
[^12]: Microsoft lists a public DNS entry for the SBC FQDN as a Direct Routing infrastructure requirement; the page does not say whether that entry is an A record or an SRV record. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Infrastructure requirements table, Public DNS row. Checked 2026-09-24.
[^13]: For Teams Direct Routing, the SBC FQDN must belong to a domain verified in the Microsoft 365 tenant, and the default *.onmicrosoft.com domain cannot be used. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SBC domain names. Checked 2026-09-24.
[^14]: Microsoft states that wildcard certificates are supported for the Direct Routing SBC when they comply with RFC 2818, and the certificate should carry the SBC FQDN in the CN or SAN (disputed). Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Public trusted certificate for the SBC. Checked 2026-09-24.
[^15]: RFC 2782 obsoletes RFC 2052. Source: [RFC 2782: A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html), Document header. Checked 2026-09-24.
[^16]: An SRV record's owner name has the form _Service._Proto.Name, and the record carries priority, weight, port and target fields. Source: [RFC 2782: A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html), The format of the SRV RR. Checked 2026-09-24.
[^17]: Under RFC 2782 a client must attempt the reachable target with the lowest-numbered priority first. Source: [RFC 2782: A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html), The format of the SRV RR, Priority field. Checked 2026-09-24.
[^18]: Under RFC 2782 an SRV target of '.' means the service is decidedly not available at that domain. Source: [RFC 2782: A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html), The format of the SRV RR, Target field. Checked 2026-09-24.
[^19]: Under RFC 2782 the SRV target must not be an alias (a CNAME). Source: [RFC 2782: A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html), The format of the SRV RR, Target field. Checked 2026-09-24.
[^20]: Under RFC 2782, among records of equal priority, larger weights should be given a proportionately higher probability of selection, and weight-0 records get a very small chance of selection when others exist. Source: [RFC 2782: A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html), The format of the SRV RR, Weight field. Checked 2026-09-24.
[^21]: Under RFC 3263, when the target is a numeric IP address or the URI carries an explicit port but no transport parameter, the client uses UDP for a sip URI and TCP for a sips URI. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^22]: Under RFC 3263 a client treats a 503 response, a transport failure, or expiry of timer B or timer F as failure and should send a new request to the next element in the resolved list. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.3 Details of RFC 2782 Process. Checked 2026-09-24.
[^23]: RFC 3263 requires that, for a SIPS NAPTR result, both the queried domain and the NAPTR replacement domain be valid according to the site certificate. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^24]: Under RFC 3263 a client performs the NAPTR query only when no transport protocol and no port are specified and the target is not a numeric IP address. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^25]: RFC 3263 defines the NAPTR service field values SIP+D2U for UDP, SIP+D2T for TCP, SIP+D2S for SCTP and SIPS+D2T for TLS over TCP. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^26]: Under RFC 3263, if no NAPTR records are found the client constructs SRV queries for the transport protocols it supports. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^27]: Under RFC 3263, if no SRV records are found the client performs an A or AAAA lookup of the domain name and contacts it at the default port for the selected transport. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.2 Determining Port and IP Address. Checked 2026-09-24.
[^28]: Under RFC 3263, if neither NAPTR nor SRV records are found the client should use UDP for a sip URI and TCP for a sips URI. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^29]: Under RFC 3263, if the target is a domain name but the URI contains a port, the client performs an A or AAAA lookup and does not query SRV. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.2 Determining Port and IP Address. Checked 2026-09-24.
[^30]: RFC 3263 has a SIP client resolving a domain-name target try NAPTR records first, then SRV records if no NAPTR records exist, then an A or AAAA lookup if no SRV records exist. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol; Section 4.2 Determining Port and IP Address. Checked 2026-09-24.
[^31]: RFC 3263 requires that retransmissions of a SIP request and the ACK for a non-2xx response to INVITE be sent to the same host as the original request. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4 Client Usage (introductory text). Checked 2026-09-24.
[^32]: Under RFC 3263 a client resolving a sips URI must discard any NAPTR services that do not contain SIPS. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^33]: RFC 3263 uses the SRV service and protocol labels _sip._udp, _sip._tcp and _sips._tcp to locate SIP servers. Source: [RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers](https://www.rfc-editor.org/rfc/rfc3263.html), Section 4.1 Selecting a Transport Protocol. Checked 2026-09-24.
[^34]: Under RFC 3403 NAPTR records are processed in ascending ORDER value, with PREFERENCE choosing among records of equal ORDER, and a client must not simply use the first record with a known service. Source: [RFC 3403: Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database](https://www.rfc-editor.org/rfc/rfc3403.html), NAPTR RR Format (ORDER and PREFERENCE fields) and the processing rules that follow. Checked 2026-09-24.
[^35]: Under RFC 5922 an implementation may examine the certificate CN field only if the certificate has no subjectAltName. Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Section 7.1. Checked 2026-09-24.
[^36]: RFC 5922 states that implementations must not match any form of wildcard such as a leading '*.' when checking SIP domain identities in certificates (disputed). Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Section 7.2. Checked 2026-09-24.
[^37]: Under RFC 5922 a SIP TLS client compares the certificate identities against the original domain of the URI it passed into RFC 3263 resolution, not against the SRV target host name. Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Section 7.3 Client Behavior. Checked 2026-09-24.
[^38]: Under RFC 5922, SIP domain identities come from subjectAltName URI entries with the sip scheme and no user part, and from subjectAltName DNS entries only when no SIP URI entries are present. Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Section 7.1. Checked 2026-09-24.
[^39]: RFC 5922, Domain Certificates in SIP (June 2010, Standards Track), updates RFC 3261. Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Document header. Checked 2026-09-24.
[^40]: RFC 7984 has a dual-stack SIP client look up address records for every address family it supports and add all resulting addresses to the list to contact, rather than one A or AAAA lookup. Source: [RFC 7984: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network](https://www.rfc-editor.org/rfc/rfc7984.html), Section 3.1. Checked 2026-09-24.
[^41]: RFC 7984 allows RFC 6724 destination address selection to reorder addresses derived from one SRV record but forbids it from reordering addresses derived from different SRV records. Source: [RFC 7984: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network](https://www.rfc-editor.org/rfc/rfc7984.html), Section 4. Checked 2026-09-24.
[^42]: RFC 7984 (September 2016, Standards Track) updates RFC 3263 for locating SIP servers in dual-stack IPv4/IPv6 networks. Source: [RFC 7984: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network](https://www.rfc-editor.org/rfc/rfc7984.html), Document header. Checked 2026-09-24.
[^43]: Twilio publishes NAPTR and SRV records on the generic localized edge names pstn.[edge].twilio.com (for example pstn.ashburn.twilio.com), which resolve to the same IPs as a customer's personal localized trunk domain. Source: [Sending SIP to Twilio - Best Practices](https://www.twilio.com/docs/sip-trunking/sending-sip-to-twilio-best-practices), Localized termination URI and SRV/NAPTR records section. Checked 2026-09-24.
[^44]: Twilio Elastic SIP Trunking accepts up to ten origination SIP URIs whose host is an IP address or FQDN, each with a priority (0-65535, lowest used first) and a weight (1-65535) for sharing load within a priority. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Origination section, origination SIP URI priority and weight. Checked 2026-09-24.
[^45]: Twilio recommends putting the personal trunk domain in the Request-URI and setting the generic localized edge domain as the outbound proxy or Route header, so SRV and NAPTR resolution applies. Source: [Sending SIP to Twilio - Best Practices](https://www.twilio.com/docs/sip-trunking/sending-sip-to-twilio-best-practices), SRV and NAPTR records, configuration guidance. Checked 2026-09-24.
[^46]: Twilio states that all customer localized SIP trunk domains resolve to the same A record, so the personal domain both identifies the trunk and controls where traffic is routed. Source: [Sending SIP to Twilio - Best Practices](https://www.twilio.com/docs/sip-trunking/sending-sip-to-twilio-best-practices), Localized termination URI section. Checked 2026-09-24.
[^47]: Webex for Government does not support a registration-based Local Gateway, so its trunks are certificate-based and depend on a public A or SRV record. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Registration-based vs certificate-based Local Gateway overview. Checked 2026-09-24.
[^48]: Cisco lists IOS XE 17.9.1a or later as a requirement for a certificate-based Webex Calling Local Gateway. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Certificate-based Local Gateway prerequisites. Checked 2026-09-24.
[^49]: For a certificate-based Webex Calling Local Gateway trunk, the certificate CN or SAN must match the FQDN or SRV address configured in Control Hub; for an SRV address the certificate carries the SRV domain name, not a target host. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Certificate-based Local Gateway, certificate requirements and FQDN/SRV examples (cube1.lgw.com and lgws.lgw.com). Checked 2026-09-24.
[^50]: Whether a Webex Calling certificate-based trunk uses an FQDN or SRV address, the Contact address on new SIP dialogs from the Local Gateway must use the name configured in Control Hub. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Certificate-based Local Gateway configuration section. Checked 2026-09-24.
[^51]: Cisco's Local Gateway guide shows ip host SRV entries (for example _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com) with session target dns:wxtocucm.io, so the gateway can pick Unified CM hosts and ports without external DNS. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Local Gateway with Unified CM, dial-peer and ip host configuration. Checked 2026-09-24.
[^52]: Control Hub converts trunk FQDN entries to lowercase, so Cisco instructs that the Local Gateway certificate use only lowercase letters. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Certificate-based Local Gateway, certificate requirements. Checked 2026-09-24.
[^53]: For a registration-based Webex Calling Local Gateway, only SRV-based Webex Calling addresses are supported on the tenant side toward Webex Calling, for example sip-server dns: and registrar dns: pointing at the Control Hub registrar domain. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Registration-based Local Gateway configuration section. Checked 2026-09-24.
[^54]: Control Hub accepts both FQDN and SRV formats for the trunk address, while the Local Gateway's tenant-side configuration toward Webex Calling should use only SRV-based Webex Calling Edge addresses. Source: [Configure trunks, route groups, and dial plans for Webex Calling](https://help.webex.com/article/n0xb944/Configure-Trunks-Route-Groups-and-Dial-Plans-for-Cisco-Webex-Calling), Certificate-based trunk requirements. Checked 2026-09-24.
[^55]: For a certificate-based Webex Calling trunk, the Local Gateway must be reachable from the internet on a public IPv4 address that resolves from a DNS A or SRV record in a domain verified in Control Hub. Source: [Configure trunks, route groups, and dial plans for Webex Calling](https://help.webex.com/article/n0xb944/Configure-Trunks-Route-Groups-and-Dial-Plans-for-Cisco-Webex-Calling), Certificate-based trunk requirements. Checked 2026-09-24.
[^56]: When a Webex Calling certificate-based trunk uses an SRV address, the SRV service type must have the _sips._tcp prefix. Source: [Configure trunks, route groups, and dial plans for Webex Calling](https://help.webex.com/article/n0xb944/Configure-Trunks-Route-Groups-and-Dial-Plans-for-Cisco-Webex-Calling), Certificate-based trunk requirements, SRV address. Checked 2026-09-24.
[^57]: Each Webex Calling trunk is created with an FQDN or SRV host address that must be unique across the whole organization; no two trunks may share an address. Source: [Configure trunks, route groups, and dial plans for Webex Calling](https://help.webex.com/article/n0xb944/Configure-Trunks-Route-Groups-and-Dial-Plans-for-Cisco-Webex-Calling), Certificate-based trunk requirements. Checked 2026-09-24.
[^58]: Certificate-based trunks require a domain claimed and verified in Control Hub together with a DNS A or SRV record, whereas registration-based trunks impose no domain claim or DNS requirement. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Registration versus certificate comparison table. Checked 2026-09-04.
[^59]: A certificate-based trunk's fully qualified domain name or SRV host address must be unique across the whole organisation, and a different port does not make an address unique: a trunk at london.lgw.cisco.com:5062 cannot be created while any other trunk uses the host address london.lgw.cisco.com, in either FQDN or SRV form. Source: [Configure trunks, route groups, and dial plans for Webex Calling](https://help.webex.com/article/n0xb944/Configure-Trunks-Route-Groups-and-Dial-Plans-for-Cisco-Webex-Calling), Add a certificate-based trunk to a location, Before you begin, Unique address across the organization. Checked 2026-09-15.
[^60]: A certificate-based trunk address must resolve from the public internet through a DNS A record or a DNS SRV record; an FQDN must resolve to an A record and not to a CNAME, an SRV service type must carry the prefix _sips._tcp, and Cisco prefers a time to live of 300 seconds or higher on all record types. Source: [Configure trunks, route groups, and dial plans for Webex Calling](https://help.webex.com/article/n0xb944/Configure-Trunks-Route-Groups-and-Dial-Plans-for-Cisco-Webex-Calling), Add a certificate-based trunk to a location, Before you begin, DNS configuration. Checked 2026-09-15.