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 .
I would propose a solution and also show why it is not yet
implementable at SC .
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.
- 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
- 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.