NAPTR
Says which transports the domain offers and in what order of preference. The first step of RFC 3263 discovery, and the one most often missing.
A SIP credential lets anyone place calls billed to your account, and a public web form is the last place it should be typed. This test takes a domain and nothing else — there is no field for a username, a password or an extension, which is the only reliable way to guarantee it never receives one.
Says which transports the domain offers and in what order of preference. The first step of RFC 3263 discovery, and the one most often missing.
Names the servers for a transport, with priority and weight. Lower priority is tried first; within a priority, higher weight takes more traffic.
UDP, TCP or TLS. On anything but TLS, the caller and callee identities and the media negotiation travel in clear text.
We open a connection and nothing more. No SIP message is sent, so this cannot register, place a call, or probe a server's behaviour.
Most SIP deployments configure a server address into every handset and never publish a record. That works, and it means every future change is a visit to every phone. SRV records let you move the service, add a second server, or fail traffic over, without touching a single device — and they cost nothing.
NAPTR is the step above, and it is the one that decides whether your phones use encryption. Without it, a client that finds both a TLS and a UDP option picks by its own rules, and in practice many choose UDP. Publishing NAPTR with SIPS+D2T at a lower order tells them which you prefer. It is advisory rather than binding, so if every device can do TLS, removing the UDP records is what actually stops it being used.
On what the absence of TLS exposes: SIP carries who is calling whom, the registration challenge, and the SDP that says where media will flow. In clear text, anyone on the path can read the call records and can alter the SDP to redirect the audio elsewhere. That is a different and larger problem than the audio itself being unencrypted.
A limitation worth stating: UDP cannot be tested here. There is no connection to open, and the only alternative is to send an unsolicited SIP message to somebody else's server, which we do not do. A UDP target is therefore reported as untested rather than unreachable — plenty of working commercial providers advertise UDP only.
No. There is no diagnostic a public tool can perform with your SIP username and password that is worth the risk of typing them into a web page — and a stolen SIP credential is used to place expensive international calls on your account, usually overnight. If any tool asks, that is the moment to close the tab.
Not to make calls work today. You need them to be able to change anything later without reconfiguring every device, and to have any failover at all. They cost nothing to publish, which makes the trade-off straightforward.
Because UDP has no connection to open. Testing it would mean sending a SIP message to someone else's server unsolicited, which we do not do. Untested means we learnt nothing — not that the server is down. Plenty of working providers advertise UDP only.
Check what name it covers. RFC 5922 expects a SIP certificate to identify the SIP domain, which is often a different name from the SRV target the client connected to — and clients differ on which one they check. A certificate naming only the server hostname will fail on some clients and work on others.
If the devices support it, yes. Without it the call detail records and the media negotiation are readable by anything on the path, and alterable. The usual obstacle is older handsets, and the usual answer is to run both for a while — while knowing that a client offered both will often choose the unencrypted one.
Voice is the least forgiving thing on a network and the first to be blamed on the platform. We run UCaaS and the network under it together, which is the only way the question of whose fault it is stops being a conversation between two vendors.