Start with the question you are answering
A transaction follows a request and its responses. A dialog is a longer-lived relationship identified by Call-ID and local and remote tags. Several transactions can occur within that relationship. Neither unit is the same thing as an RTP stream.
Choose the scope before filtering a trace. “Did the peer answer this request?” calls for transaction evidence. “Does the peer recognize this ongoing conversation?” calls for dialog evidence. “Can the caller hear?” requires media evidence as well.
Keep INVITE acknowledgement rules distinct
The ACK for an INVITE failure is handled differently from the ACK for a successful INVITE. RFC 6026 also updates INVITE transaction handling after success so additional 2xx responses can reach the calling application and retransmitted requests can be absorbed appropriately. An old state diagram that immediately discards all transaction state after 2xx is incomplete.
When a trace repeats a successful response, inspect whether the corresponding acknowledgement arrives. Do not infer a new user call from every repeated message. Use the dedicated ACK guide for the acknowledgement path.
Build a scoped incident timeline
First group messages by the signaling leg you can actually observe. Within that leg, retain transaction matching information, request method and sequence number. Then group the related dialogs using their complete identifiers. A B2BUA can create a separate relationship on its other side.
For a failed hold operation, keep the original successful setup and the later change request. If you retain only the failed request, you can lose the state that explains why the peer rejected it.
Use the scope to choose the next investigation
A retransmission problem should lead you toward message delivery and transaction matching. A dialog-not-found response should lead you toward identifiers, routing and retained peer state. A successful change followed by silence should lead you toward the accepted SDP and media path.
Write the conclusion at the same scope as the evidence: this request completed, this dialog remained active, or these media packets arrived. That phrasing prevents a successful SIP response from becoming an unsupported claim about the entire telephone call.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: transaction and dialog definitions ↗
- IETF RFC 6026: corrected INVITE transaction handling ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.