SIPFLEX HELP

Secure your Sipflex trunk

Sipflex applies network and fraud controls, while you remain responsible for securing the PBX or application connected to the service.

Use separate, strong credentials

  • Use the dedicated trunk password, not the portal password
  • Create separate API users for applications
  • Store secrets outside source code and browser-side JavaScript
  • Rotate credentials when access changes or compromise is suspected
  • Never include passwords in screenshots or support tickets

Protect portal access

Enable two-factor authentication in the account security settings and keep account-user access limited to people who need it. Use individual logins where available so access can be removed without sharing or changing a general credential.

Restrict the network path

Do not expose SIP ports to the whole internet unless your architecture genuinely requires it. Registered trunks normally work through NAT without broad inbound port-forwarding. For an IP-authenticated peer, allow only the required Sipflex signalling and media sources.

Sipflex network address

Use 52.56.188.70/32 where a PBX, SBC or firewall requires the current Sipflex source allow-list.

Profile access-control lists can further restrict where account connections are accepted from. Apply them only when the customer endpoint has a stable address and the rule will not block intended failover.

Use TLS and SRTP deliberately

TLS encrypts SIP signalling. SRTP encrypts media. They protect different parts of the call and must be configured consistently on both sides. A TLS connection uses port 5061; do not configure TLS against a UDP-only setting.

Apply sensible calling controls

Use the destination, spend, balance and notification controls available to the account. A strong password does not replace restrictions appropriate to the destinations and traffic profile your application actually needs.

If compromise is suspected

  1. Stop or isolate the affected PBX, application or credential.
  2. Rotate the relevant trunk, portal or API credential.
  3. Review call records for unusual destinations and times.
  4. Confirm that firewall, ACL and destination controls are still correct.
  5. Contact Sipflex with the affected number, timeframe and evidence—without sending passwords.

Prepare the evidence