Ryan Malloy 7fc037ec4a Agent thread 002: Initial 126s timer analysis ... New thread investigating 20-concurrent call teardowns at fixed 126s. ### Findings So Far: - sip_guardian: NO 126s timer (only 5s/10min timers found) - DialogManager: 10-min TTL, read-only tracking (doesn't close conns) - caddy-l4 proxy: NO explicit SetDeadline/timeout in proxy or dial code - No connection pools, goroutine limits, or concurrency-triggered teardowns ### Symptom Profile: - Dead-consistent 126s (not jittery) = hard-coded timer - Load-dependent (20-concurrent yes, 1-concurrent survives 150s+) - Treatment-independent (Echo = Wait both die) - Survives conntrack bump to 1800s on both hosts - TCP transport from Twilio ### Next Investigation: Need to check for: 1. Go net package TCP KeepAlive defaults 2. Asterisk PJSIP TCP transport settings 3. Whether this is an upstream (carrier or Twilio) timer Recommending bypass test (direct proxy without sip_guardian) to isolate whether it's caddy-l4 itself or something in our handler chain. See: docs/agent-threads/proxy-association-timer-126s/001-*		2026-06-23 14:21:20 -06:00
..
agent-threads	Agent thread 002: Initial 126s timer analysis	2026-06-23 14:21:20 -06:00
troubleshooting	Update case study: conntrack fix was defense-in-depth, not root cause	2026-06-22 16:16:29 -06:00