Reading and Understanding SIP in Xima CCaaS
How to obtain a SIP trace for a CCaaS call, read the messages and response codes in it, and work from a reported symptom to the part of the trace that explains it.
A SIP trace is the record of the signaling exchanged between the carrier, the UC platform, CCaaS, and the devices involved in a single call or registration. It is the most direct evidence available for a call that failed, a call that connected with no audio, or a SIP extension or phone that will not stay registered. This page covers where to obtain a trace, how to read the messages in it, what the common response codes mean, and how to go from a reported symptom to the part of the trace that explains it. No prior packet-level experience is assumed.
What a SIP Trace Is
SIP (Session Initiation Protocol) is the signaling protocol that sets up, modifies, and tears down a call. It carries the instructions about the call — who is calling, who is being called, what happened at each step, and where the audio should be sent. SIP does not carry the audio itself.
The audio travels separately over RTP (Real-Time Transport Protocol), on a different set of ports and often by a different network path. The addresses and ports RTP uses are negotiated inside the SIP messages using SDP (Session Description Protocol), a short block of text carried in the body of an INVITE and in the answer to it.
A SIP trace is a time-ordered record of those signaling messages as one system saw them. Reading one quickly answers three questions:
- How far the call got — whether it was offered, alerted, answered, or rejected, and which side ended it
- Who ended it, and why — the response code and the direction it travelled in name the party that refused, timed out, or hung up
- Where the audio was told to go — the SDP in each direction gives the address and port each side published for RTP
Clean Signaling, No AudioBecause signaling and media are separate, a call can look perfect in the trace and still be silent. Signaling that completes normally with no audio in either direction is one of the most useful findings a trace produces — it points the investigation at the media path rather than at CCaaS or the UC platform.
CCAC Web Phone CallsWhen an agent answers on the CCAC web phone, the leg between CCaaS and the agent's browser uses WebRTC rather than SIP: call setup travels over HTTPS/WSS and audio over WebRTC media. A SIP trace covers the carrier, UC platform, and CCaaS legs of the call. For audio issues on the web phone itself, see CCAC Troubleshooting.
Obtaining a SIP Trace
A CCaaS call usually crosses several systems — the carrier, the UC platform, CCaaS, and the agent's device — and each one can only trace the signaling it handled. Where a trace comes from depends on which leg of the call is in question.
| Source | What It Shows |
|---|---|
| UC platform | The carrier leg and the leg between the UC platform and CCaaS. Many UC platforms (for example, NetSapiens) provide a SIP flow per call from Call History in their portal; others provide traces through their own support team |
| SBC or on-premises phone system | The signaling as the customer's own edge device saw it, captured on that device or with a capture tool such as Wireshark — see SBC Guidelines |
| CCaaS | The signaling as CCaaS sent and received it. CCaaS-side traces are retrieved by Xima Support for specific calls named in a support ticket |
To locate the call on any of these systems:
- Identify the call in Cradle to Grave by its time, the external number, and the agent or skill involved
- Note the call's date, time and time zone, the external and dialed numbers, the direction, and its
Report Media ID - Use those details to locate the same call in the UC platform's call history, or include them in the support ticket so Xima Support can retrieve the CCaaS-side trace
Collect Call Details FirstCollect the call details from the end customer before looking for a trace. The minimum set is the call time with the time zone, the caller and dialed numbers, the direction (inbound or outbound), and the affected agent, extension, or device. Without a specific call, a trace cannot be found, and "it happens sometimes" cannot be traced at all.
Traces Are Not Retained IndefinitelyRetrieve or request the trace for a reported call as soon as the issue is reported, rather than at the end of an investigation, so the evidence still exists when it is needed.
Collect Multiple ExamplesA single call shows what happened once; three calls show whether the behavior is consistent, which device or route it follows, and whether it is tied to a time of day.
Anatomy of a SIP Message
Every message in a trace is either a request (a verb such as INVITE, REGISTER, ACK, BYE, or CANCEL) or a response (a three-digit code such as 180 Ringing or 486 Busy Here). Both are plain text, and both are built the same way: a first line, a set of headers, and sometimes a body.
Requests
| Request | Description |
|---|---|
| INVITE | A call is being offered. Carries the calling and called party, the routing headers, and an SDP body describing the media the sender supports and where to send it |
| REGISTER | A device or SIP extension is telling the platform where it can be reached. Registration traces are where calls-not-arriving and no-service issues are confirmed |
| ACK | Confirms receipt of a 200 OK to an INVITE. The call is established only once the ACK is exchanged |
| BYE | An established call is being ended. The direction of the BYE names the side that hung up |
| CANCEL | A call that was still ringing is being withdrawn before it was answered, usually because the caller gave up or another device answered first |
| re-INVITE | An INVITE inside an existing call, used to change the session. Appears at hold, resume, transfer, and when media is re-pointed mid-call |
| REFER | A transfer is being requested, naming the party the call should be sent to |
| OPTIONS | A keepalive or reachability check between SIP endpoints. Useful on trunk issues; noise on most call traces |
Headers Worth Reading
A real INVITE carries twenty or more headers. The following are the ones that answer questions. See SIP Header Fields for how CCaaS reads several of these for routing.
| Header | Description |
|---|---|
From and To | The calling and called identities as presented. Caller ID complaints are read here first, against what the account is configured to send |
Call-ID | The unique identifier for one call leg. Use it to keep legs apart when a call is forwarded, queued, or transferred and the trace shows several at once |
Contact | The address and port the sender says it can be reached at directly. On a registration, this is where calls to that device or extension are sent |
Via | The path the request took, newest hop first, and the transport in use (UDP, TCP, or TLS). Responses follow this path back |
CSeq | A sequence number plus the method. Pairs a response with the request it answers, and exposes retransmissions, which repeat the same CSeq |
User-Agent or Server | The make, model, and firmware of the device, or the identity of the far-end system. Confirms which device actually sent a message when several share one extension |
Expires | On a REGISTER, how long the registration is good for. Compare it against how often the device is actually re-registering |
Reason or the response reason phrase | Free text from the party that rejected or ended the call. On carrier-side failures this is often the only plain-language explanation available |
The SDP Body
SDP is the block in the body of an INVITE or a 200 OK that answers the question "where should the audio be sent, and in what format". Four lines carry almost all of the diagnostic value.
| SDP Line | Description |
|---|---|
c= (connection) | The IP address the sender wants RTP delivered to. A private address here on a device behind NAT, or a public address on a device that has no way of knowing one, is the single highest-value field in a no-audio investigation |
m=audio (media) | The port RTP will arrive on, and the list of codec payload types offered, in preference order |
a=rtpmap | Names each payload type — for example, PCMU or G722. Compare the offer against the answer to see which codec was actually agreed. See Voice Audio Codecs |
a=sendrecv, a=sendonly, a=recvonly, a=inactive | The media direction that was negotiated. A one-way audio complaint that shows sendonly or recvonly here was negotiated that way deliberately, which is a very different problem from media being lost in the network |
A Normal Call, Message by Message
Recognizing what a healthy call looks like comes first — most diagnosis is spotting where a trace stops matching this shape. The example below is an inbound call from the PSTN, through the carrier and the UC platform, to a CCaaS SIP extension, answered and then ended by the caller.
| Step | Message | Description |
|---|---|---|
| 1 | Carrier sends INVITE to the UC platform | The call is offered to the DID, with the caller's SDP attached |
| 2 | UC platform replies 100 Trying | The INVITE was received and is being processed. Stops the carrier retransmitting it |
| 3 | UC platform sends INVITE to CCaaS | The next leg, sent to the Contact address the CCaaS SIP extension published when it registered |
| 4 | CCaaS replies 180 Ringing | The call has been accepted for alerting. Relayed back toward the caller as ringback |
| 5 | CCaaS replies 200 OK with SDP | Answered. The SDP here is the answer to the offer, naming the codec chosen and where CCaaS wants RTP |
| 6 | ACK in each direction | Each leg is established. Signaling for call setup is finished |
| 7 | RTP flows | Audio, on the addresses and ports from the SDP exchange. This is the conversation |
| 8 | BYE, then 200 OK | One side hung up and the other confirmed. The direction of the BYE names who ended the call |
The INVITE, Annotated
The following shows the shape of the INVITE at step 3, sent from the UC platform toward CCaaS. Addresses and numbers are examples.
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 203.0.113.20:5060;branch=z9hG4bK6a1f2c
From: "WIRELESS CALLER" <sip:[email protected]>;tag=8841aa
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
User-Agent: UC-Platform
Content-Type: application/sdp
v=0
o=- 2890844526 2890844526 IN IP4 203.0.113.20
c=IN IP4 203.0.113.20
m=audio 24114 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecvReading it in order: the request line shows the call being sent to the extension's registered address; From carries the inbound caller ID the agent will see; the c= and m= lines say to send audio to 203.0.113.20 on port 24114; and a=sendrecv means two-way audio was offered. The 200 OK answers with its own c=, m=, and the single codec it accepted. Comparing those two SDP blocks is the whole of basic media diagnosis.
Follow One Call-ID at a TimeA call that passes through an IVR, a skill queue, or a transfer produces more than two legs, each with its own
Call-ID. Follow oneCall-IDat a time — trying to read every leg at once is the most common reason a trace looks incomprehensible.
Common SIP Response Codes
Responses are grouped by their first digit: 1xx is progress, 2xx is success, 3xx is redirection, 4xx is a failure at the requesting side, 5xx is a server failure, and 6xx is a global refusal. The following codes appear in day-to-day troubleshooting.
| Code | Meaning | What to Do With It |
|---|---|---|
100 Trying | Request received, being worked on | Normal. Its absence, with the INVITE repeating, means the request is not reaching the far end |
180 Ringing | The destination is alerting | Normal. Proof the call reached something prepared to ring |
183 Session Progress | Early media, such as carrier ringback or a network announcement, is being provided before answer | Normal on outbound calls. If a caller reports hearing a recorded message instead of ringing, the explanation is in the 183 and the SDP with it |
200 OK | Success. Against an INVITE it means answered; against a REGISTER it means registered | Normal. On an INVITE, read the SDP it carries |
401 / 407 | Authentication is being requested | Normal once, as a challenge the device then answers. A loop of challenge and retry means the credentials are wrong — for a CCaaS SIP extension, compare them against SIP Extensions |
403 Forbidden | Understood and refused | Check permissions and policy on the refusing side: dial permissions, blocked numbers, an unregistered or disabled account, or a carrier refusing the caller ID presented |
404 Not Found | The dialed destination does not exist where the request was sent | Check the digits as dialed, the dial plan or translation that acted on them, and whether the number is routed to the right place |
408 Request Timeout | No answer came back in time | Treat as a reachability problem rather than a call problem. Look at the network path, firewall rules, and whether the device or extension is really registered |
480 Temporarily Unavailable | The destination exists but nothing is available to take the call | Usually no device or SIP extension registered, or every device busy or in do not disturb. Check registration state first |
486 Busy Here | The destination is busy | Expected behavior. Becomes a finding only when the user says the line was free, which points at call appearance limits or a stale call on the device |
487 Request Terminated | The INVITE was cancelled before it was answered | Normal, and always paired with a CANCEL. Read the CANCEL to find out who gave up, and whether another device answered first |
488 Not Acceptable Here | The media offered was refused | Compare the codec lists in the two SDP bodies. A codec set that does not overlap with what the far end offers produces this — see Voice Audio Codecs |
503 Service Unavailable | The next hop refused or could not take the request | Note which side sent it. From the carrier on one destination only, it is a routing matter to escalate with examples rather than a site problem |
603 Decline | The call was refused outright | Often a user pressing decline, or a far-end policy such as call screening or spam blocking rejecting the caller ID |
Always Record the DirectionA response code describes what the sending party decided, not the underlying cause, and the party that sent it is as important as the code. A
503sent from CCaaS toward the UC platform and a503sent from a carrier toward the UC platform are different problems with different owners. Always record the direction alongside the code.
Reading a Trace by Symptom
Start from what was reported and go to the part of the trace that answers it, rather than reading the flow top to bottom.
| Reported Symptom | What to Look At in the Trace | What It Points To |
|---|---|---|
| One-way or no audio | Signaling completes normally through ACK. Compare the c= and m= lines in both SDP bodies, and the negotiated direction attribute | A private address or an unexpected port in the SDP means media was aimed somewhere it could not be delivered. Clean signaling with no media is a network path or NAT problem, not a platform one |
| Calls do not reach CCaaS or the agent | Whether an INVITE was sent toward the CCaaS SIP extension or device at all, the address in its Contact, and whether a 180 came back. A 480 with no further leg is decisive | No INVITE means routing or registration. An INVITE with no response means the destination was unreachable at its registered address |
| SIP extension or phone keeps losing registration | REGISTER frequency against the Expires value, whether the source address and port change between registrations, and any repeating 401 or 407 challenge | Re-registering far more often than configured, or a port that moves each time, points at a short NAT timeout or SIP inspection on a firewall. A repeating challenge points at credentials |
| Calls drop at a consistent time, often around 30 seconds | Whether the ACK was received, and which side sent the BYE and when | A missing or misdirected ACK, or a session timer expiring, both show here. A consistent drop interval is a signaling path problem rather than a quality problem |
| Outbound call to one specific number fails | The digits in the request line as the carrier received them, and the response code and reason phrase the carrier returned | Altered digits point at a dial plan or translation. A carrier 403, 404, or 503 on one destination only is a carrier routing matter to escalate with examples |
| Caller ID is wrong on outbound calls | The From header on the leg sent to the carrier, and any identity headers alongside it | If the correct number was sent, the name or number the far party saw was substituted downstream, which is a carrier or caller ID database matter rather than a configuration one |
| Long delay before the call connects | The timestamps between the INVITE, the 100, and the first 180 or 183, and any INVITE retransmissions with the same CSeq | Retransmissions mean messages are being lost on the path. A gap before the far end responds, with no retransmissions, is delay at the far end |
| Suspected SIP ALG on the customer network | Contact and Via values that do not match where the packet actually came from, and SDP addresses or ports the device could not have written itself | Something on the path is rewriting SIP in transit. SIP ALG should be disabled on the customer's router or firewall |
Compare a Working CallPull a trace for a call that worked as well as one that failed, from the same site and ideally the same device or extension. The difference between the two is usually visible in one or two fields, and it is far faster to find than reading a failed call on its own.
What a Trace Cannot Show
Knowing the limits keeps an investigation from stalling on evidence that was never going to be there.
- It shows what one system received, not what the device sent. Anything on the path between the two can alter a message. A trace points at that; it does not prove it. Confirmation comes from the device configuration, or from a capture taken at the site.
- It is signaling, not audio. Choppy, robotic, or distorted audio is caused by loss, jitter, and delay on the RTP path, and a trace of clean signaling will not explain any of it.
- It covers one call. Intermittent faults need several traces across different times and devices before a pattern is safe to act on.
- It does not describe the local network. Bandwidth limits, double NAT, aggressive firewall rules, and short NAT timeouts are inferred from their effects, never read directly.
Sharing a SIP Trace
The complete flow is preferred over a screenshot or a pasted excerpt, because it gives the reviewer every message for the call.
- Export or share the full trace from the system that captured it — a shared link from the UC platform's call history where available, or the capture file from an SBC or capture tool
- Add it to the support ticket with one line saying what that call is an example of and what the customer experienced on it
- Repeat for each example call, so each trace has its own description
Treat Traces as Customer DataA shared trace link or capture file exposes the full flow for that call, including the numbers involved. Share traces through the support ticket rather than in open channels.
Who Does What
| Partner or Administrator | Xima Support |
|---|---|
| Collects specific example calls from the end customer, with time, time zone, numbers, direction, and the affected agent or device | Reviews the CCaaS-side records and signaling for the specific calls and registrations identified |
| Retrieves the trace from the UC platform or the site's SBC and reads it against the symptom | Interprets a trace with the partner or administrator when the finding is unclear, and confirms what CCaaS saw |
| Resolves findings that sit on the customer network, including SIP ALG, NAT, firewall rules, and bandwidth | Advises on next steps when the evidence points beyond the local network, including the UC platform or carrier |
| Shares the trace and findings in the ticket | Does not have access to customer premises equipment, and does not contact the end customer or their internet provider on the partner's behalf |
When to Escalate to Xima Support
Escalate when the trace shows a failure on the CCaaS, UC platform, or carrier side, when the trace and the customer's description disagree, or when the local network has been ruled out and the symptom continues. Include the following when submitting a ticket:
- The CCaaS hostname (
<hostname>.xima.cloud), the UC platform in use, and the affected agents, extensions, or phone numbers - Two or three example calls with date, time, time zone, direction, the numbers involved, and the
Report Media IDfrom Cradle to Grave, each with its trace where one is available - What the customer experienced on those calls, and what was expected instead
- The response code and the direction it travelled in, if the call failed
- What has already been read in the trace, and what was concluded from it
- Phone make, model, and firmware, and whether the issue affects one device or every device at the site
- Router or firewall make and model, and the state of SIP ALG if the symptom involves audio or registration
- A trace for a working call from the same site, where one is available
Updated about 10 hours ago