Provide one precise call example
- Calling number
- Called number
- Inbound or outbound direction
- Exact date and time
- Timezone—preferably UK local time or UTC
- What the caller and recipient experienced
- Any displayed SIP response or release cause
Describe the connection
- SIP registration, SIP peering, IAX2 or built-in platform profile
- PBX, SBC or application name and version
- UDP, TCP or TLS transport
- Whether the problem affects every call or only a destination, number or direction
- Recent changes to routing, credentials, firewall or software
Include identifiers and a sanitised trace
A SIP Call-ID lets both sides refer to the same dialog. Include it when available. A short trace covering one failed attempt is normally more useful than a very large log containing unrelated traffic.
For audio problems, include the SIP and SDP exchange and describe the local RTP addresses actually used. For registration problems, include the response sequence without exposing the digest response or password.
Never send secrets
Do not send portal passwords, trunk passwords, API keys, payment details or reusable authentication headers. Sipflex does not need your plaintext password to check provider-side registration.
What Sipflex investigates
We can check account status, Sipflex credentials, registration state, number assignment and provider-side call routing. We may offer limited advice based on the evidence. Configuration and step-by-step troubleshooting of the customer PBX, firewall, dial plan or application remain outside the support scope.