Freeze one attempt and the exact service identity
Record UTC and local time, Vodafone legal entity, the ordered Evolved Voice over Public Internet element, site, access, endpoint, called and calling numbers, direction, expected edge, PBX route, answer and media result. Redact credentials and personal data.
Do not substitute Hybrid Voice, GSIP or storm documentation because it contains a familiar SIP field. Classify the first unexpected state: order or activation, access or endpoint reachability, provider attempt, number or identity delivery, PBX selection, answer, or media.
Verify order, access and endpoint-diversity state
Compare the current order and accepted design with the loaded edge configuration. Preserve the access circuit or Internet path, public and local tuples, DNS answers, selected target, transport, endpoint role, health state and failover policy without exposing secrets.
Customer Endpoint Diversity is not a self-explanatory topology. Record which endpoint was eligible, which became unavailable, how Vodafone selected the alternate and whether the primary later became authoritative again.
Follow signaling through the firewall to the PBX
Align an authorized capture at the customer edge with the same attempt’s firewall and PBX logs. Preserve source and destination tuples, Request-URI, From, To, P-Asserted-Identity where present, Call-ID, response sequence and SDP. A reachable edge, OPTIONS response or TLS session is not proof of a routed call.
Change only the demonstrated owner. Do not open broad port ranges or import addresses from Hybrid, GSIP or storm records without the current Evolved design and provider evidence.
Separate number state from PBX routing
For an inbound failure, prove whether Vodafone attempted the expected endpoint before changing the dialplan. Correlate the called number, port or allocation state, delivered form, identity headers and exact route. For outbound failures, preserve the selected trunk, presented identity, response and policy owner.
Requested, scheduled, ported, activated and routed are distinct. One working number does not prove another number, site, endpoint or direction.
Separate security, fraud alerts, answer and media
If encryption was ordered, preserve DNS, time, certificate chain, served identity, TLS result, SDP offer and answer, SRTP profile and media on each leg. If Vodafone fraud monitoring raised an alert, record its timestamp, scope and provider case separately from the packet and call evidence.
A 200 response or connected call does not prove audible media. Preserve negotiated codec, packet rate, DTMF method, actual RTP or SRTP tuples, packet direction and decoded audio at authorized points.
Retest one correction, restoration and emergency state separately
After an authorized correction, repeat the affected ordinary call and an unaffected control. Preserve provider attempt, edge receipt, loaded PBX route, answer, media and normal hangup. If continuity was involved, demonstrate the alternate path and then prove the next eligible call returns to the intended primary.
Do not place an uncoordinated emergency call. Confirm registered site address, effective update, number mapping, outbound identity, callback and alternate method through Vodafone’s approved process. No Vodafone account, site, endpoint, trunk, packet, call, media, failover or emergency result was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Vodafone UK — SIP trunking ↗
- Vodafone — Converged Hybrid/Evolved Voice Service Specific Terms v1.4 ↗
- Vodafone — Converged Hybrid Voice data sheet ↗
- Vodafone — Tiered Support Services brochure ↗
- Vodafone storm Service Specific Terms v2.3 ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.