Recognize actual proxy forking
A SIP proxy can send an initial request toward multiple destinations. In a parallel attempt, more than one destination can be ringing at once. That does not establish how a particular PBX implements a ring group: a B2BUA may originate separate calls and present different signaling upstream.
Record whether you are observing the caller-to-proxy leg, a downstream branch or a PBX-created call leg. Draw the actual roles before interpreting repeated responses as duplicates.
Logical end-to-end late-answer example; the forking proxy and route set are omitted. ACK and BYE follow each dialog’s actual routing.
Track the answers as separate dialogs
Distinct successful responses from forked destinations can establish different dialogs, distinguished by their tags. The caller must acknowledge each successful response; an unwanted confirmed dialog is ended with BYE. CANCEL is for a pending attempt and cannot undo an answer that has already won a timing race.
The figure shows a simplified late-answer case. Actual routing may retain the proxy in the path. It omits provisional responses, cancellation and media so the separate acceptance and cleanup steps remain readable.
Investigate a phone that keeps ringing or a stray call
Collect both destination branches and the caller-side exchange. Record when each branch rang, answered, received cancellation or received termination. Synchronize capture clocks before comparing close events. The order in a merged trace can otherwise imply a race that did not happen.
If one destination remains connected after another is selected, inspect the acknowledgement and termination of that specific dialog. If a phone only displays ringing, compare its display with received signaling before assuming a live server-side call remains.
Verify the difficult timing cases
Use controlled destinations to test one answer, no answer, a busy branch and nearly simultaneous answers. Verify which participant is selected, what the unselected participant sees and whether all unused call state clears. Preserve the routing policy separately from the protocol trace.
Do not turn a timing workaround into an undocumented winner-selection policy. For a PBX ring group, validate the user-facing ring strategy and its separate call legs using the PBX’s own documentation as well as the SIP evidence.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: multiple successful responses and dialog cleanup ↗
- IETF RFC 6026: additional INVITE success responses ↗
- IETF RFC 5407: call-flow race conditions ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.