How is SIP/SIMPLE for an XMPP alternative?

sidetone

sidetone

How is SIMPLE for an XMPP messaging alternative?

Both are accepted IETF open-source standards.

XMPP is great, except it has a lot of overhead (sometimes heavy lag) because it uses XML. Is SIMPLE as secure as XMPP?
 
SIMPLE is SIP. It definitely outweighs XMPP. It handles messaging, presence and much more. It seamlessly integrates with standardised protocols - radius, SS7, etc.
 
I wish they had one that started with standardization in mind at the beginning for both messaging and voice. As SIP later implemented SIMPLE for messaging, and XMPP later implemented Jingle for voice.

Then, had XML only for handshake, initiation, buddy list, log out, log in, accept/decline, optionally a different XML for minutes of messages to compensate for dropped messages, and things like this. 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.

A hybrid SIP/Simple and XMPP/Jingle protocol that is thoroughly thought through for common features from the beginning would be nice.
 
Last edited:
sidetone said:
I wish they had one that started with standardization in mind at the beginning for both messaging and voice.
Click to expand...
The world would be a better place if standardisation were easier and fair for all emerging solutions.

sidetone said:
SIMPLE for messaging, and XMPP later implemented Jingle for voice.
Click to expand...

Yes, SIP was first for voice communication like XMPP was first for text messaging.

sidetone said:
A hybrid SIP/Simple and XMPP/Jingle protocol that is throroughly thought through for common features from the beginning would be nice.
Click to expand...

It's always a tug of war for the standardisation bodies to come to terms on what to accept as the defacto. Businesses have their various interests to protect.


sidetone said:
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.
Click to expand...
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.

sidetone said:
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.
Click to expand...
SIP like HTTP has a secure implementation. It is SIPs. With that, the body of its signalling (payload) is encrypted like HTTPs'.
 
Another thing to bear in mind is that these two protocols were extended as the needs arise. Just as I said that there were later hacked to support additional features, the infrastructure also underwent tremendous overhauling - bandwith capacity increase, reduced Signal loss, etc. All of these and much more as the needs necessitated the extension of the various protocols.
 
It mentions SIPS. It says there's still a vulnerability, and that SIP requires a VPN and SIPS to be secure. To add a VPN is a lot, that security should be fully in the SIPS/SIMPLE protocol itself.

The article is a little bit difficult for me to understand because its wording isn't detailed. But it says the data is still not encrypted in SIPS, only certain points of the SIPS connection is secured, and it can be gained access to, even on a VPN. This article was updated a few months ago.

At this time, it seems that SIPS/SIMPLE and XMPP/Jingle are far from perfect solutions. Each one lacks what the other one has: security in one, poor connection strength in the other.


In retrospect, the past needs that are still needed can be put forth, I wish in a hybrid protocol.
 
The article is not an authoritative source. Check IETF RFCs, RFPs and other standardisation groups' documentation. Even w4C might have something. Why VPN? Is HTTP requiring it?
 
So, the author's knowledge is out of date, rather than the article's date? And you're saying HTTP as a transport rather than UDP or HTTPS? SIPS would be the connection, and for the transport HTTP vs HTTPS or UDP. I can see that. HTTP would require a VPN, because it's not HTTPS.

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.

Also, I don't know if this is widely implemented by all applications. 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.

SRTP for SIPS secure voice, perhaps video and perhaps text transport?

/etc/services
Code: 
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

I glanced at one of those pages. I need to look at it again, and the rest of those pages.
 
sidetone said:
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.
Click to expand...

You can build SIP with encryption support. You definitely will see it in the build options for a SIP stack e.g. PJSIP.

sidetone said:
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.
Click to expand...
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.

(S)RTP comes into play after SIP negotiation though it (being secured or not) would have been requested in the negotiation. SIP and (S)RTP, though application layer protocols, with one on top of the other in implementation, can make stateful and stateless connections vis-à-vis TCP/UDP.
 
net/pjsip has the EXTSRTP option for SRTP. There's net/libsrtp2.

net/asterisk13 and net/asterisk16 have SRTP and PJSIP options. This needs to be set and compiled in, due to some potential OpenSSL conflict.

Then there's net/mediastreamer and gstreamer1-plugins-srtp that use SRTP.
Many of these use the same SRTP library, but there are potential conflicts when installing whole ports.

There's nothing that requires any form of SRTP in the ports category of net-im.

This is good, but it looks like these SIP/SIMPLE features aren't widely implemented and anyone in a communication would have to be updated and knowledgeable. It seems like it fits well for an Asterisk PBX setting. This is all very interesting about SIP/SIMPLE.

This is good information to help make an informed choice about SIP/SIMPLE.
 
Huh?
community.jitsi.org

Jitsi Meet: What is XMPP used for?

I installed jitsi meet on my Debian server, and it is working fine. What I do not understand is where XMPP is coming into the game. What is it used for? An example would be nice. The manual installation docs say that xmpp is accessed through the web server, and that the xmpp servertalks with...
community.jitsi.org community.jitsi.org
 
SIP Integration with XMPP in Presence Aware Clients (SIXPAC) in IEFT mailing list,

https://mailarchive.ietf.org/arch/browse/sixpac/


That proposal for a dual stack was discussed there from 2010-2011, but didn't go forward.

A hybrid XMPP/Jingle and SIP/Simple protocol would be better, with the improved features included by default.

It's difficult to know if common applications for mobile phones have the right security transport built in for SIP/Simple. For a desktop or for what's available, it takes an expert to make sure that SIPS is set up and being used. It's not set up to include it as an option by default.


Maybe if certain extensions for XMPP are ensured as being enabled, that will be enough.
 
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 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 Future of Telephony or both books. I learned about the existence of FreeBSD from one of these two books too.


Asterisk: the Definitive Guide is freely available online by the publisher/author. http://www.asteriskdocs.org/
 
sidetone said:
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.
Click to expand...
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.

About SIP security dropping off, once negotiation is completed, payload transmission among clients starts and that's not SIP. Unless, there is negotiated QoS, changes to one client may not affect the other. Remember the keep-alive feature in HTTP, SIP connection repeatedly sends it - keep-alive signal - otherwise a call will be dropped at the receiver's client.

Based on that premise, a change in security settings will be appropriately processed at both ends in the form of a SIP signalling renegotiation. 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.

And Yes, the best security SIP had in its ver. 1 was the unique ID in its header just like HTTP with plain cookie.
 
Lamia said:
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.
Click to expand...
That's good.
 
You must log in or register to reply here.
Back
Top