Telephony and SBC
This page is for partners and for the administrators of the SIP trunk and the session border controller (SBC) connected to Graia CCaaS. Most telephony problems reported to support were caused outside Graia CCaaS: by the customer's own SBC or by the carrier. The SIP trace shows which side it is, so start there.
:::note Graia CCaaS connects to your SBC or carrier only Graia CCaaS has no connection to Microsoft Teams or to any other phone system your agents use. When agents answer calls in an external voice application, such as Teams or a desk phone, Graia CCaaS calls the agent's phone number through your SBC or carrier, and your own setup delivers the call from there. Problems after your SBC are outside Graia CCaaS: see Agents who answer in an external voice application. :::
Start with the SIP trace
Before you assume a platform fault, find out who rejected or ended the call. Every call to an agent and every outbound call has its own SIP signalling, and the response code and the sender tell you where to look.
- Your SBC or carrier logs: look for the INVITE and the final response. If your SBC or carrier sent the error, the fix is on your side.
- Graia support: can look up the call in the platform's SIP traces and send you the call flow and the packet capture, for example to forward to your carrier or SBC provider. Give the date and exact time with the time zone, the caller number, the channel number and the agent.
- Portal: calls an agent didn't get show up in Task History (Historical Reports › Tasks). Use them to find examples with exact times.
:::caution Report quickly Graia CCaaS keeps SIP traces for about 10 days. After that, a call can no longer be investigated at signalling level. Reproduce and report problems while they're fresh. :::
SIP responses seen in support cases
| Response | Who usually sends it | What it usually means | What to check |
|---|---|---|---|
403 Forbidden | Your SBC or carrier | The INVITE isn't accepted: unknown source, wrong trunk authentication, or the agent's number isn't set up behind your SBC. | Allowed sources on both sides, trunk credentials, the agent's number in your own phone system. |
404 Not Found | Graia CCaaS (inbound) or your SBC (outbound) | Inbound: the called number isn't assigned to any channel. Outbound: your SBC has no route for the call or the agent leg. | The To number against the channel numbers; outbound routing on your SBC. |
408 Request Timeout | Either side | The INVITE got no answer at all. | Is the far end up? Are the SIP ports open? Is it sending to the right address? |
480 Temporarily Unavailable | Carrier or your SBC | The carrier or SBC bounced the call, or the agent's voice application is unreachable. | Carrier status; SBC logs for the rejected INVITE; the agent's voice application. |
481 Call/Transaction Does Not Exist | Either side | Often a follow-up to a lost or fragmented message, for example a re-INVITE too large for one packet. | SDP size and MTU (see Connect an SBC or SIP trunk). |
486 Busy Here | Graia CCaaS or the far end | Inbound: the number in the To field isn't a channel number. Outbound: the called party or your SBC returned busy. | Add the number as an alternative number on the channel. |
487 Request Terminated | Graia CCaaS | The call rang but nobody answered before the RONA timeout, so the agent leg was cancelled. | Why the agent didn't see or answer the call in their voice application. |
488 Not Acceptable | Either side | The media offer (codecs) wasn't accepted, or the called number didn't match. | The codecs offered; that the called number matches the channel number exactly. |
500 Server Internal Error | Usually your SBC | Internal fault on the device that sent it. | The SBC's health and logs. |
502 Bad Gateway | Graia CCaaS | The call reached the passive voice instance, which rejects it so your SBC retries the other address. | That your SBC fails over to the second address (see Active and passive voice instances). |
503 Service Unavailable | Usually your SBC or carrier | The device is overloaded, has its signalling groups down, or has no free channels. | SBC status and signalling groups; channel capacity. |
503 … CAC LIMIT | Your SBC or carrier | The call admission control limit is reached: no free concurrent channels. | Channel capacity (see Calls fail at busy times). |
603 Decline | Carrier, your SBC or Graia CCaaS | Carrier: the caller ID isn't in its allowed ranges. Your side: the agent declined the call in their voice application. Platform: a temporary routing problem. | Allowed caller ID ranges at the carrier; whether the agent declined; your SBC's retry list. |
604 Does Not Exist Anywhere | Your SBC or carrier | The agent's number isn't active on the carrier or partner platform. | That the agent's number is activated at the provider. |
All agents go to RONA or calls drop at once
When every agent of a team is put into RONA as soon as a call is offered, or calls drop the moment they connect, the most common cause by far is the customer's own SBC rejecting the calls to the agents. Graia CCaaS calls each agent through your SBC (the agent leg); if the SBC refuses that INVITE, the agent can't answer and goes to RONA.
Check: find two or three affected calls and look for the final response in your SBC logs, or ask Graia support for the trace. Typical responses are 403, 480, 500, 503 and 604, sent by the SBC itself.
Common causes, most frequent first:
- The SBC rejects or doesn't answer the agent leg – a configuration change, a stuck session, signalling groups left down after maintenance, or a node failure. Fix it on the SBC or with your SBC provider; switching to the second SBC node often restores service.
- The SBC still answers OPTIONS but rejects calls – for example with
503while its signalling groups are drained. Because OPTIONS keepalives still succeed, no failover happens. Bring the signalling groups back up. - Channel capacity is exhausted – see Calls fail at busy times.
- Expired or replaced certificates on your SBC – see Certificates on your SBC.
- The carrier, or the provider of your agents' voice application, has an outage – see the next section and Outage at your voice provider.
Who fixes it: your SBC administrator or SBC provider. Graia support can provide traces to prove where the rejection comes from.
While the problem lasts, agents can't leave RONA usefully because every new call fails the same way. Consider an emergency workflow with an announcement that you can assign to the affected channels.
No inbound calls reach the contact centre
The carrier or telephony provider has an outage
Callers hear "number doesn't exist", "number not in use" or nothing, and no call appears in Graia CCaaS – not even in the IVR.
Check: ask Graia support whether the calls reached the platform at all. If no INVITE arrived, the calls stopped before Graia CCaaS: at the carrier, at a number-hosting provider in the chain, or at your SBC. Check your trunk status and whether your trunk still answers SIP OPTIONS.
Fix: contact your carrier or telephony provider. Nothing can be changed in Graia CCaaS to route calls that never arrive.
Active and passive voice instances
Graia CCaaS runs each tenant on one of two voice instances: an active one and a passive one. You receive two SIP addresses. The passive instance rejects calls with 502 Bad Gateway so that your SBC tries the other address. After a failover, the roles swap.
Symptoms when this isn't set up correctly:
- All inbound calls fail with
502after a platform failover, while the "other" trunk works. - Inbound calls stop for a whole tenant because the SBC sends to one address only.
- Transfers from an external voicebot back to agents fail, because the voicebot's trunk points at one instance only.
Your SBC must:
- Have both addresses configured as one route with failover.
- Send SIP OPTIONS keepalives to both addresses and use their replies to decide which is reachable.
- Retry the second address on
502responses to INVITE. Add603to the retry list as well: during a temporary routing problem the platform can answer603 Decline. - Not depend on a single address being the active one forever.
The same applies to every system that sends calls to Graia CCaaS: carriers, SBCs, PBXs and external voicebots. Tenants that share one SBC should be on the same instance; ask Graia support if you connect one SBC to several tenants.
Who fixes it: your SBC or carrier administrator configures failover. Only Graia support can move a tenant to the other instance manually, for example to restore service while your SBC is being fixed.
The platform doesn't accept traffic from your SBC
If your SBC's OPTIONS to the platform get no reply and all calls fail with 502, for example after you added or replaced an SBC, the platform may not be set up to accept traffic from your SBC's public IP address. Contact Graia support with the public IP addresses of all your SBCs.
Calls to a number fail with 404, 486 Busy Here or "not available"
The call reaches Graia CCaaS, but the number in the To field doesn't match a channel number, so the platform answers 404 Not Found or 486 Busy Here. Callers hear a busy tone, "not available" or "number not found".
| Cause | Check | Fix |
|---|---|---|
| The number isn't assigned to any channel. | Search for the number under Voice › Channels. | Add it to a channel, and confirm your carrier routes it to Graia CCaaS. |
| The call was forwarded, and the To field still carries the originally dialled number. | Compare the To number in the SIP trace with the channel's Phone Number. | Add the dialled number as an alternative number on the channel (see Alternative inbound numbers), or have your carrier rewrite the To field to the channel number. |
The number format differs. For example a double +, a missing country code, or a national format. | Compare the exact digits in the trace with the channel number. | Send numbers in E.164 format (+ and country code). Align your SBC's number manipulation rules so the destination matches the channel number exactly. |
| The channel number contains an invisible character (such as a zero-width space) copied from another document. | One number in a range fails while its neighbours work. | Delete the number in the channel and type it again by hand, without pasting. |
Changes to channels can take up to 30 minutes to apply.
Outbound calls fail or drop immediately
Outbound calls in Graia CCaaS have two legs: the platform first calls the agent (the agent leg), then dials the customer (the customer leg). Either leg can be rejected. The agent typically sees the call window open for a second and close, or the call ring once and drop.
Causes, most frequent first:
- Your SBC rejects the call with
404,480or503. Check the SBC's outbound routing and logs for the rejected INVITE. - The carrier rejects the caller ID with
603 Decline, because the presented number isn't in the ranges it allows on your trunk. Ask the carrier to allow the number, or change which number you present (see The wrong number is shown). - The carrier rejects the number format. If calls work with
+and the country code but not in national format, ask the carrier to accept both, or dial in international format. - Short or emergency numbers fail. On the agent leg, the caller ID is the dialled number. Your SBC must accept an agent-leg call that comes "from" a three-digit number and route it to the agent. Otherwise it rejects it with
404. - The carrier or trunk provider rejects all calls with
403. Check the trunk registration and whether the provider's IP addresses changed.
If only one agent is affected while others can call, see Agent calls and connection: the cause is on that agent's side, not on the trunk.
If your carrier flags unusual international traffic from your trunk and no such calls appear in Graia CCaaS history, the calls came from other equipment on your side. Check your SBC and gateway logs.
The wrong number is shown
Caller ID, PAI and the "Use channel number as dialing number" setting
Use channel number as dialing number (Administration › Configuration › Voice) decides which number goes in the SIP FROM header of calls the platform places – including the calls to agents on behalf of inbound customers.
- Off:
FROMcarries the original caller (the customer, or the agent for consults). The channel number goes in aP-Asserted-Identityheader. - On:
FROMcarries the channel number on every leg except a consult to an agent.
See the full table of headers per call scenario.
This one setting has visible effects in several places, so test both inbound and outbound calls after changing it:
| Symptom | Likely cause |
|---|---|
| Agents see the channel name or number instead of the caller's number in their voice application. | The setting is on. Turn it off. |
| A third-party call recorder shows the channel number for every call, so you can't search recordings by caller. | The setting is on; the recorder reads the agent leg's FROM. Turn it off, or have the recorder read a custom SIP header. |
| Customers see an agent's direct number instead of the central number on outbound calls. | The setting is off, and your carrier doesn't use the PAI header. Turn it on, or add a rule on your SBC to present the central number. |
A redirect from a workflow to an external voicebot needs the channel number in FROM. | Keep the setting on, and pass the caller number in a custom SIP header. |
A custom PAI header requested from Graia overrides this setting. Whether the receiving phone shows any of these numbers also depends on the carrier.
The caller's number is wrong or hidden
Graia CCaaS shows the number it receives. If incoming calls show a number that isn't the real caller, or a fixed number, your carrier or SBC changed it before the call reached the platform. If forwarded calls to agents' mobiles show "Private number", the carrier on that leg hides the identity. Check the SIP trace: if the platform sent the correct FROM, ask the carrier.
After a carrier moves to E.164 caller numbers, a CRM that stores national-format numbers stops finding customers. Adjust the number transformation rules on your SBC, and test before rolling out.
Calls fail at busy times: 503 CAC limit
At peak times, calls to agents fail and agents go to RONA, while calls wait in queue. Your SBC or trunk returns 503 with a call admission control (CAC) message.
Each answered call uses two channels (customer leg and agent leg), and callers waiting in the queue use one each. As a rule of thumb, size your trunk and SBC licences at about 2.5 concurrent channels per agent. Callbacks and campaigns add to this.
Who fixes it: your carrier or SBC provider, by raising the channel limit or licences.
The IVR doesn't recognise keypresses
Callers press digits but the IVR plays its prompt to the end and takes the default path. If this happens only for callers from one country or one mobile network, a carrier in the chain isn't passing DTMF (or passes it in an unsupported way). Ask that carrier to fix DTMF transmission. Graia CCaaS can only control the DTMF it sends itself.
Agents who answer in an external voice application
Some tenants have agents answer calls in their own voice application, such as Microsoft Teams or a desk phone, instead of in the browser. Graia CCaaS calls the agent's phone number through your SBC or carrier. Everything after that – your SBC routing, your phone system and the agent's device – is your setup, and your telephony team or provider fixes it. Most problems show up as agents going to RONA.
Agents answer in the voice application
Agents answer in their voice application, not in the agent application. The agent application shows the call with only a hang-up button – that's expected. See Answer an inbound call.
If the call doesn't ring in the voice application, check the SIP trace first:
- Your SBC rejected the call (for example
403,480,604): fix the routing on your SBC. - The call rang (
180) and was cancelled after the RONA timeout (487): the call reached your side. Check the voice application and its settings with your telephony team: notifications, do-not-disturb, call forwarding, and whether a busy agent's second call is rejected. - The platform shows the call answered (
200 OK) but there's no audio: investigate on your side of the SBC.
The agent's phone number doesn't match
The agent's Phone Number in Agents › Agents must match the number your SBC routes to the agent exactly: international format with + and country code, no spaces, no extra characters. A mismatch makes the agent leg fail, or calls close automatically as soon as they arrive.
Outbound calls must start in the agent application
Agents must place calls – including callbacks – from the agent application, not from their voice application. A call started there isn't known to Graia CCaaS: the agent still shows as Available, gets routed calls they can't answer, and goes to RONA. If an agent must call from their voice application, they should set a break first. Routing uses only the agent's state in the agent application.
Transfers to directory contacts also go back out through your SBC. If they fail with a transfer error while transfers to channels work, check your SBC's traces for the rejected INVITE.
Certificates on your SBC
An expired certificate on one of your SBCs makes part of the calls fail – for example one call in three if you have several SBCs. Agents see the call in the agent application, but it never rings on their side.
- Route all calls to the healthy SBC.
- Renew the certificate on the affected SBC and bring it back.
- Restore the original routing.
When you renew a certificate, issue it with the same Subject and SAN values as the old one, and keep the SBC software up to date.
Outage at your voice provider
When the provider of your agents' voice application has an outage, agents go to RONA and can't take calls. Check the provider's service health. Use a queue timeout with an announcement, or an emergency workflow you can assign to channels, to inform callers.
Connect an SBC or SIP trunk
When you connect a new SBC, carrier or voicebot trunk, ask Graia support for the SIP connection details and check these points. Most onboarding problems come from one of them.
- Both instances: configure both voice instance addresses with OPTIONS keepalives and failover on
502and603(see Active and passive voice instances). - All source IPs: allow all the platform's source IP addresses on your SBC, firewall and any external voicebot trunk – not only the one you see in your first test.
- Tenant identification: Graia CCaaS identifies your tenant by a header in each INVITE, or by trunk credentials. Without the correct value, calls arrive as an unknown number or are rejected.
- Number format: send numbers in E.164 format (
+and country code). - Codec: G.711 A-law is supported.
- Transport, addresses and ports: use the values Graia support gives you for your tenant (UDP, TCP or TLS).
- Test number: have a number assigned to a channel before you test inbound calls.
SIP over TLS
For TLS, your SBC must trust the public root certificate authority that signs the platform's certificates, and the trunk is set up per tenant with credentials. Test inbound first, then outbound. A 403 Forbidden on the outbound test usually means the credentials or the tenant identification don't match.
OPTIONS challenged for authentication
The platform answers unauthenticated OPTIONS with an authentication challenge when the tenant is identified by header. A multi-tenant trunk without credentials then logs warnings related to missing authentication IDs. To avoid this, use per-tenant SIP credentials, or send the header of one tenant in your OPTIONS.
SDP too large: fragmented INVITEs
If calls transferred in from another system (for example another phone system's auto attendant) fail intermittently on the re-INVITE, often with 481, the INVITE may be larger than the 1500-byte MTU because the SDP offers many codecs. Fragmented UDP packets get lost or misdirected. Reduce the codec offer – for example to G.711 only – so each INVITE fits in one packet, or use TCP.
Related
- Troubleshooting overview
- Agent calls and connection
- Audio and network
- Workflows and routing
- The voice channel
- Use channel number as dialing number
- RONA timeout
- The Agents menu
- Handling inbound calls
- Launching outbound calls
- Agent auto-logout mechanism
:::info Review notes (remove before listing this page)
- Confirm the 10-day SIP trace retention is still current.
- The docs describe the "Use channel number as dialing number" off state as channel number in
P-Asserted-Identity; one ticket says it goes in aDiversionheader. Which is correct, or are both sent? - Confirm the active/passive model as described: two addresses per tenant, passive answers
502, SBCs should also retry on603. Is the newer voice environment (retry on the other instance without ringing response) live, and does it change this advice? - Confirm the connection requirements: tenant identification header (name it?), G.711 A-law, E.164. Addresses and ports are deliberately not published; support provides them.
- Confirm the ~2.5 channels per agent sizing rule can be published.
- Graia CCaaS has no Microsoft Teams direct routing; the Teams content was rewritten as customer-side "external voice application" guidance (2026-10-27). Confirm that wording, and that for these agents the Phone Number in Agents › Agents is the number calls are sent to.
- Confirm that an SBC address the platform doesn't accept causes
502and unanswered OPTIONS, and that support adds SBC addresses. - Confirm "Rejected" is visible as a task status or end reason in Task History, so administrators can find failed agent legs there.
- These sections come from only 1–3 support tickets each. Keep only the ones that are generally useful: invisible character in a channel number (1), SDP too large / fragmented INVITEs (1, also the
481row), DTMF (2), OPTIONS challenged for authentication (2), SIP over TLS (2), agent phone number mismatch (2), E.164 and CRM lookup (3), outbound calls from the voice application (3), carrier flags international traffic (0). :::
Was this page helpful?