[jitsi-users] Re: Various connectivity and usage issues


#1

Bump. Was wondering if anyone had any thoughts on any of the below?

Alexis.

----- Forwarded message from Alexis <flexibeast@gmail.com> -----

From: Alexis <flexibeast@gmail.com>
To: users@jitsi.java.net
Date: Sun, 24 Mar 2013 20:54:24 +1100
Subject: Various connectivity and usage issues

Hi all,

I've recently been looking into Jitsi as a replacement for Skype, and
it's looking wonderfully promising - thank you to all who have
contributed to it!

There are several issues I'd like to raise:

(a) I can't seem to get a connection between NAT'd hosts on two
different LANs I manage. The NATing is being performed by Linux's
iptables (via masquerading) on the gateway machines for both
LANs. Pictorially:

+---------+ \
> Host A | |
+---------+ |
     > +-- LAN 1
+-----------+ |
> Gateway B | |
+-----------+ /
     >
+----------+
> Internet |
+----------+
     >
+-----------+ \
> Gateway C | |
+-----------+ |
     > +-- LAN 2
+--------+ |
> Host D | |
+--------+ /

Configuring both gateway machines to have the iptables rule:

-A FORWARD -p udp -m multiport --ports 1024:65535 -j ACCEPT

allows one to make and receive calls from/to either of those LANs to
a non-NAT'd third party elsewhere on the Internet; but attempts to
make calls between these two LANs results in ICE failures. What am I
missing?

(b) More generally, can the above iptables rule be made more specific,
e.g. specifying particular source and destination ports / port ranges,
rather than the above generic port range?

(c) Something in the ICE harvesting process is taking 60 seconds to
timeout, so that it takes at least that long for either the "Ringing"
process to be initiated (upon ICE success) or to report ICE
failure. Relevant log extracts are appended to the end of this email.

(d) In GTalk-based interactions between a host on one of the above
LANs and the abovementioned third party (who I'll refer to as 'E'),
only one person will have icons in the Jisti roster display enabling
them to make voice/video calls. So if I log in to GTalk on Host A, and
then E logs in to GTalk in Jitsi on their own box, their roster in
Jitsi will show the icons enabling them to make a voice and/or video
call, whereas my roster won't. Conversely: if E logs in to GTalk in
Jitsi, and then I log in to GTalk in Jitsi on Host A, the voice/video
icons will be displayed for me, but not for E. The voice/video icons
are still available when one opens a chat window, however, and seem to
work.

(e) One of the hosts I manage is a laptop in which the built-in Webcam
has been installed upside-down. :-/ With this host, a freestanding USB
Webcam is used. Jitsi recognises its existence, but no image data is
displayed. (It works fine in Skype.) Even if this issue could
be fixed, how difficult would it be to add vertical/horizontal video
flip functionality to Jitsi? I've tried using v4l2ucp to do vertical
flipping, but that doesn't seem to influence video output in either
Skype or Jitsi (even though logs seem to indicate that Jitsi does make
use of the v4l2 subsystem).

If there's any further information I can provide regarding any of the
above, please let me know!

Thanks in anticipation,

Alexis.

--- BEGIN LOG EXTRACT ---

20:33:49.662 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().442 Found Google STUN server STUN harvester for srvr: stun.l.google.com/74.125.31.127:19302/udp
20:33:50.623 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().411 Google TURN descriptor
20:33:50.623 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().418 new Google TURN harvester
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().411 Google TURN descriptor
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().418 new Google TURN harvester
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().411 Google TURN descriptor
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().418 new Google TURN harvester
20:33:50.628 INFO: [22] impl.protocol.jabber.CallPeerMediaHandlerJabberImpl.harvestCandidates().1079 End candidate harvest within 1 ms
20:33:50.628 INFO: [23] org.ice4j.ice.Agent.createMediaStream() Create media stream for audio
20:33:50.634 INFO: [23] org.ice4j.ice.Agent.createComponent() Create component audio.1
20:33:50.635 INFO: [23] org.ice4j.ice.Agent.gatherCandidates() Gather candidates for component audio.1
20:33:50.640 INFO: [23] org.ice4j.ice.harvest.HostCandidateHarvester.harvest() End candidate harvest within 5 ms, for org.ice4j.ice.harvest.HostCandidateHarvester, component: 1
20:33:50.641 INFO: [23] org.ice4j.ice.harvest.HostCandidateHarvester.harvest() End candidate harvest within 6 ms, for org.ice4j.ice.harvest.HostCandidateHarvester, component: 1
20:33:50.642 INFO: [24] impl.protocol.jabber.JingleNodesHarvester.harvest().79 harvest Jingle Nodes
20:33:50.643 INFO: [24] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 1 ms, for net.java.sip.communicator.impl.protocol.jabber.JingleNodesHarvester, component: 1
20:33:50.643 INFO: [24] org.ice4j.ice.harvest.CandidateHarvesterSet.setEnabled() disabling harvester: net.java.sip.communicator.impl.protocol.jabber.JingleNodesHarvester@30fb71
20:33:50.868 INFO: [25] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: stun.l.google.com/74.125.31.127:19302/udp / audio / 1found 1 candidates.
20:33:50.868 INFO: [25] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 226 ms, for org.ice4j.ice.harvest.StunCandidateHarvester, component: 1
20:33:50.871 INFO: [26] org.ice4j.ice.harvest.GoogleTurnCandidateHarvest.processSuccess() Successful Google TURN allocate
20:33:50.871 INFO: [27] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: /173.194.72.127:19305/udp / audio / 1found 1 candidates.
20:33:50.872 INFO: [27] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 230 ms, for org.ice4j.ice.harvest.GoogleTurnCandidateHarvester, component: 1
20:33:51.191 INFO: [26] org.ice4j.ice.harvest.GoogleTurnCandidateHarvest.processSuccess() Successful Google TURN allocate
20:33:51.191 INFO: [28] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: /173.194.72.127:443/tcp / audio / 1found 1 candidates.
20:33:51.192 INFO: [28] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 550 ms, for org.ice4j.ice.harvest.GoogleTurnSSLCandidateHarvester, component: 1
20:34:13.470 WARNING: [29] org.ice4j.stack.Connector.run() Connector died: /192.168.1.30:56787/tcp
java.net.SocketException: read failed
  at org.ice4j.socket.DelegatingSocket.receiveFromNetwork(DelegatingSocket.java:892)
  at org.ice4j.socket.DelegatingSocket.receive(DelegatingSocket.java:834)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:350)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:292)
  at org.ice4j.socket.MultiplexedSocket.receive(MultiplexedSocket.java:135)
  at org.ice4j.socket.IceTcpSocketWrapper.receive(IceTcpSocketWrapper.java:84)
  at org.ice4j.stack.Connector.run(Connector.java:175)
  at java.lang.Thread.run(Thread.java:679)
20:34:13.471 WARNING: [29] org.ice4j.stack.NetAccessManager.handleFatalError() Removing connector:ice4j.Connector@/192.168.1.30:56787/tcp status: running
java.net.SocketException: read failed
  at org.ice4j.socket.DelegatingSocket.receiveFromNetwork(DelegatingSocket.java:892)
  at org.ice4j.socket.DelegatingSocket.receive(DelegatingSocket.java:834)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:350)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:292)
  at org.ice4j.socket.MultiplexedSocket.receive(MultiplexedSocket.java:135)
  at org.ice4j.socket.IceTcpSocketWrapper.receive(IceTcpSocketWrapper.java:84)
  at org.ice4j.stack.Connector.run(Connector.java:175)
  at java.lang.Thread.run(Thread.java:679)
20:34:53.725 INFO: [30] org.ice4j.ice.harvest.StunCandidateHarvester.getHostCandidate() Exception TCP client connect: java.net.ConnectException: Connection timed out
20:34:53.725 INFO: [30] org.ice4j.ice.harvest.StunCandidateHarvester.startResolvingCandidate() server/candidate address type mismatch, skipping candidate in this harvester
20:34:53.725 INFO: [30] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: /173.194.72.127:19305/tcp / audio / 1found 0 candidates.
20:34:53.726 INFO: [30] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 63084 ms, for org.ice4j.ice.harvest.GoogleTurnCandidateHarvester, component: 1
20:34:53.726 INFO: [30] org.ice4j.ice.harvest.CandidateHarvesterSet.setEnabled() disabling harvester: STUN harvester for srvr: /173.194.72.127:19305/tcp
20:34:53.726 INFO: [23] org.ice4j.ice.Agent.gatherCandidates() End candidate harvest for all harvesters within 63091 ms, component: 1

--- END LOG EXTRACT ---

----- End forwarded message -----


#2

Can't really help but I do have a similar issue: I would like to be
able to communicate
across the Internet using registrar-less SIP. I have got various ports
open and I can talk to jitsi from the Internet
using sipsak. AFAICT the problem is jitsi insists that it's address
for RTP is whatever the OS says it is (which of course is wrong in any
sort of NAT scenario)
I have static IP: it would be nice to have a config option to be able
to tell jitsi what it's public IP address is.

"Just use a SIP registrar" is probably the answer I will get here, and
is the only suggestion I can give you.

···

On Sat, Apr 6, 2013 at 11:22 PM, Alexis <flexibeast@gmail.com> wrote:

Bump. Was wondering if anyone had any thoughts on any of the below?


#3

Hey Alexis,

Bump. Was wondering if anyone had any thoughts on any of the below?

Yup, sorry for the delay.

Alexis.

----- Forwarded message from Alexis <flexibeast@gmail.com> -----

From: Alexis <flexibeast@gmail.com>
To: users@jitsi.java.net
Date: Sun, 24 Mar 2013 20:54:24 +1100
Subject: Various connectivity and usage issues

Hi all,

I've recently been looking into Jitsi as a replacement for Skype, and
it's looking wonderfully promising - thank you to all who have
contributed to it!

There are several issues I'd like to raise:

(a) I can't seem to get a connection between NAT'd hosts on two
different LANs I manage. The NATing is being performed by Linux's
iptables (via masquerading) on the gateway machines for both
LANs. Pictorially:

+---------+ \
> Host A | |
+---------+ |
     > +-- LAN 1
+-----------+ |
> Gateway B | |
+-----------+ /
     >
+----------+
> Internet |
+----------+
     >
+-----------+ \
> Gateway C | |
+-----------+ |
     > +-- LAN 2
+--------+ |
> Host D | |
+--------+ /

Configuring both gateway machines to have the iptables rule:

-A FORWARD -p udp -m multiport --ports 1024:65535 -j ACCEPT
allows one to make and receive calls from/to either of those LANs to
a non-NAT'd third party elsewhere on the Internet; but attempts to
make calls between these two LANs results in ICE failures. What am I
missing?

(b) More generally, can the above iptables rule be made more specific,
e.g. specifying particular source and destination ports / port ranges,
rather than the above generic port range?

By default Jitsi would use ports between 5000 and 6000 for media. That
said I don't quite see why you would want to limit the above. You need
hoses in your LAN to initiate an outbound connection anyway.

(c) Something in the ICE harvesting process is taking 60 seconds to
timeout, so that it takes at least that long for either the "Ringing"
process to be initiated (upon ICE success) or to report ICE
failure. Relevant log extracts are appended to the end of this email.

Seems to be the GTalk relay. Can you try the same experiments with
jit.si accounts? This way Jitsi would be using standard Jingle rather
than the Google vernacular.

(d) In GTalk-based interactions between a host on one of the above
LANs and the abovementioned third party (who I'll refer to as 'E'),
only one person will have icons in the Jisti roster display enabling
them to make voice/video calls. So if I log in to GTalk on Host A, and
then E logs in to GTalk in Jitsi on their own box, their roster in
Jitsi will show the icons enabling them to make a voice and/or video
call, whereas my roster won't. Conversely: if E logs in to GTalk in
Jitsi, and then I log in to GTalk in Jitsi on Host A, the voice/video
icons will be displayed for me, but not for E. The voice/video icons
are still available when one opens a chat window, however, and seem to
work.

(e) One of the hosts I manage is a laptop in which the built-in Webcam
has been installed upside-down. :-/ With this host, a freestanding USB
Webcam is used. Jitsi recognises its existence, but no image data is
displayed. (It works fine in Skype.) Even if this issue could
be fixed, how difficult would it be to add vertical/horizontal video
flip functionality to Jitsi?

Not that difficult. The difficult part would be about discovering when
you need it.

Cheers,
Emil

···

On 06.04.13, 14:22, Alexis wrote:

I've tried using v4l2ucp to do vertical
flipping, but that doesn't seem to influence video output in either
Skype or Jitsi (even though logs seem to indicate that Jitsi does make
use of the v4l2 subsystem).

If there's any further information I can provide regarding any of the
above, please let me know!

Thanks in anticipation,

Alexis.

--- BEGIN LOG EXTRACT ---

20:33:49.662 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().442 Found Google STUN server STUN harvester for srvr: stun.l.google.com/74.125.31.127:19302/udp
20:33:50.623 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().411 Google TURN descriptor
20:33:50.623 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().418 new Google TURN harvester
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().411 Google TURN descriptor
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().418 new Google TURN harvester
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().411 Google TURN descriptor
20:33:50.625 INFO: [22] impl.protocol.jabber.TransportManagerGTalkImpl.createAgent().418 new Google TURN harvester
20:33:50.628 INFO: [22] impl.protocol.jabber.CallPeerMediaHandlerJabberImpl.harvestCandidates().1079 End candidate harvest within 1 ms
20:33:50.628 INFO: [23] org.ice4j.ice.Agent.createMediaStream() Create media stream for audio
20:33:50.634 INFO: [23] org.ice4j.ice.Agent.createComponent() Create component audio.1
20:33:50.635 INFO: [23] org.ice4j.ice.Agent.gatherCandidates() Gather candidates for component audio.1
20:33:50.640 INFO: [23] org.ice4j.ice.harvest.HostCandidateHarvester.harvest() End candidate harvest within 5 ms, for org.ice4j.ice.harvest.HostCandidateHarvester, component: 1
20:33:50.641 INFO: [23] org.ice4j.ice.harvest.HostCandidateHarvester.harvest() End candidate harvest within 6 ms, for org.ice4j.ice.harvest.HostCandidateHarvester, component: 1
20:33:50.642 INFO: [24] impl.protocol.jabber.JingleNodesHarvester.harvest().79 harvest Jingle Nodes
20:33:50.643 INFO: [24] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 1 ms, for net.java.sip.communicator.impl.protocol.jabber.JingleNodesHarvester, component: 1
20:33:50.643 INFO: [24] org.ice4j.ice.harvest.CandidateHarvesterSet.setEnabled() disabling harvester: net.java.sip.communicator.impl.protocol.jabber.JingleNodesHarvester@30fb71
20:33:50.868 INFO: [25] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: stun.l.google.com/74.125.31.127:19302/udp / audio / 1found 1 candidates.
20:33:50.868 INFO: [25] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 226 ms, for org.ice4j.ice.harvest.StunCandidateHarvester, component: 1
20:33:50.871 INFO: [26] org.ice4j.ice.harvest.GoogleTurnCandidateHarvest.processSuccess() Successful Google TURN allocate
20:33:50.871 INFO: [27] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: /173.194.72.127:19305/udp / audio / 1found 1 candidates.
20:33:50.872 INFO: [27] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 230 ms, for org.ice4j.ice.harvest.GoogleTurnCandidateHarvester, component: 1
20:33:51.191 INFO: [26] org.ice4j.ice.harvest.GoogleTurnCandidateHarvest.processSuccess() Successful Google TURN allocate
20:33:51.191 INFO: [28] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: /173.194.72.127:443/tcp / audio / 1found 1 candidates.
20:33:51.192 INFO: [28] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 550 ms, for org.ice4j.ice.harvest.GoogleTurnSSLCandidateHarvester, component: 1
20:34:13.470 WARNING: [29] org.ice4j.stack.Connector.run() Connector died: /192.168.1.30:56787/tcp
java.net.SocketException: read failed
  at org.ice4j.socket.DelegatingSocket.receiveFromNetwork(DelegatingSocket.java:892)
  at org.ice4j.socket.DelegatingSocket.receive(DelegatingSocket.java:834)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:350)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:292)
  at org.ice4j.socket.MultiplexedSocket.receive(MultiplexedSocket.java:135)
  at org.ice4j.socket.IceTcpSocketWrapper.receive(IceTcpSocketWrapper.java:84)
  at org.ice4j.stack.Connector.run(Connector.java:175)
  at java.lang.Thread.run(Thread.java:679)
20:34:13.471 WARNING: [29] org.ice4j.stack.NetAccessManager.handleFatalError() Removing connector:ice4j.Connector@/192.168.1.30:56787/tcp status: running
java.net.SocketException: read failed
  at org.ice4j.socket.DelegatingSocket.receiveFromNetwork(DelegatingSocket.java:892)
  at org.ice4j.socket.DelegatingSocket.receive(DelegatingSocket.java:834)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:350)
  at org.ice4j.socket.MultiplexingSocket.receive(MultiplexingSocket.java:292)
  at org.ice4j.socket.MultiplexedSocket.receive(MultiplexedSocket.java:135)
  at org.ice4j.socket.IceTcpSocketWrapper.receive(IceTcpSocketWrapper.java:84)
  at org.ice4j.stack.Connector.run(Connector.java:175)
  at java.lang.Thread.run(Thread.java:679)
20:34:53.725 INFO: [30] org.ice4j.ice.harvest.StunCandidateHarvester.getHostCandidate() Exception TCP client connect: java.net.ConnectException: Connection timed out
20:34:53.725 INFO: [30] org.ice4j.ice.harvest.StunCandidateHarvester.startResolvingCandidate() server/candidate address type mismatch, skipping candidate in this harvester
20:34:53.725 INFO: [30] org.ice4j.ice.harvest.StunCandidateHarvester.harvest() harvest / stream.component: STUN harvester for srvr: /173.194.72.127:19305/tcp / audio / 1found 0 candidates.
20:34:53.726 INFO: [30] org.ice4j.ice.harvest.CandidateHarvesterSet.harvest() End candidate harvest within 63084 ms, for org.ice4j.ice.harvest.GoogleTurnCandidateHarvester, component: 1
20:34:53.726 INFO: [30] org.ice4j.ice.harvest.CandidateHarvesterSet.setEnabled() disabling harvester: STUN harvester for srvr: /173.194.72.127:19305/tcp
20:34:53.726 INFO: [23] org.ice4j.ice.Agent.gatherCandidates() End candidate harvest for all harvesters within 63091 ms, component: 1

--- END LOG EXTRACT ---

----- End forwarded message -----

--
https://jitsi.org


#4

Hey Ian,

> Bump. Was wondering if anyone had any thoughts on any of the below?
Can't really help but I do have a similar issue: I would like to be
able to communicate
across the Internet using registrar-less SIP.

There's not a whole lot a SIP client can do here without the help of a
server.

I have got various ports
open and I can talk to jitsi from the Internet
using sipsak. AFAICT the problem is jitsi insists that it's address
for RTP is whatever the OS says it is (which of course is wrong in any
sort of NAT scenario)

This is not quite accurate. Most SIP servers would use the private address
as a cue to perfrorm latching:

http://tools.ietf.org/html/draft-ivov-mmusic-latching-03

I have static IP: it would be nice to have a config option to be able
to tell jitsi what it's public IP address is.

You would also need to indicate a port range. Such configuration options
are likely to help a very limited number of users so I don't think we'll be
working on this.

We will however be starting work on ICE support for SIP soon, so this is
likely to make things easier.

"Just use a SIP registrar" is probably the answer I will get here, and
is the only suggestion I can give you.

You can also run asterisk or freeswitch or sipexecs within your own network
and direct the portmappings there. Jitsi can then connect to that server.

Emil

--sent from my mobile

···

On Apr 7, 2013 1:45 AM, "Ian Haywood" <ihaywood3@gmail.com> wrote:

On Sat, Apr 6, 2013 at 11:22 PM, Alexis <flexibeast@gmail.com> wrote:


#5

Hi Emil,

Thanks for your response. :slight_smile:

>> (b) More generally, can the above iptables rule be made more specific,
>> e.g. specifying particular source and destination ports / port
>> ranges, rather than the above generic port range?

By default Jitsi would use ports between 5000 and 6000 for
media. That said I don't quite see why you would want to limit the
above. You need hoses in your LAN to initiate an outbound connection
anyway.

Well, I maintain a "deny by default" policy (the "allow by default"
policy gave us the Morris worm. :slight_smile: ); I only open specific holes
for specific needs. So for example ports 80 and 443 outbound are
allowed; but if people try to connect to an external game server
running on port 20000, they'll be blocked. Inbound connections
unrelated to requests made from within the LAN are even more
restricted; most of my users don't need to be running servers for
the rest of the world to access.

Thus, I'd like to know a minimal set of inbound ports, together with a
minimal set of outbound ports, which will enable Jitsi to
work. Opening more ports than necessary creates unnecessary
opportunities for network misuse.

>> (c) Something in the ICE harvesting process is taking 60 seconds to
>> timeout, so that it takes at least that long for either the
>> "Ringing" process to be initiated (upon ICE success) or to report
>> ICE failure. Relevant log extracts are appended to the end of
>> this email.

Seems to be the GTalk relay. Can you try the same experiments with
jit.si accounts? This way Jitsi would be using standard Jingle
rather than the Google vernacular.

*nod* I'll certainly do so, and report back with my results.

>> (e) One of the hosts I manage is a laptop in which the built-in Webcam
>> has been installed upside-down. :-/ With this host, a
>> freestanding USB Webcam is used. Jitsi recognises its existence,
>> but no image data is displayed. (It works fine in Skype.) Even if
>> this issue could be fixed, how difficult would it be to add
>> vertical/horizontal video flip functionality to Jitsi?

Not that difficult. The difficult part would be about discovering when
you need it.

Sorry, do you mean, how soon I would need that functionality
implemented?

Thanks again!

Alexis.
.

···

On 17:46:55 Sun 07-Apr-13, Emil Ivov wrote:


#6

Hey Alexis,

Hi Emil,

Thanks for your response. :slight_smile:

> >> (b) More generally, can the above iptables rule be made more

specific,

> >> e.g. specifying particular source and destination ports / port
> >> ranges, rather than the above generic port range?
>
> By default Jitsi would use ports between 5000 and 6000 for
> media. That said I don't quite see why you would want to limit the
> above. You need hoses in your LAN to initiate an outbound connection
> anyway.

Well, I maintain a "deny by default" policy (the "allow by default"
policy gave us the Morris worm. :slight_smile: );

You mean, through an UDP connection initiated from within your network?

I only open specific holes
for specific needs. So for example ports 80 and 443 outbound are
allowed;

Heads up: rant incoming (not personal, just using the thread)

I know these policies are common and many implement them but I still find
them so very perplexing: most of the malware today gets in through exactly
these two ports. Yet people keep unintentionally blocking things like VoIP
as a security measure.

Most of the things you are trying to prevent will simply use 443 to do
their job. You may want to have a look at this document:

http://tools.ietf.org/html/draft-blanchet-iab-internetoverport443-00

but if people try to connect to an external game server
running on port 20000, they'll be blocked. Inbound connections
unrelated to requests made from within the LAN are even more
restricted; most of my users don't need to be running servers for
the rest of the world to access.

Thus, I'd like to know a minimal set of inbound ports,

None.

together with a
minimal set of outbound ports,

Most of the time Jitsi will send and receive UDP on ports 5000 to 6000. We
have no real pattern for use of outbound TCP ports.

which will enable Jitsi to
work. Opening more ports than necessary creates unnecessary
opportunities for network misuse.

> >> (c) Something in the ICE harvesting process is taking 60 seconds to
> >> timeout, so that it takes at least that long for either the
> >> "Ringing" process to be initiated (upon ICE success) or to report
> >> ICE failure. Relevant log extracts are appended to the end of
> >> this email.
>
> Seems to be the GTalk relay. Can you try the same experiments with
> jit.si accounts? This way Jitsi would be using standard Jingle
> rather than the Google vernacular.

*nod* I'll certainly do so, and report back with my results.

> >> (e) One of the hosts I manage is a laptop in which the built-in

Webcam

> >> has been installed upside-down. :-/ With this host, a
> >> freestanding USB Webcam is used. Jitsi recognises its existence,
> >> but no image data is displayed. (It works fine in Skype.) Even if
> >> this issue could be fixed, how difficult would it be to add
> >> vertical/horizontal video flip functionality to Jitsi?
>
> Not that difficult. The difficult part would be about discovering when
> you need it.

Sorry, do you mean, how soon I would need that functionality
implemented?

What I meant was that it'll be hard for us to know exactly when we are
getting an upside down image that we need to flip.

Cheers,
Emil

···

On Tue, Apr 9, 2013 at 1:47 PM, Alexis <flexibeast@gmail.com> wrote:

On 17:46:55 Sun 07-Apr-13, Emil Ivov wrote:

Thanks again!

Alexis.

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#7

   > Well, I maintain a "deny by default" policy (the "allow by default"
   > policy gave us the Morris worm. :slight_smile: );

   You mean, through an UDP connection initiated from within your
   network?

Sorry, I don't understand what you're asking .... ?

   Heads up: rant incoming (not personal, just using the thread)

   I know these policies are common and many implement them but I
   still find them so very perplexing: most of the malware today
   gets in through exactly these two ports. Yet people keep
   unintentionally blocking things like VoIP as a security measure.

   Most of the things you are trying to prevent will simply use 443
   to do their job.

Some will, sure. But in practice, many things do (correctly)
successfully get blocked; for example, people engaging in na�ve
attempts at using p2p filesharing services. Similarly, there's a not
insignificant amount of malware that is na�ve, e.g. expecting that a
SMTP server will always be on port 25. That determined attempts won't
be blocked doesn't mean /all/ attempts at blocking should be
abandoned; i think reducing the overall vulnerable attack surface is a
good thing. It's like wearing a seatbelt when driving: doing so isn't
guaranteed to save your life in all circumstances, but it still might
do so in quite a number of them.

   You may want to have a look at this document:

   [2]http://tools.ietf.org/html/draft-blanchet-iab-internetoverport443-00

*nod* Will do - thanks.

   > Thus, I'd like to know a minimal set of inbound ports,

   None.

*nod* Okay.

   > together with a
   > minimal set of outbound ports,

   Most of the time Jitsi will send and receive UDP on ports 5000 to
   6000. We have no real pattern for use of outbound TCP ports.

*nod* Okay.

Thank you for clarifying that!

   > Sorry, do you mean, how soon I would need that functionality
   > implemented?

   What I meant was that it'll be hard for us to know exactly when
   we are getting an upside down image that we need to flip.

Oh! No, I wasn't at all thinking of real-time "inverted image"
detection and correction; I was thinking of a simple checkbox that
would allow users to enable/disable inversion ("vertical flip") of
their video stream, if/as required.

Alexis.

···

On 14:37:46 Tue 09-Apr-13, Emil Ivov wrote:


#8

Hey Alexis,

   > Well, I maintain a "deny by default" policy (the "allow by default"
   > policy gave us the Morris worm. :slight_smile: );

   You mean, through an UDP connection initiated from within your
   network?

Sorry, I don't understand what you're asking .... ?

I was wondering if you the "Morris worm" problem you mention was somehow
the result of you not-blocking outbound UDP connections.

   Heads up: rant incoming (not personal, just using the thread)

   I know these policies are common and many implement them but I
   still find them so very perplexing: most of the malware today
   gets in through exactly these two ports. Yet people keep
   unintentionally blocking things like VoIP as a security measure.

   Most of the things you are trying to prevent will simply use 443
   to do their job.

Some will, sure. But in practice, many things do (correctly)
successfully get blocked; for example, people engaging in naïve
attempts at using p2p filesharing services. Similarly, there's a not
insignificant amount of malware that is naïve, e.g. expecting that a
SMTP server will always be on port 25. That determined attempts won't
be blocked doesn't mean /all/ attempts at blocking should be
abandoned; i think reducing the overall vulnerable attack surface is a
good thing.

You are talking about two very different things here. One is security
and blocking outbound UDP has hardly any impact on that, the other is
control and restrictions of user behaviour. If your goal is not to deny
your users full access to Internet for some reason (e.g. fear of illegal
downloads) then sure, this makes sense. It is my personal opinion that
there are more efficient ways of doing this, like for example, simply
asking your users not to download or game, or blocking trackers rather
than transport protocols. But I do agree these measures can have varying
degrees of efficiency in different environments and you are certainly in
the best position to know which policy is best for yours.

That said, I really just want it to be clear to the subscribers of this
list that in most situations allowing outbound UDP is hardly a security
breach. No one should expect a sudden flood of attacks only because they
suddenly started allowing UDP.

It's like wearing a seatbelt when driving: doing so isn't
guaranteed to save your life in all circumstances, but it still might
do so in quite a number of them.

Well, to me this feels closer to living in a World War II concrete
bunker for fear of being bitten by a mosquito and catching malaria,
while, in the same time, still getting your tap water from a polluted river.

   You may want to have a look at this document:

   [2]http://tools.ietf.org/html/draft-blanchet-iab-internetoverport443-00

*nod* Will do - thanks.

   > Thus, I'd like to know a minimal set of inbound ports,

   None.

*nod* Okay.

   > together with a
   > minimal set of outbound ports,

   Most of the time Jitsi will send and receive UDP on ports 5000 to
   6000. We have no real pattern for use of outbound TCP ports.

*nod* Okay.

Thank you for clarifying that!

   > Sorry, do you mean, how soon I would need that functionality
   > implemented?

   What I meant was that it'll be hard for us to know exactly when
   we are getting an upside down image that we need to flip.

Oh! No, I wasn't at all thinking of real-time "inverted image"
detection and correction; I was thinking of a simple checkbox that
would allow users to enable/disable inversion ("vertical flip") of
their video stream, if/as required.

OK, this would be easier. If we don't find a way of getting a straight
image we may indeed think of resorting to something similar.

Cheers,
Emil

···

On 09.04.13, 15:17, Alexis wrote:

On 14:37:46 Tue 09-Apr-13, Emil Ivov wrote:

Alexis.

--
https://jitsi.org


#9

I was wondering if you the "Morris worm" problem you mention was somehow
the result of you not-blocking outbound UDP connections.

No, sorry, by "us" in my earlier email, I was referring to "society
in general". :slight_smile: Here's the Wikipedia entry about the Morris worm:

https://en.wikipedia.org/wiki/Morris_worm

At the time of the Morris worm, many system administrators took the
approach of "allow by default, blacklist certain ports", rather than
"deny by default, whitelist certain ports"; as I understand it, this
was one of the several reasons the worm was able to spread so widely
so quickly.

You are talking about two very different things here. One is
security and blocking outbound UDP has hardly any impact on that,
the other is control and restrictions of user behaviour. If your
goal is not to deny your users full access to Internet for some
reason (e.g. fear of illegal downloads) then sure, this makes
sense. It is my personal opinion that there are more efficient ways
of doing this, like for example, simply asking your users not to
download or game, or blocking trackers rather than transport
protocols.

Unfortunately, merely "asking users" to do something often doesn't
work. A classic example is asking users to set non-trivial passwords;
real-world experience shows that even when users formally agree to
Terms of Use which specify certain password standards - and even when
those standards aren't ludicrously complicated - non-adherence to
those standards is common. Similarly, users come up with all sorts of
rationales under which it is reasonable to have installed software X
on their machine, or under which the software they're installing is not
/really/ the sort of thing that the Terms of Use cover.

Further, many networking environments are having to deal with BYOD
("Bring Your Own Device") situations, where users (not unreasonably)
want to be able to use their personal computing devices - laptops,
smartphones, tablets - to access the network. In such situations, not
only are the devices not directly controlled by ICT administrators,
but it's not reasonable to ask users to e.g. not install certain
software on those devices. So rather than creating blanket "BYOD is
forbidden" policies which users end up doing dodgy things to work
around, it can be better allow usage constrained by certain technical
configurations. The environments I manage are in just this situation.

The majority of the time, my users don't notice the technical
restrictions I have in place, because I allow those things required by
them to Get Stuff Done. When they /do/ notice them, and bring related
problems to my attention, that serves as a useful indicator to me of
who's trying to do what on the networks for which I have
responsibility - and which I have to fix if things go wrong. This
gives me the opportunity to have dialogues with my users about what
they're trying to do, and to encourage them to engage in
security-friendly behaviours.

That said, I really just want it to be clear to the subscribers of
this list that in most situations allowing outbound UDP is hardly a
security breach. No one should expect a sudden flood of attacks only
because they suddenly started allowing UDP.

Might I, however, respectfully suggest that the documentation make
clear that Jitsi doesn't require any inbound ports be opened, and only
requires ports 5000-6000 outbound be opened? Doing so would mean that:

(a) network administrators in environments which have a "deny by
    default" policy won't have to guess which ports they need to open
    to get Jitsi to work; and

(b) network administrators can make their own assessments re. possible
    risks opening such ports might create in their specific environment(s).

I feel it's not up to software developers - and I say this as a dev
myself! - to make risk assessments on behalf of all network admins
everywhere. (Over the years I've certainly observed software
developers make bad choices regarding security issues; one that
regularly appears in the news is user passwords being stored as
plaintext!) I agree with you when you write:

"[T]hese measures can have varying degrees of efficiency in different
environments and you are certainly in the best position to know which
policy is best for yours."

Being clear about Jitsi's network-related requirements might help
network admins feel more comfortable deploying Jitsi.

> Oh! No, I wasn't at all thinking of real-time "inverted image"
> detection and correction; I was thinking of a simple checkbox that
> would allow users to enable/disable inversion ("vertical flip") of
> their video stream, if/as required.

OK, this would be easier. If we don't find a way of getting a straight
image we may indeed think of resorting to something similar.

That would be greatly appreciated - thank you!

Alexis.
.

···

On 18:38:41 Tue 09-Apr-13, Emil Ivov wrote:


#10

Asking users not do do something seems a good way of doing things to me. How do I stop employees engaging in a gambling syndicate at lunchtime between themselves? Just ask them not to do it. Seems like a perfectly acceptable way of dealing with people. Seems like explaining why we don't do something and giving people information and knowledge is better than blanketing everyone with a guilty brush and assuming they are all criminals who need to be policed like scum.

Kind Regards
Pete

···

On 10 Apr 2013, at 01:20, Alexis <flexibeast@gmail.com> wrote:

On 18:38:41 Tue 09-Apr-13, Emil Ivov wrote:

I was wondering if you the "Morris worm" problem you mention was somehow
the result of you not-blocking outbound UDP connections.

No, sorry, by "us" in my earlier email, I was referring to "society
in general". :slight_smile: Here's the Wikipedia entry about the Morris worm:

https://en.wikipedia.org/wiki/Morris_worm

At the time of the Morris worm, many system administrators took the
approach of "allow by default, blacklist certain ports", rather than
"deny by default, whitelist certain ports"; as I understand it, this
was one of the several reasons the worm was able to spread so widely
so quickly.

You are talking about two very different things here. One is
security and blocking outbound UDP has hardly any impact on that,
the other is control and restrictions of user behaviour. If your
goal is not to deny your users full access to Internet for some
reason (e.g. fear of illegal downloads) then sure, this makes
sense. It is my personal opinion that there are more efficient ways
of doing this, like for example, simply asking your users not to
download or game, or blocking trackers rather than transport
protocols.

Unfortunately, merely "asking users" to do something often doesn't
work. A classic example is asking users to set non-trivial passwords;
real-world experience shows that even when users formally agree to
Terms of Use which specify certain password standards - and even when
those standards aren't ludicrously complicated - non-adherence to
those standards is common. Similarly, users come up with all sorts of
rationales under which it is reasonable to have installed software X
on their machine, or under which the software they're installing is not
/really/ the sort of thing that the Terms of Use cover.

Further, many networking environments are having to deal with BYOD
("Bring Your Own Device") situations, where users (not unreasonably)
want to be able to use their personal computing devices - laptops,
smartphones, tablets - to access the network. In such situations, not
only are the devices not directly controlled by ICT administrators,
but it's not reasonable to ask users to e.g. not install certain
software on those devices. So rather than creating blanket "BYOD is
forbidden" policies which users end up doing dodgy things to work
around, it can be better allow usage constrained by certain technical
configurations. The environments I manage are in just this situation.

The majority of the time, my users don't notice the technical
restrictions I have in place, because I allow those things required by
them to Get Stuff Done. When they /do/ notice them, and bring related
problems to my attention, that serves as a useful indicator to me of
who's trying to do what on the networks for which I have
responsibility - and which I have to fix if things go wrong. This
gives me the opportunity to have dialogues with my users about what
they're trying to do, and to encourage them to engage in
security-friendly behaviours.

That said, I really just want it to be clear to the subscribers of
this list that in most situations allowing outbound UDP is hardly a
security breach. No one should expect a sudden flood of attacks only
because they suddenly started allowing UDP.

Might I, however, respectfully suggest that the documentation make
clear that Jitsi doesn't require any inbound ports be opened, and only
requires ports 5000-6000 outbound be opened? Doing so would mean that:

(a) network administrators in environments which have a "deny by
   default" policy won't have to guess which ports they need to open
   to get Jitsi to work; and

(b) network administrators can make their own assessments re. possible
   risks opening such ports might create in their specific environment(s).

I feel it's not up to software developers - and I say this as a dev
myself! - to make risk assessments on behalf of all network admins
everywhere. (Over the years I've certainly observed software
developers make bad choices regarding security issues; one that
regularly appears in the news is user passwords being stored as
plaintext!) I agree with you when you write:

"[T]hese measures can have varying degrees of efficiency in different
environments and you are certainly in the best position to know which
policy is best for yours."

Being clear about Jitsi's network-related requirements might help
network admins feel more comfortable deploying Jitsi.

Oh! No, I wasn't at all thinking of real-time "inverted image"
detection and correction; I was thinking of a simple checkbox that
would allow users to enable/disable inversion ("vertical flip") of
their video stream, if/as required.

OK, this would be easier. If we don't find a way of getting a straight
image we may indeed think of resorting to something similar.

That would be greatly appreciated - thank you!

Alexis.

.


#11

Asking users not do do something seems a good way of doing things to
me. How do I stop employees engaging in a gambling syndicate at
lunchtime between themselves? Just ask them not to do it. Seems like
a perfectly acceptable way of dealing with people.

Did you actually read the paragraph I wrote which begins,
"Unfortunately, merely 'asking users' to do something often doesn't
work"? It seems not.

The point is, even when users /are/ asked to do something or not do
something, they don't necessarily do so - even when politely asked on
several occasions, as I've often done, and continue to do. When users
ignore best practices, and create problems on the network as a result,
they're not the ones who have to try to manage the
consequences. Therefore, employing technical measures to limit the
possible damage they can wreak on systems they don't have to
themselves manage is a part of an overall defense-in-depth strategy.

Seems like explaining why we don't do something and giving people
information and knowledge

Did you actually read the section where I wrote

"This gives me the opportunity to have dialogues with my users about
what they're trying to do, and to encourage them to engage in
security-friendly behaviours."

? It seems not.

is better than blanketing everyone with a guilty brush and assuming
they are all criminals who need to be policed like scum.

(a) Did you actually read the section where I wrote about how I try to
    work with users to allow them to use their own devices on the
    network, and that they only rarely end up not Getting Stuff Done
    due to technical restrictions? It seems not.

(b) Of course you have the right to imply that I'm treating my users
    like scum. However, you have little idea of the full context of
    the network environment I manage, so you might like to reconsider
    making universalising claims that what works perfectly well in
    your own situation is going to work satisfactorily for everyone
    everywhere.

Any further explicit or implicit attacks on how I manage the networks
I have the responsibility for keeping up and running will be directed
to /dev/null; and I won't be making any further comments on this issue
that aren't directly related to being able to deploy and use Jitsi.

Alexis.
.

···

On 07:14:18 Wed 10-Apr-13, Peter Allebone wrote:


#12

I dont make any explicit or implicit attacks on how you manage your
networks since it does not directly affect me. I think you read too much
into what I wrote, assuming it was some personal vendetta against you. I
just disagreed with your assertion that asking people to do or not do
something in the workplace does not "often" work. I find it does often
work, often being a situation > 50%. Good luck with your networks :slight_smile:

···

On Wed, Apr 10, 2013 at 6:58 AM, Alexis <flexibeast@gmail.com> wrote:

On 07:14:18 Wed 10-Apr-13, Peter Allebone wrote:
> Asking users not do do something seems a good way of doing things to
> me. How do I stop employees engaging in a gambling syndicate at
> lunchtime between themselves? Just ask them not to do it. Seems like
> a perfectly acceptable way of dealing with people.

Did you actually read the paragraph I wrote which begins,
"Unfortunately, merely 'asking users' to do something often doesn't
work"? It seems not.

The point is, even when users /are/ asked to do something or not do
something, they don't necessarily do so - even when politely asked on
several occasions, as I've often done, and continue to do. When users
ignore best practices, and create problems on the network as a result,
they're not the ones who have to try to manage the
consequences. Therefore, employing technical measures to limit the
possible damage they can wreak on systems they don't have to
themselves manage is a part of an overall defense-in-depth strategy.

> Seems like explaining why we don't do something and giving people
> information and knowledge

Did you actually read the section where I wrote

"This gives me the opportunity to have dialogues with my users about
what they're trying to do, and to encourage them to engage in
security-friendly behaviours."

? It seems not.

> is better than blanketing everyone with a guilty brush and assuming
> they are all criminals who need to be policed like scum.

(a) Did you actually read the section where I wrote about how I try to
    work with users to allow them to use their own devices on the
    network, and that they only rarely end up not Getting Stuff Done
    due to technical restrictions? It seems not.

(b) Of course you have the right to imply that I'm treating my users
    like scum. However, you have little idea of the full context of
    the network environment I manage, so you might like to reconsider
    making universalising claims that what works perfectly well in
    your own situation is going to work satisfactorily for everyone
    everywhere.

Any further explicit or implicit attacks on how I manage the networks
I have the responsibility for keeping up and running will be directed
to /dev/null; and I won't be making any further comments on this issue
that aren't directly related to being able to deploy and use Jitsi.

Alexis.