Freeze the selected service, site and failed attempt
Record UTC and local time, exact service name, agreement and pricing-schedule version, site, access type, ONT, One NZ router or emulator, demarcation, PBX and software, ordered Calling Channels, DDIs, portal state, diversity or failover option, direction, calling and called numbers, first response, answer and audio result. Redact secrets while preserving field names and retrieval time.
Classify the first unexpected boundary: product selection, order, feasibility, access, demarcation, PBX, portal, channel, DDI, request, response, dialog, media, alternate path or restoration. Do not substitute the other One NZ SIP product or another customer configuration.
Prove the ordered access and demarcation before PBX changes
For SIP Advanced, compare the order with One NZ Access, Metro Access where applicable, ONT, supplied router and SIP or emulator presentation. For Smart SIP, prove the selected Fibre, HSNS or 4G Access, supplied Edge Router and point of connection. Establish state on both sides of the exact demarcation before changing firewall, NAT, SIP ALG, credentials or PBX objects.
A link light, reachable address, active broadband session or portal login does not prove that the trunk, source, DDI or identity is accepted. Preserve the first request and response at an authorized observation point and keep provider-side and customer-side responsibility explicit.
Map the current implementation specification to loaded PBX state
Retrieve the current order and One NZ implementation specification. Map the documented registrar or source-trust model, signaling targets, transport, ports, identity, number format, codecs, DTMF and media ranges to generated configuration and loaded PBX objects. A compatible-PBX statement or vendor lab does not establish one installed version or topology.
Preserve request, response, SDP and packet evidence for the same Call-ID. After answer, prove both media directions, selected codec, decoding and audible result separately. Do not infer encryption, media quality or DTMF success from the words secure, dedicated or high quality.
Trace Calling Channels, DDIs and portal changes independently
Compare the ordered channel quantity with portal display, active dialogs and the exact rejection. For Smart SIP, retain the four-to-fifteen bounds and the fact that a portal change adjusts service and charges; for SIP Advanced, retain the ordered scalable pool and product-page minimum without moving either rule to the other service.
For inbound failure, preserve DDI allocation or port state, emergency-location record, provider attempt, delivered called-number value, PBX receipt and route match. For outbound failure, preserve selected trunk, source identity, Request-URI, response sequence and restriction. Portal acceptance, number presence or a SIP response is not proof of a completed call.
Prove the exact diversity or failover option and restoration
Confirm whether the order includes SIP Advanced Multi-Site diversity, SIP Advanced Dual Circuit, dual Diversity or higher, or Smart SIP 4G failover Access. Record each site or circuit, path, router, trigger, provider action, PBX route, new-call result, established-call behavior and restoration. Do not treat these differently named options as interchangeable.
A second circuit, 4G attachment, forwarded number or service-level target does not prove physical diversity, completed calls, feature preservation or recovery. Keep the One NZ service-edge measurement separate from customer PBX, LAN, WAN, carrier interconnect and endpoint outcomes.
Retest one correction and close with bounded evidence
Apply one authorized correction and repeat the affected ordinary call plus an unaffected control. Preserve access and demarcation state, loaded PBX configuration, SIP exchange, DDI match, channel count, answer, both media directions and hangup. Keep old access, number routing and rollback criteria until the approved cutover is complete.
Attach the governing service description, order, implementation evidence, portal export and provider case observations. Confirm each DDI location, power, alternate calling and alarm dependencies through an approved non-live process; do not use 111 as an uncoordinated diagnostic. No One NZ service, access path, call, failover, media 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.
- One NZ — SIP Advanced ↗
- One NZ — SIP Advanced Service Description ↗
- One NZ — Smart SIP ↗
- One NZ — Smart SIP Service Description ↗
- One NZ — Terms, conditions and service descriptions ↗
- One NZ — Metro Access Service Description ↗
- One NZ — About Emergency Services on 111 ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.