Trace who cancelled an unanswered IllyVoIP SIP call

SIP CANCEL asks to stop a pending request, commonly an unanswered INVITE. To understand why an IllyVoIP call ended before answer, locate the CANCEL on the call leg you can observe and compare it with the INVITE response. A “cancelled” result alone does not tell you which person or system decided to stop the call.

1. Gather a focused existing example

Record the public call reference, time/timezone, called destination and the visible symptom. Was the caller still ringing, did the PBX play a timeout, or did someone press hang up? Use an authorised capture or PBX log from the interface you control. Avoid generating repeated paid calls just to reproduce a vague result.

Keep raw captures private. Remove credentials, authentication headers and unnecessary customer identities from any excerpt you share. Preserve the message direction, relevant sequence values and consistent redacted identifiers so the remaining evidence can still be correlated.

2. Match the cancellation to its pending INVITE

Compare Call-ID, CSeq and the transaction information, including the top Via branch, on the same observed leg. CANCEL uses the original INVITE’s CSeq number with the method changed to CANCEL. It is a separate transaction, so its response must be distinguished from the INVITE’s response.

The following is a simplified synthetic sequence, not a complete SIP message set:

Caller-side endpoint → next hop
INVITE ...
Call-ID: example-call@example.invalid
CSeq: 42 INVITE
Via: SIP/2.0/UDP example.invalid;branch=z9hG4bK-example

Caller-side endpoint → next hop
CANCEL ...
Call-ID: example-call@example.invalid
CSeq: 42 CANCEL
Via: SIP/2.0/UDP example.invalid;branch=z9hG4bK-example

Next hop → caller-side endpoint
200 OK / CSeq: 42 CANCEL
487 Request Terminated / CSeq: 42 INVITE

Caller-side endpoint → next hop
ACK ... / CSeq: 42 ACK

3. Read each result in context

A 200 response to CANCEL means that cancellation transaction was accepted for handling; it is not an answered telephone call. A 487 for INVITE commonly shows that the pending request was terminated, followed by the appropriate ACK. If the INVITE was already answered as cancellation crossed the network, inspect the final INVITE response and subsequent dialog handling instead of demanding a 487.

CANCEL does not end an already established conversation; BYE is used for established-dialog termination. Do not classify every early hangup as a CANCEL problem or assume an ACK belongs to PRACK just because both are acknowledgements in ordinary language.

4. Identify the sender on the observed leg

1. Use packet direction and addresses to identify which adjacent endpoint sent CANCEL on this leg.
2. Check that you are not looking at a CANCEL generated by a PBX for an unused fork while another branch continued.
3. Compare the endpoint/PBX log for user hangup, dial timeout, call forwarding or application cancellation at the same time.
4. Account for separate PBX or service legs: a back-to-back user agent can generate a new request and different identifiers rather than forward the same message unchanged.
5. State the limit of the evidence. The sender visible beside your capture point is not automatically the original person who requested cancellation.

5. Compare the call report without assigning unsupported blame

Open the relevant IllyVoIP call record and compare start time, duration, outcome and any failure explanation with the trace. A short duration or 487 does not prove that a recipient rejected the call. A PBX timeout can cancel an unanswered call even when no person touched the handset, while a destination rejection may have a different final response.

If a timeout is involved, record the configured value and where it applies before changing it. Extending every timer can keep unwanted calls ringing longer and does not repair an unavailable destination. Use the specific endpoint’s supported configuration and preserve a rollback value for any reviewed change.

6. Escalate with a concise timeline

Send Support the public call reference, observed leg, time, INVITE/CANCEL/final-response sequence and relevant PBX setting or log entry. Describe the symptom and expected behavior. Keep an answer-race or forked-branch case explicit. After a justified change, verify the complete result with an authorised call rather than treating a different SIP code alone as success.

Related guides

• Capture a SIP call trace for IllyVoIP Support with Wireshark
• Capture and inspect an IllyVoIP SIP call with sngrep
• Investigate SIP 487 Request Terminated on an IllyVoIP call
• How to Read and Understand Your VoIP Call Reports (CDR)

Reference

Current instructions and technical reference: RFC 3261: SIP transactions and cancellation.

Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.