[jitsi-dev] Jitsi Android Questions


#1

Hi,

aTalk-android development is a fork based on jitsi-android.

I have just released a aTalk version 0.7.2 based on the latest Smack version 0.4.2-rc (SNAPSHOT).
aTalk is now able to support XEP-0077:In-Band Registration and XEP-0158:CAPTCHA Forms for captcha protected online registration. If anybody of you is interested; the released android apk is free and can be downloaded from:
http://atalk.sytes.net/releases/atalk-android/aTalk-release.apk

Note: the aTalk is still in beta release, and support only XMPP protocol.

Regards,
CM Eng

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of dev-request@jitsi.org
Sent: Wednesday, January 11, 2017 4:49 AM
To: dev@jitsi.org
Subject: dev Digest, Vol 46, Issue 40

Send dev mailing list submissions to
  dev@jitsi.org

To subscribe or unsubscribe via the World Wide Web, visit
  http://lists.jitsi.org/mailman/listinfo/dev
or, via email, send a message with subject or body 'help' to
  dev-request@jitsi.org

You can reach the person managing the list at
  dev-owner@jitsi.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of dev digest..."

Today's Topics:

   1. Re: Jitsi Meet and bandwidth requirements (Daniel Bareiro)
   2. Re: jitsi meet on debian 8 (Antony Stone)
   3. Re: Jitsi Meet and bandwidth requirements (Boris Grozev)
   4. Jitsi Android Questions (Adrian Thompson)

----------------------------------------------------------------------

Message: 1
Date: Tue, 10 Jan 2017 16:34:36 -0300
From: Daniel Bareiro <daniel-listas@gmx.net>
To: dev@jitsi.org
Subject: Re: [jitsi-dev] Jitsi Meet and bandwidth requirements
Message-ID: <454de5cc-7cb0-6ea2-631f-536d9096cafb@gmx.net>
Content-Type: text/plain; charset="utf-8"

On 05/01/17 12:27, Boris Grozev wrote:

Hi Daniel,

Hi, Boris.

The actual bandwidth usage will depend on the available bandwidth
between the senders and the bridge, as well as the resolution
used, and whether simulcast is enabled or not.

When you talk about "the resolution used", do you mean to the
resolution of the camera, right?

Yes, kind of. The resolution that the browser gets from the camera.
It could be that your camera supports 1080p, but jitsi-meet is
configured to only use 720p (see config.resolution).

I see. I did not find any files with that name (config.resolution). I
also did not find any option with that name:

Sorry, it was a hasty reply and not very clear. I meant the
"config.resolution" property in the java script code. You can usually
set it in /etc/jitsi/meet/domain.config.js (or something similar). See
e.g. https://meet.jit.si/config.js

Ah, perfect. Thanks for the clarification. I do not see that property in my config.js file. In this case a default resolution is used?

As for the "bandwidth available between the senders and the
bridge", do you mean the bandwidth of the server or the bandwidth
of the Internet connection of each of the participants?

The bandwidth of the path between the sender and the bridge --
whatever that happens to be.

Good.

The available bandwidth between the sending client and the server.
This is calculated dynamically, and the sending bitrate (and as a
result quality, and resolution) is adjusted accordingly.

In the statistics shown by Jitsi for each participant I see:

* Bitrate.
* Packet loss.
* Resolution.
* Estimated Bandwidth.

What I am not clear is what is the difference between "bitrate" and
"Estimated Bandwidth". At first it seems the same, although I suppose
that each one would have a different point of view.

The bitrate is just how much data it being sent or received. The
"estimated bandwidth" is an estimation of how much we could
send/receive to that endpoint.

Mmmmmmm... This is an estimate of what could be sent/received under ideal conditions because there are no bottlenecks for example on the client side?

On the other hand, here "Resolution" is the one that the browser gets
from the camera? There is also other question related to it that I
mention in the following paragraph.

For the local video this is the highest resolution that you are
sending (highest, because with simulcast you may be sending more than
one). It could be the resolution of the camera, or something lower.

For remote videos, this is the resolution that you are receiving.

Thanks for the explanation.

At this point, a few days ago I was doing a test with another
person and in the statistics of Jitsi Meet I saw that the
resolution used for me and for the other part was (I think)
640x480. This seemed to me very little. Also I note that eventually
Jitsi Meet showed a message saying that the other person had
problems with their connection and the image remained momentarily
frozen and gray. Could it be that because of this Jitsi Meet has decremented the resolution of both parts to 640x480?

Yes, that's a possibility. It could also be that 640x480 was
obtained from the camera.

What caught my attention is that we both had the same value of
resolution, 640x480. Jitsi Videobridge delivers the same resolution
to all conference participants? In other words, Jitsi Videobridge
adjusts the resolution to the most optimum based on the network
conditions of that participant where these are the worst?

Currently jitsi-videobridge sends the highest available resolution for
the "selected" endpoint (the participant shown in full screen), and
the lowest available resolution for everyone else. This is
per-receiver, so you could be receiving high res for X, while someone
else receives low res for X.

Perfect. I think what I said before was wrong. The resolution shown by Jitsi Meet for both parties was 640x360 (a somewhat strange resolution).
Yesterday I did another test and this same resolution was used for both parties. We were both using Chrome/Chromium.

So in the case mentioned, this means that the selected person was shown in a resolution of 640x360 and the resolution that I am sending to that person was 640x360?

I was checking with Guvcview for the resolutions available for the camera on my notebook. These were:

640x480
640x360
352x288
320x240
800x448
960x540
1280x720

With simulcast, it will not scale linearly. For 720p with
simulcast and N participants, in perfect network conditions, the
usage will be something like 3.15Mbps outgoing, (2.5 + N * 0.15) Mbps incoming.

I'm not sure if simulcast is now enabled. What parameter setting
should I check? Currently I'm doing tests with the standard
installation, without making big changes (I just added
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS and
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS in
/etc/jitsi/videobridgesip-communicator.properties).

Simulcast is enabled by default, but you can verify that it is used
like
this: in a conference of two check the remote party's resolution
while they are shown on-stage, it should be 720p or similar. Then
click your local video, you will be shown on-stage. Check the remote
party resolution again, it should be 180p.

Note that simulcast is currently not supported on firefox.

In the test I mentioned I was using Firefox 45.6.0 ESR on Debian Jessie.
Then maybe I should try Chromium. The inability to use Firefox with
simulcast is because it does not yet support certain features of the
WebRTC? Do you know if this happens with any other browser?

We support simulcast only in Chrome and Chromium (we treat it the same
way as Chrome). I don't know what the current state of simulcast
support in firefox is in general.

Thanks for confirm.

For optimum use of bandwidth without losing image and video
quality, do you recommend using simulcast?

I am sorry. When I said "without losing image and video quality" I
meant "without losing sound and video quality"

Same answer, simulcast is definitely an improvement :slight_smile:

Perfect :slight_smile:

I was reading in the introduction to this document what is the idea
behind simulcast:

https://github.com/jitsi/jitsi-videobridge/blob/master/doc/simulcast.
md

If I understood this example correctly, the "sender" is a specific
participant in a four-member conference. Is it so?

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool that can interact with Jitsi Videobridge to determine the open rooms and the number of people who are participating in each room?

Thanks for your reply and your time.

Kind regards,
Daniel

P.S.: If you know of any way to restrict users that can connect to a conference, as I consulted in the other email, I would appreciate any comments :slight_smile:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20170110/8f11da25/attachment-0001.sig>

------------------------------

Message: 2
Date: Tue, 10 Jan 2017 20:45:18 +0100
From: Antony Stone <Antony.Stone@jitsi.open.source.it>
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] jitsi meet on debian 8
Message-ID: <201701102045.18440.Antony.Stone@jitsi.open.source.it>
Content-Type: Text/Plain; charset="utf-8"

On Tuesday 10 January 2017 at 19:46:10, Bruno Aouizerat wrote:

What do you mean by "wrong place for hosting conferences" ? the server
is a dedicated server with its own ip, with just debian 8 and jitsi
quick installed as said above

Sorry, in that case I made the wrong assumption about where your server was.

Since you said that internal participants could connect but external ones could not, I assumed that the server was located on your internal network, and the routing of packets from the external participants to the server was the problem.

Since both you and the "external participants" are connecting to this machine across the Internet, I don't know what would be different about the people who cannot connect, or who get disconnected.

I hope someone else can help to advise on how to diagnose or solve the problem.

Regards,

Antony.

--
+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++

                                                   Please reply to the list;
                                                         please *don't* CC me.

------------------------------

Message: 3
Date: Tue, 10 Jan 2017 14:19:59 -0600
From: Boris Grozev <boris@jitsi.org>
To: Jitsi Developers <dev@jitsi.org>
Subject: Re: [jitsi-dev] Jitsi Meet and bandwidth requirements
Message-ID: <a9a96d2f-f526-c52d-8c43-9bd9353503f2@jitsi.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Daniel,

On 10/01/2017 13:34, Daniel Bareiro wrote:
[snip]

Ah, perfect. Thanks for the clarification. I do not see that property in
my config.js file. In this case a default resolution is used?

Yes, I think it defaults to 720p.

[snip]

The bitrate is just how much data it being sent or received. The
"estimated bandwidth" is an estimation of how much we could send/receive
to that endpoint.

Mmmmmmm... This is an estimate of what could be sent/received under ideal
conditions because there are no bottlenecks for example on the client side?

No, it's an estimate of what could be sent under the current conditions,
taking into account bottlenecks along the way.

[snip]

Currently jitsi-videobridge sends the highest available resolution for
the "selected" endpoint (the participant shown in full screen), and the
lowest available resolution for everyone else. This is per-receiver, so
you could be receiving high res for X, while someone else receives low
res for X.

Perfect. I think what I said before was wrong. The resolution shown by
Jitsi Meet for both parties was 640x360 (a somewhat strange resolution).
Yesterday I did another test and this same resolution was used for both
parties. We were both using Chrome/Chromium.

So in the case mentioned, this means that the selected person was shown
in a resolution of 640x360 and the resolution that I am sending to that
person was 640x360?

You are probably sending 640x360 and also 320x180. This could be because
of the bandwidth estimation, or because of the camera. You are shown in
full-screen on the receiver's end (if I understand correctly), so the
bridge forwards the highest higher of the available resolutions, i.e.
640x360.

[snip]

Yes. This document is quite low-level and full of technical details.
This video may be more useful as an introduction, if this is what you
are looking for (I can't find anything similar in a text document):
https://www.youtube.com/watch?v=cmzERa0bk0Y

Interesting. Thanks for sharing this video.

In relation to this bandwidth topic, do you know if there is any tool
that can interact with Jitsi Videobridge to determine the open rooms and
the number of people who are participating in each room?

I don't know of a way to get a list live, but you can get some useful
statistics from the bridge. See here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/statistics.md

For example, for load-balancing in jicofo we use the "videostreams",
which is an estimate for the number of video streams that the bridge
forwards for all of its conferences (taking into account conference size
as much as possible).

Thanks for your reply and your time.

You are welcome. And thank you for your interest in the project.

Kind regards,
Daniel

P.S.: If you know of any way to restrict users that can connect to a
conference, as I consulted in the other email, I would appreciate any
comments :slight_smile:

One option is to manually lock a specific room. This way people joining
will need a password specific for that room. You can lock it by clicking
the "share the link" button in the menu on top, and then adding a password.

If this doesn't work for you, there are ways to require authentication
from the XMPP server. But I'm afraid I don't know much of the details
there, so someone else will have to chime in, if you have any questions
about it.

Regards,
Boris

------------------------------

Message: 4
Date: Tue, 10 Jan 2017 14:41:14 -0600
From: "Adrian Thompson" <athompson@successos.com>
To: <dev@jitsi.org>
Subject: [jitsi-dev] Jitsi Android Questions
Message-ID: <02f101d26b81$e2f70b40$a8e521c0$@successos.com>
Content-Type: text/plain; charset="utf-8"

Hello everyone,

I'm new to the list and I have a few questions about the discontinued Jitsi
Android port.

I have deployed a FreeSwitch/FusionPBX and Openfire setup with Jitsi Running
on each desktop. I am in heaven, and everything is working very well. We
have 30 or so technicians that would benefit a lot from video (jitsi meet),
voice and text communications with presence. Unfortunately, I have not seen
a mobile Sip/XMPP/Jingle unified app anywhere except for the Jitsi App on
Github. This app would solve all of these requirements in one strike of the
hammer.

Why was this abandoned?

Is there major hurdles to getting it running properly? I was able to
compile the code but ended up with considerable errors when logging into
XMPP or SIP service.

Currently, using Jitsi Meet app would not suit our purpose because we would
have to have three apps: One for XMPP, One for Jitsi Meet and one for SIP.

Any feedback/status/reasons/red flags?

There may be an opportunity for a bounty if someone can migrate Jitsi
Android to Gradle from Ant and provide a working APK and code. Because
right now I would be limited to buying multiple copies of Bria which
supports XMPP chat and SIP video.

Putting feelers out!

Thank you very much

Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20170110/69048ef6/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
dev mailing list
dev@jitsi.org
http://lists.jitsi.org/mailman/listinfo/dev

------------------------------

End of dev Digest, Vol 46, Issue 40
***********************************


#2

Hi

aTalk-android development is a fork based on jitsi-android.

I have just released a aTalk version 0.7.2 based on the latest Smack
version 0.4.2-rc (SNAPSHOT). aTalk is now able to support
XEP-0077:In-Band Registration and XEP- 0158:CAPTCHA Forms for captcha
protected online registration. If anybody of you is interested; the
released android apk is free and can be downloaded from:
http://atalk.sytes.net/releases/atalk-android/aTalk-release.apk

Note: the aTalk is still in beta release, and support only XMPP protocol.

Although the Apache License doesn't require you to publish the source code, we would appreciate it if you'd do so. In particular, the upgrade of Smack to 4.2 would be most welcome in Jitsi.

It really doesn't matter whether it's still in alpha/beta or whatever you want to call it. Please also note that some used libraries that aren't originally from Atlassian are GPL/LGPL/Eclipse licensed and mandate to release the source code if you modify them.

If you keep it closed source however, I don't think it's very appropriate to promote it on this list.

Regards,
CM Eng

Ingo