Skip to main content
Start with the symptom you see, then follow the checks in order.

​
The call button does not appear

​
The call fails straight away

​
Your platform answers with an error

When your platform refuses a call, the gateway records its answer: the status code, the reason text and the server that sent it. Use the code to find the cause.

​
The call rings for a long time and then fails

The caller hears ringing, then the call fails. In the gateway’s record, your platform answered “Ringing” and then either rejected the call (486, “Rejected” or “Busy”) or never answered. The gateway delivered the call, so look at your platform: the agent or queue it should reach may be unavailable, busy, at its concurrency limit, or out of credit. To keep callers from waiting, set up a fallback:
  1. Attach a backup trunk to the number (a second platform, a human queue or voicemail) with a later priority.
  2. On the main trunk, set a ring limit of a few seconds.
  3. Turn on try the next trunk so a rejection moves on too.
See Failover and fallback.

​
The call connects but there is silence

This is the most common problem. The call is established, but neither side hears anything.
1

Does your platform send audio first?

WhatsApp waits for the business side to send the first audio packet. Make your platform start sending a greeting, music or silence the moment it answers.
2

Is audio allowed through your firewall?

Allow the OneXtel gateway to send audio to the address and port in your SDP answer, and to receive from you.
3

Is the address in your SDP reachable?

Behind NAT, advertise your public audio address, not a private one.
4

Did you accept a codec the gateway offered?

Your SDP answer must pick a codec from your trunk’s accepted list.

​
Audio goes one way only

  • If the caller hears you but you do not hear them, check that your platform accepts audio from the gateway’s address and that symmetric RTP is on.
  • If you hear the caller but they do not hear you, check that your platform sends audio to the address and port in the gateway’s SDP, not to the signalling address.

​
Keypad tones are not recognised

Customers can press keys on a keypad during a call, and the key presses are passed to your platform as RFC 4733 telephone-events. If your platform does not react to them, check that:
  • your SDP answer includes telephone-event/8000, using the payload type from the gateway’s offer, and
  • your platform reads RFC 4733 events. It will not see the digits as audio tones or as SIP INFO messages.
See Protocols and media.

​
The call drops after a while

Check that your platform answers every re-INVITE and does not use a session timer that the call fails to refresh. If calls end at a regular interval, tell your account team the interval.

​
Reporting a problem

Send your OneXtel support contact:
  1. Your WhatsApp Business number.
  2. The date, time and timezone of the call.
  3. What the caller experienced, in a sentence.
  4. The X-WA-Number value from your platform’s log of the INVITE, if you have it.
OneXtel can then find the call record, which shows how far the call got, how it ended, and whether audio flowed both ways.

​
What OneXtel can see

For every call the gateway keeps a timeline of the SIP messages, for troubleshooting:
  • the call arriving from WhatsApp,
  • the INVITE sent to your trunk, with the request line and To header, and
  • each reply from your platform, with its status code, reason text and server name.
Audio, credentials and full caller numbers are not included, and the timeline is kept for 30 days. Ask your OneXtel support contact to look up a call by number and time.