Freeze one affected call and its direction
Record one authorized non-emergency call with timestamp and timezone, inbound or outbound direction, calling and called identities, PBX channel, SIP Call-ID, answer result and which party could hear which direction. Preserve the current Zen portal values, registration state, dialog messages, both SDP bodies and packet evidence before changing the firewall or codec list.
A successful REGISTER proves a binding was accepted; it does not prove that an INVITE reached the correct PBX route, that a dialog answered, that RTP crossed both boundaries or that either endpoint decoded audio.
Place the failure after signaling, not inside registration
Confirm the call reached the expected Zen and PBX legs, received the intended final response and created the correct local channel. Correlate Call-ID, tags, Contact, Request-URI and route before treating silence as media loss. If the call never answers, use the inbound or outbound call diagnostic instead of opening RTP broadly.
Zen publishes voip.zen.co.uk, proxy use, Digest authentication, UDP 5060, no STUN and re-registration up to 900 seconds. Those values explain the documented registration profile but do not make a completed dialog or media path automatic.
Compare the actual path with Zen’s documented media boundary
Zen lists signaling from 212.23.7.228 on UDP 5060 and call audio from 62.3.88.0–62.3.88.31 on UDP 20000–30000. For the affected call, compare the offered and answered connection addresses and ports with packets actually sent and received at the PBX edge. Check both directions independently.
Apply least-privilege rules to the current documented source ranges and selected topology. Do not expose PBX management, permit all UDP from the internet or disable the firewall to manufacture a result. If observed provider addresses differ, preserve the evidence and obtain current Zen confirmation before changing the allowlist.
Resolve SDP, NAT and B2BUA handling
Zen identifies its media handling as B2BUA. Preserve the initial offer, answer and any later session change, then verify which address and port each side was told to use. Compare public and private addressing, PBX external and local-network classification, symmetric RTP behavior and any SBC or firewall translation without assuming the registration Contact owns media.
One-way audio identifies a missing direction, not automatically the faulty device. Follow the silent direction from the sender’s encoded packets through translation and provider boundary to the expected receiver, then confirm whether packets arrived and decoded.
Keep codec, DTMF, fax and encryption claims separate
Zen documents G.711 A-law and mu-law with 20 ms packetization, RFC2833 and in-band DTMF, G.711-based fax and no T.38. Confirm the actual offer, answer, selected payload and decoded audio before reducing the codec list. A ringing or answered call does not prove a common codec, correct payload mapping or usable audio.
The reviewed settings list UDP and mark TCP, TLS and IPsec unsupported; they do not establish SRTP. Digest authentication does not encrypt signaling or media. Do not switch transport or enable incompatible protection as an audio repair without current order-specific evidence.
Retest both directions and preserve rollback
After correcting only the demonstrated route, address translation, source restriction or codec mismatch, repeat one inbound and one outbound non-emergency call. Verify alerting, answer, RTP packets in both directions, decoded speech, DTMF when required and clean release. Test fax separately with an approved representative document because Zen distinguishes G.711 fax from unsupported T.38.
Restore the prior configuration if the stated acceptance checks fail. Record the final portal values, firewall rule, PBX object, SDP and result without publishing credentials or personal call data. This workflow is documentation-derived and was not reproduced on a customer or laboratory trunk.
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.