A SIP trace can help explain what your phone or PBX sent and which response it received on an IllyVoIP call. Start with one owned attempt and a clear question, such as “Was the intended destination sent?” or “Which request received this rejection?” A collection of header names without the surrounding exchange is rarely enough.
1. Prepare a short, private trace
- Record the call time and timezone, direction, IllyVoIP line and Portal call reference if available.
- Capture or export only the relevant customer-side SIP exchange using your PBX’s supported diagnostic tools. Use the capture guide below if you need that setup.
- Keep an original private copy. In the shareable copy, remove credentials, authentication header values, unnecessary telephone numbers and private addresses.
- Use consistent replacement labels so the same call, address or tag remains recognizable across messages. Do not alter the original evidence to make it look like the example below.
2. Separate the request target from the identities
This deliberately abbreviated synthetic example shows selected fields, not a complete packet or an IllyVoIP trunk configuration. Example addresses are placeholders.
INVITE sip:destination@example.invalid SIP/2.0
Via: SIP/2.0/TLS 192.0.2.10;branch=z9hG4bK-example
From: "Example caller" <sip:caller@example.invalid>;tag=from-example
To: <sip:destination@example.invalid>
Call-ID: example-call@example.invalid
CSeq: 1 INVITE
Contact: <sip:line@192.0.2.10>The request URI identifies the request target. From and To carry logical identities; neither alone establishes the effective route or caller-ID authorization. Contact supplies a contact URI for signaling. It is not the RTP audio destination. For IllyVoIP caller-ID policy, use the dedicated caller-ID guide rather than copying identity headers from another provider.
3. Follow one exchange at a time
Use Call-ID to group the relevant SIP leg, CSeq to follow the method and sequence, and the Via branch to distinguish transactions. Dialog tags distinguish dialog relationships. A PBX can create another leg with different identifiers, so do not assume one Call-ID appears unchanged everywhere.
- Locate the request you are investigating and the responses that match it. Keep their order and timestamps.
- Read the status line on each response. A provisional response is not the same as the final outcome.
- If the trace contains another call leg, label it separately before comparing what entered and left your PBX.
- For a failure, preserve the final response and the matching request. For a successful setup followed by a problem, retain the relevant later exchange too.
The official RFC 3665 call-flow examples linked below are useful for learning how requests and responses fit together. They are explanatory protocol examples, not IllyVoIP server addresses or ready-to-use account settings.
4. Keep signaling, audio and Portal identifiers distinct
Media details can be carried in an SDP body, with connection and media descriptions distinct from SIP routing headers. Read those details only when the question concerns media negotiation, and compare them with the actual call symptoms. Seeing a plausible signaling Contact does not prove that audio can traverse the network.
In IllyVoIP, the Portal’s public call reference and the Voice API’s call_control_id serve different purposes from a SIP Call-ID. Save each in its own field if your integration uses all three. Never paste a packet Call-ID into a call-control operation or invent a mapping based on a similar-looking string.
5. Turn the trace into a useful support report
- State the user-visible symptom and the exact line and time. Include the Portal reference when it exists.
- Describe the observed sequence without asserting an unproven cause: for example, the PBX sent a request and received a particular response from a particular peer.
- Attach the short sanitized exchange and note any configuration change immediately preceding the issue.
- Keep passwords, API keys, session cookies and authorization values out of the report. Use a private support channel for any necessary account detail.
Do not change multiple headers until the trace looks like a generic internet example. IllyVoIP eligibility, incoming routing and caller-ID configuration still apply. The useful result of this exercise is a correctly correlated account-specific observation that guides the next check.
Related guides
- Capture a SIP call trace for IllyVoIP Support with Wireshark
- Investigate P-Asserted-Identity and caller-ID mismatches on an IllyVoIP trunk
- How to Read and Understand Your VoIP Call Reports (CDR)
Reference
Current instructions and technical reference: RFC 3261: SIP, RFC 3665: SIP call-flow examples, RFC 8866: Session Description Protocol.
Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.