This would be the same as using TLS, and as I said, it wouldn't be
that hard to figure out exactly what's going on: don't forget that
an RTP session comes after session establishment.
the RTP would be tunneled too, of course.
Eeer ... and Jitsi would be announcing a port on localhost then and you would manually map it over SSH?
I don't think we would be implementing anything similar at any point.
So you are telling me that you are worried about someone seeing that
you established a SIP session with another IP, but somehow it is OK
to know that you established an SSH session?
The ssh is the minimum you can get, I guess.
In the sense that some connection has to be
established, at a certain point.
With ssh the only obvious thing is that there
is a connection, but, in principle, no more
information is leaked.
How is this different? In both cases I know that there was a session between you and a specific IP addresses. The only difference is that in one case I see that TLS+SRTP are being used. In the other case I see it's SSH.
In neither case do I learn what the content of the session is.
If I am, for example, an oppressive government looking to discover links between dissidents, I will be equally happy with both kinds of data. The fact that you had an SSH session to a known dissident would tell me exactly as much as the fact that you had a TLS+SRTP session
If on the other hand a TLS+SRTP connection is being made to a server that I am not controlling then I know nothing more. Specifically, I don't know who you are talking to ( and you might just escape prison ).
Even if we ignore the RTP exchange after that and keep it at SSH you
are still leaking essentially the same metadata so I fail to see
Everything has to be tunneled, SIP/RTP and
whatever else is needed.
I fail to see the point.
Anyways, why would you even use SIP in such a case? Just stream with ffmpeg, VLC or gstreamer and there you are.
Actually, from a generic point of view, what
I fail is to see is the meaning of SIP/RTP/XMPP
as separate protocols, with separate connections.
Media is bulky so having the option of handling it separately from signalling (either with different infrastructure or potentially in a p2p manner) is a great advantage.
The best would be one encrypted container,
carrying all the needed protocols encapsulated.
Some protocols, like IAX, have gone down this path without much success and relatively feeble adoption in clients.
It is always possible for a decoupled solution (such as SIP+RTP) to route everything along the same route. The opposite is not.
Of course, a known one, like ssh or tls.
This is already "naturally" happening with X11,
using the "-X" option of ssh.
Fully transparent, but fully encrypted and masked.
And it would only take for the entire world to be have globally routable IP addresses mapped to DNS names for this to have any chance of even moderate adoption.
This will also reduce the port usage pollution,
since only one "external" IP port wil be required.
It would also require everyone to have either a globally routable address (or the capability to map them on a NAT with a globally routable address), the capability to remember it and give it around (together with those for all the machines we use ... unless you want to also deploy HIP) and also someone to register them in DNS ...
I am not saying you shouldn't do this. But we won't.
FWIW, calls with SIP+BUNDLE+RTCP-MUX only use two ports.
Yes, which is why I said that
a) there are tradeoffs both ways
b) your privacy is improved if you run your own server
I agree on b).
About a), I think that one trade off is
better than the other.
Again, you only manage to hide a little bit of information (which is arguably of no particular value) you potentially reveal more important information (the end destination of your session, as opposed to just that of your next hop) and you are doing that at the cost of tremendous complexity and total lack of usability for average users.
If you are not convinced by now then we can just agree to disagree.
On 22.07.13, 00:22, Piergiorgio Sartor wrote:
On Mon, Jul 22, 2013 at 12:04:55AM +0200, Emil Ivov wrote: