Trace PRACK and reliable provisional responses on an IllyVoIP SIP call

PRACK acknowledges a reliable provisional SIP response while a call is still being set up. When investigating an IllyVoIP call that fails before answer, match the request and response fields rather than assuming every ringing message requires PRACK. This guide is for an administrator who can inspect an authorised trace from their own SIP endpoint or PBX.

1. Start with one existing call and its symptom

Record the time/timezone, public IllyVoIP call reference and what the caller observed: no ringing, missing early audio or a rejected setup. Use a narrow capture on the interface and call leg you control. Follow the existing Wireshark or sngrep guide rather than opening broad packet collection across unrelated customers.

Treat captures as sensitive. SIP can include telephone numbers, identities, addresses and authentication material. Store the original privately and share only the relevant sanitised messages through Support. TLS signaling will not become readable merely because you selected a SIP display filter; do not disable encryption just to make a capture easier.

2. Check whether reliable provisional responses were used

Find the initial INVITE and the matching provisional response. The 100rel option indicates support or a requirement for reliable provisional signaling, depending on whether it appears in Supported or Require. For the reliable response, inspect Require: 100rel and RSeq. A normal unreliable 180 or 183 is not missing a required PRACK simply because you cannot find one.

3. Match RSeq, RAck and the INVITE sequence

This shortened example is synthetic; it is not a complete wire message or evidence of a real call:

INVITE ...
Call-ID: example-call@example.invalid
CSeq: 42 INVITE
Supported: 100rel

SIP/2.0 183 Session Progress
Call-ID: example-call@example.invalid
CSeq: 42 INVITE
Require: 100rel
RSeq: 1001

PRACK ...
Call-ID: example-call@example.invalid
CSeq: 43 PRACK
RAck: 1001 42 INVITE

SIP/2.0 200 OK
CSeq: 43 PRACK

The RAck values refer to the provisional response’s RSeq and the acknowledged INVITE’s CSeq number and method. The PRACK request has its own CSeq. Also compare Call-ID and dialog tags so you do not join messages from different forked branches or call legs.

4. Keep PRACK separate from the final call result

A successful response to PRACK acknowledges that transaction. It does not mean the INVITE was answered or that RTP audio reached the caller. The final INVITE response and its ACK are separate messages. Likewise, a 183 with SDP can describe early media without proving either reliable-provisional negotiation or audible sound.

If early audio is the symptom, compare the signaling result with the existing early-media and RTP troubleshooting guides. Do not change codec, firewall and PRACK settings simultaneously; that makes it difficult to identify which part affected the outcome.

5. Locate the missing or mismatched exchange

1. Check that the capture includes both directions and the relevant signaling transport. A one-sided trace can make a valid response appear absent.
2. Compare the reliable provisional response and the corresponding PRACK on the same observed leg. Inspect RAck values and dialog identifiers.
3. Look for the response to PRACK and any repeated provisional messages. Keep retransmission timing with the trace; do not label every repetition a new call.
4. Inspect the final INVITE result separately. A PBX or intermediary can terminate one leg and originate another with different identifiers.
5. If the endpoint exposes a documented 100rel setting, record its current value and version. Do not toggle it blindly or copy another provider’s required setting.

6. Send evidence that answers one question

Give Support the public call reference, time, endpoint/PBX version, symptom and a sanitised sequence showing the INVITE, reliable response, PRACK and relevant final result. State where the capture was taken. “PRACK not visible on my PBX-facing leg” is a supported observation; “the destination carrier never sent it” requires evidence from another leg. After a reviewed configuration change, verify setup and audio separately with an authorised call.

Related guides

• Capture a SIP call trace for IllyVoIP Support with Wireshark
• Capture and inspect an IllyVoIP SIP call with sngrep
• Diagnose missing ringback and early audio on an IllyVoIP SIP call
• My SIP phone is registered, but outgoing calls fail

Reference

Current instructions and technical reference: RFC 3262: reliable provisional responses.

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