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.
Example defensive architecture. Source restrictions, authentication, update policy and call permissions work together.
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.
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.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.