Treat the trunk as a service boundary, not a cable
A SIP trunk is a commercial and operational connection between a calling service and a PBX or session border controller. SIP supplies signaling mechanisms, but the phrase does not identify one standardized Asterisk object or guarantee a particular registration, codec, encryption, number, capacity or support model. Record the exact service, account, site, region, edge hosts and provider document set before translating the order into PBX configuration.
Keep the provider-facing trunk separate from extensions and application routes. A hosted user licence, a direct-inward-dial number, an outbound calling entitlement, a channel allowance and a message product can be sold together or separately. A successful account login or paid invoice does not prove that a number is assigned, a source is authorized or a destination is permitted.
A simplified logical view. A hosted service may combine PBX and carrier functions; actual signaling and media paths can differ.
Separate numbers, caller identity and routing authority
For each telephone number, record ownership or porting state, inbound service assignment, destination, emergency address, outbound presentation permission and callback behavior. The Request-URI used to route a call, the From identity, a trusted asserted identity and the number displayed to the called party are not interchangeable. Preserve the provider's normalization and identity rules by direction.
An inbound INVITE reaching the PBX proves delivery only to that signaling boundary. It does not prove the intended inbound route, schedule, extension, voicemail destination or answered party. Likewise, acceptance of an outbound INVITE does not establish that the presented number is authorized, attested or suitable for emergency callback.
Map authentication, registration and identification separately
A service may authenticate requests with digest credentials, authorize a fixed source address, use mutual TLS or apply more than one control. Outbound registration is a client relationship that can provide contact and authentication state; it does not automatically define how Asterisk identifies an incoming request or how the provider authorizes an outbound call.
In Asterisk PJSIP, endpoint policy, AoR and contacts, auth, identify, transport and outbound-registration objects retain different responsibilities. Confirm whether REGISTER is required, optional or unsupported and whether inbound and outbound traffic share a host or identity. Record DNS and failover behavior instead of copying one provider's object layout to another.
Keep signaling, session description and media independent
SIP starts and changes sessions; SDP describes proposed media addresses, ports, directions, codecs and attributes. RTP or another media transport follows the negotiated topology. A successful SIP response can therefore coexist with one-way, silent or failed media, and packets can arrive without producing decoded audible speech.
Confirm transport, certificate trust, codec and packetization policy, DTMF method, fax method, media addresses, NAT ownership and any SRTP requirements for the exact service. TLS protects a signaling leg, while SRTP protects media when it is offered, accepted and used. Neither label proves end-to-end protection through carrier interconnects, recording systems or downstream destinations.
Model capacity and failover as different controls
Separate simultaneous established calls, call attempts per second, purchased channels, number inventory, codec bandwidth, PBX channels and user licences. Forwarding or transfer can consume additional legs. A provider's unlimited-language statement, a PBX extension count or an OPTIONS response is not a measured capacity result. Record enforcement behavior and the response returned at each limit.
Define inbound destination failover, alternate provider routing, PBX high availability, site connectivity and power recovery independently. Multiple provider edges do not prove that the customer PBX will select or accept an alternate edge, and a carrier-side forward protects only the new calls and triggers the provider documents. Existing dialogs, recordings and emergency location may follow different paths.
Accept the complete service without hiding unknowns
Build an acceptance matrix for authorized inbound and outbound numbers, permitted and denied destination classes, identity, DTMF, hold, transfer, voicemail, fax only if ordered, two-way media, hangup, failover and recovery. Preserve Call-ID, timestamps, SIP legs, negotiated media and provider ticket identifiers. Exclude emergency numbers from routine testing and use the carrier's approved emergency-service procedure after the exact location and callback number are verified.
Record price, taxes, porting, minimum commitments, support hours, trace retention, fraud controls, messaging, codec, encryption and geographic availability as account- and date-specific facts. Leave an unknown unresolved when public documentation does not establish it. No carrier account, number, PBX, trunk, route, call, media stream, failover, emergency workflow, price, availability or compatibility was inspected or tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261 — Session Initiation Protocol ↗
- IETF RFC 4566 — Session Description Protocol ↗
- IETF RFC 3711 — Secure Real-time Transport Protocol ↗
- Asterisk: configuring res_pjsip ↗
- Asterisk: res_pjsip configuration reference ↗
- Asterisk deployment: PSTN connectivity ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.