[jitsi-dev] Jitsi and Bandwidth

#1

Hello,

I've been getting similar requests for support from colleagues quite
frequently lately (see bottom). Any advise on how to troubleshoot call
drops would be very welcome. Thank you.

The reason why I am sending this to dev list is that further up is a
report from colleague who monitored bandwidth taken up by Jitsi and he
suggests that high bandwidth consumption might be the reason behind
dropping audio. Is mentioned bandwidth use expected?

Mentioned team is using Jitsi on jit.si on different platforms, namely
one Ubuntu machine, 2 Macs and at least one Win 8 computer. The person
who sent in the beandwidth monitoring results is on Ubuntu. Codecs used
are the default ones (nobody changed any settings there). If more
details would help to troubleshoot this, let me know what details.

Thanks

karel

Folks, this week i've been on a blackboard chat [*] for the staff meeting,
and jitsi and skype yesterday for the small team meeting. I took the
opportunity in all three cases to monitor the bandwidth i used for each
of the platforms....I'm afraid skype comes out a clear winner in a
bandwidth constrained environment - on the incoming connection it
consumed less than 10Kbps while jitsi consumed 60Kbps and blackboard
100Kbps.

Skype isn't exactly bug free, but i think this may explain some of the
comms problems we have with jitsi and blackboard, esp when some of the
callers are on b/w constrained connections....

* Blackboard chat is Blackboard Collaborate conf. system

···

On 26-03-2014 16:24, joy wrote:

Hi Karel - can you help us with a problem we keep having with jitsi -
often it seems that a call starts and the audio drops so that one person
can;t be heard. for no apparent reason the audio just ends and then it
will happen again - is this a known problem? can you suggest a fix - it
is totally driving us insane and we keep reverting to skype.
thanks for your help!

#2

Hello,

Hello,

I've been getting similar requests for support from colleagues quite
frequently lately (see bottom). Any advise on how to troubleshoot call
drops would be very welcome. Thank you.

You might start by analyzing the log files. I am not aware of a known
issue that would result in audio stopping in one direction.

The reason why I am sending this to dev list is that further up is a
report from colleague who monitored bandwidth taken up by Jitsi and he
suggests that high bandwidth consumption might be the reason behind
dropping audio. Is mentioned bandwidth use expected?

High bandwidth usage should not result in no audio.

60Kbps does not seem like too much. It also depends on who is the
organizer in the conference. With a Jitsi-hosted conference (no
videobridge) the organizer will receive audio streams from everyone
else. Everyone else will receive a single audio stream.

In any case, if you are using opus (which should be the case when all
clients are Jitsi) you can control the outgoing bandwidth in the "Opus"
section in "Advanced" in the options.

Regards,
Boris

···

On 27/03/14 13:22, Karel Novotny wrote:

#3

Hi Karel,

I agree with completely with your objections - and I myself have
actually strong bandwith problems to phone with my android or linux to
the canary islands.

Its really not comfortable. And 60 K is at my opinion still too much for
phone only.

And I cant realize, that here in this community seems everybody hip for
a big fat video-solution if even the elementary stuff like a P2P phoning
still has its strong problems...

Everybody is looking forward for a good runing REPLACEMENT for all
commercial solutions like Skype, Viber, Whatsapp, a.s.o. but here the
peoples of the first interesting community witout commercial-Owner seems
to like it amusing with other stuff. Even this "other stuff" would be
running much better, if the basic problems would be resolved!

IF these problems would be resolved it would be much easier to get some
payload for a jitsi-phone-app than to hope for the big money of a
enterprise-video-solution. Just with the last, we would be in the hard
fighted business relations, since there are a lot of companies what trie
to live it from.

It may be not really a pleasure to hear these objections, but I have to
pronouce it in my engagment for free and open Software.

Fizzlifax

···

Am 27.03.2014 13:22, schrieb Karel Novotny:

Hello,

I've been getting similar requests for support from colleagues quite
frequently lately (see bottom). Any advise on how to troubleshoot call
drops would be very welcome. Thank you.

The reason why I am sending this to dev list is that further up is a
report from colleague who monitored bandwidth taken up by Jitsi and he
suggests that high bandwidth consumption might be the reason behind
dropping audio. Is mentioned bandwidth use expected?

Mentioned team is using Jitsi on jit.si on different platforms, namely
one Ubuntu machine, 2 Macs and at least one Win 8 computer. The person
who sent in the beandwidth monitoring results is on Ubuntu. Codecs used
are the default ones (nobody changed any settings there). If more
details would help to troubleshoot this, let me know what details.

Thanks

karel

Folks, this week i've been on a blackboard chat [*] for the staff meeting,
and jitsi and skype yesterday for the small team meeting. I took the
opportunity in all three cases to monitor the bandwidth i used for each
of the platforms....I'm afraid skype comes out a clear winner in a
bandwidth constrained environment - on the incoming connection it
consumed less than 10Kbps while jitsi consumed 60Kbps and blackboard
100Kbps.

Skype isn't exactly bug free, but i think this may explain some of the
comms problems we have with jitsi and blackboard, esp when some of the
callers are on b/w constrained connections....

* Blackboard chat is Blackboard Collaborate conf. system

On 26-03-2014 16:24, joy wrote:

Hi Karel - can you help us with a problem we keep having with jitsi -
often it seems that a call starts and the audio drops so that one person
can;t be heard. for no apparent reason the audio just ends and then it
will happen again - is this a known problem? can you suggest a fix - it
is totally driving us insane and we keep reverting to skype.
thanks for your help!

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

#4

Hello.
It seems Jitsi has an issue with local registrarless SIP accounts if both ipv6 and ipv4 are enabled.
I use ipv4 and have everything ipv6 blocked by firewall. And i have explicitly allowed 5060 udp through the ipv4 firewall.

if jitsi was launched with -Djava.net.preferIPv4Stack=true or _JAVA_OPTIONS was set to "-Djava.net.preferIPv4Stack=true"

jitsi listens as it should on ipv4 interfaces and i can do ip to ip SIP calls (netstat -tunlp | grep java, stripped non relevant ports).

tcp 0 0 0.0.0.0:5060 0.0.0.0:* LISTEN 20481/java
tcp 0 0 0.0.0.0:5061 0.0.0.0:* LISTEN 20481/java
udp 0 0 0.0.0.0:5060 0.0.0.0:* 20481/java

but if not, i have ONLY this:

tcp6 0 0 :::5060 :::* LISTEN 20903/java
tcp6 0 0 :::5061 :::* LISTEN 20903/java
udp6 0 0 :::5060 :::* 20903/java

I use ipv4, but ipv6 is enabled too. Now, if i dont have the prefer variable set, i cannot use local SIP at all via ipv4.

Shouldnt Jitsi listen on both ipv6 AND ipv4 in this case?

PS. I run Jitsi on Debian 64 bit and openjdk )debian version 7u51-2.4.5-2)

$ java -version
Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.5) (7u51-2.4.5-2)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

···

--
O zi buna,
Kertesz Laszlo

#5

Hello,

Hi Karel,

I agree with completely with your objections - and I myself have
actually strong bandwith problems to phone with my android or linux to
the canary islands.

Its really not comfortable. And 60 K is at my opinion still too much for
phone only.

I'm curious about how you came up with "60K for phone only"? And what
does "60K" mean -- kilobits per second, kilobytes per second?

The default bitrate used with opus (which is the default codec) is
32kbps (that is, 4 kilobytes per second). And during silence it's lower.
And it's configurable.

And I cant realize, that here in this community seems everybody hip for
a big fat video-solution if even the elementary stuff like a P2P phoning
still has its strong problems...

Could you be more specific about those problems?

Regards,
Boris

···

On 27/03/14 15:49, Ralf Hesse wrote:

#6

I can't talk about all the different points that you mentioned Ralf (I
apparently use Jitsi in a very different scenario).

However, I do agree on your point that 60Kbps bandwidth consumption
brings down Jitsi's usability significantly, in many areas outside
europe/north america. We have many people in our network who are
connected via Vsat, slow gsm data or limited shared adsl connections,
and for whom this is too much. I am aware that bandwidth availability is
gradually changing everywhere, but it is a slow and long run process.

But then again, I am not sure if the 60Kbps is a real consumption, or
whether the results of my friend's monitoring reflected some specific
situation (?). And I also don't understand who is responsible for
bandwidth consumption... the application, codec, settings,
protocol/network....?

In any case. If large scale uptake of Jitsi is a priority and there is
any chance to bring down bandwidth requirements, I would move this up on
devel priority list. It might impact on sound quality I imagine (btw, it
is far superior to skype for us, at least on jit.si network). So if this
is a trade-off and there are ways to push bandwidth down... could this
be made optional in Jitsi config?

karel

···

On 27.3.2014 15:49, Ralf Hesse wrote:

Hi Karel,

I agree with completely with your objections - and I myself have
actually strong bandwith problems to phone with my android or linux to
the canary islands.

Its really not comfortable. And 60 K is at my opinion still too much for
phone only.

And I cant realize, that here in this community seems everybody hip for
a big fat video-solution if even the elementary stuff like a P2P phoning
still has its strong problems...

Everybody is looking forward for a good runing REPLACEMENT for all
commercial solutions like Skype, Viber, Whatsapp, a.s.o. but here the
peoples of the first interesting community witout commercial-Owner seems
to like it amusing with other stuff. Even this "other stuff" would be
running much better, if the basic problems would be resolved!

IF these problems would be resolved it would be much easier to get some
payload for a jitsi-phone-app than to hope for the big money of a
enterprise-video-solution. Just with the last, we would be in the hard
fighted business relations, since there are a lot of companies what trie
to live it from.

It may be not really a pleasure to hear these objections, but I have to
pronouce it in my engagment for free and open Software.

Fizzlifax

Am 27.03.2014 13:22, schrieb Karel Novotny:

Hello,

I've been getting similar requests for support from colleagues quite
frequently lately (see bottom). Any advise on how to troubleshoot call
drops would be very welcome. Thank you.

The reason why I am sending this to dev list is that further up is a
report from colleague who monitored bandwidth taken up by Jitsi and he
suggests that high bandwidth consumption might be the reason behind
dropping audio. Is mentioned bandwidth use expected?

Mentioned team is using Jitsi on jit.si on different platforms, namely
one Ubuntu machine, 2 Macs and at least one Win 8 computer. The person
who sent in the beandwidth monitoring results is on Ubuntu. Codecs used
are the default ones (nobody changed any settings there). If more
details would help to troubleshoot this, let me know what details.

Thanks

karel

Folks, this week i've been on a blackboard chat [*] for the staff meeting,
and jitsi and skype yesterday for the small team meeting. I took the
opportunity in all three cases to monitor the bandwidth i used for each
of the platforms....I'm afraid skype comes out a clear winner in a
bandwidth constrained environment - on the incoming connection it
consumed less than 10Kbps while jitsi consumed 60Kbps and blackboard
100Kbps.

Skype isn't exactly bug free, but i think this may explain some of the
comms problems we have with jitsi and blackboard, esp when some of the
callers are on b/w constrained connections....

* Blackboard chat is Blackboard Collaborate conf. system

On 26-03-2014 16:24, joy wrote:

Hi Karel - can you help us with a problem we keep having with jitsi -
often it seems that a call starts and the audio drops so that one person
can;t be heard. for no apparent reason the audio just ends and then it
will happen again - is this a known problem? can you suggest a fix - it
is totally driving us insane and we keep reverting to skype.
thanks for your help!

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

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

#7

Hi Boris,

thanks a lot for Your question.

I am using actually with my friend who stays near Candelaria on Canary
Islands the jitsi alpha for Android.

I have a Galaxy S3 with Android 4.3 my friend an Huawei Y300 with
Android 4.1x about.

We usually try to talk over WLAN where bandwith is 65 Mbit/s on the
other side should be a similar WLAN, meanwhile there is only 1 Mbit
downstream and it seems only 128 Kbits /sec upstream. If jitsi would
need up to 60 kbit/sec we would have a problem in the moment if there
would be surfing or video-streaming (youtube) 2 or 3 other peoples in
the same time, what seems to be the fact.

AND - even if Your provider sells You 1 Mbit it is not shure, that he
will be able to deliver it permanently....

OK:
Phoning works but - You have to speak very slowly since there are a lot
of "wholes" in the streaming... means the streaming is very hacked...
and irregulary.

I enabled on my side "Hardware-Support" in the configuration, but this
seems not to help.

An other problem for me: Jitsi seems not to support GSM, HDSP and all
the mobile-Data-Stuff. MEANS: in the Moment when I leave the WLAN, Jitsi
is OFFLINE!?? - How could I change that!? - at least for chatting!

Of course there are still some other problems, but these would be the
most importants...

Thanks a lot in advance for Your interest

Ralf
P.S.
Even here in Germany, there are some villages where not much more
bandwith would be available...

···

Am 27.03.2014 23:42, schrieb Boris Grozev:

Hello,

On 27/03/14 15:49, Ralf Hesse wrote:

Hi Karel,

I agree with completely with your objections - and I myself have
actually strong bandwith problems to phone with my android or linux to
the canary islands.

Its really not comfortable. And 60 K is at my opinion still too much for
phone only.

I'm curious about how you came up with "60K for phone only"? And what
does "60K" mean -- kilobits per second, kilobytes per second?

The default bitrate used with opus (which is the default codec) is
32kbps (that is, 4 kilobytes per second). And during silence it's lower.
And it's configurable.

And I cant realize, that here in this community seems everybody hip for
a big fat video-solution if even the elementary stuff like a P2P phoning
still has its strong problems...

Could you be more specific about those problems?

Regards,
Boris

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

#8

Hi Boris,

thanks a lot for Your question.

I am using actually with my friend who stays near Candelaria on Canary
Islands the jitsi alpha for Android.

I have a Galaxy S3 with Android 4.3 my friend an Huawei Y300 with
Android 4.1x about.

We usually try to talk over WLAN where bandwith is 65 Mbit/s on the
other side should be a similar WLAN, meanwhile there is only 1 Mbit
downstream and it seems only 128 Kbits /sec upstream. If jitsi would
need up to 60 kbit/sec we would have a problem in the moment if there
would be surfing or video-streaming (youtube) 2 or 3 other peoples in
the same time, what seems to be the fact.

AND - even if Your provider sells You 1 Mbit it is not shure, that he
will be able to deliver it permanently....

OK:
Phoning works but - You have to speak very slowly since there are a lot
of "wholes" in the streaming... means the streaming is very hacked...
and irregulary.

I enabled on my side "Hardware-Support" in the configuration, but this
seems not to help.

An other problem for me: Jitsi seems not to support GSM, HDSP and all
the mobile-Data-Stuff. MEANS: in the Moment when I leave the WLAN, Jitsi
is OFFLINE!?? - How could I change that!? - at least for chatting!

Of course there are still some other problems, but these would be the
most importants...

Thanks a lot in advance for Your interest

Ralf
P.S.
Even here in Germany, there are some villages where not much more
bandwith would be available...

···

Am 27.03.2014 23:42, schrieb Boris Grozev:

Hello,

On 27/03/14 15:49, Ralf Hesse wrote:

Hi Karel,

I agree with completely with your objections - and I myself have
actually strong bandwith problems to phone with my android or linux to
the canary islands.

Its really not comfortable. And 60 K is at my opinion still too much for
phone only.

I'm curious about how you came up with "60K for phone only"? And what
does "60K" mean -- kilobits per second, kilobytes per second?

The default bitrate used with opus (which is the default codec) is
32kbps (that is, 4 kilobytes per second). And during silence it's lower.
And it's configurable.

And I cant realize, that here in this community seems everybody hip for
a big fat video-solution if even the elementary stuff like a P2P phoning
still has its strong problems...

Could you be more specific about those problems?

Regards,
Boris

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

#9

This *is* already configurable (Options->Advanced->Opus).

Regards,
Boris

···

On 28/03/14 12:15, Karel Novotny wrote:

In any case. If large scale uptake of Jitsi is a priority and there is
any chance to bring down bandwidth requirements, I would move this up on
devel priority list. It might impact on sound quality I imagine (btw, it
is far superior to skype for us, at least on jit.si network). So if this
is a trade-off and there are ways to push bandwidth down... could this
be made optional in Jitsi config?

#10

In any case. If large scale uptake of Jitsi is a priority and there is
any chance to bring down bandwidth requirements, I would move this up on
devel priority list. It might impact on sound quality I imagine (btw, it
is far superior to skype for us, at least on jit.si network). So if this
is a trade-off and there are ways to push bandwidth down... could this
be made optional in Jitsi config?

This *is* already configurable (Options->Advanced->Opus).

Great to know. Thanks. A layperson's guide/wizard on setting up Jitsi
for slow bandwidth would be awesome... one day.

Layperson's first go on what this wizard might cover is:
- What connectivity should be considered slow and requires opus
configuration.
- Explain what to configure, and how (or do it via a wizard)
- Explain who needs to configure (all communicating parties? Just the
person who is on slow connection?...)
- Explain what are the implications for performance.

karel

···

On 28.3.2014 12:48, Boris Grozev wrote:

On 28/03/14 12:15, Karel Novotny wrote:

Regards,
Boris

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

#11

Hi - thanks for Your reply!

I find

···

################
sampling rate = auto
encoder average bitrate (kbps) = 32

Use DTX = yes
Use inband FEC = yes
minimum expected packet loss (%) = 1
encoder complexity = 5
################

I guess it would be the best to configure both sides identically or not?

would it help to decrease the sampling rate to 8 KHz?

what about to decrease the bitrate?

what means DTX? and all the rest?

And what about the option:

# # # # # #
- use Hardware encoding
- use direct surface encoding
- use Hardware decoding
- use direct surface decoding

would it be better EN or DISabled?

?________________________________

Just on today I remarked another big problem to get connected:

it seems not to be possible to accept / catch a incoming call beeing in the phoning screen! - No chance to take it over! The call is ringing in the background - the systems seems to hang completely
- Only possibility: kill jitsi process - start it new and wait for the next try.

next problem: for encryption taking a call there ist a mention "give some words" ... what does it means? - even giving some words I had calls where all the time the red open treelock was present. - If I should speak some words - it would be better to mention this explicitly... - but it seems not to be the same proceeding as shown in the video for PC version.

And the next:

Why skype and other are working in a mobile network but jitsi not!?? - or what's to change to do it for?

Why ALL the other distributions are available in daily nightly builds EXEPT the android version?

Thanks in advance for Your supply

Ralf
ceterum censeo jitsim androidem esse finiendum.

Am 2014-03-28 13:25 schrieb Karel Novotny:

On 28.3.2014 12:48, Boris Grozev wrote:

On 28/03/14 12:15, Karel Novotny wrote:

In any case. If large scale uptake of Jitsi is a priority and there is
any chance to bring down bandwidth requirements, I would move this up on
devel priority list. It might impact on sound quality I imagine (btw, it
is far superior to skype for us, at least on jit.si network). So if this
is a trade-off and there are ways to push bandwidth down... could this
be made optional in Jitsi config?

This *is* already configurable (Options->Advanced->Opus).

Great to know. Thanks. A layperson's guide/wizard on setting up Jitsi
for slow bandwidth would be awesome... one day.

Layperson's first go on what this wizard might cover is:
- What connectivity should be considered slow and requires opus
configuration.
- Explain what to configure, and how (or do it via a wizard)
- Explain who needs to configure (all communicating parties? Just the
person who is on slow connection?...)
- Explain what are the implications for performance.

karel

Regards,
Boris

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

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

--
Mit freundlichen Grüßen

Ralf Hesse

70806 Kornwestheim

#12

Hi - thanks for Your reply!

I find

···

################
sampling rate = auto
encoder average bitrate (kbps) = 32

Use DTX = yes
Use inband FEC = yes
minimum expected packet loss (%) = 1
encoder complexity = 5
################

I guess it would be the best to configure both sides identically or not?

would it help to decrease the sampling rate to 8 KHz?

what about to decrease the bitrate?

what means DTX? and all the rest?

And what about the option:

# # # # # #
- use Hardware encoding
- use direct surface encoding
- use Hardware decoding
- use direct surface decoding

would it be better EN or DISabled?

?________________________________

Just on today I remarked another big problem to get connected:

it seems not to be possible to accept / catch a incoming call beeing in the phoning screen! - No chance to take it over! The call is ringing in the background - the systems seems to hang completely
- Only possibility: kill jitsi process - start it new and wait for the next try.

next problem: for encryption taking a call there ist a mention "give some words" ... what does it means? - even giving some words I had calls where all the time the red open treelock was present. - If I should speak some words - it would be better to mention this explicitly... - but it seems not to be the same proceeding as shown in the video for PC version.

And the next:

Why skype and other are working in a mobile network but jitsi not!?? - or what's to change to do it for?

Why ALL the other distributions are available in daily nightly builds EXEPT the android version?

Thanks in advance for Your supply

Ralf
ceterum censeo jitsim androidem esse finiend

Am 2014-03-28 13:25 schrieb Karel Novotny:

On 28.3.2014 12:48, Boris Grozev wrote:

On 28/03/14 12:15, Karel Novotny wrote:

In any case. If large scale uptake of Jitsi is a priority and there is
any chance to bring down bandwidth requirements, I would move this up on
devel priority list. It might impact on sound quality I imagine (btw, it
is far superior to skype for us, at least on jit.si network). So if this
is a trade-off and there are ways to push bandwidth down... could this
be made optional in Jitsi config?

This *is* already configurable (Options->Advanced->Opus).

Great to know. Thanks. A layperson's guide/wizard on setting up Jitsi
for slow bandwidth would be awesome... one day.

Layperson's first go on what this wizard might cover is:
- What connectivity should be considered slow and requires opus
configuration.
- Explain what to configure, and how (or do it via a wizard)
- Explain who needs to configure (all communicating parties? Just the
person who is on slow connection?...)
- Explain what are the implications for performance.

karel

Regards,
Boris

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

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

#13

Hello,

Hi - thanks for Your reply!

I find
################
sampling rate = auto
encoder average bitrate (kbps) = 32

Use DTX = yes
Use inband FEC = yes
minimum expected packet loss (%) = 1
encoder complexity = 5
################

I guess it would be the best to configure both sides identically or
not?

would it help to decrease the sampling rate to 8 KHz?

No, this will drastically decrease sound quality.

what about to decrease the bitrate?

This will decrease the bandwidth used. If bandwidth is a problem, you
should decrease it. However, I'm skeptical about bandwidth being a problem.

what means DTX? and all the rest?

DTX is "discontinuous transmission". It will send less packets during
periods of silence. You should keep it on unless you find that it causes
problems.

FEC is used to mitigate the problem of packets dropped in the network.
You should definitely keep it on. "minimum expected packet loss" must be
non-zero for FEC to work.

Lowering complexity will make the encoder use less CPU but will result
in lower sound quality.

And what about the option:

# # # # # #
- use Hardware encoding
- use direct surface encoding
- use Hardware decoding
- use direct surface decoding

would it be better EN or DISabled?

These are for video.

?________________________________

Just on today I remarked another big problem to get connected:

it seems not to be possible to accept / catch a incoming call beeing in
the phoning screen! - No chance to take it over! The call is ringing in
the background - the systems seems to hang completely
- Only possibility: kill jitsi process - start it new and wait for the
next try.

next problem: for encryption taking a call there ist a mention "give
some words" ... what does it means? - even giving some words I had calls
where all the time the red open treelock was present. - If I should
speak some words - it would be better to mention this explicitly... -
but it seems not to be the same proceeding as shown in the video for PC
version.

And the next:

Why skype and other are working in a mobile network but jitsi not!?? -
or what's to change to do it for?

Why ALL the other distributions are available in daily nightly builds
EXEPT the android version?

Due to lack of resources, the android version is on hold for the moment.

For the specific problem with call pick-up (I assume that's on android)
that you mentioned, I would advise you to send you logs. However it is
unlikely that anyone will be available to have a look anytime soon.

Regards,
Boris

···

On 28/03/14 18:57, Fizzlifax wrote: