[jitsi-users] No video on one side


#1

Hi!

I'm currently desperately trying to deploy a free (and end-to-end
encrypted) communications channel between a friend and me. Jitsi
seems to be a very good tool for that, however, so far I didn't manage
to make it work completely.

The setting is like this: I've running Jitsi (the latest 2.0 version)
on Debian Wheezy, and my friend on Windows. We want to use
XMPP/Jingle, with jabber.org accounts. In order to avoid problems
with NAT, I installed a TURN server on my VPS and configured both
Jitsi's to use it.

Basically that works -- zRTP confirms fine, we have an audio
connection, but video only works in one direction, namely that my
friend (running Windows) sees me but I (on Debian) can't see her. In
fact, sometimes it works, but for most of the test-calls we make it
does not; I wasn't yet able to figure out what "the difference" is.

I have to admit that I tried around different settings widely in the
process of getting anything to work, so I may have configured some
codecs or whatever wrong. Do you have any suggestions as to what
could cause the problem? Is there a known problem like that? Or a
known mis-configuration I could have made that results in those
symptoms? I would be very, very glad about any ideas -- my friend
can't understand why we don't simply use Skype if it doesn't work with
Jitsi, but I don't want to do that (for obvious reasons).

Thanks a lot! By the way, thanks for the great tool -- I'm really
looking forward to when I am able to fix this problem, since then I
have fully free and secure communication in voice, video and text! :slight_smile:

Daniel

- --
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071 5A0E 4D94 6EED 04F7 CF52
- --
Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri


#2

Hello,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I'm currently desperately trying to deploy a free (and end-to-end
encrypted) communications channel between a friend and me. Jitsi
seems to be a very good tool for that, however, so far I didn't manage
to make it work completely.

The setting is like this: I've running Jitsi (the latest 2.0 version)
on Debian Wheezy, and my friend on Windows. We want to use
XMPP/Jingle, with jabber.org accounts. In order to avoid problems
with NAT, I installed a TURN server on my VPS and configured both
Jitsi's to use it.

Basically that works -- zRTP confirms fine, we have an audio
connection, but video only works in one direction, namely that my
friend (running Windows) sees me but I (on Debian) can't see her. In
fact, sometimes it works, but for most of the test-calls we make it
does not; I wasn't yet able to figure out what "the difference" is.

I have to admit that I tried around different settings widely in the
process of getting anything to work, so I may have configured some
codecs or whatever wrong. Do you have any suggestions as to what
could cause the problem?

A shot in the dark: if you see a black window where the video should be,
ask your friend to wave vigorously at the camera[1] :slight_smile:
If that fixes the problem, please try (on your end) one of the nightly
builds.

Otherwise, please attach some logs[2], preferably from a nightly build.

Regards,
Boris

[1] No, I am not kidding, although a gentle wave close to the camera will
do as well. We're trying to make the encoder produce a keyframe.
[2] https://jitsi.org/Documentation/FAQ#logs

···

On Fri, Apr 19, 2013 at 10:10 PM, Daniel Kraft <d@domob.eu> wrote:


#3

Hi!

Thanks a lot for the fast reply!

A shot in the dark: if you see a black window where the video
should be, ask your friend to wave vigorously at the camera[1] :slight_smile:
If that fixes the problem, please try (on your end) one of the
nightly builds.

Otherwise, please attach some logs[2], preferably from a nightly
build.

So, basically the first thing I should try is using a nightly? Sounds
plausible, I'll do that! Is it most probable that it should be me to
try the nightly, or should I also try it out at my friend's? Could
that help, too?

If that doesn't help, I'll produce and send you the logs. I'll get to
the next round of testing probably tomorrow in the afternoon (CEST).

Yours,
Daniel

PS: Thanks again for the great tool, and I read some rumours that an
Android version is in the works ... if that is true, I'm really
looking forward to it! :slight_smile:

- --
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071 5A0E 4D94 6EED 04F7 CF52
- --
Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri

···

On 19/04/13 21:43, Boris Grozev wrote:


#4

Hi,

···

On Fri, Apr 19, 2013 at 10:56 PM, Daniel Kraft <d@domob.eu> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Thanks a lot for the fast reply!

On 19/04/13 21:43, Boris Grozev wrote:
> A shot in the dark: if you see a black window where the video
> should be, ask your friend to wave vigorously at the camera[1] :slight_smile:
> If that fixes the problem, please try (on your end) one of the
> nightly builds.
>
> Otherwise, please attach some logs[2], preferably from a nightly
> build.

So, basically the first thing I should try is using a nightly? Sounds
plausible, I'll do that! Is it most probable that it should be me to
try the nightly, or should I also try it out at my friend's? Could
that help, too?

For the particular issue that I had in mind, it won't be necessary. But it
was just a guess. In any case, I think using a nightly is generally a good
idea.

Regards,
Boris


#5

Hi again,

I've now had time to do another session of testing.

A shot in the dark: if you see a black window where the video
should be, ask your friend to wave vigorously at the camera[1] :slight_smile:
If that fixes the problem, please try (on your end) one of the
nightly builds.

I updated both installs to the latest nightly. (Debian amd64 and
Windows x86, respectively.)

Otherwise, please attach some logs[2], preferably from a nightly
build.

I've uploaded my friend's [1] and my own [2] logs. Hope they contain
everything that is necessary -- do they give you more ideas as to what
the problem could be? In the last session, I got a call from my
friend, answered it, and she could see me but I couldn't see her.

  [1] http://extra.domob.eu/friend.zip
  [2] http://extra.domob.eu/mine.zip

BTW, do the logs contain any sensitive information (like private keys,
XMPP passwords, TURN server password) which I should change after this
is fixed (hopefully)?

Yours,
Daniel

- --
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071 5A0E 4D94 6EED 04F7 CF52
- --
Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri

···

On 19/04/13 21:43, Boris Grozev wrote:


#6

Hi,

So, basically the first thing I should try is using a nightly?
Sounds plausible, I'll do that! Is it most probable that it should
be me to try the nightly, or should I also try it out at my
friend's? Could that help, too?

For the particular issue that I had in mind, it won't be necessary.
But it was just a guess. In any case, I think using a nightly is
generally a good idea.

thanks again -- I'll try that ASAP (tomorrow, my friend is currently
no longer available).

BTW, is the choice of codecs important? Or do you have suggestions on
which codecs might be most stable against video problems?

Yours,
Daniel

- --
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071 5A0E 4D94 6EED 04F7 CF52
- --
Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri

···

On 19/04/13 22:17, Boris Grozev wrote:


#7

Hi,

···

On Fri, Apr 19, 2013 at 11:34 PM, Daniel Kraft <d@domob.eu> wrote:

BTW, is the choice of codecs important? Or do you have suggestions on
which codecs might be most stable against video problems?

Yours,
Daniel

At the moment, the one that is most well tested is certainly h264.

Regards,
Boris


#8

Hey,

Sorry for the late-ish reply.

[...]

I've uploaded my friend's [1] and my own [2] logs. Hope they contain
everything that is necessary -- do they give you more ideas as to what
the problem could be? In the last session, I got a call from my
friend, answered it, and she could see me but I couldn't see her.

Well, I looked through the logs, but couldn't find what the actual problem
is.
Looks like both the audio and video RTP streams are setup correctly and you
are receiving RTP packets with the expected payload type on the expected
socket.

I see these exceptions, but I don't know what caused them or whether they
actually cause any problems. Hopefully someone else will have more insight:

14:11:54.755 SEVERE: [46] util.UtilActivator.uncaughtException().91 An
uncaught exception occurred in thread=Thread[Thread-56,6,main] and message
was: -4
java.lang.ArrayIndexOutOfBoundsException: -4 at
org.jitsi.impl.neomedia.RawPacket.readInt(RawPacket.java:188)
        at
org.jitsi.impl.neomedia.transform.zrtp.ZrtpRawPacket.checkCrc(ZrtpRawPacket.java:144)
       at
org.jitsi.impl.neomedia.transform.zrtp.ZRTPTransformEngine.reverseTransform(ZRTPTransformEngine.java:750)
        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(Thread.java:679)
14:11:54.757 SEVERE: [47] util.UtilActivator.uncaughtException().91 An
uncaught exception occurred in thread=Thread[Thread-55,6,main] and message
was: -8java.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(Thread.java:679)

BTW, do the logs contain any sensitive information (like private keys,
XMPP passwords, TURN server password) which I should change after this
is fixed (hopefully)?

They don't contain any passwords, but they do contain contact addresses and
other personal information.

By the way, in this particular instance, although both clients are behind
NATs, a direct connection is established (with addresses found via STUN).
Your TURN relay is not needed or used.

Regards,
Boris

···

On Sat, Apr 20, 2013 at 3:20 PM, Daniel Kraft <d@domob.eu> wrote:


#9

Hi!

Sorry for the late-ish reply.

No problem, thank you very much for looking into the logs! :slight_smile:

Well, I looked through the logs, but couldn't find what the actual
problem is.
Looks like both the audio and video RTP streams are setup correctly and
you are receiving RTP packets with the expected payload type on the
expected socket.

Ok ... actually, sometimes it works, but most of the time one direction
does not work. It also seems to depend on who calls whom and things
like that, but also for that I couldn't find out a clear "pattern".

I see these exceptions, but I don't know what caused them or whether
they actually cause any problems. Hopefully someone else will have more
insight:

14:11:54.755 SEVERE: [46] util.UtilActivator.uncaughtException().91 An
uncaught exception occurred in thread=Thread[Thread-56,6,main] and
message was: -4
java.lang.ArrayIndexOutOfBoundsException: -4 at
org.jitsi.impl.neomedia.RawPacket.readInt(RawPacket.java:188)
        at
org.jitsi.impl.neomedia.transform.zrtp.ZrtpRawPacket.checkCrc(ZrtpRawPacket.java:144)
       at
org.jitsi.impl.neomedia.transform.zrtp.ZRTPTransformEngine.reverseTransform(ZRTPTransformEngine.java:750)
        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(Thread.java:679)
14:11:54.757 SEVERE: [47] util.UtilActivator.uncaughtException().91 An
uncaught exception occurred in thread=Thread[Thread-55,6,main] and
message was: -8java.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(Thread.java:679)

So maybe it really is related to some problem that has nothing to do
with the network, but rather the media system? Hm....

    BTW, do the logs contain any sensitive information (like private keys,
    XMPP passwords, TURN server password) which I should change after this
    is fixed (hopefully)?

They don't contain any passwords, but they do contain contact addresses
and other personal information.

Thanks for clearing that up. I have no problem with that, and obviously
didn't write any sensitive messages while recording the logs anyway. :wink:

By the way, in this particular instance, although both clients are
behind NATs, a direct connection is established (with addresses found
via STUN). Your TURN relay is not needed or used.

Ah ok ... seems I have to inform myself better about STUN, because at
the moment I can't really imagine how a direct connection would work
with us behind firewalls and NATs. Thanks for the info here, too! :slight_smile:

Yours,
Daniel

···

On 24.04.2013 21:30, Boris Grozev wrote:

--
http://www.domob.eu/
--
Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri