SIPTRUNK registration, inbound Contact routing and direct-media evidence

Select credential registration or static-IP authentication first

SIPTRUNK documents a credential path in which a device sends REGISTER, receives a 401 challenge, retries with authorization and can receive a 200 response. It separately documents IP authentication using a stored public address and port. Record the mode enabled on the actual trunk before interpreting portal state or applying a PBX template.

A missing registration is a fault on the credential path but can be expected on the IP-authentication path. Do not combine the two descriptions into an unverified hybrid, and do not publish trunk credentials or reusable network identifiers.

Treat REGISTER success and the Contact destination separately

For a registered trunk, SIPTRUNK shows the Contact IP and port supplied by the PBX and an alias containing the public source observed by the provider. Its documentation says inbound traffic is attempted toward the Contact address. A REGISTER 200 response therefore does not prove that the advertised Contact is public, current, reachable or mapped to the intended PBX.

Capture the full registration exchange, accepted expiry, Contact, observed source, selected gateway and portal state for the same interval. Use the paired diagnostic when the portal says registered but inbound calls remain absent.

Follow the inbound DID into the loaded PBX route

SIPTRUNK documents default inbound formatting with a ten-digit From user and an eleven-digit To user. Preserve the provider attempt, edge receipt, Request-URI, To, From, source, transport, endpoint identification, context and first loaded route match before normalizing a number.

A portal DID assignment, successful registration and received INVITE are three different boundaries. On FreePBX, compare the GUI owner with generated and loaded PJSIP and dialplan state; do not widen trust or leave a catch-all route as a permanent repair.

Separate gateway redundancy from destination failover

The current interconnection guide recommends DNS SRV through gw.siptrunk.com or multiple documented outbound proxies when the PBX lacks SRV support. That gateway-selection behavior is different from Primary and Secondary Trunk assignment, PSTN Backup, unconditional PSTN Forward or voicemail treatment.

Record the active gateway, DNS answer set and provider-side destination order. Do not claim a recovery timer, active-call survival or automatic restoration without an account-specific controlled test.

Treat direct-media RTP as a separate security decision

SIPTRUNK says its signaling gateways act as proxies and that RTP can arrive from varied addresses and ports through a shorter media path. The provider recommends forwarding the PBX RTP range and allowing direct RTP for active calls. Preserve the actual offer and answer SDP, selected endpoints, first packet in each direction, firewall state and decoded audio before changing policy.

The provider article is not a universal instruction to expose an unrestricted UDP service. Apply the local security owner’s segmentation, state tracking, rate controls and PBX media-validation design. A connected SIP dialog is not proof of any audio, and a received RTP packet is not proof of intelligible two-way media.

Run a bounded registration, inbound, audio and recovery test

For one authorized DID and time window, record trunk mode, gateway, registration or stored IP, provider attempt, PBX receipt, route result, answer, SDP, each RTP direction and user-visible audio. Then exercise only the approved destination-failure control and restore the normal treatment.

Confirm codecs, fax, emergency identity, messaging, channel allocation, call-start rate, protected transport, pricing and support terms for the exact order. The reviewed public material does not prove one account’s current availability or compatibility. No account, PBX, packet, media stream or live call was inspected for this guide.

Diagnose a registered trunk with missing inbound calls or audio

Use the SIPTRUNK diagnostic to correlate Contact routing, loaded number match and direct-media RTP.