[sip-comm-dev] ZRTP GUI and ZRTP user actions


Dear all,

here I'm referring to a discussion about 4 weeks ago when Yana brought
up the issue that the ZRTP callback class (SCCallback) contains GUI
code an manipulates buttons and labels etc.

Yana argued that the GUI code should be in one place and not spread
over several package hierarchies.

Emanuel said it seems necessary to have the security specific classes
handle the security specific GUI.

Both are right :slight_smile: .

I would propose a solution and also show why it is not yet
implementable at SC :wink: .

Current solution:

Currently the CallParticipantPanel creates a SecureButton and a
SecureLabel and registers both with the Call using specific
functions. The SCCallback gets these security GUI elements from the
call and manipulates them.

Proposed solution:

- create a specific ZRTP GUI class, for example a panel that can hold
   all GUI elements required for ZRTP (buttons, labels), probably
   showing icon and state information. This new class would substitute
   the currently used items SecureButton and SecureLabel (would
   probably integrate them).

- extend the existing CallPanel to accept a new Event (this needs to
   be defined): ZRTP_STATE_CHANGE. Accept this either as a participant
   change event or as a call state change event. The new event contains
   ZRTP specific event data

- CallPanel forwards this event to call participant panel for further

- Call participant panel checks if a ZRTP GUI class (see above) is
   already created and mapped, if not create one. Forward the event to
   the ZRTP GUI class which uses the event specific data to get the
   latest ZRTP status information and fill its panel, for example to
   display the SAS, the SAS verification status, a padlock etc. Thus
   only the ZRTP specific GUI class (panel) knows how to deal with ZRTP
   state data.

- modify the ZRTP specific SCCallback class to store the ZRTP status,
   sends the ZRTP_STATE_CHANGE event, and provide ways that the ZRTP
   GUI class can get the ZRTP status data. The SCCallback decides when
   to send the ZRTP_STATE_CHANGE event and provides data - thus it is
   the controller and in parts the model.

- The ZRTP specific SCCallback (in transformer.zrtp) and the ZRTP
   GUI class (in the GUI package) are both responsible to keep the user

- a similar technique can be used to implement other security
   protocols, just add a new event, a new panel and a new controller.

= PROBLEM: because ZRTP is a Media based protocol the SCCallback is
   associated with the Media CallSessionImpl. The SCCallback cannot
   send Call state change or participant state change events. SC does
   not foresee "Media controlled state changes". The relevant functions
   in Call or Participant are protected. Thus media changes currently
   cannot reported to the GUI.

The ZRTP specific GUI class (panel) should also contain buttons or other
elements the user can activate. Upon activation the ZRTP GUI element
calls secure operation methods perform the required action (similar as
already done in SecureButton).

By separating it this way the ZRTP GUI and the ZRTP GUI actions are
bundled in one class, the ZRTP specific control and model (states) are
associated with ZRTP protocol.

To implement this some enhancement are required: new event, a way to
send the event, changes in several GUI classes (though not to
dramatic), and of course modifications in SCCallback, etc.

Ideas? Thoughts?

Best regards,


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