Markets open
Sign in
A smiling professional answering a call on a desk phone at a light wood desk beside a window
Support

Reacha human

For the things only we can see: what our edge received, why a call failed, and what a route did with your traffic.

Open a ticket

What you were doing, what you expected, and what happened instead. Send those three and the first reply can be an answer rather than a question.

Email
support@packetexchange.io
One inbox for support, wholesale and volume. We route it internally.
Hours
Staffed 24/7. Most messages are answered within a couple of hours.
Order of work
Traffic in trouble goes ahead of everything else. Commercial and account questions are worked in turn.
Route issue

Raise it against the seller from the failed call in your dashboard: the cause, SIP code and time travel with the report, and the seller only ever sees a pseudonymous handle, never your identity.

Open reports
Troubleshooting

Before you open a ticket

Four things worth checking first. Each has a specific symptom, so each is quick to rule out.

My digest authentication looks correct but keeps getting challenged. Why?

Almost always the realm. Ours is always 5.9.65.215, on both addresses, never your own host.

CheckCorrect valueCommon mistake
Realm5.9.65.215Using your own host, or changing it for the secondary address
UsernameBare valueAppending @domain
qopOmit itSending qop=auth, which we do not offer
REGISTERNot requiredRegistering first; a trunk answers the challenge per call

A hash computed over any other realm cannot match. The symptom of a wrong realm is specific: a correct-looking response, challenged again.

My app sends all traffic from one IP. How do you know which customer a call belongs to?

By the SIP username the call authenticates with, not by the caller ID.

CheckCorrect setupCommon mistake
AttributionThe SIP auth username on the callExpecting us to read the caller ID
Per customerA sub-account each, authenticated with its own SIP credentialsSharing one set of credentials across customers
Your softswitchSet the SIP auth username and password per call, over one shared trunkSending every call under the trunk's own credentials
Your IP whitelistAsk us to remove your sending IPLeaving it in place: the IP match wins and every call bills your operator account

The whitelist is the one that surprises people. Moving to per-customer credentials is the moment that entry has to go, or the IP keeps winning.

Where do I get a sub-account's SIP password?

Once, in the response that creates the sub-account. There is no way to read it back afterwards.

MomentWhat you getWhat to know
At creationThe SIP password and the API key, in the responseWe generate it. You do not set it.
Any time afterNothingIt cannot be read back later.
If you lose itPOST /application/sub-accounts/:id/sip-passwordThe new one is returned once, and the old password stops working immediately.

Store it at the moment you create the sub-account, or plan on rotating it. Those are the only two options.

Why does a destination say “not served” when the route covers it?

A rate deck can mark individual destinations as not served, and we refuse those calls rather than bill them.

A rate many times the deck average is a refusal in disguise.

It usually means the carrier prices that destination punitively instead of actually carrying it. Refusing protects you from a misdial costing a hundred times what you expected.

To serve it, you need a carrier that genuinely covers it.

How listing, buying, billing and settlement work is answered in the help centre.

Help centre