during the ZRTP tests with SC I discovered some glitches that could
disturb the user experience or may lead to other problems. Please keep
in mind that I use a 64bit Linux environment with 64bit Java 1.5. Some
native libraries are not yet available for 64bit Linux on AMD64
architecture - maybe this could explain some misbehaviour.
The text display that shows the SAS characters after ZRTP handshake is
completed if too small, i.e. it truncates the lower part of
charachters like q or g. a good readability of the SAS is important
because the user can or shall use this information to check if nobody
modified data during the ZRTP handshake.
ZRTP provides a mechanism to acknowledge the SAS. After the users
checked the SAS and confirmed its correctness they should be able to
acknowledge this. The ZRTP implementation offers a function the the UI
can call (similar to enable ZRTP) and ZRTP remembers that the SAS was
correct and confirmed. This enables a sort of key continuity and it is
not necessary to check the SAS on every call to the same user/user
client. If something gets wrong during key continuity processing the
user gets a warning and shall check the SAS again.
Thus I would propose to display the SAS in a button that the user can
klick and the action of this button calls ZRTP's "SAS checked"
method. for the next calls to the same user/user client ZRTP can
signal to the UI if key continuity was OK or not.
The next part is more a matter of taste . The "secure" button
display a grey closed padlock if ZRTP is not enabled. Usually grey
button signal "function not available" - thus IMHO the button is a bit
- display a white open padlock (just the contour) if ZRTP
is not enabled (make lines of the outline a bit thicker than normal
for better recognition).
- if the user clicks and enables ZRTP fill the padlock, but leave it
as an open padlock (fill could be black). The color could be changed
to red if ZRTP starts its handshake (info code: InfoHelloReceived)
- once secure mode is reached (info code: InfoSecureStateOn) the
display shall switch to a closed padlock, bright green.
4) ZRTP4J reports quite a lot of information using the callback
methods. Currently nothing is displayed in the call window.
IMHO we need to discuss and decide which info is important
and has to / should / may be displayed. The severe messages as well as
the ZRTP error codes should be displayed, also some warnings because
they may trigger some action, for example to verify the SAS.
The "redial" function of SC sometimes doesn't work. If I hangup a
call (with or without security enabled) and the call window closes I
cannot just press the dial key to setup another call to the same
destination. Sometimes it works, sometimes not. Also the list of
recently dialed numbers is not filled.
Now something for the real SC media handling gurus . Phil
Zimmermann gave his permisson to use Zfone's sound files to give
acoustic signals for example if ZRTP switches to secure state. These
files are available in PCM uLaw format (use sox to convert to other
formats). Phil's Zfone implementation somehow feeds this data into the
RTP stream (or any other way) to play an acoustic signal to the user
that something happend (similar to a ring tone?). ZRTP4J uses a
callback when is switches to secure state. Thus, in addition to the
optical (padlock) signaling, this could be a way to do an acoustic
signal too (in case the user does not pay attention to the
display). The signal is short (just 4222 bytes, roughly half a second,
this this could be held in memory in a byte array). Other sounds are
also avaliable, the longest in about 11000 bytes and is the "something
is wrong" sound in case of a severe error. Would it be possible to
play such sounds during a ongoing RTP/media session?
That's all for today .