The world would be a better place if standardisation were easier and fair for all emerging solutions.I wish they had one that started with standardization in mind at the beginning for both messaging and voice.
SIMPLE for messaging, and XMPP later implemented Jingle for voice.
A hybrid SIP/Simple and XMPP/Jingle protocol that is throroughly thought through for common features from the beginning would be nice.
XML has become the dejure specification language for parameters (names, attributes and values) in protocols long ago. UDP like TCP makes 'sockets'. It can't fit in as a whole (protocol) but for the payloads.So this XML would only be intensive only for certain parts, and minimal to record a tracking number for each message, to optionally know what got dropped, then allow for that to be resent. The messages themselves shouldn't be structured through XML, and be through the UDP protocol or something similar. It may not be fully XML compliant, because of this, but it doesn't need to be.
SIP like HTTP has a secure implementation. It is SIPs. With that, the body of its signalling (payload) is encrypted like HTTPs'.https://www.pcmag.com/news/voips-big-security-problem-its-sip, SIP has security problems. The handshake isn't secure by default, but can be. It says SIP messages can't be encrypted.
sip 5060/tcp #Session Initialization Protocol (VoIP) sip 5060/udp #Session Initialization Protocol (VoIP) sip-tls 5061/tcp #SIP over TLS sip-tls 5061/udp #SIP over TLS
For instance, I looked at Pidgin settings for XMPP, and there were options to require encryption and to not use plaintext. Pidgin settings for SIMPLE didn't have these options to confirm there were secure settings.
Nothing to do with HTTP(S) in it. They are both application layer protocols with the possibility of using UDP/TCP depending on the need. HTTP is TCP though. And TCP makes stateful connection.So a SIPS handshake is standardized to use something like HTTPS for transport, or perhaps it has to be configured to it, making sure both parties use it? That's the thing, is that SIPS has allowed different ways of doing things for the transport, that either it's not standard in how it transports or hasn't been for a long time, that people have a misconception that it's not.
You are right to a large extent. SIP negotiation is done in such a way that all parties involved agree to the same set of attributes available to each of them. SIP<->SIP(not SIPS); gsm codec<->gsm codec, etc.From what I hear, an SIP connection can be set up as secure, but it can't be verified from one end if the other end is secure. Also, it was mentioned that SIP security can drop off, while the call goes on, without users realizing it.
I read something long ago from a VOIP/PBX (O'Reilly) book, about how an older protocol SIP didn't have features (like security) in mind, when it was first implemented. The features had to be later added around the protocol. That book was either Switching to VOIP (where I learned about Asterisk), Asterisk: the Definitive Guide or both books. I learned about the existence of FreeBSD from one of these two books too.
That's good.If an encrypted payload changed to unencrypted, today's SIP client will end the call and vice versa. It might not have been so in the past as a suddenly encrypted payload would not be of any good use.