VoIP.info Provider research

SignalWire SIP trunking: credentials, resources and call-path evidence

Separate the SIP Profile, credential registration, call handler, phone-number assignment, Resource SIP Address, PBX route, caller identity, encryption, media and E911 state.

Reviewed 2026-10-17Current SignalWire SIP trunking, SIP Credential, SIP Profile, FreePBX, caller identity, rate-limit and E911 documentation reviewed October 17, 2026. The documentation distinguishes a project SIP Profile, one SIP Credential, a number-to-resource assignment, Resource SIP Addresses, the credential call handler, permitted outbound identity, PBX registration and dialplan, negotiated signaling and media, account-level call-start limits and number-level E911 provisioning. The selected Space, project, profile revision, credential, password, handler, phone number, assigned resource, PBX object, route, caller identity, encryption, codec, cipher, call rate, concurrency, emergency record, availability, price and compatibility remain account, configuration or observation specific. No account, project, credential, profile, number, resource, PBX, registration, packet, media stream, emergency workflow or live call was inspected or testedIntermediateDocumentation based · not lab tested

Inventory the project, profile, credential, resource and PBX separately

Record the legal account, Space and project, project-wide SIP Profile domain and defaults, selected SIP Credential resource ID and username, effective call handler, purchased or verified numbers, each number's assigned resource, any Resource SIP Address, PBX object, inbound context, outbound route and responsible owner. Protect the SIP password, API token and Authorization values.

SignalWire documents the SIP Profile as project-wide defaults and the SIP Credential as a project-scoped SIP identity. Updating the profile does not update an individual credential or gateway. A dashboard object, API response and loaded PBX configuration are separate evidence until their identifiers and effective values are reconciled.

Documented service facts

Reviewed 2026-10-17. Compare SIP trunk services →

SIP authentication and outbound policy

Documented

A project-scoped SIP Credential supplies the registration username and password and selects profile-default, passthrough, block-PSTN or resource handling. API project credentials manage resources and are not the SIP registration secret; preserve both without exposing either.

SIP registration

Documented

The credential has a Space-specific SIP address and password. Reconcile project profile defaults, credential values and the loaded PBX registration; a current binding does not prove number routing or call handling.

Inbound number and SIP-address routing

Documented

A purchased phone number can be assigned to a SIP endpoint resource. A Resource SIP Address is a separate inbound path to resource logic. Confirm the exact resource and PBX route for the selected call.

Inbound failover

Not verified

The reviewed documentation does not establish a redundant PBX destination, qualifying response set, retry sequence or active-call survival. Confirm a supported design before calling a second resource automatic failover.

Number and regional availability

Not verified

SignalWire documents purchasing and assigning phone numbers, but exact country, locality, number type, porting, regulatory and emergency eligibility remain inventory and account specific.

Codecs, ciphers and RTP

Documented

The profile and credential expose codec, cipher and encryption controls. Stored values, negotiated SDP, media endpoints, decoded audio and any transcoding remain call-path evidence.

Fax over the selected trunk path

Not verified

The number settings include Voice and Fax handling, but the reviewed SIP trunk sources do not establish T.38, passthrough, direction, number eligibility or equipment compatibility for a selected account.

Signaling and media protection

Documented

SignalWire documents TLS and SRTP support plus required or optional encryption policy. Certificate validation, effective cipher, negotiated SRTP and protection beyond the customer-facing leg require observed evidence.

Call-start throughput

Documented

Current rate-limit guidance lists an account-level Voice default of one call per second and a call backlog. Call starts, queue behavior, active-call concurrency, PBX capacity and account entitlement are separate controls.

E911 lifecycle

Documented

Create and validate an address, assign it to a US phone number, poll `e911_status` until active, then use 933 for the documented read-back. Status changes do not send webhooks.

Pricing and account quote

Documented

SignalWire publishes usage rates, but the selected numbers, destinations, features, throughput, taxes, support and total cost remain account and date specific. A public rate page is not a quote or availability promise.

Dashboard, API and call logs

Documented

Profiles, credentials and number assignments can be managed by dashboard or API, and call logs expose resource details. Preserve IDs, timestamps and redacted raw evidence; public docs do not prove one account or incident.

SMS and MMS

Not verified

Voice assignment to a SIP endpoint does not establish messaging eligibility, sender registration, API ownership, consent, routing, throughput, retention or price. Qualify messaging separately.

Treat registration as credential reachability, not complete service

A SIP Credential supplies a Space-specific SIP address, username and password for registration. Preserve the configured domain, transport and port, challenge, Contact, expiry, final response and the exact PBX endpoint that owns the binding. Compare credential-level encryption, codec, cipher, caller identity and handler values with the project defaults before assuming inheritance.

A successful REGISTER proves one transaction and current binding observation. It does not assign a phone number, select an inbound resource, authorize PSTN dialing, load the intended FreePBX context, negotiate media, establish capacity or complete a call.

Trace inbound numbers and Resource SIP Addresses as different paths

The trunking guide describes assigning a purchased phone number to a SIP endpoint resource for inbound PSTN delivery. The SIP Credential guide separately describes a Resource SIP Address that sends inbound SIP traffic to the owning resource's logic. Record which path the failed call used, the exact assigned resource, delivered Request-URI, first SignalWire log, PBX edge packet and final route.

For the documented FreePBX pattern, retain the from-signalwire context, custom dialplan that extracts the called number from the To header, normalized DID and first from-pstn match. Do not repair an absent number assignment by broadening an inbound route, or treat a Resource SIP Address as proof that a PSTN number targets the same resource.

Prove outbound handler, Send As identity and call-start scope

SignalWire documents credential call handlers for profile-default policy, passthrough, block-PSTN and resource execution. Record the effective handler, dialed form, outbound route, endpoint or profile send_as, purchased or verified originating number, first request, provider response and final destination result. Caller ID number and CNAM remain separate; CNAM is reviewed and retrieved downstream rather than carried as the same value as the number.

Current rate-limit documentation lists the Voice limit at the account level across projects and shows a default one call per second with a call backlog. That call-start control is not simultaneous-call capacity, per-number entitlement, destination acceptance or a guarantee of delay. Confirm the selected account's effective limits before a bounded load test.

Resolve TLS policy, SRTP, codec and media from the actual call

The trunking guide documents TLS on port 5061 and SRTP support, while the SIP Profile and credential expose encryption, cipher and codec controls. Preserve both stored layers, certificate validation, registration transport, INVITE transport, offer and answer SDP, chosen codec and cipher, RTP endpoints, first packet in each direction and decoded result.

A required-encryption setting, a TLS registration or an accepted INVITE does not prove that the intended call used the expected certificate policy, that SRTP was negotiated, that both directions carried media or that another carrier leg remained protected. Compatibility remains PBX, endpoint and call-path specific.

Accept E911, logging, availability and commercial state independently

SignalWire documents E911 as a number-level lifecycle: validate an emergency address, assign it to a phone number, poll the asynchronous e911_status until active, then use 933 for the documented read-back test. Status changes do not send webhooks. Preserve the number, address record, provisioning state, permitted outbound identity, read-back result and update owner separately; do not place an uncoordinated 911 call.

Correlate the credential, number assignment, PBX evidence and SignalWire call log for one authorized ordinary call. Keep number inventory, porting, messaging, fax, failover, concurrency, support, price, tax and regional eligibility tied to the actual account and date. Public documentation and one successful call are not availability, compatibility, quality or emergency guarantees.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.