[sip-comm-dev] Separation of ZRTP GUI and ZRTP callback and state


#1

All,

as proposed in one of my last e-mails I've changed the way how the
ZRTP GUI is implemented. Quite some modifications were necessary. It's
ready in my sandbox here. Before I commit I thought it is a good idea
to give you some information in advance. Everybody is invited to test
the modifications.

All modifications were tested and work with Phil Zimmermann's original
Zfone, this includes SAS verification.

As proposed by Emanuel we can extend the implementation to support or
use other key sharing / key negotiation mechanisms (if this will ever
happen :slight_smile: ). Currently only ZRTP is implemented.

We now have a separate ZRTP panel that handles the display of events
and necessary data and also handles user action to set SAS
verification state. Also this action is separated from the ZRTP
implementation.

The ZRTP panel is _very_ _simple_ and I kindly ask our GUI gurus to
have a look and propose a much better look-and-feel. I'm not a good
GUI designer at all :slight_smile: .

Attached to this mail is a more detailed list of modifications I've
done to make this happen.

Due to various reasons ZRTP is enabled by default for all SIP calls
(more detailed explanation see attachment). This doe not do any harm
to clients that do not support ZRTP - they just ignore it and the user
does not notice any problems. Emanuel provided a patch about 6 weeks
ago to enable/disable ZRTP on a per account basis. After these
modifications are done we can have a look at that patch and how to
integrate it.

Video is not yet supported, it's somehow prepared but needs some
additional modifications and enhancements in ZRTP handling inside
SipSessionImpl and the ZRTP SCCallback class. The GUI
and other mechanisms are already well prepared to handle video.

Regarding video support: The ZRTP specification requires one "Master"
session that must negotiate the keys before additional sessions, for
example Video, can be attached. IMHO we should define the "Audio"
session as the "Master" for this case. Is this ok?

Also because of the key negotiation and the SRTP crypto context only
1-1 calls are possible if security is enabled (one call can have
several media streams but only to the same client), that is only one
participant per call (no secure 1-n calls).

Best regards,
Werner

zrtpGuiChanges.txt (2.12 KB)


#2

Hey Werner,

Thanks for taking care of this. I've had it on my todo list for a while
so your commit is quite a relief. Will have a look at you changes this week.

Concerning video. Is there anything missing in zrtp4j to handle it or is
it only the media glue in SC that would be connecting the GUI and zrtp4j?

Cheers
Emil

Werner Dittmann wrote:

···

All,

as proposed in one of my last e-mails I've changed the way how the
ZRTP GUI is implemented. Quite some modifications were necessary. It's
ready in my sandbox here. Before I commit I thought it is a good idea
to give you some information in advance. Everybody is invited to test
the modifications.

All modifications were tested and work with Phil Zimmermann's original
Zfone, this includes SAS verification.

As proposed by Emanuel we can extend the implementation to support or
use other key sharing / key negotiation mechanisms (if this will ever
happen :slight_smile: ). Currently only ZRTP is implemented.

We now have a separate ZRTP panel that handles the display of events
and necessary data and also handles user action to set SAS
verification state. Also this action is separated from the ZRTP
implementation.

The ZRTP panel is _very_ _simple_ and I kindly ask our GUI gurus to
have a look and propose a much better look-and-feel. I'm not a good
GUI designer at all :slight_smile: .

Attached to this mail is a more detailed list of modifications I've
done to make this happen.

Due to various reasons ZRTP is enabled by default for all SIP calls
(more detailed explanation see attachment). This doe not do any harm
to clients that do not support ZRTP - they just ignore it and the user
does not notice any problems. Emanuel provided a patch about 6 weeks
ago to enable/disable ZRTP on a per account basis. After these
modifications are done we can have a look at that patch and how to
integrate it.

Video is not yet supported, it's somehow prepared but needs some
additional modifications and enhancements in ZRTP handling inside
SipSessionImpl and the ZRTP SCCallback class. The GUI
and other mechanisms are already well prepared to handle video.

Regarding video support: The ZRTP specification requires one "Master"
session that must negotiate the keys before additional sessions, for
example Video, can be attached. IMHO we should define the "Audio"
session as the "Master" for this case. Is this ok?

Also because of the key negotiation and the SRTP crypto context only
1-1 calls are possible if security is enabled (one call can have
several media streams but only to the same client), that is only one
participant per call (no secure 1-n calls).

Best regards,
Werner

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello,

First of all, I'm very sorry for the quite long silence period :). I'm very caught with lots of academic asignments at my faculty for this semester and consequently pretty much lack the free time.

However, I managed to find a few hours today to take a look at the new commited GUI changes. I can't see any problem at this moment and I think the way the proposed solution updates the GUI elements state, is probably the best or at least a much better way it was before because indeed it keeps the GUI elements separate from the media layer/package.

About the enable/disable security per account basis patch I provided some time ago, I've attached an updated (more like refactored..) version of it to this mail. This is not really fully functional though. It works in the current form in the next way:

- if the account has the "Enable default call encryption" checkbox checked in the account registration wizard all the calls will go on secured, using the new ZRTP panel (of course if the other endpoint supports it).

- if the account hasn't the above option checked the calls will go on of course unsecured, not using the ZRTP panel; the problem is here (or better said, I've stopped with the patch updating at this point.. ) - the user can't switch to secure mode at this moment during a call if the option is set off by default; if this isn't needed all is ok - the "default call encryption" option will be more like a "permanent call encryption" setting in this case; if the user should be allowed to switch to secure mode during a call even if he/she set "default securing off", then the current patch should be modified

Unfortunately I pretty much lack the free time at this moment :frowning: (actually until February when the semester and some of my academic tasks end..), so like I said I've attached the patch in it's current form which probably should be further developed especially in case of the above stated problem ( also please note that I didn't have the time to test it thoroughly; it's pretty much a refactoring of the old patch, like I said, with some modifications done, especially to ease the integration when needed - the fact that it actually worked from the first run in the current form was a bit of a surprise even for me :slight_smile: ). The patch attached is done against revision 4772 (Werner's commit).

Regards,
Emanuel

securityenableaccounts.patch (10 KB)

···

On Sun, 30 Nov 2008, Werner Dittmann wrote:

All,

as proposed in one of my last e-mails I've changed the way how the
ZRTP GUI is implemented. Quite some modifications were necessary. It's
ready in my sandbox here. Before I commit I thought it is a good idea
to give you some information in advance. Everybody is invited to test
the modifications.

All modifications were tested and work with Phil Zimmermann's original
Zfone, this includes SAS verification.

As proposed by Emanuel we can extend the implementation to support or
use other key sharing / key negotiation mechanisms (if this will ever
happen :slight_smile: ). Currently only ZRTP is implemented.

We now have a separate ZRTP panel that handles the display of events
and necessary data and also handles user action to set SAS
verification state. Also this action is separated from the ZRTP
implementation.

The ZRTP panel is _very_ _simple_ and I kindly ask our GUI gurus to
have a look and propose a much better look-and-feel. I'm not a good
GUI designer at all :slight_smile: .

Attached to this mail is a more detailed list of modifications I've
done to make this happen.

Due to various reasons ZRTP is enabled by default for all SIP calls
(more detailed explanation see attachment). This doe not do any harm
to clients that do not support ZRTP - they just ignore it and the user
does not notice any problems. Emanuel provided a patch about 6 weeks
ago to enable/disable ZRTP on a per account basis. After these
modifications are done we can have a look at that patch and how to
integrate it.

Video is not yet supported, it's somehow prepared but needs some
additional modifications and enhancements in ZRTP handling inside
SipSessionImpl and the ZRTP SCCallback class. The GUI
and other mechanisms are already well prepared to handle video.

Regarding video support: The ZRTP specification requires one "Master"
session that must negotiate the keys before additional sessions, for
example Video, can be attached. IMHO we should define the "Audio"
session as the "Master" for this case. Is this ok?

Also because of the key negotiation and the SRTP crypto context only
1-1 calls are possible if security is enabled (one call can have
several media streams but only to the same client), that is only one
participant per call (no secure 1-n calls).

Best regards,
Werner


#4

Emil,

Emil Ivov schrieb:

Hey Werner,

Thanks for taking care of this. I've had it on my todo list for a while
so your commit is quite a relief. Will have a look at you changes this week.

Welcome. Maybe Yana can have a look at the ZrtpPanel and its design and
brush it up. She has done a marvelous job with the new design and icons.

Concerning video. Is there anything missing in zrtp4j to handle it or is
it only the media glue in SC that would be connecting the GUI and zrtp4j?

ZRTP4J supports multi-stream mode already. It's the glue between ZRTP4J
and SC and the order how to set-up the streams. Here we need to follow the
requirements of ZRTP regarding multi-streaming. This was one reason to
separate the GUI handling from SCCallback - it's now a bit simpler to
implement the multi-stream mode. If all goes well I can bring in the
modifications during the next week. However I cannot test it - no video
equipment available on my computer.

Regards,
Werner

···

Cheers
Emil

Werner Dittmann wrote:

All,

as proposed in one of my last e-mails I've changed the way how the
ZRTP GUI is implemented. Quite some modifications were necessary. It's
ready in my sandbox here. Before I commit I thought it is a good idea
to give you some information in advance. Everybody is invited to test
the modifications.

All modifications were tested and work with Phil Zimmermann's original
Zfone, this includes SAS verification.

As proposed by Emanuel we can extend the implementation to support or
use other key sharing / key negotiation mechanisms (if this will ever
happen :slight_smile: ). Currently only ZRTP is implemented.

We now have a separate ZRTP panel that handles the display of events
and necessary data and also handles user action to set SAS
verification state. Also this action is separated from the ZRTP
implementation.

The ZRTP panel is _very_ _simple_ and I kindly ask our GUI gurus to
have a look and propose a much better look-and-feel. I'm not a good
GUI designer at all :slight_smile: .

Attached to this mail is a more detailed list of modifications I've
done to make this happen.

Due to various reasons ZRTP is enabled by default for all SIP calls
(more detailed explanation see attachment). This doe not do any harm
to clients that do not support ZRTP - they just ignore it and the user
does not notice any problems. Emanuel provided a patch about 6 weeks
ago to enable/disable ZRTP on a per account basis. After these
modifications are done we can have a look at that patch and how to
integrate it.

Video is not yet supported, it's somehow prepared but needs some
additional modifications and enhancements in ZRTP handling inside
SipSessionImpl and the ZRTP SCCallback class. The GUI
and other mechanisms are already well prepared to handle video.

Regarding video support: The ZRTP specification requires one "Master"
session that must negotiate the keys before additional sessions, for
example Video, can be attached. IMHO we should define the "Audio"
session as the "Master" for this case. Is this ok?

Also because of the key negotiation and the SRTP crypto context only
1-1 calls are possible if security is enabled (one call can have
several media streams but only to the same client), that is only one
participant per call (no secure 1-n calls).

Best regards,
Werner

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

The patch attached is done against revision 4772 (Werner's commit).

Correction, my mistake, it's actually rev. 4773.

···

On Mon, 1 Dec 2008, Onica S. Emanuel wrote:

Regards,
Emanuel

On Sun, 30 Nov 2008, Werner Dittmann wrote:

All,

as proposed in one of my last e-mails I've changed the way how the
ZRTP GUI is implemented. Quite some modifications were necessary. It's
ready in my sandbox here. Before I commit I thought it is a good idea
to give you some information in advance. Everybody is invited to test
the modifications.

All modifications were tested and work with Phil Zimmermann's original
Zfone, this includes SAS verification.

As proposed by Emanuel we can extend the implementation to support or
use other key sharing / key negotiation mechanisms (if this will ever
happen :slight_smile: ). Currently only ZRTP is implemented.

We now have a separate ZRTP panel that handles the display of events
and necessary data and also handles user action to set SAS
verification state. Also this action is separated from the ZRTP
implementation.

The ZRTP panel is _very_ _simple_ and I kindly ask our GUI gurus to
have a look and propose a much better look-and-feel. I'm not a good
GUI designer at all :slight_smile: .

Attached to this mail is a more detailed list of modifications I've
done to make this happen.

Due to various reasons ZRTP is enabled by default for all SIP calls
(more detailed explanation see attachment). This doe not do any harm
to clients that do not support ZRTP - they just ignore it and the user
does not notice any problems. Emanuel provided a patch about 6 weeks
ago to enable/disable ZRTP on a per account basis. After these
modifications are done we can have a look at that patch and how to
integrate it.

Video is not yet supported, it's somehow prepared but needs some
additional modifications and enhancements in ZRTP handling inside
SipSessionImpl and the ZRTP SCCallback class. The GUI
and other mechanisms are already well prepared to handle video.

Regarding video support: The ZRTP specification requires one "Master"
session that must negotiate the keys before additional sessions, for
example Video, can be attached. IMHO we should define the "Audio"
session as the "Master" for this case. Is this ok?

Also because of the key negotiation and the SRTP crypto context only
1-1 calls are possible if security is enabled (one call can have
several media streams but only to the same client), that is only one
participant per call (no secure 1-n calls).

Best regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Yana,

When I receive a XMPP voice call on SC, the icons for call accept and
call reject do not show completely using the WIN build. Parts of the
buttons are missing.

During a call, a mouse hover over the 3 icons gives no information bubble
to tell what clicking a particular icon will do.

Screenshots attached.

Regards, Earl


#7

Hi Earl,

When I receive a XMPP voice call on SC, the icons for call accept and
call reject do not show completely using the WIN build. Parts of the
buttons are missing.

Thank you for the feedback!

I think trunk in r4783 fixes the problem.

Regards,
Lubo

···

On Mon, Dec 1, 2008 at 10:45 PM, Earl <Large.Files@gmx.net> wrote:

Hi Yana,

When I receive a XMPP voice call on SC, the icons for call accept and
call reject do not show completely using the WIN build. Parts of the
buttons are missing.

During a call, a mouse hover over the 3 icons gives no information bubble
to tell what clicking a particular icon will do.

Screenshots attached.

Regards, Earl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi,

When I move audio codecs up and down, it works, but the changes
do not stick. Next time the codec order has reverted and my preferences
have disappeared. The changes in the desired codec order should
hold.

Earl

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hey Earl,

Thanks for the report. This is indeed a bug. Could you please create an
issue with P2 priority in our tracker?

Thanks
Emil

Earl wrote:

···

Hi,

When I move audio codecs up and down, it works, but the changes
do not stick. Next time the codec order has reverted and my preferences
have disappeared. The changes in the desired codec order should
hold.

Earl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

The issue has been reported as
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=515.

Regards,
Lubo

···

On Thu, Dec 4, 2008 at 12:06 AM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Earl,

Thanks for the report. This is indeed a bug. Could you please create an
issue with P2 priority in our tracker?

Thanks
Emil

Earl wrote:

Hi,

When I move audio codecs up and down, it works, but the changes
do not stick. Next time the codec order has reverted and my preferences
have disappeared. The changes in the desired codec order should
hold.

Earl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net