[jitsi-users] Direct PC-to-PC calls


#1

Hiall,

The Wikipedia entry for Jitsi implies that it enables connecting directly peer-to-peer, without a server. Is that true? If so, howdo I set it up? Let's say both sides of the call are running Jitsi, have direct Internet connections (no NAT) and know each other's IP addresses.


#2

Isn't this frowned upon since it opens up the users to a
man-in-the-middle attack? In fact, for some reason, I thought Jitsi
actually disallowed it at one point.

Anthony

···

On 07/21/2013 09:57 AM, Ansis Māliņš wrote:

Then you use SIP without a server. It should be possible to create
a SIP account while leaving server blank. Then you add a contact in
the form of john@<other guy's IP>

--
Anthony Papillion
Phone: 1.918.533.9699
SIP: 17772098750@in.callcentric.com
XMPP: cypherpunk@patts.us

www.cajuntechie.org


#3

Then you use SIP without a server. It should be possible to create a SIP
account while leaving server blank. Then you add a contact in the form of
john@<other guy's IP>

···

On Jul 21, 2013 4:54 PM, <jitsi@realityexists.net> wrote:

Hi all,

The Wikipedia entry for Jitsi implies that it enables connecting directly peer-to-peer,
without a server. Is that true? If so, how do I set it up? Let's say both
sides of the call are running Jitsi, have direct Internet connections (no
NAT) and know each other's IP addresses.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

Thanks, that didn't occur to me.

I've tried this out using a VM. The host (running Jitsi on Windows) and the VM (running Jitsi on Linux) add each other. The host user can see the VM user online, but not vice versa. When I try to call from host to VM it rings (sometimes), and the call comes through in the VM, but when I try to answer it immediately disconnects with the following errors logged (in the VM): http://pastebin.com/kqWAF0rX

If I try to call from the VM to the host (even though the user shows offline) I get an "invalid transport" error: http://pastebin.com/n2SyzTad - or, on other attempts, it just got stuck at "Initiating call".

···

On 21.07.2013 18:57, Ansis Ma-lin,s( wrote:

Then you use SIP without a server. It should be possible to create a SIP account while leaving server blank. Then you add a contact in the form of john@<other guy's IP>

On Jul 21, 2013 4:54 PM, <jitsi@realityexists.net > <mailto:jitsi@realityexists.net>> wrote:

    Hiall,

    The Wikipedia entry for Jitsi implies that it enables connecting
    directly peer-to-peer, without a server. Is that true? If so,
    howdo I set it up? Let's say both sides of the call are running
    Jitsi, have direct Internet connections (no NAT) and know each
    other's IP addresses.

    _______________________________________________
    users mailing list
    users@jitsi.org <mailto:users@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#5

I don't think this represents any specific risks of MitM attacks but yes, we generally advise against using registrarless accounts because they are unreliable and lead to exactly the kind of issues that jitsi@realityexists.net is having.

jitsi@realityexists.net, it might help if you tell us exactly why you'd like to avoid using servers. Is it security? Latency? Curiosity?

Cheers,
Emil

···

On 21.07.13, 19:25, Anthony Papillion wrote:

On 07/21/2013 09:57 AM, Ansis Māliņš wrote:

Then you use SIP without a server. It should be possible to create
a SIP account while leaving server blank. Then you add a contact in
the form of john@<other guy's IP>

Isn't this frowned upon since it opens up the users to a
man-in-the-middle attack? In fact, for some reason, I thought Jitsi
actually disallowed it at one point.

--
https://jitsi.org


#6

A VM using what virtualization solution? Virtualbox, for instance does NAT.
If you want a real world test use a real world setup, two machines,
two IP addresses.
Otherwise we will have to read your rant about how things do not work
in your simulated fantasyy scenario of two VMs in the same machine
which is not a real world usage scenario.

FC

···

On Sun, Jul 21, 2013 at 12:19 PM, <jitsi@realityexists.net> wrote:

I've tried this out using a VM. The host (running Jitsi on Windows) and the
VM (running Jitsi on Linux) add each other.

--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell


#7

We've found connections using Jitsi to be unreliable. Sometimes it fails to connect altogether. Sometimes it connects, but then drops out. Sometimes it connects, but only one side can hear the other. Video also hasn't worked. At this stage I don't know whether the issue is on the client or on the server, so I'd like to eliminate the server as a factor.

In theory, if we can connect directly then a server offers little benefit anyway. In practice, it appears that connecting directly is even less reliable.

···

On 21.07.2013 22:44, Emil Ivov wrote:

On 21.07.13, 19:25, Anthony Papillion wrote:

On 07/21/2013 09:57 AM, Ansis Māliņš wrote:

Then you use SIP without a server. It should be possible to create
a SIP account while leaving server blank. Then you add a contact in
the form of john@<other guy's IP>

Isn't this frowned upon since it opens up the users to a
man-in-the-middle attack? In fact, for some reason, I thought Jitsi
actually disallowed it at one point.

I don't think this represents any specific risks of MitM attacks but yes, we generally advise against using registrarless accounts because they are unreliable and lead to exactly the kind of issues that jitsi@realityexists.net is having.

jitsi@realityexists.net, it might help if you tell us exactly why you'd like to avoid using servers. Is it security? Latency? Curiosity?

Cheers,
Emil


#8

We've found connections using Jitsi to be unreliable. In practice, it

appears that connecting directly is even less reliable.

Have you considered running your own XMPP server in that case?

···

On 21 July 2013 13:01, <jitsi@realityexists.net> wrote:

We've found connections using Jitsi to be unreliable. Sometimes it fails
to connect altogether. Sometimes it connects, but then drops out. Sometimes
it connects, but only one side can hear the other. Video also hasn't
worked. At this stage I don't know whether the issue is on the client or on
the server, so I'd like to eliminate the server as a factor.

In theory, if we can connect directly then a server offers little benefit
anyway. In practice, it appears that connecting directly is even less
reliable.

On 21.07.2013 22:44, Emil Ivov wrote:

On 21.07.13, 19:25, Anthony Papillion wrote:

On 07/21/2013 09:57 AM, Ansis Māliņš wrote:

Then you use SIP without a server. It should be possible to create
a SIP account while leaving server blank. Then you add a contact in
the form of john@<other guy's IP>

Isn't this frowned upon since it opens up the users to a
man-in-the-middle attack? In fact, for some reason, I thought Jitsi
actually disallowed it at one point.

I don't think this represents any specific risks of MitM attacks but yes,
we generally advise against using registrarless accounts because they are
unreliable and lead to exactly the kind of issues that
jitsi@realityexists.net is having.

jitsi@realityexists.net, it might help if you tell us exactly why you'd
like to avoid using servers. Is it security? Latency? Curiosity?

Cheers,
Emil

______________________________**_________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/users<http://lists.jitsi.org/mailman/listinfo/users>

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info


#9

We've found connections using Jitsi to be unreliable.

If you don't use a server it will be yes.

Sometimes it fails
to connect altogether. Sometimes it connects, but then drops out.
Sometimes it connects, but only one side can hear the other. Video also
hasn't worked. At this stage I don't know whether the issue is on the
client or on the server, so I'd like to eliminate the server as a factor.

You can try connecting through ippi.com then. That server is known to work.

In theory, if we can connect directly then a server offers little
benefit anyway.

In theory yes, but that's only the case in a very specific set of scenarios. We therefore don't spend a lot of effort making sure that serverless mode works well.

In practice, it appears that connecting directly is even
less reliable.

Exactly,
Emil

···

On 21.07.13, 22:01, jitsi@realityexists.net wrote:

On 21.07.2013 22:44, Emil Ivov wrote:

On 21.07.13, 19:25, Anthony Papillion wrote:

On 07/21/2013 09:57 AM, Ansis Māliņš wrote:

Then you use SIP without a server. It should be possible to create
a SIP account while leaving server blank. Then you add a contact in
the form of john@<other guy's IP>

Isn't this frowned upon since it opens up the users to a
man-in-the-middle attack? In fact, for some reason, I thought Jitsi
actually disallowed it at one point.

I don't think this represents any specific risks of MitM attacks but
yes, we generally advise against using registrarless accounts because
they are unreliable and lead to exactly the kind of issues that
jitsi@realityexists.net is having.

jitsi@realityexists.net, it might help if you tell us exactly why
you'd like to avoid using servers. Is it security? Latency? Curiosity?

Cheers,
Emil

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#10

Hi Emil,

[...]

In theory yes, but that's only the case in a very specific set of
scenarios. We therefore don't spend a lot of effort making sure that
serverless mode works well.

there is anyway the point that "serverless" is
more "secure".
I mean, apart from ZRTP, the server, AFAIK, can
track the "metadata", that is when two IPs gets
together. So, even if the content of the conversation
is unknown, still there is the possibility to
track who is talking with whom and when.
Serverless would eliminate this last "leakage".

Now, it is clear that all the NAT stuff work
easily and better with servers, nevertheless it
would be wise to look into some scenarios where
serverless could be used reliably.

Of course, local installation of servers like
"Prosody" might be an option too.

bye,

···

On Sun, Jul 21, 2013 at 10:19:17PM +0200, Emil Ivov wrote:

--

piergiorgio


#11

Hi Emil,

[...]

In theory yes, but that's only the case in a very specific set of
scenarios. We therefore don't spend a lot of effort making sure that
serverless mode works well.

there is anyway the point that "serverless" is
more "secure".
I mean, apart from ZRTP, the server, AFAIK, can
track the "metadata", that is when two IPs gets
together. So, even if the content of the conversation
is unknown, still there is the possibility to
track who is talking with whom and when.
Serverless would eliminate this last "leakage".

Not necessarily. That kind of data can also be obtained from anyone that's on your path. Your Internet provider, hotspot admin, or those of your peer for example.

Using a server with a TLS connection makes this data unavailable to them. So it's a tradeoff either way.

If you are controlling the server then you could even be considered beter off that way.

Now, it is clear that all the NAT stuff work
easily and better with servers, nevertheless it
would be wise to look into some scenarios where
serverless could be used reliably.

I don't believe this is realistic.

That said, if anyone here feels like contributing patches on some specific problems with our registrarless accounts: don't hesitate.

Cheers,
Emil

···

On 21.07.13, 22:30, Piergiorgio Sartor wrote:

On Sun, Jul 21, 2013 at 10:19:17PM +0200, Emil Ivov wrote:

Of course, local installation of servers like
"Prosody" might be an option too.

bye,

--
https://jitsi.org


#12

Hi Emil,

[...]

Not necessarily. That kind of data can also be obtained from anyone
that's on your path. Your Internet provider, hotspot admin, or those
of your peer for example.

I'm not sure, I mean, what they can track is
that a connection was established, but this
could be anything, for example "tor" or else.
I mean, given the assumption that it starts
tunneled encrypted.

Using a server with a TLS connection makes this data unavailable to
them. So it's a tradeoff either way.

I'm not expert, but how can the server not know
the data flow "from-to"?
Isn't the data going always thru the server?

If you are controlling the server then you could even be considered
beter off that way.

So, the best to do would be to install a
server in one of the (two) client PCs?

bye,

···

On Sun, Jul 21, 2013 at 10:44:22PM +0200, Emil Ivov wrote:

--

piergiorgio


#13

Hi Emil,

[...]

Not necessarily. That kind of data can also be obtained from anyone
that's on your path. Your Internet provider, hotspot admin, or those
of your peer for example.

I'm not sure, I mean, what they can track is
that a connection was established, but this
could be anything, for example "tor" or else.
I mean, given the assumption that it starts
tunneled encrypted.

If it starts tunnelled then you are using a server. If by encrypted you mean TLS then, yeas headers wouldn't be visible but it would still be possible to guess relatively reliably that a certain session was SIP followed by RTP.

And of course in this case your peer is fairly obvious.

Note that for the above to work you both need to have public addresses and no firewalling for the ports you use for SIP.

All in all, a scenario that's tricky to setup and with very questionable benefits.

Using a server with a TLS connection makes this data unavailable to
them. So it's a tradeoff either way.

I'm not expert, but how can the server not know
the data flow "from-to"?
Isn't the data going always thru the server?

My point here was that if you connect to a SIP server using TLS, then your Internet provider or hotspot admin don't know where your calls are going to.

If you don't use a server, they do.

If you are controlling the server then you could even be considered
beter off that way.

So, the best to do would be to install a
server in one of the (two) client PCs?

Why would it have to be on the client PCs? Just running your own server anywhere, improves your service and privacy by a lot.

Emil

···

On 21.07.13, 22:58, Piergiorgio Sartor wrote:

On Sun, Jul 21, 2013 at 10:44:22PM +0200, Emil Ivov wrote:

--
https://jitsi.org


#14

Hi Emil,

[...]

If it starts tunnelled then you are using a server. If by encrypted
you mean TLS then, yeas headers wouldn't be visible but it would
still be possible to guess relatively reliably that a certain
session was SIP followed by RTP.

maybe we have some misunderstanding here.
I can establish a ssh tunnel, with local port(s)
mapped to a remote machine and the other way
around, without any server in the middle.
Only the "local" ssh server(s).

There is no way to know what kind of traffic
is passing in the tunnel.
So, the only information the ISP can track is
that there was a connection between IP1 and IP2
at a certain time.

All in all, a scenario that's tricky to setup and with very
questionable benefits.

I agree, it is tricky.

[...]

My point here was that if you connect to a SIP server using TLS,
then your Internet provider or hotspot admin don't know where your
calls are going to.

The SIP server knows,

If you don't use a server, they do.

I think it does not matter who knows, ISP or SIP :-),
someone knows anyway.
The difference is that, with tunneling, the ISP does
only know that there is a connection, but not what for.
The SIP server knows exactly what is the scope of the
connection.

[...]

Why would it have to be on the client PCs? Just running your own
server anywhere, improves your service and privacy by a lot.

I guess you're right, the server needs to be
somewhere else, under the direct control of
the user(s), for the best security and, maybe,
for performances too.

Thanks,

bye,

···

On Sun, Jul 21, 2013 at 11:04:50PM +0200, Emil Ivov wrote:

--

piergiorgio


#15

Hi Emil,

[...]

If it starts tunnelled then you are using a server. If by encrypted
you mean TLS then, yeas headers wouldn't be visible but it would
still be possible to guess relatively reliably that a certain
session was SIP followed by RTP.

maybe we have some misunderstanding here.
I can establish a ssh tunnel, with local port(s)
mapped to a remote machine and the other way
around, without any server in the middle.
Only the "local" ssh server(s).

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.

There is no way to know what kind of traffic
is passing in the tunnel.
So, the only information the ISP can track is
that there was a connection between IP1 and IP2
at a certain time.

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?

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 your point.

All in all, a scenario that's tricky to setup and with very
questionable benefits.

I agree, it is tricky.

[...]

My point here was that if you connect to a SIP server using TLS,
then your Internet provider or hotspot admin don't know where your
calls are going to.

The SIP server knows,

Yes, which is why I said that

a) there are tradeoffs both ways
b) your privacy is improved if you run your own server

If you don't use a server, they do.

I think it does not matter who knows, ISP or SIP :-),
someone knows anyway.
The difference is that, with tunneling, the ISP does
only know that there is a connection, but not what for.
The SIP server knows exactly what is the scope of the
connection.

see above

Emil

···

On 21.07.13, 23:35, Piergiorgio Sartor wrote:

On Sun, Jul 21, 2013 at 11:04:50PM +0200, Emil Ivov wrote:

Why would it have to be on the client PCs? Just running your own
server anywhere, improves your service and privacy by a lot.

I guess you're right, the server needs to be
somewhere else, under the direct control of
the user(s), for the best security and, maybe,
for performances too.

Thanks,

bye,

--
https://jitsi.org


#16

Thank you, I tried out Prosody and it works. Users can see each other online and exchange text messages and make/receive voice calls.

There is still no video, but I think that's a client-side issue. The video preview in Options, Video works fine - I can see myself. When I enable video during a call the video window appears (on both local and remote sides), but it's black. On my side (the side enabling video) I get this in the Jitsi log:

21:08:25.186 SEVERE: [240] util.UtilActivator.uncaughtException().91 An uncaught exception occurred in thread=Thread[Thread-72,6,main] and message was: -8
java.lang.ArrayIndexOutOfBoundsException: -8
     at org.jitsi.impl.neomedia.RawPacket.readInt(RawPacket.java:188)
     at org.jitsi.impl.neomedia.RawPacket.getSRTCPIndex(RawPacket.java:542)
     at org.jitsi.impl.neomedia.transform.srtp.SRTCPCryptoContext.reverseTransformPacket(SRTCPCryptoContext.java:378)
     at org.jitsi.impl.neomedia.transform.srtp.SRTCPTransformer.reverseTransform(SRTCPTransformer.java:123)
     at org.jitsi.impl.neomedia.transform.zrtp.ZRTCPTransformer.reverseTransform(ZRTCPTransformer.java:82)
     at org.jitsi.impl.neomedia.transform.TransformEngineChain$PacketTransformerChain.reverseTransform(TransformEngineChain.java:179)
     at org.jitsi.impl.neomedia.transform.TransformUDPInputStream.createRawPacket(TransformUDPInputStream.java:65)
     at org.jitsi.impl.neomedia.RTPConnectorInputStream.run(RTPConnectorInputStream.java:338)
     at java.lang.Thread.run(Unknown Source)
21:08:25.266 INFO: [229] org.ice4j.ice.Agent.run() ICE state is TERMINATED

···

On 22.07.2013 0:30, Piergiorgio Sartor wrote:

Hi Emil,

On Sun, Jul 21, 2013 at 10:19:17PM +0200, Emil Ivov wrote:
[...]

In theory yes, but that's only the case in a very specific set of
scenarios. We therefore don't spend a lot of effort making sure that
serverless mode works well.

there is anyway the point that "serverless" is
more "secure".
I mean, apart from ZRTP, the server, AFAIK, can
track the "metadata", that is when two IPs gets
together. So, even if the content of the conversation
is unknown, still there is the possibility to
track who is talking with whom and when.
Serverless would eliminate this last "leakage".

Now, it is clear that all the NAT stuff work
easily and better with servers, nevertheless it
would be wise to look into some scenarios where
serverless could be used reliably.

Of course, local installation of servers like
"Prosody" might be an option too.

bye,


#17

Hi Emil,

[...]

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.

[...]

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.

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
your point.

Everything has to be tunneled, SIP/RTP and
whatever else is needed.

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.
The best would be one encrypted container,
carrying all the needed protocols encapsulated.
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.

This will also reduce the port usage pollution,
since only one "external" IP port wil be required.

[...]

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.

bye,

···

On Mon, Jul 22, 2013 at 12:04:55AM +0200, Emil Ivov wrote:

--

piergiorgio


#18

This may not be your problem, but just in case: quit any other programs that make use of the web cam, e.g. Skype. Then quit and restart jitsi. We also had black video and that was the cause but your issue may of course be different.

···

Thank you, I tried out Prosody and it works. Users can see each other online and exchange text messages and make/receive voice calls.

There is still no video, but I think that's a client-side issue. The video preview in Options, Video works fine - I can see myself. When I enable video during a call the video window appears (on both local and remote sides), but it's black. On my side (the side enabling video) I get this in the Jitsi log:

21:08:25.186 SEVERE: [240] util.UtilActivator.uncaughtException().91 An uncaught exception occurred in thread=Thread[Thread-72,6,main] and message was: -8
java.lang.ArrayIndexOutOfBoundsException: -8
     at org.jitsi.impl.neomedia.RawPacket.readInt(RawPacket.java:188)
     at org.jitsi.impl.neomedia.RawPacket.getSRTCPIndex(RawPacket.java:542)
     at org.jitsi.impl.neomedia.transform.srtp.SRTCPCryptoContext.reverseTransformPacket(SRTCPCryptoContext.java:378)
     at org.jitsi.impl.neomedia.transform.srtp.SRTCPTransformer.reverseTransform(SRTCPTransformer.java:123)
     at org.jitsi.impl.neomedia.transform.zrtp.ZRTCPTransformer.reverseTransform(ZRTCPTransformer.java:82)
     at org.jitsi.impl.neomedia.transform.TransformEngineChain$PacketTransformerChain.reverseTransform(TransformEngineChain.java:179)
     at org.jitsi.impl.neomedia.transform.TransformUDPInputStream.createRawPacket(TransformUDPInputStream.java:65)
     at org.jitsi.impl.neomedia.RTPConnectorInputStream.run(RTPConnectorInputStream.java:338)
     at java.lang.Thread.run(Unknown Source)
21:08:25.266 INFO: [229] org.ice4j.ice.Agent.run() ICE state is TERMINATED

On 22.07.2013 0:30, Piergiorgio Sartor wrote:

Hi Emil,

On Sun, Jul 21, 2013 at 10:19:17PM +0200, Emil Ivov wrote:
[...]

In theory yes, but that's only the case in a very specific set of
scenarios. We therefore don't spend a lot of effort making sure that
serverless mode works well.

there is anyway the point that "serverless" is
more "secure".
I mean, apart from ZRTP, the server, AFAIK, can
track the "metadata", that is when two IPs gets
together. So, even if the content of the conversation
is unknown, still there is the possibility to
track who is talking with whom and when.
Serverless would eliminate this last "leakage".

Now, it is clear that all the NAT stuff work
easily and better with servers, nevertheless it
would be wise to look into some scenarios where
serverless could be used reliably.

Of course, local installation of servers like
"Prosody" might be an option too.

bye,

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#19

Hi Emil,

[...]

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 :wink: ).

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
your point.

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.

Scalability. Flexibility.

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.

Emil

···

On 22.07.13, 00:22, Piergiorgio Sartor wrote:

On Mon, Jul 22, 2013 at 12:04:55AM +0200, Emil Ivov wrote:

bye,

--
https://jitsi.org


#20

Different protocols, for different needs, developed by different
people, over different periods of time.
Jitsi integrates them in a single client.

Not supporting industry-standard and open protocols would put Jitsi in
the same category as Skype, a proprietary solution that speaks a
proprietary protocol, that has zero interoperability with other client
software, and which basically can talk only to itself.

I know that in the world of Apple and walled gardens, the value of
open solutions and interoperability takes a bit of effort to
understand, but please try to make an effort. Its like the open
internet vs Farcebook.

If you want to design a single protocol that takes over SIP and XMPP
the IETF will surely listen to your proposal, but it will take a while
(think:years) before it gains any traction because the industry has
already invested quite a bit of development effort in supporting
today's open protocols.

FC

···

On Sun, Jul 21, 2013 at 7:22 PM, Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> wrote:

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.

--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell