[jitsi-dev] feature requests


#1

Hi,

As suggested my Emil on the Users mailing list I'd like to file some feature requests:

http://java.net/nonav/projects/jitsi/lists/users/archive/2012-04/message/126

Before posting on JIRA, I'd like to know if I can actually proceed in doing so.

My requests will be:

1) optionally configure Jitsi to accept only one call at a time and that if another caller tries to reach me, a busy signal should be sent back. My "status" should be the general one, so, if I have several accounts (jabber, sip, etc.), being busy on just one of them is enough to consider myself globally busy and should not receive any other calls.

2) whenever there's an incoming call and the Jitsi phone rings, it shoudl optionally make a sound (beep) in the internal PC speaker. So, just like the sound file for incoming calls is played out to the loudspeakers, a beep should also sound on the internal speaker until the call is answered. There are quite a lot of cases where a user moving around in an office can only hear the internal speaker beep if the "audio out" is connected to a headset.

3) the Jitsi "events" mechanism should pass arguments to the custom user scripts. For example, whenever there's an incoming call, I'd like to run a custom script but I'd also like to know who's calling. So Jitsi could pass the caller's number to the custom script. That way, integrating with a CRM is simple - the script can lookup the caller's number in a database and show it to the callee before answering the phone.

4) there should be a Jitsi "event" or trigger for "answering calls". There's one for incoming call and another for hanging up a call but "answering a call" isn't contemplated.

5) when provisioning via a custom HTTPS URL, if I set the locale language, it will be loaded into Jitsi just fine but it will be applied only if the user restarts Jitsi. I'm wondering if it's possible to apply the language early enough in the Jitsi launching process in order to avoid program restart.

6) when a provisioning URL does not contain ${password} but contains ${username}, the username is sent blank. Can't the username with which the user has logged into the OS be sent instead? (eg., Linux 'whoami' or Windows %USERNAME%)
That would allow for some easy provisioning cases without the unnecessary Jitsi dialog box asking for username and password, when a password is not really needed, according to admin.

Of course I realize you have limited resources so I would also appreciate it if you could just lend me a hand on where in the Jitsi source code I should focus my attention on in order to introduce some of my feature requests. I'm not fluent in java but I can learn (I'm using netbeans and I'm building from SVN).

In any case, can I post my requests on JIRA?

Thanks,

Vieri


#2

I was also wondering if I could ask for another feature that just came to mind:

scine Jitsi has this great provisioning feature, it would be useful (for admin purposes) to optionally disable some menu items such as:

"File -> Add new account"
"Tools -> Options"

However, if "Tools -> Options" is disabled then it would be useful for the user to be able to do things like:

- choose the audio (mic & speakers) and video hardware devices (there can be more than one)
- generate security private keys (fingerprints) for each account auto-provisioned

These should be new items available under the Tools menu.

Can I post this feature request?

Thanks

Vieri


#3

Hey Vieri,

Hi,

As suggested my Emil on the Users mailing list I'd like to file some
feature requests:

http://java.net/nonav/projects/jitsi/lists/users/archive/2012-04/message/126

Before posting on JIRA, I'd like to know if I can actually proceed
in doing so.

My requests will be:

1) optionally configure Jitsi to accept only one call at a time and
that if another caller tries to reach me, a busy signal should be
sent back. My "status" should be the general one, so, if I have
several accounts (jabber, sip, etc.), being busy on just one of them
is enough to consider myself globally busy and should not receive any
other calls.

Yes, thanks, please open a feature request for this one.

2) whenever there's an incoming call and the Jitsi phone rings, it
shoudl optionally make a sound (beep) in the internal PC speaker. So,
just like the sound file for incoming calls is played out to the
loudspeakers, a beep should also sound on the internal speaker until
the call is answered. There are quite a lot of cases where a user
moving around in an office can only hear the internal speaker beep if
the "audio out" is connected to a headset.

Given how many modern computers do not have a PC speaker and emulate it
through their audio device, I don't think this one will be a priority.
If you could find someone interested in implementing it then we can have
it. I think it's unlikely the current dev team would get to it otherwise.

3) the Jitsi "events" mechanism should pass arguments to the custom
user scripts. For example, whenever there's an incoming call, I'd
like to run a custom script but I'd also like to know who's calling.
So Jitsi could pass the caller's number to the custom script. That
way, integrating with a CRM is simple - the script can lookup the
caller's number in a database and show it to the callee before
answering the phone.

OK. Please enter this one as a feature request.

4) there should be a Jitsi "event" or trigger for "answering calls".
There's one for incoming call and another for hanging up a call but
"answering a call" isn't contemplated.

OK. Please open a ticket for this one. However we should make it about
beginning a call. Not only answering one.

5) when provisioning via a custom HTTPS URL, if I set the locale
language, it will be loaded into Jitsi just fine but it will be
applied only if the user restarts Jitsi. I'm wondering if it's
possible to apply the language early enough in the Jitsi launching
process in order to avoid program restart.

Not currently, I am afraid. The same would apply if users change it via
the user interface.

6) when a provisioning URL does not contain \{password\} but contains {username}, the username is sent blank. Can't the username with
which the user has logged into the OS be sent instead? (eg., Linux
'whoami' or Windows %USERNAME%) That would allow for some easy
provisioning cases without the unnecessary Jitsi dialog box asking
for username and password, when a password is not really needed,
according to admin.

Hmmm ... interesting. We could actually implement a mechanism that
allows retrieving any system property via provisioning. Something like
\{system\.property\_name\}\. The user name would hence be available as {system.user.name}

Of course I realize you have limited resources so I would also
appreciate it if you could just lend me a hand on where in the Jitsi
source code I should focus my attention on in order to introduce some
of my feature requests. I'm not fluent in java but I can learn (I'm
using netbeans and I'm building from SVN).

Sure. Which one would you like to start with?

Cheers,
Emil

···

On 16.04.12 20:36, Vieri wrote:

In any case, can I post my requests on JIRA?

Thanks,

Vieri

--
http://jitsi.org


#4

Hi Emil,

···

--- On Sun, 4/22/12, Emil Ivov <emcho@jitsi.org> wrote:

> 2) whenever there's an incoming call and the Jitsi
phone rings, it
> shoudl optionally make a sound (beep) in the internal
PC speaker. So,
> just like the sound file for incoming calls is played
out to the
> loudspeakers, a beep should also sound on the internal
speaker until
> the call is answered. There are quite a lot of cases
where a user
> moving around in an office can only hear the internal
speaker beep if
> the "audio out" is connected to a headset.

Given how many modern computers do not have a PC speaker and
emulate it
through their audio device, I don't think this one will be a
priority.
If you could find someone interested in implementing it then
we can have
it. I think it's unlikely the current dev team would get to
it otherwise.
> Of course I realize you have limited resources so I
would also
> appreciate it if you could just lend me a hand on where
in the Jitsi
> source code I should focus my attention on in order to
introduce some
> of my feature requests.

Sure. Which one would you like to start with?

Well, for starters, maybe issue num. 2 is the easiest. Besides, it's the one jitsi devs probably won't tackle with (and I understand why). I don't want you to do my homework for me so I'll get back to you tomorrow, after I take a look at the source code. I should probably search for the code that plays the wav for incoming calls (ring tone) and that's where I should try to beep the internal speaker.
Actually, right now my hack is simple: I define an event trigger: for each incoming call event (ring), launch a custom script that actually rings the internal speaker. That's good enough for me except that I don't know when to stop ringing because there's no "answered call" event trigger.
Anyway, will get back to it tomorrow if time permits.

Thanks

Vieri


#5

This is actually already possible. One could disable quite a number of
things, including any of the configuration tabs.

Yana, could you please remind us what the exact strings are for the
properties that Vieri is asking for?

Emil

···

On 16.04.12 20:48, Vieri wrote:

I was also wondering if I could ask for another feature that just came to mind:

scine Jitsi has this great provisioning feature, it would be useful (for admin purposes) to optionally disable some menu items such as:

"File -> Add new account"
"Tools -> Options"

However, if "Tools -> Options" is disabled then it would be useful for the user to be able to do things like:

- choose the audio (mic & speakers) and video hardware devices (there can be more than one)
- generate security private keys (fingerprints) for each account auto-provisioned

These should be new items available under the Tools menu.

Can I post this feature request?

Thanks

Vieri

--
http://jitsi.org


#6

I've done a very quick and ugly hack to:

PortAudioClipImpl.java

(I'm using PortAudio)

within
runOnceInPlayThread
I added this simple system call:

        try
        {
        Runtime.getRuntime().exec("Beep_in.exe");
        }
        catch (IOException e)
        {
        }

This is of course Windows-specific but it "works for me". Each time the incomingCall.wav is played (in a loop), so is "Beep_in.exe". The Windows exe simply calls an OS beep function. I think I can beep directly from Java without calling an external program (maybe with jna) but in any case it would be Windows-specific.
Just a question though:
When I answer an incoming call that repeatedly beeps correctly, it stops beeping as expected (also stops playing the wav file). However, when I hang up, it beeps once (the wav file isn't played or at least I can't hear it).
Why does it beep once?

So I moved the call to Beep_in.exe from runOnceInPlayThread
to runInPlayThread within:

            if(isLooping())
            {
                synchronized(syncObject)
                {
                    if (started)
                    {

It now seems to work as expected.
I can notice some I/O overhead each time it calls Beep_in.exe so I'll try to use JNA instead. Any suggestions?

Thanks,

Vieri

···

--- On Sun, 4/22/12, Vieri <rentorbuy@yahoo.com> wrote:

Hi Emil,

--- On Sun, 4/22/12, Emil Ivov <emcho@jitsi.org> > wrote:

> > 2) whenever there's an incoming call and the
Jitsi
> phone rings, it
> > shoudl optionally make a sound (beep) in the
internal
> PC speaker. So,
> > just like the sound file for incoming calls is
played
> out to the
> > loudspeakers, a beep should also sound on the
internal
> speaker until
> > the call is answered. There are quite a lot of
cases
> where a user
> > moving around in an office can only hear the
internal
> speaker beep if
> > the "audio out" is connected to a headset.
>
> Given how many modern computers do not have a PC
speaker and
> emulate it
> through their audio device, I don't think this one will
be a
> priority.
> If you could find someone interested in implementing it
then
> we can have
> it. I think it's unlikely the current dev team would
get to
> it otherwise.
> > Of course I realize you have limited resources so
I
> would also
> > appreciate it if you could just lend me a hand on
where
> in the Jitsi
> > source code I should focus my attention on in
order to
> introduce some
> > of my feature requests.
>
> Sure. Which one would you like to start with?

Well, for starters, maybe issue num. 2 is the easiest.
Besides, it's the one jitsi devs probably won't tackle with
(and I understand why). I don't want you to do my homework
for me so I'll get back to you tomorrow, after I take a look
at the source code. I should probably search for the code
that plays the wav for incoming calls (ring tone) and that's
where I should try to beep the internal speaker.
Actually, right now my hack is simple: I define an event
trigger: for each incoming call event (ring), launch a
custom script that actually rings the internal speaker.
That's good enough for me except that I don't know when to
stop ringing because there's no "answered call" event
trigger.
Anyway, will get back to it tomorrow if time permits.


#7

Hi Vieri, Emil,

"File -> Add new account" can be configured by specifying "net.java.sip.communicator.impl.gui.main.configforms.SHOW_ACCOUNT_CONFIG".
"Tools -> Options" can be configured by specifying "net.java.sip.communicator.impl.gui.main.configforms.SHOW_OPTIONS_WINDOW"

Cheers,
Yana

···

On Apr 22, 2012, at 2:24 PM, Emil Ivov wrote:

This is actually already possible. One could disable quite a number of
things, including any of the configuration tabs.

Yana, could you please remind us what the exact strings are for the
properties that Vieri is asking for?

Emil

On 16.04.12 20:48, Vieri wrote:

I was also wondering if I could ask for another feature that just came to mind:

scine Jitsi has this great provisioning feature, it would be useful (for admin purposes) to optionally disable some menu items such as:

"File -> Add new account"
"Tools -> Options"

However, if "Tools -> Options" is disabled then it would be useful for the user to be able to do things like:

- choose the audio (mic & speakers) and video hardware devices (there can be more than one)
- generate security private keys (fingerprints) for each account auto-provisioned

These should be new items available under the Tools menu.

Can I post this feature request?

Thanks

Vieri

--
http://jitsi.org


#8

Thanks Yana!

net.java.sip.communicator.impl.gui.main.configforms.SHOW_ACCOUNT_CONFIG
and
net.java.sip.communicator.impl.gui.main.configforms.SHOW_OPTIONS_WINDOW
are evaluated as booleans.

So If I disable/hide "Tools -> Options" then the user won't be able to:
- choose the audio (mic & speakers) and video hardware devices (there can be more than one)
- generate security private keys (fingerprints) for each auto-provisioned account

Another way would be to enable/show "Tools -> Options" but hide everything else except "Tools -> Options -> Security", "Tools -> Options -> Video" and "Tools -> Options -> Audio" (one would still need to disable some elements within these tabs).

I'm not sure I can actually disable/hide sub-elements of a menu (eg. "Tools -> Options -> Video") via config/provisioning.

Anyway, I'll search for the relevant calls in the source code and disable them directly there.

Thanks again,

Vieri

···

--- On Mon, 4/23/12, Yana Stamcheva <yana@jitsi.org> wrote:

"File -> Add new account" can be configured by specifying
"net.java.sip.communicator.impl.gui.main.configforms.SHOW_ACCOUNT_CONFIG".
"Tools -> Options" can be configured by specifying
"net.java.sip.communicator.impl.gui.main.configforms.SHOW_OPTIONS_WINDOW"


#9

Hi Vieri,

Sorry I misunderstood your question. Here are the other properties that could be of help:

"net.java.sip.communicator.plugin.generalconfig.DISABLED" - disables the "General" tab of the Options dialog
"net.java.sip.communicator.plugin.notificationconfiguration.DISABLED" - disables the "Events" tab
"net.java.sip.communicator.plugin.advancedconfig.DISABLED" - disables the "Advanced" tab
"net.java.sip.communicator.plugin.chatconfig.DISABLED" - disables the "Chat" tab

The "Accounts" tab is disabled by the property I've already mentioned earlier.

Hope this helps,
Yana

···

On Apr 23, 2012, at 3:11 PM, Vieri wrote:

--- On Mon, 4/23/12, Yana Stamcheva <yana@jitsi.org> wrote:

"File -> Add new account" can be configured by specifying
"net.java.sip.communicator.impl.gui.main.configforms.SHOW_ACCOUNT_CONFIG".
"Tools -> Options" can be configured by specifying
"net.java.sip.communicator.impl.gui.main.configforms.SHOW_OPTIONS_WINDOW"

Thanks Yana!

net.java.sip.communicator.impl.gui.main.configforms.SHOW_ACCOUNT_CONFIG
and
net.java.sip.communicator.impl.gui.main.configforms.SHOW_OPTIONS_WINDOW
are evaluated as booleans.

So If I disable/hide "Tools -> Options" then the user won't be able to:
- choose the audio (mic & speakers) and video hardware devices (there can be more than one)
- generate security private keys (fingerprints) for each auto-provisioned account

Another way would be to enable/show "Tools -> Options" but hide everything else except "Tools -> Options -> Security", "Tools -> Options -> Video" and "Tools -> Options -> Audio" (one would still need to disable some elements within these tabs).

I'm not sure I can actually disable/hide sub-elements of a menu (eg. "Tools -> Options -> Video") via config/provisioning.

Anyway, I'll search for the relevant calls in the source code and disable them directly there.

Thanks again,

Vieri


#10

Thanks Yana.
I don't know if there's an easy way to "grep"/search the jitsi source tree in order to list *all* properties.
Searching for the string '= "net.java.sip.communicator.' is not too bad although incomplete and inaccurate.
Anyway, I've got all I need now. Thanks again.

Vieri

···

--- On Mon, 4/23/12, Yana Stamcheva <yana@jitsi.org> wrote:

Hi Vieri,

Sorry I misunderstood your question. Here are the other
properties that could be of help:

"net.java.sip.communicator.plugin.generalconfig.DISABLED" -
disables the "General" tab of the Options dialog
"net.java.sip.communicator.plugin.notificationconfiguration.DISABLED"
- disables the "Events" tab
"net.java.sip.communicator.plugin.advancedconfig.DISABLED" -
disables the "Advanced" tab
"net.java.sip.communicator.plugin.chatconfig.DISABLED" -
disables the "Chat" tab


#11

Hi Vieri

if it happen that you use git as a forntend to Jitsi's
SVN then you could use the following command:

git grep '"net\.java\.sip\.communicator\.'

from the top level directory. This gives pretty much all of
the property strings - and it's a lot :slight_smile: . If you
call this command from the src directoy then the grep will
goes down the src structure only. It's not perfect but a quite
good approximation :-).

Regards,
Werner

···

Am 23.04.2012 17:53, schrieb Vieri:

--- On Mon, 4/23/12, Yana Stamcheva <yana@jitsi.org> wrote:

Hi Vieri,

Sorry I misunderstood your question. Here are the other
properties that could be of help:

"net.java.sip.communicator.plugin.generalconfig.DISABLED" -
disables the "General" tab of the Options dialog
"net.java.sip.communicator.plugin.notificationconfiguration.DISABLED"
- disables the "Events" tab
"net.java.sip.communicator.plugin.advancedconfig.DISABLED" -
disables the "Advanced" tab
"net.java.sip.communicator.plugin.chatconfig.DISABLED" -
disables the "Chat" tab

Thanks Yana.
I don't know if there's an easy way to "grep"/search the jitsi source tree in order to list *all* properties.
Searching for the string '= "net.java.sip.communicator.' is not too bad although incomplete and inaccurate.
Anyway, I've got all I need now. Thanks again.

Vieri


#12

Thanks Werner!

···

--- On Mon, 4/23/12, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

git grep '"net\.java\.sip\.communicator\.'