Yay.com SIP trunking: inbound identity, destination and SRTP evidence

Model the number, inbound trunk and outbound authorization separately

Record the account, Yay.com number, number-to-trunk assignment, inbound identity choice, destination address or FQDN, port, transport, outbound authorized source addresses or username and password, and the matching PBX objects. The dashboard requires the number to be assigned to the trunk before that trunk becomes its inbound route.

A working outbound call or accepted source address does not establish number assignment, destination reachability or the identity delivered to the PBX. Likewise, an inbound INVITE does not prove outbound authorization.

Preserve the inbound identity and number format actually selected

Yay.com lets inbound delivery identify the request by the dialled number or by a configured trunk username, while still passing dialled-number information. It also offers E.164 with a leading plus or GB national format. Preserve the selected controls and the actual Request-URI, To and asserted identity rather than broadening PBX patterns to accept every form.

Compare those values with the loaded PJSIP endpoint identification, context and first matching FreePBX inbound route. A request can reach the listener yet miss the intended route because the selected identity or format differs.

Treat IP delivery, FQDN resolution and registration as different evidence

The inbound destination can be a public address or FQDN with a selected port and UDP, TCP or TLS transport. Preserve the submitted destination, current DNS answers, TTL, chosen address, provider source, customer-edge receipt and listener. A saved FQDN is not proof of the address used for one call.

The general trunk workflow documents source-IP authorization for outbound calls and optional credentials, while the FreePBX example also shows a registered credential path at talk.yay.com. Determine the selected model before interpreting REGISTER or copying a template.

Prove TLS signaling and SRTP media independently

Yay.com documents TLS for SIP and SRTP for audio. For inbound SRTP, its guidance requires encryption to be enabled in both the endpoint and the Yay dashboard and warns that a mismatch causes call problems. Preserve the configured hostname, certificate chain, TLS session, SDP offer and answer, negotiated media profile, RTP directions and decoded audio.

A successful TLS session does not establish SRTP negotiation or two-way audio. The customer-facing encrypted leg also does not prove protection through every carrier, forwarded destination, recording system or endpoint.

Use published firewall inputs without converting them into packet evidence

The current firewall page publishes separate SIP and RTP source addresses plus signaling and media port guidance and says to disable SIP ALG when enabled. Record the exact dated source page, but compare it with DNS, the provider attempt, edge decisions and a narrow authorized capture.

Do not open the full Internet, accept anonymous SIP or assume every published address participated in one call. A permitted rule is not proof that a packet arrived, matched the intended PBX object or followed the negotiated media destination.

Keep the FreePBX example inside its driver and release boundary

The public Yay.com FreePBX example uses type=peer, insecure=port,invite, register strings and other chan_sip-style fields. Retain it only as provider terminology and historical screen context. Do not copy those fields into FreePBX 17 PJSIP without mapping them to the installed release and supported owners.

Make durable changes through current trunk, Asterisk SIP Settings and inbound-route controls, then inspect generated and loaded endpoint, identify, AOR, registration and transport state. Use the paired diagnostic to correct the earliest demonstrated mismatch.

Diagnose inbound identity and media without changing working outbound authorization

Use the Yay.com inbound diagnostic to trace number assignment, identity, destination, PBX matching, TLS, SDP and SRTP.