[sip-comm-dev] Some observation during SC testing (with and without ZRTP)


#1

All,

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.

1)
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.

2)
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.

3)
The next part is more a matter of taste :slight_smile: . 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
misleading.

My proposal:

- 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.

5)
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.

6)
Now something for the real SC media handling gurus :slight_smile: . 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 :slight_smile: .

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


#2

Hey Werner,

(inline)

Werner Dittmann написа:

All,

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.

1)
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.

Yes. We are going to handle this as part of issue 463

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=463

2)
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.

I've created issue 460 for this one:

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=460

3)
The next part is more a matter of taste :slight_smile: . 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
misleading.

My proposal:

- 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.

463 again.

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.

I've added this comment to 454:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=454

I'll probably need to discuss this with you a bit more after I look
through the zrtp4j API which I haven't had the chance to do so far.
Basically we'd need to decide what information we would need to bring up
to the UI.

5)
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.

Oh yes. I had noticed this some time ago. Just entered 461:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=461

6)
Now something for the real SC media handling gurus :slight_smile: . 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?

I entered this as
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=462
although I've assigned a low priority. It is still scheduled for rc1 so
we'll handle it if we have the time (or if anyone sends a patch of course).

I have to confess however that I am a bit confused as to why these need
to be played by the transmitter. After all notifications are best
handled by the local UI so it would make a lot of sense to simply
accompany visual notifications with these sounds. Is there any
security-related reason to move them in the transmitter?

That's all for today :slight_smile: .

Thanks for all your help Werner!

Cheers
Emil

···

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

Emil,

thanks for taking care of these issues - somehow I need to
use to the bug tracker in the first place :slight_smile: .

Just a comment on the sound issue (the last one): these sounds
should be handled locally - sorry if I was not clear with that.
If the local SC UI is able to play sound, for example when it
switches the padlock to "secure" state, that would be perfect.
Would that be similar to playing the ring tone?

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

(inline)

<SNIP ---- SNAP>

···

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


#4

Emil,

just forgot to mention the message topic. If you are interessted
you may have a look at the ZrtpCodes class that conatins the Info,
Warning, Error, and ZRTP error codes.

I'll do some exercise here and provide you a proposal which messages
IMHO are important and/or relevant for the end user. Other messages could
go into a log file if required. Also some layout of a message window
or message area inside the call window may be required?

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

(inline)

<SNIP ---- SNAP>

···

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


#5

Hey Werner,

Werner Dittmann написа:

Emil,

Just a comment on the sound issue (the last one): these sounds
should be handled locally - sorry if I was not clear with that.
If the local SC UI is able to play sound, for example when it
switches the padlock to "secure" state, that would be perfect.
Would that be similar to playing the ring tone?

OK, I must have misunderstood then. That would definitely be a lot
simpler. Will try to handle it as part of the UI issues. Incidentally, I
couldn't really find the sounds. Are they available for download
anywhere? Would they be compatible with our LGPL license?

just forgot to mention the message topic. If you are interessted
you may have a look at the ZrtpCodes class that conatins the Info,
Warning, Error, and ZRTP error codes.

OK will have a look.

I'll do some exercise here and provide you a proposal which messages
IMHO are important and/or relevant for the end user.

Oh, yes, this would be very helpful thanks!

Other messages could
go into a log file if required. Also some layout of a message window
or message area inside the call window may be required?

Not sure I understand the question. Could you please explain?

Cheers
Emil

···

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

(inline)

<SNIP ---- SNAP>

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