# Calls that drop after about 30 seconds

Canonical: https://warmtransfer.net/knowledge/sip-calls-drop-30-seconds

Last verified: 2026-09-25

RFC 6026, published in September 2010, updates RFC 3261[^33]. It adds an Accepted state to both INVITE client and server transactions and specifies that an element sending or receiving a 2xx to INVITE must not destroy the matching INVITE transaction state[^6].

## Transaction mechanics and the 32-second signature

After RFC 6026, retransmissions of a 2xx response to INVITE are handled by the transaction user (the UAS core), not by the INVITE server transaction[^1]. A UAS core passes its 2xx response to the transport repeatedly, at an interval that starts at T1 seconds and doubles on each retransmission until it reaches T2 seconds[^2]. The INVITE client transaction must not generate the ACK for a 2xx response; the UAC core sends that ACK in a new transaction[^7]. 

RFC 6026 defines Timer L as 64*T1 for all transports, representing the time an INVITE server transaction stays in the Accepted state to cover how long a UAS core may retransmit the 2xx while waiting for an ACK[^41]. RFC 6026 also defines Timer M as 64*T1, which is the time an INVITE client transaction stays in the Accepted state waiting for 2xx retransmissions or for further 2xx responses from other branches of a forked INVITE[^42]. Under RFC 6026, a proxy must not forward a response for which it has no matching transaction state machine, preventing it from statelessly forwarding stray 2xx responses[^30].

Asterisk res_pjsip uses a default SIP timer T1 of 500 ms, with a minimum of 100 ms[^8]. Asterisk res_pjsip uses a default Timer B of 32000 ms (32 seconds), which is 64 times its 500 ms default T1[^9]. WarmTransfer's reading of the sources is that with the common T1 of 500 ms, 64*T1 is 32 seconds, meaning a call that is answered and then torn down by the called side about 32 seconds later matches the missing-ACK timeout rather than a session-timer expiry[^3]. However, sources disagree on how quickly a UAS tears down a call after a missing ACK; the OpenSIPS blog says 5 to 10 seconds, but 64*T1 with T1 = 500 ms gives about 32 seconds[^10].

## Routing and NAT causes of missing ACKs

In the field, a common cause of a missing ACK is a proxy that does not handle a NATed callee: the callee's private IP stays in the Contact of the 200 OK, causing the ACK to be sent to an unreachable address[^26]. In the field, applying NAT fix-ups too broadly can also cause a missing ACK, because rewriting the Contact of a reply from another proxy rather than an endpoint removes the routing information needed to reach the callee[^18]. For OpenSIPS, the blog advises calling fix_nated_contact() in onreply routes only for replies that come directly from endpoints, not from intermediate proxies[^29].

In the field, a 2009 3CX forum thread documented incoming calls dropping at exactly 32 seconds with logs stating "ACK is not received", where removing a port-forwarding rule and correcting the public IP used in the Contact resolved most occurrences[^4].

Under RFC 3581, a client may add an empty "rport" parameter to the top Via header to signal support for symmetric response routing[^35]. When a request carries rport, the server must set rport to the source port of the request and send responses to the IP in "received" and the port in "rport", following the NAT binding created by the request[^36]. RFC 6314, an Informational RFC from July 2011, assumes NATs without SIP-aware ALGs and notes that ALGs have limits, including requiring signaling and media to pass through the same device and failing with encrypted signaling[^34]. RFC 6314 also notes that NAT policy can close connections after a period of inactivity, pointing to RFC 5626 (SIP Outbound) keep-alives, rather than SIP signaling itself, as the way to keep NAT bindings open[^25]. Cisco recommends turning off SIP ALG or similar SIP-aware functions on routers and firewalls carrying Webex Calling traffic because some ALG implementations cause firewall traversal problems[^44].

Routing failures can also stem from header configuration:
- A proxy forwarding between interfaces with different properties, such as TCP to UDP or IPv4 to IPv6, cannot write a single Record-Route value that is correct for both sides of the dialog[^37].
- If a proxy inserts a numeric-IP Record-Route without a transport parameter, later in-dialog requests default to UDP under RFC 3263 procedures, which fail if the other side used TCP[^38].
- RFC 5658 recommends that a proxy insert two Record-Route header values—one for the inbound interface and one for the outbound interface—rather than rewriting Record-Route in responses[^17].

In Teams Direct Routing, the SIP proxy chooses the next hop for in-dialog requests from the top Record-Route first, falling back to the Contact header if no Record-Route exists[^22]. Direct Routing does not support an IP address in Record-Route or Contact; only an FQDN matching the SBC certificate's CN or SAN is supported, and an IP address or mismatched FQDN causes call failure[^23]. Microsoft recommends using only the Contact header when no proxy SBC is in use, requiring Record-Route only when a proxy SBC with Local Media Optimization must remain in the path; if both are present, their values must be identical[^21].

## Session timers compared to 30-second drops

RFC 4028 recommends a Session-Expires value of 1800 seconds (30 minutes)[^39]. The absolute minimum session interval under RFC 4028 is 90 seconds, and Min-SE defaults to 90 seconds when absent[^20]. If an element receives a Session-Expires value below its minimum, it responds 422 (Session Interval Too Small) with a Min-SE header stating its minimum[^5]. The Session-Expires header's refresher parameter ("uac" or "uas") designates the side responsible for refreshes[^32], and the refresher sends a refresh once half the session interval elapses[^31]. If the non-refresher receives no refresh, RFC 4028 states it SHOULD send a BYE slightly before expiration, with a recommended margin of the smaller of 32 seconds and one third of the session interval[^27]. RFC 4028 session timers negotiated with the "timer" option tag function even when only one party supports the extension[^28].

WarmTransfer's reading of the sources is that even at the RFC 4028 minimum interval of 90 seconds, a missed refresh ends the call at about 60 seconds (90 minus the smaller of 32 and 30 seconds), so a standards-conformant session-timer failure cannot explain a drop at about 30 seconds on its own, as session-timer drops usually appear at 15 or 30 minutes[^40]. 

The Teams Direct Routing SIP proxy always offers the session timer on non-bypass calls, does not offer it on media-bypass calls, and does not require the SBC to use it[^24]. 

In Cisco environments, the 2015 CallManager (Unified CM) default SIP Session Expires Timer is documented as 1800 seconds, placing refreshes at about 900 seconds (15 minutes)[^16]. Cisco identifies a common cause of drops at 15 minutes as firewall or router TCP timeouts being shorter than the SIP session expires timer, or network devices intercepting refresh messages[^14]. CUBE handles session refresh on each call leg independently; with "midcall-signaling passthru media-change", it consumes mid-call re-INVITEs locally and relays them to the other leg only when media changes[^12]. The CUBE "session refresh" command under voice service voip / sip adds a Session-Expires header to outbound INVITEs when absent on inbound INVITEs[^13]. A 2018 CUBE technote lists both recommended Session-Expires and default Min-SE as 1800 seconds and advises against lower settings[^11].

## Diagnosing dropped calls

In the field, the first diagnostic step for a suspected missing ACK is a SIP capture showing whether the ACK reaches the callee device, followed by checking that the Contact in the 200 OK contains an address reachable by the caller[^19].

To diagnose a session-refresh drop, Cisco specifies collecting SIP logs from both sides to check the refresher role in the initial INVITE, verify that a re-INVITE or UPDATE goes out before half the interval, confirm that Unified CM relays it to the far side, and check that responses come back[^15].

## See also

See also [SIP session timers](https://warmtransfer.net/knowledge/sip-session-timers).
See also [SIP retransmission timers and transaction state](https://warmtransfer.net/knowledge/sip-retransmission-timers).
See also [SIP transactions dialogs and call setup](https://warmtransfer.net/knowledge/sip-transactions-dialogs).
See also [NAT traversal ICE STUN and TURN](https://warmtransfer.net/knowledge/nat-traversal-ice).
See also [SIP capture and analysis with Wireshark and sngrep and HOMER](https://warmtransfer.net/knowledge/sip-capture-analysis).

## Applicability

The deployment model is not covered by the sources below. In the field, 3CX observations reflect 2009-era releases[^4].

## What remains uncertain

RFC 3261 raw-text verification of the no-ACK BYE rule is not covered by the sources below. Cisco ASA and FTD SIP inspection effects on Contact and Via and on call drops are not covered by the sources below. RFC 3261 Table 4 default T1 500 ms and T2 4 s are not covered by the sources below. Teams Direct Routing actual Session-Expires value on non-bypass calls is not covered by the sources below. Palo Alto Networks SIP ALG guidance is not covered by the sources below. Route sets built from Record-Route and ACK routing are not covered by the sources below. SBC session timer and ACK handling defaults are not covered by the sources below. Current Unified CM 15 SIP profile session expires timer documentation is not covered by the sources below.

## Sources

[^1]: After RFC 6026, retransmissions of a 2xx response to INVITE are handled by the transaction user (the UAS core), not by the INVITE server transaction. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Change to RFC 3261 section 17.2.1 (INVITE Server Transaction). Checked 2026-09-25.
[^2]: A UAS core passes its 2xx response to the transport repeatedly, at an interval that starts at T1 seconds and doubles on each retransmission until it reaches T2 seconds. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Section 8 (Exact Changes to RFC 3261), entry for RFC 3261 page 85, section 13.3.1.4. Checked 2026-09-25.
[^3]: With the common T1 of 500 ms, 64*T1 is 32 seconds. A call that is answered and then torn down by the called side about 32 seconds later therefore matches the missing-ACK timeout, not a session-timer expiry (inferred). Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Table 4 entries for Timer L/M (64*T1), combined with the Asterisk DEFAULT_TIMER_T1 = 500. Checked 2026-09-25.
[^4]: In a 2009 3CX forum thread, incoming calls dropped at exactly 32 seconds and the logs said 'ACK is not received'. Removing a port-forwarding rule and correcting the public IP used in the Contact fixed most occurrences (field report). Source: [Strange call disconnect after 32 seconds](https://www.3cx.com/community/threads/strange-call-disconnect-after-32-seconds.10827/), Posts by kliker (2009-07-24) and MatsW (2009-08-27/28). Checked 2026-09-25.
[^5]: When a Session-Expires value is below an element's minimum, the element responds 422 (Session Interval Too Small) with a Min-SE header giving its minimum. Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), 422 response definition (Session Interval Too Small). Checked 2026-09-25.
[^6]: RFC 6026 adds an Accepted state to both INVITE client and server transactions and says an element sending or receiving a 2xx to INVITE must not destroy the matching INVITE transaction state. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Sections describing client and server transaction changes (Accepted state). Checked 2026-09-25.
[^7]: The INVITE client transaction must not generate the ACK for a 2xx response; the UAC core sends that ACK in a new transaction. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Change to RFC 3261 section 17.1.1.2 (Formal Description). Checked 2026-09-25.
[^8]: Asterisk res_pjsip uses a default SIP timer T1 of 500 ms, with a minimum of 100 ms. Source: [asterisk/res/res_pjsip/config_system.c](https://github.com/asterisk/asterisk/blob/master/res/res_pjsip/config_system.c), res/res_pjsip/config_system.c, #define DEFAULT_TIMER_T1 and TIMER_T1_MIN. Checked 2026-09-25.
[^9]: Asterisk res_pjsip uses a default Timer B of 32000 ms (32 seconds), which is 64 times its 500 ms default T1. Source: [asterisk/res/res_pjsip/config_system.c](https://github.com/asterisk/asterisk/blob/master/res/res_pjsip/config_system.c), res/res_pjsip/config_system.c, #define DEFAULT_TIMER_B. Checked 2026-09-25.
[^10]: Sources disagree on how quickly a UAS tears down a call after a missing ACK. The OpenSIPS blog says 5 to 10 seconds, but 64*T1 with T1 = 500 ms gives about 32 seconds (disputed). Source: [Troubleshooting missing ACK in SIP](https://blog.opensips.org/2017/02/22/troubleshooting-missing-ack-in-sip/), Opening section describing the disconnect after missing ACK. Checked 2026-09-25.
[^11]: The 2018 CUBE technote gives both the recommended Session-Expires and the default Min-SE as 1800 seconds, and advises against setting the session timer lower. Source: [Troubleshoot Session Refresh on CUBE](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/213843-troubleshoot-session-refresh-on-cube.html), Section on Session-Expires and Min-SE values. Checked 2026-09-25.
[^12]: CUBE handles session refresh on each call leg independently. With 'midcall-signaling passthru media-change', it consumes mid-call re-INVITEs locally and passes them to the other leg only when media changes. Source: [Troubleshoot Session Refresh on CUBE](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/213843-troubleshoot-session-refresh-on-cube.html), Discussion of mid-call signaling and session refresh. Checked 2026-09-25.
[^13]: The CUBE 'session refresh' command under voice service voip / sip adds a Session-Expires header to outbound INVITEs when the inbound INVITE did not carry one. Source: [Troubleshoot Session Refresh on CUBE](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/213843-troubleshoot-session-refresh-on-cube.html), Configuration section on session refresh. Checked 2026-09-25.
[^14]: Cisco gives a common cause of SIP calls dropping at 15 minutes: the TCP timeout on firewalls or routers is shorter than the SIP session expires timer. It also says network devices that intercept refresh messages can cause the failure. Source: [Troubleshoot Call Failures on TC Endpoints Registered to Cisco CallManager](https://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/telepresence-codec-c40/119207-ts-failures-end-ccm-00.html), Section 'Problem: SIP Call Drop after 15 Minutes', cause paragraph. Checked 2026-09-25.
[^15]: To prove a session-refresh drop, Cisco says to collect SIP logs from both sides and check four things: the refresher role in the initial INVITE, that a re-INVITE or UPDATE goes out before half the interval, that Unified CM relays it to the far side, and that responses come back. Source: [Troubleshoot Call Failures on TC Endpoints Registered to Cisco CallManager](https://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/telepresence-codec-c40/119207-ts-failures-end-ccm-00.html), Section 'Problem: SIP Call Drop after 15 Minutes', solution steps. Checked 2026-09-25.
[^16]: The 2015 Cisco technote gives the CallManager (Unified CM) default SIP Session Expires Timer as 1800 seconds, which puts refreshes at about 900 seconds (15 minutes). Source: [Troubleshoot Call Failures on TC Endpoints Registered to Cisco CallManager](https://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/telepresence-codec-c40/119207-ts-failures-end-ccm-00.html), Section 'Problem: SIP Call Drop after 15 Minutes'. Checked 2026-09-25.
[^17]: RFC 5658 recommends that a proxy insert two Record-Route header values, one for the inbound interface and one for the outbound interface, instead of rewriting Record-Route in responses. Source: [RFC 5658: Addressing Record-Route Issues in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5658.html), Section 5. Checked 2026-09-25.
[^18]: Applying NAT fix-ups too broadly can also cause a missing ACK. Rewriting the Contact of a reply that came from another proxy, not from the endpoint, removes the routing information needed to reach the callee (field report). Source: [Troubleshooting missing ACK in SIP](https://blog.opensips.org/2017/02/22/troubleshooting-missing-ack-in-sip/), Section on root causes: 'Excessive NAT Handling'. Checked 2026-09-25.
[^19]: The first diagnostic step for a suspected missing ACK is a SIP capture showing whether the ACK actually reaches the callee device. Then check that the Contact in the 200 OK carries an address the caller side can reach (field report). Source: [Troubleshooting missing ACK in SIP](https://blog.opensips.org/2017/02/22/troubleshooting-missing-ack-in-sip/), Diagnostic approach section. Checked 2026-09-25.
[^20]: Under RFC 4028 the absolute minimum session interval is 90 seconds, and Min-SE defaults to 90 seconds when the header is absent. Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), Section 5 (Min-SE header field definition). Checked 2026-09-25.
[^21]: Microsoft recommends using only the Contact header, not Record-Route, when no proxy SBC is in use. Record-Route is needed when a proxy SBC with Local Media Optimization must stay in the path, and if both headers are used their values must be identical. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Contact and Record-Route headers considerations'. Checked 2026-09-25.
[^22]: For in-dialog requests, the Direct Routing SIP proxy picks the next hop from the top Record-Route first. If there is no Record-Route, it uses the Contact header. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Contact and Record-Route headers considerations'. Checked 2026-09-25.
[^23]: Direct Routing does not support an IP address in Record-Route or Contact. Only an FQDN that matches the SBC certificate's CN or SAN is supported, and an IP address or mismatched FQDN makes the call fail. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Use of FQDN name in Contact or Record-Route'. Checked 2026-09-25.
[^24]: The Teams Direct Routing SIP proxy always offers the session timer on non-bypass calls, does not offer it on media-bypass calls, and does not require the SBC to use it. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Session timer'. Checked 2026-09-25.
[^25]: RFC 6314 notes that NAT policy can close connections after a period of inactivity. It points to RFC 5626 (SIP Outbound) keep-alives, rather than SIP signaling itself, as the way to keep NAT bindings open. Source: [RFC 6314: NAT Traversal Practices for Client-Server SIP](https://www.rfc-editor.org/rfc/rfc6314.html), Section 3 (inactivity) and section 4.1.2 (keep-alive). Checked 2026-09-25.
[^26]: A common cause of a missing ACK is a proxy that does not handle a NATed callee: the callee's private IP stays in the Contact of the 200 OK, so the ACK is sent to an address it cannot reach (field report). Source: [Troubleshooting missing ACK in SIP](https://blog.opensips.org/2017/02/22/troubleshooting-missing-ack-in-sip/), Section on root causes: 'No NAT Handling'. Checked 2026-09-25.
[^27]: If the side that does not refresh receives no refresh, RFC 4028 says it SHOULD send a BYE slightly before the session expires. The recommended margin is the smaller of 32 seconds and one third of the session interval. Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), Section 10 (UAS/UAC behaviour on session expiration). Checked 2026-09-25.
[^28]: RFC 4028 session timers, negotiated with the 'timer' option tag, still work when only one party to the call supports the extension. Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), Introduction/overview of operation (backward compatibility). Checked 2026-09-25.
[^29]: For OpenSIPS, the blog advises calling fix_nated_contact() in onreply routes only for replies that come directly from endpoints, not from intermediate proxies. Source: [Troubleshooting missing ACK in SIP](https://blog.opensips.org/2017/02/22/troubleshooting-missing-ack-in-sip/), Solutions section. Checked 2026-09-25.
[^30]: Under RFC 6026, a proxy must not forward a response for which it has no matching transaction state machine, so it can no longer statelessly forward stray 2xx responses. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Change to RFC 3261 section 16.7 (Response Processing). Checked 2026-09-25.
[^31]: Under RFC 4028 the refresher sends its session refresh once half the session interval has elapsed. Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), Section 7.2. Checked 2026-09-25.
[^32]: The Session-Expires header's refresher parameter, 'uac' or 'uas', names the side responsible for sending session refreshes. Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), Section 4 (Session-Expires header field definition). Checked 2026-09-25.
[^33]: RFC 6026, published in September 2010, updates RFC 3261. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), RFC header (Updates: 3261; date). Checked 2026-09-25.
[^34]: RFC 6314, an Informational RFC from July 2011, assumes NATs without SIP-aware ALGs. It notes that ALGs have limits, including needing signaling and media to pass through the same device and failing with encrypted signaling. Source: [RFC 6314: NAT Traversal Practices for Client-Server SIP](https://www.rfc-editor.org/rfc/rfc6314.html), Section 3. Checked 2026-09-25.
[^35]: An RFC 3581 client may add an empty 'rport' parameter to the top Via header to signal that it supports symmetric response routing. Source: [RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing](https://www.rfc-editor.org/rfc/rfc3581.html), Client behaviour section. Checked 2026-09-25.
[^36]: When a request carries rport, the server must set rport to the request's source port. It then sends responses to the IP in 'received' and the port in 'rport', so the responses follow the NAT binding the request created. Source: [RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing](https://www.rfc-editor.org/rfc/rfc3581.html), Server behaviour section. Checked 2026-09-25.
[^37]: A proxy that forwards between interfaces with different properties, such as TCP to UDP or IPv4 to IPv6, cannot write one Record-Route value that is correct for both sides of the dialog. Source: [RFC 5658: Addressing Record-Route Issues in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5658.html), Section 3.2. Checked 2026-09-25.
[^38]: If a proxy puts a numeric-IP Record-Route without a transport parameter, later in-dialog requests such as ACK or BYE default to UDP under RFC 3263 procedures. When the other side of the proxy used TCP, those requests fail. Source: [RFC 5658: Addressing Record-Route Issues in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5658.html), Section 6.1, Figure 4. Checked 2026-09-25.
[^39]: RFC 4028 recommends a Session-Expires value of 1800 seconds (30 minutes). Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), Section 4 (UAC behaviour, Session-Expires recommendation). Checked 2026-09-25.
[^40]: Even at the RFC 4028 minimum interval of 90 seconds, a missed refresh ends the call at about 60 seconds (90 minus the smaller of 32 and 30 seconds). A standards-conformant session-timer failure therefore cannot, on its own, explain a drop at about 30 seconds. Session-timer drops usually appear at 15 or 30 minutes (inferred). Source: [RFC 4028: Session Timers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc4028.html), Section 10 combined with Min-SE minimum (section 5). Checked 2026-09-25.
[^41]: RFC 6026 defines Timer L as 64*T1 for all transports: the time an INVITE server transaction stays in the Accepted state, which covers how long a UAS core may retransmit the 2xx while waiting for an ACK. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Change to RFC 3261 section 17.2.1; Table 4 entry for Timer L. Checked 2026-09-25.
[^42]: RFC 6026 defines Timer M as 64*T1: the time an INVITE client transaction stays in the Accepted state, waiting for 2xx retransmissions or for further 2xx responses from other branches of a forked INVITE. Source: [RFC 6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests](https://www.rfc-editor.org/rfc/rfc6026.html), Table 4 entry for Timer M; change to RFC 3261 section 17.1.1. Checked 2026-09-25.
[^43]: Under RFC 3261, if a UAS retransmits its 2xx response to an INVITE for 64*T1 seconds without receiving an ACK, the dialog is confirmed but the session SHOULD be terminated with a BYE. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 13.3.1.4 (The INVITE is Accepted). Checked 2026-09-25.
[^44]: Cisco recommends turning off SIP ALG, or similar SIP-aware functions, on routers and firewalls carrying Webex Calling traffic, because some ALG implementations cause firewall traversal problems. Source: [Port Reference Information for Webex Calling](https://help.webex.com/article/b2exve/port-reference-information-for-cisco-webex-calling), Section 'SIP Application Layer Gateway'. Checked 2026-09-25.