[jitsi-dev] The state of XMPP Conferencing (and in-call UI restriction)


#1

Hi again all,

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+ person audio call is initiated from scratch it fails, and upgrading a 2 person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption, and the particular stacktrace in the attached log files makes me think it's an issue with this encryption method.

Is it possible for SDES support to work with three person calls? And if not, is there a provisioning setting I can use to disable this functionality? I would like to disable various components of the In call UI actually - my business has no current need for "Hold" nor "Videochat" (especially as we are not using Jitsi Videobridge). Would it be possible to disable the UI buttons for these without disabling eg Screen Sharing / Remote Desktop? I'm generally interested in locking down Jitsi to a basic featureset before I roll in stuff that I think is "mature" enough and necessary, especially as there is some user education that has to go on.

Many thanks as always.

···

---
Toby Pinder
Software Developer
Smith Electric Vehicles


#2

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+
person audio call is initiated from scratch it fails, and upgrading a 2
person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption,

and

the particular stacktrace in the attached log files makes me think it's an
issue with this encryption method.

Could you please add/send those logs?

Is it possible for SDES support to work with three person calls?

Well, at least it should. The key for each media stream is exchanged between
the conference master and the corresponding participant. The participants
don't know each other's keys.
AFAIK it still works for SIP, so there might be an issue in passing the keys
from the XMPP layer down to the media layer.

And if not,
is there a provisioning setting I can use to disable this functionality? I
would like to disable various components of the In call UI actually - my
business has no current need for "Hold" nor "Videochat" (especially as we

are

not using Jitsi Videobridge). Would it be possible to disable the UI

buttons

for these without disabling eg Screen Sharing / Remote Desktop? I'm

generally

interested in locking down Jitsi to a basic featureset before I roll in

stuff

that I think is "mature" enough and necessary, especially as there is some
user education that has to go on.

Many thanks as always.
---
Toby Pinder

Ingo


#3

My apologies, I'll have to get back to you on this on Monday Morning - I've been swamped with other stuff and my logs are only accessible from work. I may get some opportunity this weekend to do some tinkering with SIP for comparative purposes to see if that's working, but as I'd be operating "alone" without US collaborators and on a completely different stack I'm not sure how representative a test that would be.

Many thanks,
Toby Pinder | Software Developer
Smith Electric Vehicles

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+
person audio call is initiated from scratch it fails, and upgrading a 2
person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption,

and

the particular stacktrace in the attached log files makes me think it's an
issue with this encryption method.

Could you please add/send those logs?

Is it possible for SDES support to work with three person calls?

Well, at least it should. The key for each media stream is exchanged between
the conference master and the corresponding participant. The participants
don't know each other's keys.
AFAIK it still works for SIP, so there might be an issue in passing the keys
from the XMPP layer down to the media layer.

And if not,
is there a provisioning setting I can use to disable this functionality? I
would like to disable various components of the In call UI actually - my
business has no current need for "Hold" nor "Videochat" (especially as we

are

not using Jitsi Videobridge). Would it be possible to disable the UI

buttons

for these without disabling eg Screen Sharing / Remote Desktop? I'm

generally

interested in locking down Jitsi to a basic featureset before I roll in

stuff

that I think is "mature" enough and necessary, especially as there is some
user education that has to go on.

Many thanks as always.
---
Toby Pinder

Ingo

···

On 31/10/13 21:06, Ingo Bauersachs wrote:

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


#4

Hi Ingo (and devs),

Sorry for the delay. We scheduled a test call in which myself (person A) called Ross (person B) and then I (person A) attempted to add David (person C). C was not able to join the call. Log files are attached.

By the way, those logs show some unrelated issues to do with (person B), who is running Jitsi for Windows through Confluence on a Mac. We believe he had some DNS related issues but they are unrelated and we have tested this experiment with other users: we consistently reproduce the same problem.

Potential stacktrace of interest (in A.toby.log.0 line 441):

15:51:46.021 SEVERE: [25] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null java.lang.NullPointerException
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceParticipantPanel.securityOn(BasicConferenceParticipantPanel.java:487)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.securityOn(ConferencePeerPanel.java:523)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.initSecuritySettings(ConferencePeerPanel.java:315)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:243)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:188)
  at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.updateViewFromModel(AudioConferenceCallPanel.java:187)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:521)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.java:640)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:497)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.initializeComplete(BasicConferenceCallPanel.java:383)
  at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.<init>(AudioConferenceCallPanel.java:132)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromModelInEventDispatchThread(CallPanel.java:1002)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromModelInEventDispatchThread(CallPanel.java:2135)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPanel.java:65)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.java:335)
  at java.awt.event.InvocationEvent.dispatch(Unknown Source)
  at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
  at java.awt.EventQueue.access$200(Unknown Source)
  at java.awt.EventQueue$3.run(Unknown Source)
  at java.awt.EventQueue$3.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
  at java.awt.EventQueue.dispatchEvent(Unknown Source)
  at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
  at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
  at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
  at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
  at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
  at java.awt.EventDispatchThread.run(Unknown Source)

It certainly seems to my uninitiated self that this is an issue during the negotiation interacting with the crypto, but I don't want to jump to conclusions.

Thanks for your help,

Toby Pinder | Software Developer
Smith Electric Vehicles

Conference.zip (62.8 KB)

···

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

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder
Sent: 01 November 2013 14:22
To: dev@jitsi.org
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI restriction)

My apologies, I'll have to get back to you on this on Monday Morning - I've been swamped with other stuff and my logs are only accessible from work. I may get some opportunity this weekend to do some tinkering with SIP for comparative purposes to see if that's working, but as I'd be operating "alone" without US collaborators and on a completely different stack I'm not sure how representative a test that would be.

Many thanks,
Toby Pinder | Software Developer
Smith Electric Vehicles

On 31/10/13 21:06, Ingo Bauersachs wrote:

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+
person audio call is initiated from scratch it fails, and upgrading a 2
person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption,

and

the particular stacktrace in the attached log files makes me think it's an
issue with this encryption method.

Could you please add/send those logs?

Is it possible for SDES support to work with three person calls?

Well, at least it should. The key for each media stream is exchanged between
the conference master and the corresponding participant. The participants
don't know each other's keys.
AFAIK it still works for SIP, so there might be an issue in passing the keys
from the XMPP layer down to the media layer.

And if not,
is there a provisioning setting I can use to disable this functionality? I
would like to disable various components of the In call UI actually - my
business has no current need for "Hold" nor "Videochat" (especially as we

are

not using Jitsi Videobridge). Would it be possible to disable the UI

buttons

for these without disabling eg Screen Sharing / Remote Desktop? I'm

generally

interested in locking down Jitsi to a basic featureset before I roll in

stuff

that I think is "mature" enough and necessary, especially as there is some
user education that has to go on.

Many thanks as always.
---
Toby Pinder

Ingo

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


#5

Tony,

To switch from a two-person call to a conference call, I think you
actually have to start with a conference call to begin with. (In other
words end the two-person call and then go to "Tools > Create a
Conference Call..." (or "Tools > Create a Video Bridge...").

I'm not able to verify if this is correct right now, so let me know if
I'm wrong.

David

···

On 11/4/2013 11:18 AM, Toby Pinder wrote:

Hi Ingo (and devs),

Sorry for the delay. We scheduled a test call in which myself (person A) called Ross (person B) and then I (person A) attempted to add David (person C). C was not able to join the call. Log files are attached.

By the way, those logs show some unrelated issues to do with (person B), who is running Jitsi for Windows through Confluence on a Mac. We believe he had some DNS related issues but they are unrelated and we have tested this experiment with other users: we consistently reproduce the same problem.

Potential stacktrace of interest (in A.toby.log.0 line 441):

15:51:46.021 SEVERE: [25] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null java.lang.NullPointerException
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceParticipantPanel.securityOn(BasicConferenceParticipantPanel.java:487)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.securityOn(ConferencePeerPanel.java:523)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.initSecuritySettings(ConferencePeerPanel.java:315)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:243)
  at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:188)
  at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.updateViewFromModel(AudioConferenceCallPanel.java:187)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:521)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.java:640)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:497)
  at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.initializeComplete(BasicConferenceCallPanel.java:383)
  at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.<init>(AudioConferenceCallPanel.java:132)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromModelInEventDispatchThread(CallPanel.java:1002)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromModelInEventDispatchThread(CallPanel.java:2135)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPanel.java:65)
  at net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.java:335)
  at java.awt.event.InvocationEvent.dispatch(Unknown Source)
  at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
  at java.awt.EventQueue.access$200(Unknown Source)
  at java.awt.EventQueue$3.run(Unknown Source)
  at java.awt.EventQueue$3.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
  at java.awt.EventQueue.dispatchEvent(Unknown Source)
  at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
  at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
  at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
  at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
  at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
  at java.awt.EventDispatchThread.run(Unknown Source)

It certainly seems to my uninitiated self that this is an issue during the negotiation interacting with the crypto, but I don't want to jump to conclusions.

Thanks for your help,

Toby Pinder | Software Developer
Smith Electric Vehicles
----------------------------------------------------------------------------------------

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder
Sent: 01 November 2013 14:22
To: dev@jitsi.org
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI restriction)

My apologies, I'll have to get back to you on this on Monday Morning - I've been swamped with other stuff and my logs are only accessible from work. I may get some opportunity this weekend to do some tinkering with SIP for comparative purposes to see if that's working, but as I'd be operating "alone" without US collaborators and on a completely different stack I'm not sure how representative a test that would be.

Many thanks,
Toby Pinder | Software Developer
Smith Electric Vehicles

On 31/10/13 21:06, Ingo Bauersachs wrote:

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+
person audio call is initiated from scratch it fails, and upgrading a 2
person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption,

and

the particular stacktrace in the attached log files makes me think it's an
issue with this encryption method.

Could you please add/send those logs?

Is it possible for SDES support to work with three person calls?

Well, at least it should. The key for each media stream is exchanged between
the conference master and the corresponding participant. The participants
don't know each other's keys.
AFAIK it still works for SIP, so there might be an issue in passing the keys
from the XMPP layer down to the media layer.

And if not,
is there a provisioning setting I can use to disable this functionality? I
would like to disable various components of the In call UI actually - my
business has no current need for "Hold" nor "Videochat" (especially as we

are

not using Jitsi Videobridge). Would it be possible to disable the UI

buttons

for these without disabling eg Screen Sharing / Remote Desktop? I'm

generally

interested in locking down Jitsi to a basic featureset before I roll in

stuff

that I think is "mature" enough and necessary, especially as there is some
user education that has to go on.

Many thanks as always.
---
Toby Pinder

Ingo

_______________________________________________
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


#6

Hey David,

There is no such requirement for regular conference calls (the one
that Jitsi mixes and/or relays). It's not impossible that a bug would
prevent one scenario from happening while the other completes
successfully but generally both work.

Video bridge conferences do indeed need to be created as such. At
least currently. We may want to make that automatic in the future.

Cheers,
Emil

···

On Tue, Nov 5, 2013 at 1:07 AM, David Bolton <davidkbolton@gmail.com> wrote:

Tony,

To switch from a two-person call to a conference call, I think you
actually have to start with a conference call to begin with. (In other
words end the two-person call and then go to "Tools > Create a
Conference Call..." (or "Tools > Create a Video Bridge...").

I'm not able to verify if this is correct right now, so let me know if
I'm wrong.

David

On 11/4/2013 11:18 AM, Toby Pinder wrote:

Hi Ingo (and devs),

Sorry for the delay. We scheduled a test call in which myself (person A) called Ross (person B) and then I (person A) attempted to add David (person C). C was not able to join the call. Log files are attached.

By the way, those logs show some unrelated issues to do with (person B), who is running Jitsi for Windows through Confluence on a Mac. We believe he had some DNS related issues but they are unrelated and we have tested this experiment with other users: we consistently reproduce the same problem.

Potential stacktrace of interest (in A.toby.log.0 line 441):

15:51:46.021 SEVERE: [25] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null java.lang.NullPointerException
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceParticipantPanel.securityOn(BasicConferenceParticipantPanel.java:487)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.securityOn(ConferencePeerPanel.java:523)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.initSecuritySettings(ConferencePeerPanel.java:315)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:243)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:188)
      at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.updateViewFromModel(AudioConferenceCallPanel.java:187)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:521)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.java:640)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:497)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.initializeComplete(BasicConferenceCallPanel.java:383)
      at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.<init>(AudioConferenceCallPanel.java:132)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromModelInEventDispatchThread(CallPanel.java:1002)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromModelInEventDispatchThread(CallPanel.java:2135)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPanel.java:65)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.java:335)
      at java.awt.event.InvocationEvent.dispatch(Unknown Source)
      at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
      at java.awt.EventQueue.access$200(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
      at java.awt.EventQueue.dispatchEvent(Unknown Source)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.run(Unknown Source)

It certainly seems to my uninitiated self that this is an issue during the negotiation interacting with the crypto, but I don't want to jump to conclusions.

Thanks for your help,

Toby Pinder | Software Developer
Smith Electric Vehicles
----------------------------------------------------------------------------------------

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder
Sent: 01 November 2013 14:22
To: dev@jitsi.org
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI restriction)

My apologies, I'll have to get back to you on this on Monday Morning - I've been swamped with other stuff and my logs are only accessible from work. I may get some opportunity this weekend to do some tinkering with SIP for comparative purposes to see if that's working, but as I'd be operating "alone" without US collaborators and on a completely different stack I'm not sure how representative a test that would be.

Many thanks,
Toby Pinder | Software Developer
Smith Electric Vehicles

On 31/10/13 21:06, Ingo Bauersachs wrote:

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+
person audio call is initiated from scratch it fails, and upgrading a 2
person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption,

and

the particular stacktrace in the attached log files makes me think it's an
issue with this encryption method.

Could you please add/send those logs?

Is it possible for SDES support to work with three person calls?

Well, at least it should. The key for each media stream is exchanged between
the conference master and the corresponding participant. The participants
don't know each other's keys.
AFAIK it still works for SIP, so there might be an issue in passing the keys
from the XMPP layer down to the media layer.

And if not,
is there a provisioning setting I can use to disable this functionality? I
would like to disable various components of the In call UI actually - my
business has no current need for "Hold" nor "Videochat" (especially as we

are

not using Jitsi Videobridge). Would it be possible to disable the UI

buttons

for these without disabling eg Screen Sharing / Remote Desktop? I'm

generally

interested in locking down Jitsi to a basic featureset before I roll in

stuff

that I think is "mature" enough and necessary, especially as there is some
user education that has to go on.

Many thanks as always.
---
Toby Pinder

Ingo

_______________________________________________
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

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

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


#7

David,

I tried creating a multimedia call "from scratch" rather than "upgrading" an existing call in the manner you specified. In this way similar stacktraces are thrown and the call does not connect for any of the three users. I'll provide logs of this separate arrangement if you think they are useful?

Thanks,
Toby Pinder | Software Developer
Smith Electric Vehicles

Tony,

To switch from a two-person call to a conference call, I think you
actually have to start with a conference call to begin with. (In other
words end the two-person call and then go to "Tools > Create a
Conference Call..." (or "Tools > Create a Video Bridge...").

I'm not able to verify if this is correct right now, so let me know if
I'm wrong.

David

···

On 05/11/13 00:07, David Bolton wrote:

On 11/4/2013 11:18 AM, Toby Pinder wrote:

Hi Ingo (and devs),

Sorry for the delay. We scheduled a test call in which myself (person A) called Ross (person B) and then I (person A) attempted to add David (person C). C was not able to join the call. Log files are attached.

By the way, those logs show some unrelated issues to do with (person B), who is running Jitsi for Windows through Confluence on a Mac. We believe he had some DNS related issues but they are unrelated and we have tested this experiment with other users: we consistently reproduce the same problem.

Potential stacktrace of interest (in A.toby.log.0 line 441):

15:51:46.021 SEVERE: [25] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null java.lang.NullPointerException
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceParticipantPanel.securityOn(BasicConferenceParticipantPanel.java:487)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.securityOn(ConferencePeerPanel.java:523)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.initSecuritySettings(ConferencePeerPanel.java:315)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:243)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:188)
      at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.updateViewFromModel(AudioConferenceCallPanel.java:187)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:521)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.java:640)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:497)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.initializeComplete(BasicConferenceCallPanel.java:383)
      at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.<init>(AudioConferenceCallPanel.java:132)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromModelInEventDispatchThread(CallPanel.java:1002)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromModelInEventDispatchThread(CallPanel.java:2135)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPanel.java:65)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.java:335)
      at java.awt.event.InvocationEvent.dispatch(Unknown Source)
      at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
      at java.awt.EventQueue.access$200(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
      at java.awt.EventQueue.dispatchEvent(Unknown Source)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.run(Unknown Source)

It certainly seems to my uninitiated self that this is an issue during the negotiation interacting with the crypto, but I don't want to jump to conclusions.

Thanks for your help,

Toby Pinder | Software Developer
Smith Electric Vehicles
----------------------------------------------------------------------------------------

From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder
Sent: 01 November 2013 14:22
To: dev@jitsi.org<mailto:dev@jitsi.org>
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI restriction)

My apologies, I'll have to get back to you on this on Monday Morning - I've been swamped with other stuff and my logs are only accessible from work. I may get some opportunity this weekend to do some tinkering with SIP for comparative purposes to see if that's working, but as I'd be operating "alone" without US collaborators and on a completely different stack I'm not sure how representative a test that would be.

Many thanks,
Toby Pinder | Software Developer
Smith Electric Vehicles

On 31/10/13 21:06, Ingo Bauersachs wrote:

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+
person audio call is initiated from scratch it fails, and upgrading a 2
person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption,

and

the particular stacktrace in the attached log files makes me think it's an
issue with this encryption method.

Could you please add/send those logs?

Is it possible for SDES support to work with three person calls?

Well, at least it should. The key for each media stream is exchanged between
the conference master and the corresponding participant. The participants
don't know each other's keys.
AFAIK it still works for SIP, so there might be an issue in passing the keys
from the XMPP layer down to the media layer.

And if not,
is there a provisioning setting I can use to disable this functionality? I
would like to disable various components of the In call UI actually - my
business has no current need for "Hold" nor "Videochat" (especially as we

are

not using Jitsi Videobridge). Would it be possible to disable the UI

buttons

for these without disabling eg Screen Sharing / Remote Desktop? I'm

generally

interested in locking down Jitsi to a basic featureset before I roll in

stuff

that I think is "mature" enough and necessary, especially as there is some
user education that has to go on.

Many thanks as always.
---
Toby Pinder

Ingo

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

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

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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part7.08010701.04090904@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


#8

Oh and I apologise for the message density on this issue but I should point out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which we haven't had the opportunity to even test yet.

Hey David,

There is no such requirement for regular conference calls (the one
that Jitsi mixes and/or relays). It's not impossible that a bug would
prevent one scenario from happening while the other completes
successfully but generally both work.

Video bridge conferences do indeed need to be created as such. At
least currently. We may want to make that automatic in the future.

Cheers,
Emil

···

On 05/11/13 00:40, Emil Ivov wrote:

On Tue, Nov 5, 2013 at 1:07 AM, David Bolton <davidkbolton@gmail.com><mailto:davidkbolton@gmail.com> wrote:

Tony,

To switch from a two-person call to a conference call, I think you
actually have to start with a conference call to begin with. (In other
words end the two-person call and then go to "Tools > Create a
Conference Call..." (or "Tools > Create a Video Bridge...").

I'm not able to verify if this is correct right now, so let me know if
I'm wrong.

David

On 11/4/2013 11:18 AM, Toby Pinder wrote:

Hi Ingo (and devs),

Sorry for the delay. We scheduled a test call in which myself (person A) called Ross (person B) and then I (person A) attempted to add David (person C). C was not able to join the call. Log files are attached.

By the way, those logs show some unrelated issues to do with (person B), who is running Jitsi for Windows through Confluence on a Mac. We believe he had some DNS related issues but they are unrelated and we have tested this experiment with other users: we consistently reproduce the same problem.

Potential stacktrace of interest (in A.toby.log.0 line 441):

15:51:46.021 SEVERE: [25] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null java.lang.NullPointerException
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceParticipantPanel.securityOn(BasicConferenceParticipantPanel.java:487)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.securityOn(ConferencePeerPanel.java:523)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.initSecuritySettings(ConferencePeerPanel.java:315)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:243)
      at net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPanel.<init>(ConferencePeerPanel.java:188)
      at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.updateViewFromModel(AudioConferenceCallPanel.java:187)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:521)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.java:640)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.updateViewFromModel(BasicConferenceCallPanel.java:497)
      at net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCallPanel.initializeComplete(BasicConferenceCallPanel.java:383)
      at net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCallPanel.<init>(AudioConferenceCallPanel.java:132)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromModelInEventDispatchThread(CallPanel.java:1002)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromModelInEventDispatchThread(CallPanel.java:2135)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPanel.java:65)
      at net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.java:335)
      at java.awt.event.InvocationEvent.dispatch(Unknown Source)
      at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
      at java.awt.EventQueue.access$200(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
      at java.awt.EventQueue.dispatchEvent(Unknown Source)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.run(Unknown Source)

It certainly seems to my uninitiated self that this is an issue during the negotiation interacting with the crypto, but I don't want to jump to conclusions.

Thanks for your help,

Toby Pinder | Software Developer
Smith Electric Vehicles
----------------------------------------------------------------------------------------

From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder
Sent: 01 November 2013 14:22
To: dev@jitsi.org<mailto:dev@jitsi.org>
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI restriction)

My apologies, I'll have to get back to you on this on Monday Morning - I've been swamped with other stuff and my logs are only accessible from work. I may get some opportunity this weekend to do some tinkering with SIP for comparative purposes to see if that's working, but as I'd be operating "alone" without US collaborators and on a completely different stack I'm not sure how representative a test that would be.

Many thanks,
Toby Pinder | Software Developer
Smith Electric Vehicles

On 31/10/13 21:06, Ingo Bauersachs wrote:

I have been experiencing issues with XMPP chat and SDES: as soon as a 3+
person audio call is initiated from scratch it fails, and upgrading a 2
person call to a 3 person one simply fails for that third person.

We have had success with this prior when testing without SDES encryption,

and

the particular stacktrace in the attached log files makes me think it's an
issue with this encryption method.

Could you please add/send those logs?

Is it possible for SDES support to work with three person calls?

Well, at least it should. The key for each media stream is exchanged between
the conference master and the corresponding participant. The participants
don't know each other's keys.
AFAIK it still works for SIP, so there might be an issue in passing the keys
from the XMPP layer down to the media layer.

And if not,
is there a provisioning setting I can use to disable this functionality? I
would like to disable various components of the In call UI actually - my
business has no current need for "Hold" nor "Videochat" (especially as we

are

not using Jitsi Videobridge). Would it be possible to disable the UI

buttons

for these without disabling eg Screen Sharing / Remote Desktop? I'm

generally

interested in locking down Jitsi to a basic featureset before I roll in

stuff

that I think is "mature" enough and necessary, especially as there is some
user education that has to go on.

Many thanks as always.
---
Toby Pinder

Ingo

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

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

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

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

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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part9.03070703.03080203@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


#9

Toby

Thanks for your logs. I just committed a hack that should at least fix the
bug you observed. I currently have no possibility to test SDES with XMPP,
but a conference with SIP and three SDES encrypted participants now worked
fine. Can you give it another try?

Ingo

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Toby

Pinder
Sent: Dienstag, 5. November 2013 11:25
To: dev@jitsi.org
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
restriction)
Oh and I apologise for the message density on this issue but I should

point

out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which

we

haven't had the opportunity to even test yet.

  Hey David,

  There is no such requirement for regular conference calls (the one
  that Jitsi mixes and/or relays). It's not impossible that a bug

would

  prevent one scenario from happening while the other completes
  successfully but generally both work.

  Video bridge conferences do indeed need to be created as such. At
  least currently. We may want to make that automatic in the future.

  Cheers,
  Emil

<mailto:davidkbolton@gmail.com> wrote: > Tony, > > To

switch from a

two-person call to a conference call, I think you > actually have to
start with a conference call to begin with. (In other > words end

the

two-person call and then go to "Tools > Create a > Conference

Call..."

(or "Tools > Create a Video Bridge..."). > > I'm not able to

verify if

this is correct right now, so let me know if > I'm wrong. > >

David

Hi Ingo (and

devs), >> >> Sorry for the delay. We scheduled a test call in

which

myself (person A) called Ross (person B) and then I (person A) attempted
to add David (person C). C was not able to join the call. Log files are
attached. >> >> By the way, those logs show some unrelated issues

to

do with (person B), who is running Jitsi for Windows through Confluence
on a Mac. We believe he had some DNS related issues but they are
unrelated and we have tested this experiment with other users: we
consistently reproduce the same problem. >> >> Potential

stacktrace of

interest (in A.toby.log.0 line 441): >> >> 15:51:46.021 SEVERE: [25]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferencePa
rtic ipantPanel.securityOn(BasicConferenceParticipantPanel.java:487) >>
      at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.s ecurityOn(ConferencePeerPanel.java:523) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.i nitSecuritySettings(ConferencePeerPanel.java:315) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:243) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:188) >> at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.updateViewFromModel(AudioConferenceCallPanel.java:187) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:521) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa
nel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.jav
a:64 0) >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:497) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.initializeComplete(BasicConferenceCallPanel.java:383) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.<init>(AudioConferenceCallPanel.java:132) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromMo
delI nEventDispatchThread(CallPanel.java:1002) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromMode
lInE ventDispatchThread(CallPanel.java:2135) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPan
el.j ava:65) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.ja
va:3 35) >> at java.awt.event.InvocationEvent.dispatch(Unknown
Source) >> at java.awt.EventQueue.dispatchEventImpl(Unknown
Source) >> at java.awt.EventQueue.access$200(Unknown Source)

     at java.awt.EventQueue$3.run(Unknown Source) >> at
java.awt.EventQueue$3.run(Unknown Source) >> at
java.security.AccessController.doPrivileged(Native Method) >> at
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
  >> at java.awt.EventQueue.dispatchEvent(Unknown Source) >>

at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
  >> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
Source) >> at
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) >>
     at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >> at
java.awt.EventDispatchThread.run(Unknown Source) >> >> It

certainly

seems to my uninitiated self that this is an issue during the
negotiation interacting with the crypto, but I don't want to jump to
conclusions. >> >> Thanks for your help, >> >> Toby

Pinder |

Software Developer >> Smith Electric Vehicles >>
-------------------------------------------------------------------
--------------------- >> >> From: dev-bounces@jitsi.org
[mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder >> Sent: 01
November 2013 14:22 >> To: dev@jitsi.org >> Subject: Re: [jitsi-dev]
The state of XMPP Conferencing (and in- call UI restriction) >> >>

My

apologies, I'll have to get back to you on this on Monday Morning - I've
been swamped with other stuff and my logs are only accessible from work.
I may get some opportunity this weekend to do some tinkering with SIP
for comparative purposes to see if that's working, but as I'd be
operating "alone" without US collaborators and on a completely different
stack I'm not sure how representative a test that would be. >> >>

Many

thanks, >> Toby Pinder | Software Developer >> Smith Electric

Vehicles

  >> >> On 31/10/13 21:06, Ingo Bauersachs wrote: >>> I have

been

experiencing issues with XMPP chat and SDES: as soon as a 3+ >>> person
audio call is initiated from scratch it fails, and upgrading a 2 >>>
person call to a 3 person one simply fails for that third person. >>>
  >>> We have had success with this prior when testing without SDES
encryption, >> and >>> the particular stacktrace in the attached log
files makes me think it's an >>> issue with this encryption method. >>
Could you please add/send those logs? >> >>> Is it possible

for SDES

support to work with three person calls? >> Well, at least it should.
The key for each media stream is exchanged between >> the conference
master and the corresponding participant. The participants >> don't
know each other's keys. >> AFAIK it still works for SIP, so there

might

be an issue in passing the keys >> from the XMPP layer down to the
media layer. >> >>> And if not, >>> is there a provisioning

setting I

···

-----Original Message-----
On 05/11/13 00:40, Emil Ivov wrote:
  On Tue, Nov 5, 2013 at 1:07 AM, David Bolton <davidkbolton@gmail.com>
  > > > > On 11/4/2013 11:18 AM, Toby Pinder wrote:
can use to disable this functionality? I >>> would like to disable
various components of the In call UI actually - my >>> business has no
current need for "Hold" nor "Videochat" (especially as we >> are >>>
not using Jitsi Videobridge). Would it be possible to disable the UI >>
buttons >>> for these without disabling eg Screen Sharing / Remote
Desktop? I'm >> generally >>> interested in locking down Jitsi to a
basic featureset before I roll in >> stuff >>> that I think is
"mature" enough and necessary, especially as there is some >>> user
education that has to go on. >>> >>> Many thanks as always. >>>

---

  >>> Toby Pinder >> Ingo >> >> >>
_______________________________________________ >> 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 > > >
_______________________________________________ > dev mailing list

dev@jitsi.org > Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev

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

  _______________________________________________ dev mailing

list

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


#10

Ingo,

Thanks for this. I'll schedule a test as soon as it's possible to find willing test subjects and report back with the logs.

Toby Pinder | Software Developer
Smith Electric Vehicles

Toby

Thanks for your logs. I just committed a hack that should at least fix the
bug you observed. I currently have no possibility to test SDES with XMPP,
but a conference with SIP and three SDES encrypted participants now worked
fine. Can you give it another try?

Ingo

From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of

Toby

Pinder
Sent: Dienstag, 5. November 2013 11:25
To: dev@jitsi.org<mailto:dev@jitsi.org>
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
restriction)
Oh and I apologise for the message density on this issue but I should

point

out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which

we

haven't had the opportunity to even test yet.

      Hey David,

      There is no such requirement for regular conference calls (the one
      that Jitsi mixes and/or relays). It's not impossible that a bug

would

      prevent one scenario from happening while the other completes
      successfully but generally both work.

      Video bridge conferences do indeed need to be created as such. At
      least currently. We may want to make that automatic in the future.

      Cheers,
      Emil

      On Tue, Nov 5, 2013 at 1:07 AM, David Bolton

<davidkbolton@gmail.com><mailto:davidkbolton@gmail.com>

<mailto:davidkbolton@gmail.com> wrote: > Tony, > > To

switch from a

two-person call to a conference call, I think you > actually have to
start with a conference call to begin with. (In other > words end

the

two-person call and then go to "Tools > Create a > Conference

Call..."

(or "Tools > Create a Video Bridge..."). > > I'm not able to

verify if

this is correct right now, so let me know if > I'm wrong. > >

David

Hi Ingo (and

devs), >> >> Sorry for the delay. We scheduled a test call in

which

myself (person A) called Ross (person B) and then I (person A) attempted
to add David (person C). C was not able to join the call. Log files are
attached. >> >> By the way, those logs show some unrelated issues

to

do with (person B), who is running Jitsi for Windows through Confluence
on a Mac. We believe he had some DNS related issues but they are
unrelated and we have tested this experiment with other users: we
consistently reproduce the same problem. >> >> Potential

stacktrace of

interest (in A.toby.log.0 line 441): >> >> 15:51:46.021 SEVERE: [25]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferencePa
rtic ipantPanel.securityOn(BasicConferenceParticipantPanel.java:487) >>
      at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.s ecurityOn(ConferencePeerPanel.java:523) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.i nitSecuritySettings(ConferencePeerPanel.java:315) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:243) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:188) >> at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.updateViewFromModel(AudioConferenceCallPanel.java:187) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:521) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa
nel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.jav
a:64 0) >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:497) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.initializeComplete(BasicConferenceCallPanel.java:383) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.<init>(AudioConferenceCallPanel.java:132) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromMo
delI nEventDispatchThread(CallPanel.java:1002) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromMode
lInE ventDispatchThread(CallPanel.java:2135) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPan
el.j ava:65) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.ja
va:3 35) >> at java.awt.event.InvocationEvent.dispatch(Unknown
Source) >> at java.awt.EventQueue.dispatchEventImpl(Unknown
Source) >> at java.awt.EventQueue.access$200(Unknown Source)

     at java.awt.EventQueue$3.run(Unknown Source) >> at
java.awt.EventQueue$3.run(Unknown Source) >> at
java.security.AccessController.doPrivileged(Native Method) >> at
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
      >> at java.awt.EventQueue.dispatchEvent(Unknown Source) >>

at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
      >> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
Source) >> at
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) >>
     at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >> at
java.awt.EventDispatchThread.run(Unknown Source) >> >> It

certainly

seems to my uninitiated self that this is an issue during the
negotiation interacting with the crypto, but I don't want to jump to
conclusions. >> >> Thanks for your help, >> >> Toby

Pinder |

Software Developer >> Smith Electric Vehicles >>
-------------------------------------------------------------------
--------------------- >> >> From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>
[mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder >> Sent: 01
November 2013 14:22 >> To: dev@jitsi.org<mailto:dev@jitsi.org> >> Subject: Re: [jitsi-dev]
The state of XMPP Conferencing (and in- call UI restriction) >> >>

My

apologies, I'll have to get back to you on this on Monday Morning - I've
been swamped with other stuff and my logs are only accessible from work.
I may get some opportunity this weekend to do some tinkering with SIP
for comparative purposes to see if that's working, but as I'd be
operating "alone" without US collaborators and on a completely different
stack I'm not sure how representative a test that would be. >> >>

Many

thanks, >> Toby Pinder | Software Developer >> Smith Electric

Vehicles

      >> >> On 31/10/13 21:06, Ingo Bauersachs wrote: >>> I have

been

experiencing issues with XMPP chat and SDES: as soon as a 3+ >>> person
audio call is initiated from scratch it fails, and upgrading a 2 >>>
person call to a 3 person one simply fails for that third person. >>>
      >>> We have had success with this prior when testing without SDES
encryption, >> and >>> the particular stacktrace in the attached log
files makes me think it's an >>> issue with this encryption method. >>
Could you please add/send those logs? >> >>> Is it possible

for SDES

support to work with three person calls? >> Well, at least it should.
The key for each media stream is exchanged between >> the conference
master and the corresponding participant. The participants >> don't
know each other's keys. >> AFAIK it still works for SIP, so there

might

be an issue in passing the keys >> from the XMPP layer down to the
media layer. >> >>> And if not, >>> is there a provisioning

setting I

···

On 05/11/13 22:57, Ingo Bauersachs wrote:

-----Original Message-----
On 05/11/13 00:40, Emil Ivov wrote:
      > > > > On 11/4/2013 11:18 AM, Toby Pinder wrote:
can use to disable this functionality? I >>> would like to disable
various components of the In call UI actually - my >>> business has no
current need for "Hold" nor "Videochat" (especially as we >> are >>>
not using Jitsi Videobridge). Would it be possible to disable the UI >>
buttons >>> for these without disabling eg Screen Sharing / Remote
Desktop? I'm >> generally >>> interested in locking down Jitsi to a
basic featureset before I roll in >> stuff >>> that I think is
"mature" enough and necessary, especially as there is some >>> user
education that has to go on. >>> >>> Many thanks as always. >>>

---

      >>> Toby Pinder >> Ingo >> >> >>
_______________________________________________ >> dev mailing list

dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list options:

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

dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list options:

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

dev@jitsi.org<mailto:dev@jitsi.org> > Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev

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

      _______________________________________________ dev mailing

list

      dev@jitsi.org<mailto:dev@jitsi.org> Unsubscribe instructions and other list options:
      http://lists.jitsi.org/mailman/listinfo/dev

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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part12.00040607.06030504@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


#11

Ingo,

Thanks for this. I'll schedule a test as soon as it's possible to find willing test subjects and report back with the logs.

Toby Pinder | Software Developer
Smith Electric Vehicles

Toby

Thanks for your logs. I just committed a hack that should at least fix the
bug you observed. I currently have no possibility to test SDES with XMPP,
but a conference with SIP and three SDES encrypted participants now worked
fine. Can you give it another try?

Ingo

From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of

Toby

Pinder
Sent: Dienstag, 5. November 2013 11:25
To: dev@jitsi.org<mailto:dev@jitsi.org>
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
restriction)
Oh and I apologise for the message density on this issue but I should

point

out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which

we

haven't had the opportunity to even test yet.

      Hey David,

      There is no such requirement for regular conference calls (the one
      that Jitsi mixes and/or relays). It's not impossible that a bug

would

      prevent one scenario from happening while the other completes
      successfully but generally both work.

      Video bridge conferences do indeed need to be created as such. At
      least currently. We may want to make that automatic in the future.

      Cheers,
      Emil

      On Tue, Nov 5, 2013 at 1:07 AM, David Bolton

<davidkbolton@gmail.com><mailto:davidkbolton@gmail.com>

<mailto:davidkbolton@gmail.com> wrote: > Tony, > > To

switch from a

two-person call to a conference call, I think you > actually have to
start with a conference call to begin with. (In other > words end

the

two-person call and then go to "Tools > Create a > Conference

Call..."

(or "Tools > Create a Video Bridge..."). > > I'm not able to

verify if

this is correct right now, so let me know if > I'm wrong. > >

David

Hi Ingo (and

devs), >> >> Sorry for the delay. We scheduled a test call in

which

myself (person A) called Ross (person B) and then I (person A) attempted
to add David (person C). C was not able to join the call. Log files are
attached. >> >> By the way, those logs show some unrelated issues

to

do with (person B), who is running Jitsi for Windows through Confluence
on a Mac. We believe he had some DNS related issues but they are
unrelated and we have tested this experiment with other users: we
consistently reproduce the same problem. >> >> Potential

stacktrace of

interest (in A.toby.log.0 line 441): >> >> 15:51:46.021 SEVERE: [25]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferencePa
rtic ipantPanel.securityOn(BasicConferenceParticipantPanel.java:487) >>
      at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.s ecurityOn(ConferencePeerPanel.java:523) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.i nitSecuritySettings(ConferencePeerPanel.java:315) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:243) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:188) >> at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.updateViewFromModel(AudioConferenceCallPanel.java:187) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:521) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa
nel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.jav
a:64 0) >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:497) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.initializeComplete(BasicConferenceCallPanel.java:383) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.<init>(AudioConferenceCallPanel.java:132) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromMo
delI nEventDispatchThread(CallPanel.java:1002) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromMode
lInE ventDispatchThread(CallPanel.java:2135) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPan
el.j ava:65) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.ja
va:3 35) >> at java.awt.event.InvocationEvent.dispatch(Unknown
Source) >> at java.awt.EventQueue.dispatchEventImpl(Unknown
Source) >> at java.awt.EventQueue.access$200(Unknown Source)

     at java.awt.EventQueue$3.run(Unknown Source) >> at
java.awt.EventQueue$3.run(Unknown Source) >> at
java.security.AccessController.doPrivileged(Native Method) >> at
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
      >> at java.awt.EventQueue.dispatchEvent(Unknown Source) >>

at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
      >> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
Source) >> at
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) >>
     at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >> at
java.awt.EventDispatchThread.run(Unknown Source) >> >> It

certainly

seems to my uninitiated self that this is an issue during the
negotiation interacting with the crypto, but I don't want to jump to
conclusions. >> >> Thanks for your help, >> >> Toby

Pinder |

Software Developer >> Smith Electric Vehicles >>
-------------------------------------------------------------------
--------------------- >> >> From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>
[mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder >> Sent: 01
November 2013 14:22 >> To: dev@jitsi.org<mailto:dev@jitsi.org> >> Subject: Re: [jitsi-dev]
The state of XMPP Conferencing (and in- call UI restriction) >> >>

My

apologies, I'll have to get back to you on this on Monday Morning - I've
been swamped with other stuff and my logs are only accessible from work.
I may get some opportunity this weekend to do some tinkering with SIP
for comparative purposes to see if that's working, but as I'd be
operating "alone" without US collaborators and on a completely different
stack I'm not sure how representative a test that would be. >> >>

Many

thanks, >> Toby Pinder | Software Developer >> Smith Electric

Vehicles

      >> >> On 31/10/13 21:06, Ingo Bauersachs wrote: >>> I have

been

experiencing issues with XMPP chat and SDES: as soon as a 3+ >>> person
audio call is initiated from scratch it fails, and upgrading a 2 >>>
person call to a 3 person one simply fails for that third person. >>>
      >>> We have had success with this prior when testing without SDES
encryption, >> and >>> the particular stacktrace in the attached log
files makes me think it's an >>> issue with this encryption method. >>
Could you please add/send those logs? >> >>> Is it possible

for SDES

support to work with three person calls? >> Well, at least it should.
The key for each media stream is exchanged between >> the conference
master and the corresponding participant. The participants >> don't
know each other's keys. >> AFAIK it still works for SIP, so there

might

be an issue in passing the keys >> from the XMPP layer down to the
media layer. >> >>> And if not, >>> is there a provisioning

setting I

···

On 05/11/13 22:57, Ingo Bauersachs wrote:

-----Original Message-----
On 05/11/13 00:40, Emil Ivov wrote:
      > > > > On 11/4/2013 11:18 AM, Toby Pinder wrote:
can use to disable this functionality? I >>> would like to disable
various components of the In call UI actually - my >>> business has no
current need for "Hold" nor "Videochat" (especially as we >> are >>>
not using Jitsi Videobridge). Would it be possible to disable the UI >>
buttons >>> for these without disabling eg Screen Sharing / Remote
Desktop? I'm >> generally >>> interested in locking down Jitsi to a
basic featureset before I roll in >> stuff >>> that I think is
"mature" enough and necessary, especially as there is some >>> user
education that has to go on. >>> >>> Many thanks as always. >>>

---

      >>> Toby Pinder >> Ingo >> >> >>
_______________________________________________ >> dev mailing list

dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list options:

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

dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list options:

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

dev@jitsi.org<mailto:dev@jitsi.org> > Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev

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

      _______________________________________________ dev mailing

list

      dev@jitsi.org<mailto:dev@jitsi.org> Unsubscribe instructions and other list options:
      http://lists.jitsi.org/mailman/listinfo/dev

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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part12.03040802.07080601@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


#12

Ingo,

Thanks a lot for this! Sorry for the delays in getting back to you (I had to find willing test subjects) but we've tried this today and it was successful.

The version of Jitsi we used is equivalent to
https://github.com/jitsi/jitsi/commit/be3bcff1ec1d0df18fae184761e25d3454e40e9f.
It's referred to in the logs as "Smith Chat" but the changes are minor and focused on cosmetics and changes like emoticons and default configuration.

In our test Person A called Person B and then we added Person C to upgrade to a conference. This worked without problems, and we added Person D to make it a four person call just to make sure without any issues too. However, the padlock indicator for secure communication was inconsistent between users, and appears to show that Person B is not secure.

I have attached the log file from the host (user A). Unfortunately I failed to get the correct logs from the other users on this one (I think they all restarted Jitsi, rendering the "log.0" file useless to us and by the time I noticed it was too late).

I have also attached two screenshots. A.png shows the state of the security padlocks as observed by user A, and B.png shows the state of the security padlocks as observed by users B, C and D. I believe this issue is cosmetic rather than insecurity, but please let me know if there is anything you'd like me to test with Wireshark etc. to confirm this. It makes sense that the UI might not have properly responded to the call "upgrade" scenario but I'd be happy to verify this given instructions.

Thanks once again,
Toby Pinder | Software Developer
Smith Electric Vehicles

Toby

Thanks for your logs. I just committed a hack that should at least fix the
bug you observed. I currently have no possibility to test SDES with XMPP,
but a conference with SIP and three SDES encrypted participants now worked
fine. Can you give it another try?

Ingo

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Toby

Pinder
Sent: Dienstag, 5. November 2013 11:25
To: dev@jitsi.org
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
restriction)
Oh and I apologise for the message density on this issue but I should

point

out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which

we

haven't had the opportunity to even test yet.

  Hey David,

  There is no such requirement for regular conference calls \(the one
  that Jitsi mixes and/or relays\)\. It&#39;s not impossible that a bug

would

  prevent one scenario from happening while the other completes
  successfully but generally both work\.

  Video bridge conferences do indeed need to be created as such\. At
  least currently\. We may want to make that automatic in the future\.

  Cheers,
  Emil

<mailto:davidkbolton@gmail.com> wrote: > Tony, > > To

switch from a

two-person call to a conference call, I think you > actually have to
start with a conference call to begin with. (In other > words end

the

two-person call and then go to "Tools > Create a > Conference

Call..."

(or "Tools > Create a Video Bridge..."). > > I'm not able to

verify if

this is correct right now, so let me know if > I'm wrong. > >

David

Hi Ingo (and

devs), >> >> Sorry for the delay. We scheduled a test call in

which

myself (person A) called Ross (person B) and then I (person A) attempted
to add David (person C). C was not able to join the call. Log files are
attached. >> >> By the way, those logs show some unrelated issues

to

do with (person B), who is running Jitsi for Windows through Confluence
on a Mac. We believe he had some DNS related issues but they are
unrelated and we have tested this experiment with other users: we
consistently reproduce the same problem. >> >> Potential

stacktrace of

interest (in A.toby.log.0 line 441): >> >> 15:51:46.021 SEVERE: [25]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferencePa
rtic ipantPanel.securityOn(BasicConferenceParticipantPanel.java:487) >>
at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.s ecurityOn(ConferencePeerPanel.java:523) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.i nitSecuritySettings(ConferencePeerPanel.java:315) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:243) >> at
net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan
el.< init>(ConferencePeerPanel.java:188) >> at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.updateViewFromModel(AudioConferenceCallPanel.java:187) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:521) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa
nel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.jav
a:64 0) >> at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:497) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa
llPa nel.initializeComplete(BasicConferenceCallPanel.java:383) >>

at
net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa
llPa nel.<init>(AudioConferenceCallPanel.java:132) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromMo
delI nEventDispatchThread(CallPanel.java:1002) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromMode
lInE ventDispatchThread(CallPanel.java:2135) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPan
el.j ava:65) >> at
net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.ja
va:3 35) >> at java.awt.event.InvocationEvent.dispatch(Unknown
Source) >> at java.awt.EventQueue.dispatchEventImpl(Unknown
Source) >> at java.awt.EventQueue.access$200(Unknown Source)

  at java\.awt\.EventQueue$3\.run\(Unknown Source\)     &gt;&gt;       at

java.awt.EventQueue$3.run(Unknown Source) >> at
java.security.AccessController.doPrivileged(Native Method) >> at
java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
>> at java.awt.EventQueue.dispatchEvent(Unknown Source) >>

at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
>> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
Source) >> at
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) >>
at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >> at
java.awt.EventDispatchThread.run(Unknown Source) >> >> It

certainly

seems to my uninitiated self that this is an issue during the
negotiation interacting with the crypto, but I don't want to jump to
conclusions. >> >> Thanks for your help, >> >> Toby

Pinder |

Software Developer >> Smith Electric Vehicles >>
-------------------------------------------------------------------
--------------------- >> >> From: dev-bounces@jitsi.org
[mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder >> Sent: 01
November 2013 14:22 >> To: dev@jitsi.org >> Subject: Re: [jitsi-dev]
The state of XMPP Conferencing (and in- call UI restriction) >> >>

My

apologies, I'll have to get back to you on this on Monday Morning - I've
been swamped with other stuff and my logs are only accessible from work.
I may get some opportunity this weekend to do some tinkering with SIP
for comparative purposes to see if that's working, but as I'd be
operating "alone" without US collaborators and on a completely different
stack I'm not sure how representative a test that would be. >> >>

Many

thanks, >> Toby Pinder | Software Developer >> Smith Electric

Vehicles

  &gt;&gt;      &gt;&gt; On 31/10/13 21:06, Ingo Bauersachs wrote:    &gt;&gt;&gt; I have

been

experiencing issues with XMPP chat and SDES: as soon as a 3+ >>> person
audio call is initiated from scratch it fails, and upgrading a 2 >>>
person call to a 3 person one simply fails for that third person. >>>
>>> We have had success with this prior when testing without SDES
encryption, >> and >>> the particular stacktrace in the attached log
files makes me think it's an >>> issue with this encryption method. >>
Could you please add/send those logs? >> >>> Is it possible

for SDES

support to work with three person calls? >> Well, at least it should.
The key for each media stream is exchanged between >> the conference
master and the corresponding participant. The participants >> don't
know each other's keys. >> AFAIK it still works for SIP, so there

might

be an issue in passing the keys >> from the XMPP layer down to the
media layer. >> >>> And if not, >>> is there a provisioning

setting I

a.toby.log.0 (193 KB)

···

On 05/11/13 22:57, Ingo Bauersachs wrote:

-----Original Message-----
On 05/11/13 00:40, Emil Ivov wrote:
On Tue, Nov 5, 2013 at 1:07 AM, David Bolton <davidkbolton@gmail.com>
> > > > On 11/4/2013 11:18 AM, Toby Pinder wrote:
can use to disable this functionality? I >>> would like to disable
various components of the In call UI actually - my >>> business has no
current need for "Hold" nor "Videochat" (especially as we >> are >>>
not using Jitsi Videobridge). Would it be possible to disable the UI >>
buttons >>> for these without disabling eg Screen Sharing / Remote
Desktop? I'm >> generally >>> interested in locking down Jitsi to a
basic featureset before I roll in >> stuff >>> that I think is
"mature" enough and necessary, especially as there is some >>> user
education that has to go on. >>> >>> Many thanks as always. >>>

---

  &gt;&gt;&gt; Toby Pinder         &gt;&gt; Ingo         &gt;&gt;      &gt;&gt;      &gt;&gt;

_______________________________________________ >> 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 > > >
_______________________________________________ > dev mailing list

dev@jitsi.org > Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev

  \-\-
  Emil Ivov, Ph\.D\.                       67000 Strasbourg,
  Project Lead                           France
  Jitsi
  emcho@jitsi\.org                        PHONE: \+33\.1\.77\.62\.43\.30
  https://jitsi.org                       FAX:   \+33\.1\.77\.62\.47\.31

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_         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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com
W. www.smithelectric.com

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


#13

Thanks Toby!

I committed a small fix that should fix the UI glitch you were seeing for
the conference initiator (A).

As for the security status of the participants: they intentionally don't see
a security indication for the other participants because they cannot know if
they are encrypted or not.

   A
/ | \
B C D

1) A sees all connection as secure
2) B, C, D see the connection to A as secure
3) B doesn't know if the connection of C and D to A is secure, hence there's
no indication
4) C (same but for B and D)
5) D (same but for B and C)

We used to propagate the status in cases 3-5 from case 2 down in earlier
versions, but this is wrong. While we hear all of the participants through
the encrypted channel to A, one of the participants could be connected to A
unencrypted. A could distribute its knowledge about the encryption status,
but this would again not be secure (B,C,D cannot prove whether A is telling
the truth).

So, once the build with the commit 60e4be3 is through, you should be good to
go.

Ingo

From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of

Toby

Pinder
Sent: Donnerstag, 7. November 2013 17:53
To: dev@jitsi.org
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
restriction)

Ingo,

Thanks a lot for this! Sorry for the delays in getting back to you (I had

to

find willing test subjects) but we've tried this today and it was

successful.

The version of Jitsi we used is equivalent to

https://github.com/jitsi/jitsi/commit/be3bcff1ec1d0df18fae184761e25d3454e40e
9

f.
It's referred to in the logs as "Smith Chat" but the changes are minor and
focused on cosmetics and changes like emoticons and default configuration.

In our test Person A called Person B and then we added Person C to upgrade

to

a conference. This worked without problems, and we added Person D to make

it

a four person call just to make sure without any issues too. However, the
padlock indicator for secure communication was inconsistent between users,
and appears to show that Person B is not secure.

I have attached the log file from the host (user A). Unfortunately I

failed

to get the correct logs from the other users on this one (I think they all
restarted Jitsi, rendering the "log.0" file useless to us and by the time

I

noticed it was too late).

I have also attached two screenshots. A.png shows the state of the

security

padlocks as observed by user A, and B.png shows the state of the security
padlocks as observed by users B, C and D. I believe this issue is cosmetic
rather than insecurity, but please let me know if there is anything you'd
like me to test with Wireshark etc. to confirm this. It makes sense that

the

UI might not have properly responded to the call "upgrade" scenario but

I'd

be happy to verify this given instructions.

Thanks once again,
Toby Pinder | Software Developer
Smith Electric Vehicles

Toby

Thanks for your logs. I just committed a hack that should at least fix the
bug you observed. I currently have no possibility to test SDES with XMPP,
but a conference with SIP and three SDES encrypted participants now worked
fine. Can you give it another try?

Ingo

> From: dev-bounces@jitsi.org [mailto:dev-bounces@jitsi.org] On Behalf Of
Toby
> Pinder
> Sent: Dienstag, 5. November 2013 11:25
> To: dev@jitsi.org
> Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
> restriction)
> Oh and I apologise for the message density on this issue but I should
point
> out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which
we
> haven't had the opportunity to even test yet.
>
>
>
> Hey David,
>
> There is no such requirement for regular conference calls (the one
> that Jitsi mixes and/or relays). It's not impossible that a bug
would
> prevent one scenario from happening while the other completes
> successfully but generally both work.
>
> Video bridge conferences do indeed need to be created as such. At
> least currently. We may want to make that automatic in the future.
>
> Cheers,
> Emil
>
> On Tue, Nov 5, 2013 at 1:07 AM, David Bolton
<davidkbolton@gmail.com>
> <mailto:davidkbolton@gmail.com> wrote: > Tony, > >

To

switch from a
> two-person call to a conference call, I think you > actually have to
> start with a conference call to begin with. (In other > words

end

the
> two-person call and then go to "Tools > Create a > Conference
Call..."
> (or "Tools > Create a Video Bridge..."). > > I'm not able to
verify if
> this is correct right now, so let me know if > I'm wrong. > >
David
>> Hi Ingo (and
> devs), >> >> Sorry for the delay. We scheduled a test call

in

which
> myself (person A) called Ross (person B) and then I (person A) attempted
> to add David (person C). C was not able to join the call. Log files are
> attached. >> >> By the way, those logs show some unrelated

issues

to
> do with (person B), who is running Jitsi for Windows through Confluence
> on a Mac. We believe he had some DNS related issues but they are
> unrelated and we have tested this experiment with other users: we
> consistently reproduce the same problem. >> >> Potential
stacktrace of
> interest (in A.toby.log.0 line 441): >> >> 15:51:46.021 SEVERE:

[25]

> util.UtilActivator.uncaughtException().108 An uncaught exception
> occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
> java.lang.NullPointerException >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferencePa

> rtic ipantPanel.securityOn(BasicConferenceParticipantPanel.java:487) >>
> at
>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.s ecurityOn(ConferencePeerPanel.java:523) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.i nitSecuritySettings(ConferencePeerPanel.java:315) >>

at

>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.< init>(ConferencePeerPanel.java:243) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.< init>(ConferencePeerPanel.java:188) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa

> llPa nel.updateViewFromModel(AudioConferenceCallPanel.java:187) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:521) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa
>

nel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.jav

> a:64 0) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:497) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa nel.initializeComplete(BasicConferenceCallPanel.java:383) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa

> llPa nel.<init>(AudioConferenceCallPanel.java:132) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromMo

> delI nEventDispatchThread(CallPanel.java:1002) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromMode

> lInE ventDispatchThread(CallPanel.java:2135) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPan

> el.j ava:65) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.ja

> va:3 35) >> at

java.awt.event.InvocationEvent.dispatch(Unknown

> Source) >> at java.awt.EventQueue.dispatchEventImpl(Unknown
> Source) >> at java.awt.EventQueue.access$200(Unknown Source)
>>
> at java.awt.EventQueue$3.run(Unknown Source) >> at
> java.awt.EventQueue$3.run(Unknown Source) >> at
> java.security.AccessController.doPrivileged(Native Method) >>

at

> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
> >> at java.awt.EventQueue.dispatchEvent(Unknown Source) >>

> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> >> at

java.awt.EventDispatchThread.pumpEventsForFilter(Unknown

> Source) >> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) >>
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

at

> java.awt.EventDispatchThread.run(Unknown Source) >> >> It
certainly
> seems to my uninitiated self that this is an issue during the
> negotiation interacting with the crypto, but I don't want to jump to
> conclusions. >> >> Thanks for your help, >> >> Toby
Pinder |
> Software Developer >> Smith Electric Vehicles >>
> -------------------------------------------------------------------
> --------------------- >> >> From: dev-bounces@jitsi.org
> [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder >> Sent:

01

> November 2013 14:22 >> To: dev@jitsi.org >> Subject: Re:

[jitsi-dev]

> The state of XMPP Conferencing (and in- call UI restriction) >> >>
My
> apologies, I'll have to get back to you on this on Monday Morning - I've
> been swamped with other stuff and my logs are only accessible from work.
> I may get some opportunity this weekend to do some tinkering with SIP
> for comparative purposes to see if that's working, but as I'd be
> operating "alone" without US collaborators and on a completely different
> stack I'm not sure how representative a test that would be. >> >>
Many
> thanks, >> Toby Pinder | Software Developer >> Smith Electric
Vehicles
> >> >> On 31/10/13 21:06, Ingo Bauersachs wrote: >>> I have
been
> experiencing issues with XMPP chat and SDES: as soon as a 3+ >>> person
> audio call is initiated from scratch it fails, and upgrading a 2

> person call to a 3 person one simply fails for that third person.

> >>> We have had success with this prior when testing without SDES
> encryption, >> and >>> the particular stacktrace in the attached log
> files makes me think it's an >>> issue with this encryption method. >>
> Could you please add/send those logs? >> >>> Is it possible
for SDES
> support to work with three person calls? >> Well, at least it

should.

> The key for each media stream is exchanged between >> the conference
> master and the corresponding participant. The participants >> don't
> know each other's keys. >> AFAIK it still works for SIP, so there
might
> be an issue in passing the keys >> from the XMPP layer down to the
> media layer. >> >>> And if not, >>> is there a

provisioning

setting I
> can use to disable this functionality? I >>> would like to disable
> various components of the In call UI actually - my >>> business has

no

> current need for "Hold" nor "Videochat" (especially as we >> are

> not using Jitsi Videobridge). Would it be possible to disable the UI >>
> buttons >>> for these without disabling eg Screen Sharing / Remote
> Desktop? I'm >> generally >>> interested in locking down Jitsi to a
> basic featureset before I roll in >> stuff >>> that I think

is

> "mature" enough and necessary, especially as there is some >>> user
> education that has to go on. >>> >>> Many thanks as always.

---
> >>> Toby Pinder >> Ingo >> >> >>
> _______________________________________________ >> 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 > > >
> _______________________________________________ > dev mailing list
>
> dev@jitsi.org > Unsubscribe instructions and other list options:
>
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> Jitsi
> emcho@jitsi.org PHONE: +33.1.77.62.43.30
> https://jitsi.org FAX: +33.1.77.62.47.31
>
> _______________________________________________ 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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com
W. www.smithelectric.com

This email and any attachments thereto may contain private, confidential,

and

privileged material for the sole use of the intended recipient. Any

review,

copying, or distribution of this email (or any attachments thereto) by

others

is strictly prohibited. If you are not the intended recipient, please

contact

the sender immediately and permanently delete the original and any copies

of

···

-----Original Message-----
On 05/11/13 22:57, Ingo Bauersachs wrote:
> -----Original Message-----
> On 05/11/13 00:40, Emil Ivov wrote:
> > > > > On 11/4/2013 11:18 AM, Toby Pinder wrote:
this email and any attachments thereto.


#14

Excellent: I'll see if I can confirm the fixes for you some time next week.

The security indicator being absent makes sense: it's only "off" that's potentially concerning anyway.

Thanks again,
Toby Pinder | Software Developer
Smith Electric Vehicles

Thanks Toby!

I committed a small fix that should fix the UI glitch you were seeing for
the conference initiator (A).

As for the security status of the participants: they intentionally don't see
a security indication for the other participants because they cannot know if
they are encrypted or not.

   A
/ | \
B C D

1) A sees all connection as secure
2) B, C, D see the connection to A as secure
3) B doesn't know if the connection of C and D to A is secure, hence there's
no indication
4) C (same but for B and D)
5) D (same but for B and C)

We used to propagate the status in cases 3-5 from case 2 down in earlier
versions, but this is wrong. While we hear all of the participants through
the encrypted channel to A, one of the participants could be connected to A
unencrypted. A could distribute its knowledge about the encryption status,
but this would again not be secure (B,C,D cannot prove whether A is telling
the truth).

So, once the build with the commit 60e4be3 is through, you should be good to
go.

Ingo

From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of

Toby

Pinder
Sent: Donnerstag, 7. November 2013 17:53
To: dev@jitsi.org<mailto:dev@jitsi.org>
Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
restriction)

Ingo,

Thanks a lot for this! Sorry for the delays in getting back to you (I had

to

find willing test subjects) but we've tried this today and it was

successful.

The version of Jitsi we used is equivalent to

https://github.com/jitsi/jitsi/commit/be3bcff1ec1d0df18fae184761e25d3454e40e
9

f.
It's referred to in the logs as "Smith Chat" but the changes are minor and
focused on cosmetics and changes like emoticons and default configuration.

In our test Person A called Person B and then we added Person C to upgrade

to

a conference. This worked without problems, and we added Person D to make

it

a four person call just to make sure without any issues too. However, the
padlock indicator for secure communication was inconsistent between users,
and appears to show that Person B is not secure.

I have attached the log file from the host (user A). Unfortunately I

failed

to get the correct logs from the other users on this one (I think they all
restarted Jitsi, rendering the "log.0" file useless to us and by the time

I

noticed it was too late).

I have also attached two screenshots. A.png shows the state of the

security

padlocks as observed by user A, and B.png shows the state of the security
padlocks as observed by users B, C and D. I believe this issue is cosmetic
rather than insecurity, but please let me know if there is anything you'd
like me to test with Wireshark etc. to confirm this. It makes sense that

the

UI might not have properly responded to the call "upgrade" scenario but

I'd

be happy to verify this given instructions.

Thanks once again,
Toby Pinder | Software Developer
Smith Electric Vehicles

Toby

Thanks for your logs. I just committed a hack that should at least fix the
bug you observed. I currently have no possibility to test SDES with XMPP,
but a conference with SIP and three SDES encrypted participants now worked
fine. Can you give it another try?

Ingo

> From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org> [mailto:dev-bounces@jitsi.org] On Behalf Of
Toby
> Pinder
> Sent: Dienstag, 5. November 2013 11:25
> To: dev@jitsi.org<mailto:dev@jitsi.org>
> Subject: Re: [jitsi-dev] The state of XMPP Conferencing (and in-call UI
> restriction)
> Oh and I apologise for the message density on this issue but I should
point
> out that my XMPP/SDES issue is wholly unrelated to Video Bridging, which
we
> haven't had the opportunity to even test yet.
>
>
>
> Hey David,
>
> There is no such requirement for regular conference calls (the one
> that Jitsi mixes and/or relays). It's not impossible that a bug
would
> prevent one scenario from happening while the other completes
> successfully but generally both work.
>
> Video bridge conferences do indeed need to be created as such. At
> least currently. We may want to make that automatic in the future.
>
> Cheers,
> Emil
>
> On Tue, Nov 5, 2013 at 1:07 AM, David Bolton
<davidkbolton@gmail.com><mailto:davidkbolton@gmail.com>
> <mailto:davidkbolton@gmail.com> wrote: > Tony, > >

To

switch from a
> two-person call to a conference call, I think you > actually have to
> start with a conference call to begin with. (In other > words

end

the
> two-person call and then go to "Tools > Create a > Conference
Call..."
> (or "Tools > Create a Video Bridge..."). > > I'm not able to
verify if
> this is correct right now, so let me know if > I'm wrong. > >
David
>> Hi Ingo (and
> devs), >> >> Sorry for the delay. We scheduled a test call

in

which
> myself (person A) called Ross (person B) and then I (person A) attempted
> to add David (person C). C was not able to join the call. Log files are
> attached. >> >> By the way, those logs show some unrelated

issues

to
> do with (person B), who is running Jitsi for Windows through Confluence
> on a Mac. We believe he had some DNS related issues but they are
> unrelated and we have tested this experiment with other users: we
> consistently reproduce the same problem. >> >> Potential
stacktrace of
> interest (in A.toby.log.0 line 441): >> >> 15:51:46.021 SEVERE:

[25]

> util.UtilActivator.uncaughtException().108 An uncaught exception
> occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
> java.lang.NullPointerException >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferencePa

> rtic ipantPanel.securityOn(BasicConferenceParticipantPanel.java:487) >>
> at
>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.s ecurityOn(ConferencePeerPanel.java:523) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.i nitSecuritySettings(ConferencePeerPanel.java:315) >>

at

>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.< init>(ConferencePeerPanel.java:243) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.ConferencePeerPan

> el.< init>(ConferencePeerPanel.java:188) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa

> llPa nel.updateViewFromModel(AudioConferenceCallPanel.java:187) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:521) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa
>

nel.updateViewFromModelInEventDispatchThread(BasicConferenceCallPanel.jav

> a:64 0) >> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa nel.updateViewFromModel(BasicConferenceCallPanel.java:497) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.BasicConferenceCa

> llPa nel.initializeComplete(BasicConferenceCallPanel.java:383) >>

> at
>

net.java.sip.communicator.impl.gui.main.call.conference.AudioConferenceCa

> llPa nel.<init>(AudioConferenceCallPanel.java:132) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel.doUpdateViewFromMo

> delI nEventDispatchThread(CallPanel.java:1002) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel.updateViewFromMode

> lInE ventDispatchThread(CallPanel.java:2135) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel.access$300(CallPan

> el.j ava:65) >> at
>

net.java.sip.communicator.impl.gui.main.call.CallPanel$2.run(CallPanel.ja

> va:3 35) >> at

java.awt.event.InvocationEvent.dispatch(Unknown

> Source) >> at java.awt.EventQueue.dispatchEventImpl(Unknown
> Source) >> at java.awt.EventQueue.access$200(Unknown Source)
>>
> at java.awt.EventQueue$3.run(Unknown Source) >> at
> java.awt.EventQueue$3.run(Unknown Source) >> at
> java.security.AccessController.doPrivileged(Native Method) >>

at

> java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
> >> at java.awt.EventQueue.dispatchEvent(Unknown Source) >>

> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> >> at

java.awt.EventDispatchThread.pumpEventsForFilter(Unknown

> Source) >> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) >>
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) >>

at

> java.awt.EventDispatchThread.run(Unknown Source) >> >> It
certainly
> seems to my uninitiated self that this is an issue during the
> negotiation interacting with the crypto, but I don't want to jump to
> conclusions. >> >> Thanks for your help, >> >> Toby
Pinder |
> Software Developer >> Smith Electric Vehicles >>
> -------------------------------------------------------------------
> --------------------- >> >> From: dev-bounces@jitsi.org<mailto:dev-bounces@jitsi.org>
> [mailto:dev-bounces@jitsi.org] On Behalf Of Toby Pinder >> Sent:

01

> November 2013 14:22 >> To: dev@jitsi.org<mailto:dev@jitsi.org> >> Subject: Re:

[jitsi-dev]

> The state of XMPP Conferencing (and in- call UI restriction) >> >>
My
> apologies, I'll have to get back to you on this on Monday Morning - I've
> been swamped with other stuff and my logs are only accessible from work.
> I may get some opportunity this weekend to do some tinkering with SIP
> for comparative purposes to see if that's working, but as I'd be
> operating "alone" without US collaborators and on a completely different
> stack I'm not sure how representative a test that would be. >> >>
Many
> thanks, >> Toby Pinder | Software Developer >> Smith Electric
Vehicles
> >> >> On 31/10/13 21:06, Ingo Bauersachs wrote: >>> I have
been
> experiencing issues with XMPP chat and SDES: as soon as a 3+ >>> person
> audio call is initiated from scratch it fails, and upgrading a 2

> person call to a 3 person one simply fails for that third person.

> >>> We have had success with this prior when testing without SDES
> encryption, >> and >>> the particular stacktrace in the attached log
> files makes me think it's an >>> issue with this encryption method. >>
> Could you please add/send those logs? >> >>> Is it possible
for SDES
> support to work with three person calls? >> Well, at least it

should.

> The key for each media stream is exchanged between >> the conference
> master and the corresponding participant. The participants >> don't
> know each other's keys. >> AFAIK it still works for SIP, so there
might
> be an issue in passing the keys >> from the XMPP layer down to the
> media layer. >> >>> And if not, >>> is there a

provisioning

setting I
> can use to disable this functionality? I >>> would like to disable
> various components of the In call UI actually - my >>> business has

no

> current need for "Hold" nor "Videochat" (especially as we >> are

> not using Jitsi Videobridge). Would it be possible to disable the UI >>
> buttons >>> for these without disabling eg Screen Sharing / Remote
> Desktop? I'm >> generally >>> interested in locking down Jitsi to a
> basic featureset before I roll in >> stuff >>> that I think

is

> "mature" enough and necessary, especially as there is some >>> user
> education that has to go on. >>> >>> Many thanks as always.

---
> >>> Toby Pinder >> Ingo >> >> >>
> _______________________________________________ >> dev mailing

list

>>
> dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list

options:

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

list

>>
> dev@jitsi.org<mailto:dev@jitsi.org> >> Unsubscribe instructions and other list

options:

>>
> http://lists.jitsi.org/mailman/listinfo/dev > > >
> _______________________________________________ > dev mailing list
>
> dev@jitsi.org<mailto:dev@jitsi.org> > Unsubscribe instructions and other list options:
>
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> Jitsi
> emcho@jitsi.org<mailto:emcho@jitsi.org> PHONE: +33.1.77.62.43.30
> https://jitsi.org FAX: +33.1.77.62.47.31
>
> _______________________________________________ dev

mailing

list
> dev@jitsi.org<mailto:dev@jitsi.org> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>

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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com<mailto:toby.pinder@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com>

This email and any attachments thereto may contain private, confidential,

and

privileged material for the sole use of the intended recipient. Any

review,

copying, or distribution of this email (or any attachments thereto) by

others

is strictly prohibited. If you are not the intended recipient, please

contact

the sender immediately and permanently delete the original and any copies

of

···

On 07/11/13 22:45, Ingo Bauersachs wrote:

-----Original Message-----
On 05/11/13 22:57, Ingo Bauersachs wrote:
> -----Original Message-----
> On 05/11/13 00:40, Emil Ivov wrote:
> > > > > On 11/4/2013 11:18 AM, Toby Pinder wrote:
this email and any attachments thereto.

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

--
Toby Pinder | Telemetry Software Engineer

Switchboard +44 (0)845 077 9077

E. toby.pinder@smithelectric.com<mailto:ross.cooney@smithelectric.com>
W. www.smithelectric.com<http://www.smithelectric.com/>

[cid:part15.01000206.06080400@smithelectric.com]

This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.