WARP

WARP guide

Setting Up a SIP Trunk on WARP

How to create, configure, secure, and verify customer SIP trunks on WARP.

A SIP trunk connects your PBX, SBC, softphone, or application to WARP for voice calling. Set up one trunk per logical call path, location, customer system, or operational boundary that you want to manage separately.

The basic workflow is:

  1. Create the trunk.
  2. Choose the authentication mode.
  3. Add IP allowlist entries, digest credentials, or both.
  4. Add endpoints if the trunk should send traffic to configured destinations.
  5. Confirm capacity, codecs, and DTMF.
  6. Place inbound and outbound test calls.

Network Connectivity and Firewall Whitelisting

WARP uses symmetric SIP signaling, so traffic flows in both directions between your equipment and WARP. Whitelist all required addresses before testing.

DirectionAddressTransport
You send to WARP34.44.183.87UDP, port 5060
You send to WARP34.55.182.145TCP port 5060 / TLS port 5061
WARP sends to you34.58.165.135Outbound signaling source

Use the UDP address for plain UDP SIP and the TCP/TLS address for connection-oriented or encrypted signaling. WARP's outbound signaling to your equipment originates from 34.58.165.135; allow inbound traffic from that address so call setup, in-dialog messages, and teardown reach you reliably.

Authentication Modes

Each trunk has an authentication mode:

  • IP allowlist (IP_ACL) - devices are identified by source IP. Best for a fixed PBX or SBC with a stable public IP.
  • Digest - devices authenticate with username and password. Best for softphones, mobile clients, or endpoints without a static IP.
  • Either - a device passes if it matches the IP allowlist or presents valid digest credentials.
  • Both (strict) - a device must match the IP allowlist and present valid digest credentials.

If you are unsure, start with IP allowlist for a PBX or Digest for softphones. You can adjust later without recreating the trunk.

IP Allowlist Entries

For IP allowlist, Either, or Both modes, add the public IP address your equipment presents to the internet. If your PBX sits behind NAT, use the firewall's public IP, not the private LAN address.

Keep the list tight. Calls from source IPs not on the allowlist are rejected before normal call routing.

Digest Credentials

For Digest, Either, or Both modes, create credentials for devices that authenticate with username and password.

Use these values in your device:

  • SIP server, registrar, and domain: warp.ringer.tel
  • SRV records: _sip._udp.warp.ringer.tel, _sip._tcp.warp.ringer.tel, and _sips._tcp.warp.ringer.tel
  • Username: the full server-prefixed username WARP gives you, such as tg1a2b3c4d-alice
  • Password: the show-once password created with the credential

The password is shown only once. Store it immediately. If you lose it, rotate the credential to generate a new one.

Endpoints

Use trunk endpoints when you want WARP to send traffic to one or more configured destinations for the trunk. Endpoints are managed under the trunk detail page and require trunks:write to create, edit, or delete.

Use clear endpoint names and keep destination details current. After endpoint changes, place a test call before relying on the route.

Capacity, Number Classes, Codecs, and DTMF

WARP enforces calls-per-second and concurrent-channel limits by direction and number class. Number classes include toll-free, local, intrastate, interstate, Zone 1, and international. International is disabled by default; contact support if you need it enabled.

If you exceed CPS, WARP can return SIP 503 with a Retry-After header. Your equipment should slow down and retry after that interval.

Inbound calls use the codec list configured on the trunk. Outbound calls forward your equipment's codec offer downstream. For DTMF, RFC2833 telephone-events are recommended unless your equipment requires inband tones.

Verification Checklist

Before production use:

  1. Confirm all three WARP IP addresses are allowed by your firewall.
  2. Confirm the trunk authentication mode matches your equipment.
  3. For IP allowlist trunks, confirm your public source IP is listed.
  4. For digest trunks, confirm the device registers with the full server-prefixed username.
  5. Confirm endpoints if the trunk uses them.
  6. Place an outbound test call and confirm two-way audio.
  7. Place an inbound test call to a number routed to this trunk and confirm two-way audio.
  8. Test DTMF digits in both directions.

If audio works one way only, re-check inbound allowance for 34.58.165.135; that is the most common missed firewall rule.

Scopes and API Reference

Read operations require trunks:read:

  • GET /v1/trunks
  • GET /v1/trunks/:trunk_id
  • GET /v1/trunks/:trunk_id/ips
  • GET /v1/trunks/:trunk_id/credentials
  • GET /v1/trunks/:trunk_id/endpoints
  • GET /v1/trunks/:trunk_id/cascade-preview
  • GET /v1/trunks/:trunk_id/throttle-state
  • GET /v1/network/vendor-ips
  • GET /v1/network/ingress-ips

Write operations require trunks:write; sensitive credential and endpoint writes may also require step-up verification:

  • POST /v1/trunks
  • PUT /v1/trunks/:trunk_id
  • DELETE /v1/trunks/:trunk_id
  • POST /v1/trunks/:trunk_id/ips
  • PATCH /v1/trunks/:trunk_id/ips/:ip_id
  • DELETE /v1/trunks/:trunk_id/ips/:ip_id
  • POST /v1/trunks/:trunk_id/credentials
  • POST /v1/trunks/:trunk_id/credentials/:cred_id/rotate
  • PATCH /v1/trunks/:trunk_id/credentials/:cred_id
  • DELETE /v1/trunks/:trunk_id/credentials/:cred_id
  • POST /v1/trunks/:trunk_id/endpoints
  • PATCH /v1/trunks/:trunk_id/endpoints/:endpoint_id
  • DELETE /v1/trunks/:trunk_id/endpoints/:endpoint_id