Follow an IllyVoIP SIP call from INVITE to hangup

A SIP trace explains how a call was set up and cleared. Start with one known IllyVoIP call and follow its signaling in time order. Compare it with the call record and audio evidence; signaling alone cannot prove that both people heard each other.

1. Find the call and collect the right evidence

1. In IllyVoIP call history, identify the attempt by time, timezone, direction and destination. Record its call reference and reported result.
2. If you manage the connected PBX, obtain its existing SIP log or an authorized trace for that time. Portal call history is not a packet capture.
3. Keep the original evidence privately. Make a sanitized copy for sharing, removing authentication, private addresses where unnecessary and customer numbers.
4. Determine which leg the trace covers: your phone to PBX, PBX to IllyVoIP, or another authorized hop.

Different legs can use different Call-ID values or negotiated media addresses. Do not join two calls solely because their destinations match. Use timestamps, dialog information and the PBX’s own correlation where available. An encrypted connection may not expose readable signaling in a network capture; use authorized application logs instead of disabling transport security.

2. Recognize a normal answered exchange

Illustrative successful dialog, not a captured customer call:
Caller                         Called side
  | -------- INVITE ----------> |
  | <------- 100 Trying ------- |  optional provisional response
  | <------- 180 Ringing ------ |  provisional response
  | <------- 200 OK ----------- |  successful INVITE response
  | -------- ACK -------------> |
  |       media conversation    |
  | -------- BYE -------------> |  either side may end the dialog
  | <------- 200 OK ----------- |  response to BYE

Read the method associated with each response. A 200 response to REGISTER, OPTIONS or BYE is not the same as a 200 response to the call’s INVITE. The CSeq method helps distinguish them. A 100 response means processing has begun; 180 indicates ringing, while 183 can carry session progress and early-media information. Neither provisional response proves the person answered.

3. Check the final INVITE result

1. Locate the final response for the intended INVITE transaction.
2. For a successful response, find the corresponding ACK and the selected dialog.
3. For an unsuccessful attempt, record the final response and any explanatory Reason information as observed.
4. If your PBX tried another destination or route, follow that separate attempt rather than treating its messages as one uninterrupted dialog.

Authentication challenges can be followed by an authenticated request. Retransmitted messages are not automatically extra billed calls. Interpret either case in the surrounding sequence. Do not conclude that a customer is unreachable from a single response without checking the IllyVoIP call result and any subsequent attempt.

4. Distinguish canceling from hanging up

CANCEL applies to a pending request, such as an unanswered INVITE. BYE ends an established dialog. A canceled attempt can show a successful response to CANCEL and a separate final response to INVITE. If an answer and cancellation cross in flight, the complete sequence matters. Keep those messages when escalating instead of attaching only the last status line.

5. Investigate media separately

Once signaling establishes the call, inspect the negotiated SDP and authorized RTP evidence for audio problems. Compare addresses, ports, payload mapping and packet flow in both directions. A clean INVITE/200/ACK exchange does not rule out blocked RTP, a microphone problem or one-way audio. Do not change codec, NAT and firewall settings simultaneously; preserve a reproducible baseline.

6. Send a focused support report

Include the IllyVoIP call reference, exact time and timezone, direction, connected PBX or phone, expected outcome and observed outcome. State which leg the trace represents and the first unexpected message. For a disconnect, identify which observed side sent BYE and when, without assuming that this alone establishes the business reason. Share sanitized evidence through Support rather than posting raw SIP logs publicly.

Related guides

• Diagnose choppy IllyVoIP calls: jitter, packet loss and network load
• Check RTP payload types against SDP when IllyVoIP audio fails

Reference

Current instructions and technical reference: RFC 3261: SIP, RFC 3665: SIP call-flow examples.

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