# SIP OPTIONS pings and trunk keepalives Canonical: https://warmtransfer.net/knowledge/sip-options-keepalive Last verified: 2026-09-24 In SIP networks, the OPTIONS method queries a user agent or server for its capabilities outside of an established dialog without initiating a session[^54]. Trunk implementations and session border controllers widely employ these out-of-dialog transactions as heartbeat keepalives to track peer availability, trigger failover routing, and prevent calls from routing to dead endpoints[^40][^1][^20]. ## How it works Under RFC 3261, an OPTIONS request solicits capabilities and should receive the response that an INVITE would receive, returning 200 OK if the peer can accept an INVITE or 486 Busy Here if it cannot take new sessions[^55]. RFC 3261 specifies that a 200 OK sent in reply to an OPTIONS request should include `Allow`, `Accept`, `Accept-Encoding`, `Accept-Language`, and `Supported` header fields outlining the responder's supported features[^53]. For non-INVITE client transactions like OPTIONS, RFC 3261 defines the transaction timeout Timer F as 64*T1, where T1 defaults to 500 ms[^56]. Beyond full SIP transactions, RFC 5626 defines alternative keepalive mechanisms for client-initiated connections[^57][^60]. On connection-oriented transports, RFC 5626 keepalives consist of a client sending a double CRLF (`\r\n\r\n`) and the server responding with a single CRLF (`\r\n`)[^57]. RFC 5626 specifies an upper bound of 120 seconds and a lower bound of 95 seconds for these CRLF keepalive intervals[^58]. For connectionless transports like UDP, RFC 5626 specifies STUN Binding Requests sent over the flow as keepalives at randomized intervals between 24 and 29 seconds[^60]. A Flow-Timer header returned in a successful registration response indicates how many seconds the server waits without receiving keepalives[^59]. ## Microsoft Teams Direct Routing Microsoft Teams Direct Routing uses SIP OPTIONS messages sent by Session Border Controllers (SBCs) alongside TLS handshake monitoring to verify health at the application level, catching conditions such as expired certificates or malfunctioning SIP stacks that pass network pings[^40][^22]. This monitoring is active without tenant administrator intervention[^40]. The tenant SBC setting `SendSipOptions` (`Send SIP options` in the Teams admin center) defaults to True, which Microsoft strongly recommends maintaining; disabling it removes the SBC from the Direct Routing Monitoring and Alert system[^41][^42]. ### Signaling Exchange and Timing Microsoft describes the Direct Routing OPTIONS exchange in this order: the SBC opens TLS to the SIP proxy FQDN, the SBC sends OPTIONS, the proxy identifies the SBC FQDN and answers 200 OK on the same TLS connection, the proxy sends OPTIONS to the Contact FQDN, the SBC answers 200 OK, and the SBC is marked Active in the Teams admin center[^35]. Validating an SBC pairing requires confirming both directions: the SBC must receive 200 OK to its outbound OPTIONS and must reply with 200 OK to inbound OPTIONS from Direct Routing[^45]. When identifying an incoming OPTIONS message from an SBC, the Microsoft SIP proxy checks for a known tenant SBC FQDN in the `Record-Route` header first, falling back to the `Contact` header[^39]. For Microsoft 365, Office 365, and GCC environments, Direct Routing signaling endpoints are `sip.pstnhub.microsoft.com`, `sip2.pstnhub.microsoft.com`, and `sip3.pstnhub.microsoft.com`, communicating over SIP/TLS on port 5061[^37]. Microsoft requires that OPTIONS be sent to FQDNs rather than fixed IP addresses, because proxy IP addresses can migrate during outages or maintenance; devices supporting DNS names can target `sip-all.pstnhub.microsoft.com`, which resolves to all proxy IP addresses[^36][^43]. Microsoft's connection guidance dictates that SIP OPTIONS pings must not be sent more frequently than 1 transaction every 60 seconds per configured trunk per endpoint, and includes a second clause referencing 180 seconds[^31]. Direct Routing considers an SBC healthy if an OPTIONS message was received within the last 3 minutes (three times the standard 1-minute interval)[^44]. In multi-tenant hosted carrier architectures, only the hosted SBC sends SIP OPTIONS, and derived trunks inherit the main SBC's status[^32]. ### Routing and Status Direct Routing uses received OPTIONS health to make outbound routing decisions when multiple SBCs are configured for a user[^34]. If an SBC misses its regular OPTIONS interval, Direct Routing demotes it rather than removing it completely: it is skipped on the initial attempt, but if the alternate SBC fails, the demoted SBC is attempted before call failure[^26]. If multiple SBCs share equal priority and healthy status, calls are balanced among them using a Fisher-Yates shuffle[^29]. Direct Routing configuration also defines `FailoverResponseCodes` (defaulting to 408, 503, and 504) and `FailoverTimeSeconds` (defaulting to 10 seconds), but `FailoverResponseCodes` applies exclusively to responses to an initial INVITE terminated by the SBC and does not apply to OPTIONS[^27][^28]. In the Direct Routing health dashboard, the SBC's SIP options status displays one of three values[^25]: - `Active`: OPTIONS are arriving on a regular interval[^25]. - `Warning, no SIP options`: the SBC is configured to send OPTIONS, but none have been received[^25]. - `Warning, SIP Messages aren't configured`: OPTIONS monitoring is disabled[^25]. The dashboard reports that SBCs send OPTIONS every minute by default (varying by SBC vendor), generates warnings if OPTIONS are missing, and includes a `SIP options last checked` timestamp in the per-SBC detail view[^24][^33]. ### Common Direct Routing Troubleshooting Scenarios Microsoft identifies several root causes when OPTIONS transactions fail: - **No 200 OK received by SBC**: Common causes include providing an IP address instead of an FQDN in the `Contact` header, mismatching the `Record-Route` or `Contact` FQDN against the name configured in Teams, or using an unvalidated or unactivated domain[^23]. - **SBC receives 200 OK but no inbound OPTIONS**: Microsoft advises verifying that the `Record-Route` or `Contact` FQDN resolves to the correct IP address and confirming firewalls permit inbound traffic from all Microsoft SIP proxy signaling addresses[^21]. - **Intermittent Inactive status**: Sending OPTIONS to fixed IP addresses instead of configuring all 3 proxy FQDNs causes drops when IP endpoints shift across datacenters[^36]. ## Cisco Platforms ### Cisco Unified Border Element (CUBE) CUBE manages trunk monitoring using keepalive profiles configured globally via `voice class sip-options-keepalive ` and bound to dial-peers with `voice-class sip options-keepalive profile `[^6]. Profile parameters and operational behaviors include: - **Timers and Thresholds**: `up-interval` sets the ping interval while the heartbeat status is Up (default 60 seconds); `down-interval` sets the interval while Down (default 30 seconds); and `retry` defines consecutive failed pings permitted before changing status from Up to Down (default 5 retries)[^13][^3][^8]. - **Transport and Modification**: The profile `transport` parameter accepts `tcp`, `tcp tls`, `udp`, or `system` (default `system`), and `sip-profiles` selects a SIP profile to apply header modifications to the OPTIONS message[^12]. - **Dial-Peer Busyout**: When an OPTIONS keepalive fails, CUBE busies out all associated dial-peers to steer calls away[^1]. When targeting a server group, CUBE sets the dial-peer to BUSY only after all targets in the group fail to answer[^9]. - **Ping Groups**: Dial-peers sharing a destination can be grouped under a single keepalive profile to consolidate ping traffic into a single stream[^5]. - **DNS SRV**: Beginning in Cisco IOS XE Cupertino 17.9.1a, CUBE can monitor individual SRV hosts behind a DNS destination and balance traffic based on keepalive health and SRV priority[^11]. - **Outbound Proxies**: If an outbound proxy is set on the dial-peer or its tenant, keepalives target the outbound proxy address[^4]. - **Restrictions**: CUBE does not support attaching one profile across dial-peers with differing bind interfaces, nor does it support profiles in multi-VRF environments[^7]. CUBE keepalive status is inspected with `show voice class sip-options-keepalive `, `show dial-peer voip keepalive status `, and `show dial-peer voice summary`[^10]. ### Cisco Unified Communications Manager (CUCM) Unified CM configures SIP OPTIONS Ping inside the SIP Profile applied to a SIP trunk[^19]. Once enabled, every Unified CM node executing the trunk's SIP daemon transmits periodic OPTIONS requests (exchanged every 60 seconds by default) to every destination IP address on the trunk[^19][^15]. Cisco recommends enabling OPTIONS ping across all trunks so status is tracked dynamically rather than waiting for per-call setup timeouts[^20]. Unified CM considers a destination address out of service if it fails to answer an OPTIONS request, answers with 408 Request Timeout or 503 Service Unavailable, or fails TCP socket establishment[^18]. A trunk is considered in service as long as at least 1 node receives a non-408, non-503 response from at least 1 destination address[^16]. If every remote peer fails, Unified CM marks the trunk status as No Service and reports that all remote peers are out of service[^14]. Cisco documents 3 out-of-service reason codes in trunk failure scenarios[^17]: - `Local=1`: No response to OPTIONS after UDP retries expire[^17]. - `Local=2`: Inability to establish a socket connection to the remote peer[^17]. - `Local=3`: DNS failure resolving the peer's hostname or SRV record[^17]. ## Kamailio Dispatcher Module Kamailio manages outbound gateway health checks using its `dispatcher` module[^47]. Probing behavior is governed by module parameters: - `ds_ping_method`: Sets the SIP method used for gateway probing (defaults to OPTIONS)[^47]. - `ds_ping_interval`: Sets the interval between probes; defaults to 0, which disables probing of inactive destinations until explicitly set by an operator[^46]. - `ds_probing_threshold`: The number of failed pings before marking a gateway inactive (defaults to 1)[^50]. - `ds_inactive_threshold`: The number of successful pings before returning an inactive gateway to service (defaults to 1)[^50]. - `ds_ping_reply_codes`: Defines acceptable response codes; defaults strictly to 200 OK unless configured with additional acceptable status codes[^49]. - `ds_probing_mode`: Controls which destinations are probed; 0 probes only destinations in `PROBING` state, 1 probes all destinations, 2 probes only `INACTIVE` destinations flagged with `PROBING`, and 3 continuously probes `PROBING` destinations without altering their probing state[^48]. ## See also See also [CUBE dial-peer matching and voice class URI and translation profiles](https://warmtransfer.net/knowledge/cube-dial-peers). See also [Kamailio and OpenSIPS SIP proxies](https://warmtransfer.net/knowledge/kamailio-sip-proxy). See also [SIP transactions dialogs and call setup](https://warmtransfer.net/knowledge/sip-transactions-dialogs). See also [SIP response codes and failure interpretation](https://warmtransfer.net/knowledge/sip-response-codes). See also [NAT traversal ICE STUN and TURN](https://warmtransfer.net/knowledge/nat-traversal-ice). ## Applicability Applies to: Microsoft Teams Phone Direct Routing, Cisco CUBE (IOS XE), Cisco Unified Communications Manager, IETF SIP, and Kamailio dispatcher module. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-24. DNS SRV monitoring on CUBE is supported from Cisco IOS XE Cupertino 17.9.1a and later[^11]. ## What remains uncertain Whether later Unified CM releases alter the trunk in-service and out-of-service evaluation rules is not covered by the sources below. The specific meaning and application of Microsoft's secondary 180-second clause regarding Direct Routing OPTIONS ping frequency is not covered by the sources below. ## Sources [^1]: When an OPTIONS keepalive fails, CUBE busies out (makes inactive) every dial-peer associated with that profile, so calls can be routed elsewhere. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Overview'. Checked 2026-09-24. [^2]: CUBE's default up-interval of 60 seconds appears to fall inside the 60-to-180-second OPTIONS window Microsoft describes for Direct Routing, so a CUBE left at its defaults should not break Microsoft's frequency rule while the destination is up (inferred). Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), up-interval default, read against ms-learn-dr-connect-sbc 'Considerations' OPTIONS bullet. Checked 2026-09-24. [^3]: In a CUBE keepalive profile, down-interval sets how many seconds apart OPTIONS pings are sent while the destination's heartbeat status is Down. The default is 30. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Configure SIP Out-of-Dialog OPTIONS Ping Group', down-interval step. Checked 2026-09-24. [^4]: If an outbound proxy is configured on the dial-peer, or on a tenant associated with it, CUBE runs the keepalive session against the outbound proxy address. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), restrictions/notes under 'Configure SIP Out-of-Dialog OPTIONS Ping Group'. Checked 2026-09-24. [^5]: Dial-peers that share a destination can be grouped under one keepalive profile, so CUBE sends a single set of OPTIONS pings for the whole group instead of one set per dial-peer. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), sections 'Overview' and 'Feature Information' (SIP Out-of-dialog OPTIONS Ping Group row). Checked 2026-09-24. [^6]: On CUBE, an OPTIONS keepalive profile is created globally with 'voice class sip-options-keepalive ' and attached to a dial-peer with 'voice-class sip options-keepalive profile '. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Configure SIP Out-of-Dialog OPTIONS Ping Group'. Checked 2026-09-24. [^7]: CUBE does not support putting one keepalive profile on two or more dial-peers that have different bind interfaces, and does not support it in a multi-VRF setup. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), restrictions under 'Configure SIP Out-of-Dialog OPTIONS Ping Group'. Checked 2026-09-24. [^8]: In a CUBE keepalive profile, retry sets how many failed OPTIONS pings are allowed before the heartbeat status changes from Up to Down. The default is 5. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Configure SIP Out-of-Dialog OPTIONS Ping Group', retry step. Checked 2026-09-24. [^9]: For a dial-peer whose destination is a server group, CUBE sets the dial-peer to BUSY only when none of the group's targets answer the OPTIONS ping. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Overview' (server group paragraph). Checked 2026-09-24. [^10]: Commands for checking CUBE keepalive state are 'show voice class sip-options-keepalive ', 'show dial-peer voip keepalive status ' and 'show dial-peer voice summary'. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Configuration Examples For SIP Out-of-Dialog OPTIONS Ping Group' and verification steps. Checked 2026-09-24. [^11]: From Cisco IOS XE Cupertino 17.9.1a, CUBE can use OPTIONS keepalive to monitor every SRV host behind a DNS destination and spreads calls across those hosts by SRV priority and keepalive status. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), sections 'OPTIONS Ping for DNS SRV Hosts' and 'Load Balancing for DNS SRV Hosts'. Checked 2026-09-24. [^12]: A CUBE keepalive profile has a transport option accepting tcp, tcp tls, udp or system, with system as the default, and a sip-profiles option that picks the SIP profile applied to the OPTIONS message. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Configure SIP Out-of-Dialog OPTIONS Ping Group', transport and sip-profiles steps. Checked 2026-09-24. [^13]: In a CUBE keepalive profile, up-interval sets how many seconds apart OPTIONS pings are sent while the destination's heartbeat status is Up. The default is 60. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - SIP Trunk Monitoring](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_oodo-ping-group.html), section 'Configure SIP Out-of-Dialog OPTIONS Ping Group', up-interval step. Checked 2026-09-24. [^14]: When every remote peer of a SIP trunk is out of service, Unified CM reports that all remote peers are out of service and cannot handle calls for the trunk, and the trunk shows No Service. Source: [Calls through Session Initiation Protocol (SIP) Trunk Failure](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213718-calls-through-session-initiation-protoco.html), problem description and trunk status discussion. Checked 2026-09-24. [^15]: Cisco's CUCM-to-CUBE OPTIONS ping tech note says the OPTIONS messages are exchanged every 60 seconds by default. Source: [Configure Options Ping Between CUCM and CUBE](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214218-configure-options-ping-between-cucm-and.html), configuration section describing the SIP profile OPTIONS ping. Checked 2026-09-24. [^16]: Unified CM treats a trunk as in service when at least one node gets a response other than 408 or 503 from at least one destination address. Source: [Cisco Unified Communications Manager Trunks (Session Management Edition deployment guide 8.6(1))](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/session_mgmt/deploy/8_6_1/trunks.html), section 'SIP OPTIONS Ping'. Checked 2026-09-24. [^17]: Cisco's SIP trunk failure tech note lists out-of-service reason codes: Local=1 means no responses to OPTIONS after all retries over UDP, Local=2 means Unified CM could not open a socket to the remote peer, and Local=3 means DNS could not resolve the hostname or SRV record. Source: [Calls through Session Initiation Protocol (SIP) Trunk Failure](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213718-calls-through-session-initiation-protoco.html), troubleshooting scenarios labelled Local=1, Local=2, Local=3. Checked 2026-09-24. [^18]: Unified CM marks a trunk destination address out of service if it does not answer an OPTIONS request, answers with 503 Service Unavailable or 408 Request Timeout, or a TCP connection to it cannot be set up. Source: [Cisco Unified Communications Manager Trunks (Session Management Edition deployment guide 8.6(1))](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/session_mgmt/deploy/8_6_1/trunks.html), section 'SIP OPTIONS Ping'. Checked 2026-09-24. [^19]: In Unified CM, SIP OPTIONS Ping is turned on in the SIP Profile attached to a SIP trunk. Every node running the trunk's SIP daemon then periodically sends OPTIONS to each of the trunk's destination IP addresses. Source: [Cisco Unified Communications Manager Trunks (Session Management Edition deployment guide 8.6(1))](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/session_mgmt/deploy/8_6_1/trunks.html), section 'SIP OPTIONS Ping'. Checked 2026-09-24. [^20]: Cisco recommends enabling SIP OPTIONS Ping on all SIP trunks, because Unified CM can then track trunk state as it changes instead of discovering it per call through timeouts. Source: [Cisco Unified Communications Manager Trunks (Session Management Edition deployment guide 8.6(1))](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/session_mgmt/deploy/8_6_1/trunks.html), section 'SIP OPTIONS Ping'. Checked 2026-09-24. [^21]: If the SBC gets 200 OK from the SIP proxy but never receives the proxy's OPTIONS, Microsoft says to check that the Record-Route or Contact FQDN is correct and resolves to the right IP, and that firewall rules allow inbound traffic from all SIP proxy signalling addresses. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), section 'SIP options issues' > 'SBC receives "200 OK" response but not SIP options'. Checked 2026-09-24. [^22]: Microsoft says it uses SIP OPTIONS together with TLS handshake monitoring to check SBC health at the application level. A trunk that answers a network ping can still fail if its certificate has expired or its SIP stack is not working. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), section 'The SBCs tab', 'SIP options status' value 'Warning, SIP Messages aren't configured'. Checked 2026-09-24. [^23]: Causes Microsoft lists for an SBC getting no 200 OK to its OPTIONS include: a Contact header carrying an IP address instead of the FQDN, an FQDN in Record-Route or Contact that differs from the one configured in Teams, and a domain that is not fully validated or not activated. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), section 'SIP options issues' > 'SBC doesn't receive a "200 OK" response from SIP proxy'. Checked 2026-09-24. [^24]: The Direct Routing health dashboard says the SBC sends OPTIONS every minute by default, that this can vary by SBC vendor, and that Direct Routing warns when OPTIONS are not being sent or are not configured. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), section 'The SBCs tab', bullet 'SIP options status'. Checked 2026-09-24. [^25]: The dashboard's SIP options status can be Active (OPTIONS arriving on a regular interval), 'Warning, no SIP options' (the SBC is configured to send them but none have ever been seen), or 'Warning, SIP Messages aren't configured' (OPTIONS trunk monitoring is off). Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), section 'The SBCs tab', bullet 'SIP options status', list of possible values. Checked 2026-09-24. [^26]: An SBC that stops sending OPTIONS on the regular interval is demoted, meaning it is not tried first. If the other SBC in the route cannot deliver the call, the demoted SBC is tried again before the call fails. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), section 'Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) options messages', paragraphs on demotion (sbc1/sbc2.contoso.com example). Checked 2026-09-24. [^27]: The Direct Routing FailoverResponseCodes setting (default 408, 503, 504) applies to responses to an SBC-terminated initial INVITE. It does not concern OPTIONS. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'SBC settings', table row 'Failover response codes / FailoverResponseCodes'. Checked 2026-09-24. [^28]: FailoverTimeSeconds defaults to 10 seconds. An outbound call the gateway does not answer within that time is routed to the next available trunk, or dropped if there is no other trunk. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'SBC settings', table row 'Failover times (seconds) / FailoverTimeSeconds'. Checked 2026-09-24. [^29]: When two or more SBCs in one route are healthy and have equal priority, Direct Routing spreads calls between them with a Fisher-Yates shuffle. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), section 'Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) options messages', last paragraph. Checked 2026-09-24. [^30]: The 180-second clause in Microsoft's OPTIONS frequency rule contradicts itself as written ('more or less frequent'). Read together with the three-minute health window on the monitoring page, the likely intent is that an SBC sends OPTIONS no more often than every 60 seconds and no less often than every 180 seconds (inferred). Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'Considerations', SIP OPTIONS bullet; read against ms-learn-dr-monitor section 'Monitoring availability of Session Border Controllers...'. Checked 2026-09-24. [^31]: Microsoft's SBC connection guidance says SIP OPTIONS pings MUST NOT be sent more often than one transaction every 60 seconds per configured trunk per endpoint, and adds a second clause that refers to 180 seconds. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'Connect the SBC to the tenant' > 'Considerations', bullet on SIP OPTIONS pings. Checked 2026-09-24. [^32]: In the hosted (multi-tenant carrier) model, only the hosted SBC should send SIP OPTIONS, and the status of SBCs in a derived trunk follows the main SBC. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), section 'Overview of the SIP options process', Note. Checked 2026-09-24. [^33]: The dashboard's per-SBC detail view has a 'SIP options last checked' field showing when OPTIONS were last received from that SBC. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), section 'Detailed information for each SBC', bullet 'SIP options last checked'. Checked 2026-09-24. [^34]: When a route contains several SBCs for a user, Direct Routing uses the OPTIONS information received from each SBC when choosing where to send the call. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), section 'Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) options messages', paragraphs 1-2. Checked 2026-09-24. [^35]: Microsoft describes the Direct Routing OPTIONS exchange in this order: the SBC opens TLS to the SIP proxy FQDN, the SBC sends OPTIONS, the proxy identifies the SBC FQDN and answers 200 OK on the same TLS connection, the proxy sends OPTIONS to the Contact FQDN, the SBC answers 200 OK, and the SBC is marked Active in the Teams admin center. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), section 'Overview of the SIP options process', bullets 1-7. Checked 2026-09-24. [^36]: An SBC that sends OPTIONS to fixed IP addresses rather than to the SIP proxy FQDNs can show as intermittently inactive, because those addresses can move to another datacenter during maintenance or outages. Microsoft says to send OPTIONS to FQDNs only and to configure all three proxy FQDNs. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), section 'SIP options issues' > 'SBC status is intermittently inactive', first bullet. Checked 2026-09-24. [^37]: For Microsoft 365, Office 365 and GCC, Direct Routing's SIP connection points are sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com, and the SBC signals to the Microsoft SIP proxy over SIP/TLS on port 5061. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), sections 'SIP signaling: FQDNs' and 'SIP signaling ports'. Checked 2026-09-24. [^38]: When Direct Routing receives OPTIONS from an SBC, it starts sending its own OPTIONS to the SBC FQDN given in the Contact header of those incoming OPTIONS. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'Verify the SBC connection' > 'Validate SIP options'. Checked 2026-09-24. [^39]: When the Microsoft SIP proxy receives OPTIONS from an SBC, it looks for a known tenant's SBC FQDN in the Record-Route header first and falls back to the Contact header. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), section 'Overview of the SIP options process', bullet 3. Checked 2026-09-24. [^40]: Teams Direct Routing monitors SBC health using the SIP OPTIONS messages the SBC sends, and the tenant administrator does not need to do anything to turn this monitoring on. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), section 'Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) options messages', first paragraph. Checked 2026-09-24. [^41]: The SBC setting SendSipOptions ('Send SIP options' in the Teams admin center) defaults to True, and Microsoft strongly recommends leaving it on. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'SBC settings', table row 'Send SIP options / SendSIPOptions'. Checked 2026-09-24. [^42]: If Send SIP options is turned off, the SBC is left out of the Direct Routing Monitoring and Alert system. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'SBC settings', table row 'Send SIP options / SendSIPOptions', Description column. Checked 2026-09-24. [^43]: Devices that support DNS names can use sip-all.pstnhub.microsoft.com, which resolves to all possible SIP proxy IP addresses. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), section 'SBC status is intermittently inactive', Note under the three-FQDN list. Checked 2026-09-24. [^44]: Direct Routing treats an SBC as healthy if it sent OPTIONS at some point in the last three minutes, which is three times the regular one-minute interval. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), section 'Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) options messages', worked example (11:00-11:15 AM). Checked 2026-09-24. [^45]: To validate pairing, check on the SBC that its outgoing OPTIONS receive 200 OK, and that it answers the OPTIONS arriving from Direct Routing with 200 OK. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), section 'Verify the SBC connection' > 'Validate SIP options'. Checked 2026-09-24. [^46]: The dispatcher module's ds_ping_interval defaults to 0, and at 0 pinging of inactive gateways is disabled, so an operator has to set it for OPTIONS probing to run. Source: [DISPATCHER Module](https://www.kamailio.org/docs/modules/stable/modules/dispatcher.html), parameter ds_ping_interval. Checked 2026-09-24. [^47]: The Kamailio dispatcher module's ds_ping_method parameter, the SIP method used to probe destinations, defaults to OPTIONS. Source: [DISPATCHER Module](https://www.kamailio.org/docs/modules/stable/modules/dispatcher.html), parameter ds_ping_method. Checked 2026-09-24. [^48]: ds_probing_mode decides which dispatcher destinations get probed: 0 probes only destinations in PROBING state, 1 probes all, 2 probes only INACTIVE destinations with PROBING set, and 3 keeps probing PROBING destinations without changing their PROBING state. Source: [DISPATCHER Module](https://www.kamailio.org/docs/modules/stable/modules/dispatcher.html), parameter ds_probing_mode. Checked 2026-09-24. [^49]: By default the dispatcher module counts only 200 OK to a probe as success. The ds_ping_reply_codes parameter can add other codes. Source: [DISPATCHER Module](https://www.kamailio.org/docs/modules/stable/modules/dispatcher.html), parameter ds_ping_reply_codes. Checked 2026-09-24. [^50]: By default the dispatcher module marks a destination inactive after the first failed probe (ds_probing_threshold = 1) and active again after the first successful one (ds_inactive_threshold = 1). Source: [DISPATCHER Module](https://www.kamailio.org/docs/modules/stable/modules/dispatcher.html), parameters ds_probing_threshold and ds_inactive_threshold. Checked 2026-09-24. [^51]: An implementation that uses RFC 3261 default timers for an OPTIONS transaction with no response would give up after about 32 seconds (64 x 500 ms). Vendors can and do shorten this with their own retry and timeout settings (inferred). Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), derived from Section 17.1.2.2 and Table 4. Checked 2026-09-24. [^52]: Reachability and readiness to take calls are different things, and platforms map them differently. RFC 3261 lets a UAS answer OPTIONS with a non-200 status to show readiness, Unified CM counts only 408, 503 or no response as out of service, and Kamailio's dispatcher by default accepts only 200 OK. The same far-end reply can therefore keep a trunk up on one platform and mark it down on another (inferred). Source: [Cisco Unified Communications Manager Trunks (Session Management Edition deployment guide 8.6(1))](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/session_mgmt/deploy/8_6_1/trunks.html), section 'SIP OPTIONS Ping', read against rfc-3261-sip Section 11.2 and kamailio-dispatcher-module-stable parameter ds_ping_reply_codes. Checked 2026-09-24. [^53]: Per RFC 3261, a 200 OK to OPTIONS should carry Allow, Accept, Accept-Encoding, Accept-Language and Supported header fields describing the responder's capabilities. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 11.2. Checked 2026-09-24. [^54]: In SIP, the OPTIONS method asks a UA or server for its capabilities without setting up a session, and it can be sent outside a dialog. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 11 'Querying for Capabilities' and 11.1. Checked 2026-09-24. [^55]: RFC 3261 says the response to an OPTIONS should be the one an INVITE would get: 200 if the server would accept an INVITE, 486 Busy Here if it currently cannot take new sessions. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 11.2 'Processing of OPTIONS Request'. Checked 2026-09-24. [^56]: In RFC 3261, the timeout for a non-INVITE client transaction (Timer F) is 64*T1, and T1's default is 500 ms. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 17.1.2.2 and Table 4 (Appendix A timer values); T1 in Section 17.1.1.1. Checked 2026-09-24. [^57]: RFC 5626 defines a keepalive for connection-oriented transports in which the client sends a double CRLF and the server answers with a single CRLF. Source: [RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5626.html), Section 4.4.1. Checked 2026-09-24. [^58]: RFC 5626 says the upper bound for CRLF keepalive intervals should be 120 seconds, with 95 seconds as the lower bound. Source: [RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5626.html), Section 4.4.1. Checked 2026-09-24. [^59]: In RFC 5626, a Flow-Timer header in a successful registration response gives the number of seconds the server will wait without seeing keepalives. Source: [RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5626.html), Section 4.4. Checked 2026-09-24. [^60]: For connectionless transports such as UDP, RFC 5626 uses STUN Binding Requests over the flow as the keepalive, sent at random intervals of 24 to 29 seconds. Source: [RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5626.html), Section 4.4.2. Checked 2026-09-24.