SIP trunk IP authentication

What the provider trusts

An IP-authenticated trunk identifies permitted traffic using configured network addresses rather than relying only on a registration credential. The provider's implementation determines the precise rules. Obtain its signaling and media requirements and your assigned source-address policy in writing.

Separate administration, signaling and media

Keep trust narrow

A provider allowlist is not a reason to permit all internet traffic to your PBX. Restrict accepted sources and destinations according to the documented topology. Keep inbound trunk routing separate from internal users' outbound privileges.

Plan address changes

A new ISP, failover link or NAT gateway can change the source address the provider sees. Update the provider's allowlist through its supported process and test both inbound and outbound calling. Registration status may be irrelevant for a trunk that does not use registration.

SIP.US documents this boundary directly: its IP-authenticated mode requires a configured static public address, does not use REGISTER and cannot coexist with credential registration on the same trunk. Review the provider record before choosing its health signal.

Voxtelesys likewise documents a static-IP path alongside registrar credentials. Its provider record keeps that identity choice separate from inbound route-profile priority.

Amazon Chime SDK Voice Connector termination can combine a public source CIDR allowlist with SIP credentials. The provider record keeps both controls explicit and does not treat either as a SIP REGISTER requirement.

Diagnose with both sides

Record the public egress address, response code and call timestamp. Ask the provider whether the request reached its platform and matched the expected account. If signaling succeeds but media fails, inspect SDP and media allowlists independently. Do not add arbitrary addresses until the failure disappears. Keep an inventory connecting each allowed address to its owner, purpose and review date.

Do not reduce BYOC-P mutual TLS to an IP allow-list

Zoom Phone BYOC-P Internet peering combines bidirectional address policy with mutual TLS and a supported public certificate chain. Source acceptance, certificate validation, private-key custody, SIP routing and final call authorization remain different controls.

Treat CCAI Platform BYOC authentication as directional

The CCAI Platform BYOC record preserves inbound SIP authentication or source policy separately from the outbound IP-to-IP handshake. An accepted inbound request does not validate the outbound destination or address rule.

Do not combine SIPcity registration and peering identities

SIPcity documents number-and-password registration separately from static public-IP peering. The SIPcity provider record preserves the enabled portal mode, issued host, transport, SIP identity and source address instead of merging two examples.

Do not infer a generic Toku authentication profile

Toku publishes carrier voice and adjacent Teams connectivity but not one public customer-trunk authentication or registration contract. The Toku provider record requires the provider-issued signaling source, target, identity, transport and certificate design.

Keep LoopUp endpoint identity and mutual TLS separate

LoopUp documents dedicated IP endpoints and mutual TLS for encrypted trunks while registration is unsupported. The provider record preserves endpoint uniqueness, certificate identity, trust anchors and observed authorization as different controls.

Keep Localphone SIP credentials distinct from account sign-in

Localphone documents a dashboard-issued SIP ID and SIP password that differ from the main account credentials. The Localphone service record preserves the issued identity, registrar, loaded registration and observed challenge without exposing the secret.

Use the right health signal for a SIPTRUNK trunk

SIPTRUNK does not expose an ordinary registration status for an IP-authenticated trunk. Use the SIPTRUNK mode-mismatch diagnostic to compare the portal mode, public source address, stored destination, gateway traffic and call result without inventing a REGISTER requirement.

Use a different health signal for a SIP.US IP-authenticated trunk

SIP.US shows an IP Auth label instead of ordinary registration state and requires one matching public address and port. The SIP.US failover diagnostic separates that mode from gateway selection, secondary-trunk assignment and PSTN treatment.

Compare Twilio ACL state with the address Twilio observed

Twilio identifies likely ACL rejection from a 403 on the initial INVITE and exposes the observed address through the response evidence. The provider diagnostic keeps this separate from a post-407 credential failure.

Do not confuse AWS termination controls with inbound origination

Allowed source CIDRs and SIP credentials govern Voice Connector termination; phone assignment, group priority and origination routes govern inbound delivery. Use the routing diagnostic for the latter.

Do not expect REGISTER on a didlogic IP-authenticated trunk

didlogic documents registration for digest authentication and an explicit SIP URI for IP-authenticated inbound delivery. The diagnostic keeps the two models distinct.

Anveo Direct outbound IP identity does not prove inbound routing

A successful source-IP-authenticated outbound call does not prove the DID destination, primary URI or backup URI. The Anveo Direct diagnostic keeps those objects separate.

Keep AVOXI outbound identity direction-specific

AVOXI documents one authentication choice per individual outbound trunk. The AVOXI diagnostic keeps that identity separate from inbound SIP URI routing.

Easybell Trusted IP is direction-specific

Inbound IP-only delivery ignores SIP credentials and can try stored addresses sequentially. The Easybell diagnostic separates that path from outbound identity and registration.

SIP.US IP authentication has no normal REGISTER status

SIP.US shows an IP Auth label and binds traffic to the stored public address. The DID diagnostic prevents that expected state from being mistaken for a registration failure.

Bulk Solutions identity can differ by call direction

Current first-party workflows show inbound IP delivery and outbound source-IP or digest identity as separate choices. The provider guide preserves each owner.

Yay.com uses different controls by direction

Outbound calls can use approved source addresses or username and password, while inbound delivery uses the assigned number, configured identity and destination. The provider guide preserves each owner.

Sinch Voice API termination uses application credentials

The Sinch guide records application key, secret and regional realm without converting current Voice API trunking into an unverified source-IP model.