Make the Statement of Work the current interface boundary
8x8's current Network Best Practices lists SIP trunks and TIE trunks as SIPS signaling and SRTP, then directs the reader to the customized Statement of Work for the unique implementation. Preserve that SOW, the Professional Services handover, support cases, approved public addresses, assigned peers, authentication mode, transport, certificate requirements, media profile and effective date as one versioned control set.
The separately published interface specification remains the detailed interoperability reference for supported standards, methods, headers, authentication, number formatting, E911 and call flows. Where a generic page, interface PDF and account SOW differ, do not merge them into a fictional universal profile; confirm the account-specific requirement with 8x8 before changing the PBX or firewall.
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.
Keep fixed source identity, digest challenge and REGISTER separate
The linked interface specification documents the fixed-interface model historically used for X Series trunks: traffic arrives from an approved static public address, outbound INVITEs can be challenged with digest authentication, and the interface does not use SIP REGISTER. Treat those as three separate checks and verify that the current account SOW still assigns that model.
An absent registration object is not by itself an outage for a no-REGISTER trunk. Likewise, an allowlisted address does not prove that a challenged INVITE supplied the correct authorization, and a completed digest exchange does not prove the source address, number identity or downstream call was accepted. Never paste reusable Authorization material into a general ticket.
Separate a claimed number from its trunk assignment
The current X Series FAQ says Professional Services performs the initial trunk configuration and Technical Support owns later IP-address, E911-address and number-assignment changes. A number first claimed in Admin Console is reserved for the account; the FAQ then requires support to assign it to the X Series SIP trunk. Claim, assignment, inbound delivery, outbound presentation and recipient display remain distinct evidence.
For each affected number, retain its Admin Console state, support case, effective trunk assignment, Request-URI, To, From and asserted identity, PBX match and final result. Returning a trunk number to the available inventory is another support-owned state change, not merely a local PBX edit.
Do not mix endpoint ports with the trunk security profile
8x8's current network page publishes ports for physical phones, Work applications, contact-center softphones and other products alongside the SOW-scoped trunk rows. Those endpoint values are not a trunk firewall template. For the trunk, apply only the assigned peers, names, ports, signaling transport, certificate trust and media ranges in the current SOW and approved support record.
The same page recommends active-standby WAN failover and warns that active-active load balancing may not be supported. That network design guidance does not establish provider-side trunk failover, alternate peers, health detection or established-call survival. Preserve address translation and egress identity across the approved standby path and test it separately.
Trace signaling, answer, billing and media independently
For one authorized call, correlate the support-owned trunk configuration, source and destination address, Request-URI, identity headers, challenge, response, PBX route, answer, SDP and both media directions. The FAQ associates billing start with SIP 200 OK and rounds usage to the next minute; that billing boundary is not proof that a person answered, two-way audio worked or the expected application handled the call.
Preserve which component sent each response and which address carried each RTP or SRTP direction. A successful TLS handshake is not SIP acceptance, a 200 response is not media proof, and packets in both directions are not intelligible audio without an authorized endpoint observation.
Control changes, emergency identity and recovery through support
Because X Series trunk settings are not editable in Admin Console, record the exact Technical Support case, approval, requested before-and-after values, effective time and rollback for provider-owned changes. Reconcile the applied provider state with the PBX and firewall before declaring recovery; a local edit can make one test pass while leaving the account configuration unchanged.
The FAQ separately identifies E911-address changes as support-owned. Current Admin Console address documentation distinguishes site, emergency and additional-information addresses, but those user-profile rules do not by themselves prove a SIP trunk's emergency calling identity or dispatch record. Use the contracted trunk procedure and an approved non-live verification path. No 8x8 service behavior was laboratory validated 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 ↗
- 8x8 Network Best Practices ↗
- 8x8 X Series upgrade impact ↗
- 8x8 Admin Console phone-number claiming ↗
- 8x8 Admin Console service and emergency addresses ↗
- 8x8 SIP Trunking Interface Specification (archived attachment) ↗
- 8x8 X Series SIP Trunk FAQ (legacy article URL) ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.