Freeze one failed inbound attempt and the working control
Record the called Yay.com number, timestamp and timezone, number-to-trunk assignment, inbound identity choice, destination, port, transport, current DNS answers, provider attempt, customer-edge receipt, PBX response, route result, SDP and audio. Preserve a working outbound call or registration only as a bounded control for that separate path.
Redact credentials, telephone numbers, customer addresses and call content before sharing. Outbound success does not establish the inbound assignment, destination, certificate result or media policy.
Prove the number is assigned to the intended trunk
Confirm the affected number currently routes to the intended SIP trunk. Then preserve whether inbound authentication presents the dialled number or configured username and whether the selected CLI format is E.164 or GB national. Compare the actual Request-URI and identity headers with the expected PBX route.
A trunk object can exist and outbound calls can succeed while the number remains assigned elsewhere. Correct that provider owner before changing Asterisk or FreePBX.
Locate the request at the configured destination
Resolve the configured FQDN at the incident time and compare the provider attempt with the customer public address, NAT mapping, edge policy and operating-system listener. If no request reaches the edge, investigate assignment, destination, DNS and network ownership. If it arrives, preserve source, destination, transport and first response.
Use the provider's current signaling sources as dated inputs, not as proof of arrival. Do not disable the firewall or accept anonymous traffic to make the symptom disappear.
Match one request to the intended PJSIP object and route
Compare source, transport, Request-URI, To and asserted identity with loaded PJSIP endpoint identification, context and the first FreePBX inbound-route match. A TLS connection or packet on port 5061 can still miss dialplan because the identify rule, context or number form is wrong.
Inspect generated and loaded state before editing. Do not import the legacy chan_sip example, add a catch-all DID pattern or broaden provider-source trust when one mapping is incorrect.
Separate TLS success from SRTP and decoded audio
If signaling completes but audio is absent or one-way, compare the Yay dashboard encryption control with the endpoint or PBX setting, then preserve certificate validation, SDP offer and answer, negotiated SRTP profile, advertised media addresses, packet directions and decoded result. Yay.com specifically warns that enabling inbound call encryption on only one side causes problems.
Use current RTP source guidance and the negotiated destination ports. A completed TLS handshake, 200 response or observed SRTP packet does not by itself establish two-way intelligible audio.
Correct the earliest owner and retest the same path
Change only the earliest demonstrated mismatch: number assignment, inbound identity, format, destination, DNS, NAT, firewall, listener, endpoint identification, context, route, dashboard encryption, SDP or media policy. Repeat the same inbound attempt and the working outbound control, then verify hangup and rollback.
Keep any credential-registration fault separate from IP-authorized outbound and direct inbound delivery. No Yay.com account, PBX, certificate, packet, media stream or live call was inspected for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Yay.com SIP Trunks for business phone systems ↗
- Yay.com create a SIP trunk ↗
- Yay.com SIP trunks and how to use them ↗
- Yay.com call encryption, TLS and SRTP ↗
- Yay.com firewall guide ↗
- Yay.com legacy FreePBX configuration example ↗
- Yay.com trunk-authentication API ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.