VoIP.info Troubleshooting

Proximus Business Trunking is down or calls fail

Find the first divergence across the ordered flavour, access, CPE, SBC, PBX, number, channel, signaling, fax, media, redundancy and emergency boundaries.

Reviewed 2026-10-25The current Proximus product page, 15 January 2024 Business Trunking contractual service description, 1 January 2026 contract summary, legal-document index and large-organisation support page were reviewed October 25, 2026. Multi Standard, Multi Converged, Cloud Basic and Cloud Advanced retain different access, CPE and SBC scopes; the selected order and implementation records govern. No Proximus or BICS account, order, site, Explore path, access line, CPE, SBC, PBX, number, channel, call, packet, fax, media stream, redundancy event, emergency result, price, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one attempt and the exact service identity

Record UTC and local time, Business Trunking order and flavour, site, Proximus connectivity, CPE, network SBC, customer or cloud SBC, PBX and software, calling and called numbers, direction, expected route, answer and media result. Redact credentials and personal data.

Classify the first unexpected state: order or acceptance, access, CPE, SBC, PBX, number delivery, capacity, signaling, fax or media. Do not substitute an Enterprise Voice or Fixed Voice Infinity profile.

Confirm the flavour and demarcation before changing rules

Compare the current order, data-capture form, implementation record and loaded state. Multi Standard, Multi Converged, Cloud Basic and Cloud Advanced allocate access, CPE and SBC responsibilities differently.

Preserve the exact demarcation and support owner. A successful path test to one address does not prove the intended network SBC, customer SBC, PBX route or number state.

Correlate access, SBC and PBX evidence

Align an authorized capture with access, CPE, SBC, PBX and provider records for the same attempt. Preserve tuples, Request-URI, identity headers, Call-ID, response sequence and SDP.

The documented Basic-Single, Single, Basic-Multi and Secure-Multi labels are not interchangeable. Show which legs are configured, reachable and selected, and where the first expected transaction is absent.

Separate number delivery, channel state and acceptance

For inbound failures, prove whether the expected number reached the selected Proximus edge before changing the dialplan. For outbound failures, preserve the selected trunk, presented identity, response and owner.

Correlate the current order and data-capture values with acceptance and live counters. Allocated numbers, configured channels, accepted implementation and observed simultaneous-call capacity remain different evidence.

Separate signaling success, fax and media

A successful SIP response does not establish audible media. Preserve negotiated codec, packetization, DTMF, RTP tuples, packet direction and decoded audio at authorized points. Keep each call leg and any transcoding boundary separate.

G.711, G.729 and T.38 are documented capabilities. For fax, record gateway, T.38 negotiation, fallback, packet loss and page result; do not turn capability text into a completed-fax guarantee.

Retest one correction, redundancy and emergency state separately

After an authorized correction, repeat the affected ordinary call and an unaffected control. Preserve provider attempt, PBX receipt, answer, media and hangup. If redundancy was involved, show the selected alternate and then the next eligible call returning to the intended primary.

Do not place an uncoordinated emergency call. Confirm effective location, presented number, remote-site or EVN treatment, callback and alternate method through the approved Proximus process. No account, path, trunk, call, media, redundancy or emergency result was tested for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.