Mildly hijacking this thread... A few months back I investigated SIP as a replacement for skype, discord, whatsapp etc. It seemed a very insecure protocol: If I have an account on server A, and someone else has an account on server B then a user on server B can call me but neither my client nor my server will verify with server B that the caller is who they say they are.
The email ecosystem had the same problem where anyone could send an email from any address but managed to solve it by adding new standards on top of old ones to verify senders. I hope something similar can happen for SIP.
If you are talking about SPF and DKIM, none of them verify the sender. The former indicates which IP adresses are allowed to send a email from for a specific domain name. The latter lets you verify that the email originated from the domain. But not from the sender itself.
If you were talking about PGP signatures, ignore my previous words :)
The issue you see in SIP predates voice over IP. PSTN suffers from the very same issue.
Well if you get an email from xxx@somemail.com and the SPF and DKIM check out then it means that the mail really came from somemail and they have had the chance to verify that xxx is authorized to send the email with e.g. a password. The system is not 100% foolproof but it's good enough when working with reputable or selfhosted email services. It's way, way better than "anyone can trivially pretend to be anyone"
You can use many of the same techniques used to drop email spam, for example forward and reverse DNS lookups and of course your favourite next gen firewall can do all sorts of fancy things to help decide "trustworthyness". You can use authenticated trunks between A and B. You can allow anon connections but pre-screen calls by asking the source to identify themselves and play that to the recipient who can choose to accept or drop the call.
You can do an awful lot of things with SIP that are unthinkable or plain unlikely with PSTN. SIP can be encrypted (OK the RTP streams can) You can use IAX2 for those times when NAT and SIPnRTP are too hard (hint: try Symmetric RTP - fixes many NAT related problems)
Don't confuse SIP with something it isn't! SIP is a comms mechanism and a damn good one, considering how old it is. When you deploy SIP, you also have the option of using all of the very latest funky security stuff around it to support it thanks to the fact that it runs over UDP/IP or TCP/IP.
The email ecosystem had the same problem where anyone could send an email from any address - I'm not sure that you can call this a problem. I could call myself Mr Donald Trump, in fact my real name could even be Mr Donald Trump but it wont really make me POTUS but you need some way to tell the difference. Comms is tricky and safe comms in the modern world is very tricky. How far should a comms protocol go in ensuring that the source is who the recipient thinks it is? Or is that really a job for another protocol/system perhaps with some hooks of some sort?
The email ecosystem had the same problem where anyone could send an email from any address but managed to solve it by adding new standards on top of old ones to verify senders. I hope something similar can happen for SIP.