Begin with the current Professional Services handover
8x8's interface specification documents a two-part trust model: SIP traffic must arrive from a pre-registered static public IP address, and outbound INVITE requests are challenged with SIP digest authentication. Neither control replaces the other. Preserve the exact X Series order, Professional Services handover, approved public addresses, assigned peers, credentials, ports, number assignments and change owner before building the PBX object.
The specification is historical while the X Series FAQ was updated June 25, 2024. Treat its interface details as published evidence, not a substitute for the current account record. A firewall path, accepted source address, completed digest challenge and answered call are separate states. Do not copy addresses or credentials from another 8x8 service or site.
Documented service facts
Reviewed 2026-09-29. Compare SIP trunk services →
Authentication
Documented8x8's published interface specification requires signaling from a pre-registered static public IP address and challenges outbound INVITE requests with SIP digest authentication. Both controls belong to the documented interface: a permitted source address alone does not prove the credentials, Request-URI or calling identity are accepted. Obtain the current Professional Services handover because the specification is historical and X Series changes are support-managed.
SIP registration
DocumentedThe interface specification explicitly says there is no registrar and REGISTER is not supported. This is a fixed-interface trunk, not a phone-style registration workflow. Do not treat an absent registration indicator as a fault or transfer that statement to a different 8x8 product; confirm the ordered X Series trunk and current handover record.
Inbound delivery
DocumentedThe X Series FAQ says an Admin Console claimed number is assigned to the SIP trunk by Technical Support. That administrative assignment does not establish the source peer, Request-URI, presented number format, PBX match or final destination. Preserve the claimed-number record, support change and one authorized inbound trace through the intended route.
Inbound failover
Not verifiedThe reviewed public specification and X Series FAQ do not establish ordered customer destinations, failure triggers, retry responses, recovery behavior or established-call survival. A provider platform being available and a customer PBX having multiple addresses are not a failover contract. Obtain the current topology and run only provider-approved bounded new-call tests with rollback.
Number and regional availability
Not verifiedThe FAQ documents claiming numbers in Admin Console and support-managed assignment to a trunk, but it does not provide a complete current country, number-type, inventory, portability or installation matrix for this service. Confirm every requested number and address with a dated orderability or port result rather than transferring coverage claims from 8x8 Work or another product.
Audio codecs and DTMF
DocumentedThe interface specification lists RTP/AVP over UDP, G.711 mu-law, G.729 and RFC 2833 telephone-event DTMF, while preferring out-of-band DTMF. Those are interface inputs, not evidence of the ordered codec entitlement, negotiated payload, audio quality or downstream PSTN handling. Retain the current SDP offer and answer, packetization, selected payloads and RTP endpoints from authorized calls.
T.38 fax
Not verified8x8 publishes T.38 material for other fax and endpoint contexts, but the reviewed trunk-interface extract does not establish T.38 negotiation or a fax acceptance workflow for the ordered X Series trunk. Do not transfer a platform or ATA statement into this record. Qualify the exact number, direction, gateway, document set, ECM, switchover and fallback separately.
Signaling and media encryption
DocumentedThe reviewed interface specification supports UDP for SIP and states that TCP and TLS are not supported; its media profile is UDP RTP/AVP rather than a published SRTP profile. Keep that dated interface boundary attached to the exact trunk and obtain current written confirmation before deployment. Do not transfer TLS or SRTP claims from 8x8 Cloud PBX, applications or managed endpoints.
Concurrent calls and burst
Not verifiedThe reviewed public sources do not establish the purchased simultaneous-call total, calls-per-second allowance, burst behavior or rejection response for an account. Keep concurrent sessions, call starts, codec bandwidth, PBX capacity and billing units separate, and never derive entitlement from a successful call or the number of assigned telephone numbers.
Emergency calling
DocumentedThe X Series FAQ says SIP-trunk E911 address changes are handled through Technical Support. That change path does not establish eligibility, accepted calling identity, dispatch location, callback route, nomadic-use rules or an approved test procedure. Resolve each for every site and number, keep an independent fallback and never place an uncoordinated live emergency test.
Pricing model
Not verifiedThe FAQ says usage billing begins when a call receives SIP 200 OK and rounds up to the next minute, and that CDRs appear on the monthly bill. It does not provide a complete current rate card or account quote. Obtain dated terms for trunks, numbers, destinations, minimums, rounding, emergency service, support, taxes, commitment, renewal and termination.
Administration and support
DocumentedInitial X Series SIP trunk configuration is performed by 8x8 Professional Services. The FAQ says later IP-address, number-assignment and E911-address changes require Technical Support rather than self-service trunk editing in Admin Console. Preserve the order, handover, case IDs, approved addresses, number assignments, redacted credentials, timestamps and CDRs; verify account roles and retention.
SMS and MMS
Not verifiedThe reviewed SIP trunk sources do not establish SMS or MMS entitlement on trunk-assigned numbers. 8x8 publishes messaging registration material for other services, but it is not a trunk commitment. Verify the exact product, number capability, sender registration, consent controls, API or application path, throughput, retention and fees separately.
Do not build a registration workflow
The 8x8 specification explicitly says the trunk interface has no registrar and does not support REGISTER. An absent registration indicator is therefore expected for this documented service, not proof of an outage. Configure the PBX as the supported fixed interface and use the exact current peer and authentication data supplied for the order.
Keep this boundary scoped to the X Series SIP trunk. 8x8 phones, applications, fax endpoints and other managed services can use registration or provisioning flows that do not apply here. Confirm loaded peer state, one authorized INVITE challenge and the provider response without exposing passwords or reusable Authorization data in tickets.
Trace assigned numbers and E.164 identity independently
The interface specification requires full E.164-format numbers for Request-URI, To and From on outbound call termination and describes Remote-Party-ID for caller identity. The current FAQ says a number claimed in Admin Console is assigned to the SIP trunk by Technical Support. Those statements do not prove an account's accepted identity, inbound Request-URI, asserted headers or PBX route.
For each number, retain the Admin Console claim, support assignment, authorized source peer, Request-URI, To, From, Remote-Party-ID or other current asserted identity, PBX match and final destination. Number ownership, assignment, inbound delivery, outbound acceptance and recipient display remain separate results. Confirm coverage, inventory and porting with dated order evidence.
Keep the dated media and protection profile attached to this interface
The specification lists UDP RTP/AVP, G.711 mu-law, G.729 and RFC 2833 telephone-event DTMF, preferring out-of-band DTMF. It also states that SIP uses UDP and that TCP and TLS are not supported in the documented interface. Do not transfer TLS or SRTP statements from 8x8 Cloud PBX, applications or managed endpoints into this trunk record. Obtain current written confirmation before deployment because the specification is dated.
Published payload support is not proof of negotiation, audio quality or DTMF success. Preserve the current SDP offer and answer, selected codec, packetization, telephone-event mapping and RTP endpoints from authorized calls. The reviewed trunk sources do not establish T.38 acceptance; qualify fax separately rather than transferring a general 8x8 fax statement.
Use the support workflow as an operational control
The X Series FAQ says Professional Services performs initial SIP trunk configuration and that administrators cannot edit it in Admin Console. Later IP-address changes, E911-address changes, number assignment and number removal require Technical Support. Preserve case identifiers, approvals, before-and-after settings, timestamps and rollback; a local PBX change alone cannot complete a provider-owned update.
The same FAQ says trunk CDRs appear on the monthly bill, billing begins at SIP 200 OK and usage rounds up to the next minute. That is a billing event description, not a complete current quote. Retain the answered application, timestamps and CDR, then reconcile the contracted rate, minimums, destinations, numbers, taxes, support, commitment and termination terms.
Resolve resilience, capacity, emergency and messaging before cutover
The reviewed sources do not establish ordered alternate customer destinations, failure triggers, recovery, established-call survival, purchased simultaneous calls or calls per second. Obtain those values from the current design and contract. Keep provider availability, customer access, PBX reachability and number routing separate, and run only approved bounded new-call failure and capacity tests.
The FAQ documents a support path for changing the SIP-trunk E911 address but not the complete accepted calling identity, dispatch location, callback behavior, nomadic-use rules or test procedure. Resolve them for every site and number, retain an independent fallback and never place an uncoordinated live emergency test. Messaging entitlement is also unverified; do not transfer SMS registration material from another 8x8 product. No account, order, PBX, trunk, address, credential, number, route, call, media, fax, protection, failover, capacity, emergency call, message, price, availability or support response was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- 8x8 SIP Trunking Interface Specification ↗
- 8x8 X Series SIP Trunk FAQ ↗
- Bell voice solutions and SIP Trunking ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.