some first thoughts on this topic.
The latest version of ZRTP4J (1.3.1) implements the multi-stream mode
as specified in the ZRTP draft. This involved some changes and
enhancements in the ZRTP4J core functions.
*** How does it work ***
According to ZRTP specification:
1) only one media stream (usually the first one) MUST use a full
fledged Diffie-Helman (DH) key negotiation,
2) All other media streams for the same call MUST use multi-stream
mode. However, multi-stream mode exchange can start only after the
fist DH mode exchange is completed.
These requirements imply some synchronization of ZRTP exchanges,
however it's not too difficult to do this. ZRTP4J already reports when
a client can start a multi-stream ZRTP exchange.
Despite the fact the multi-stream exchanges re-use some data from the
DH ZRTP exchange (beefed up with nonces) each multi-stream session has
it own, independent set of key, hash, and HMAC data.
*** Setting up of several media streams ***
If a client likes to set up several media streams for _the same call_
it should use the following call flow. This is already a bit aligned
with SC's working using JMF (or FMJ):
The application shall create the required RTPManagers for the media
streams. SC already creates RTPManagers for audio and video. If both
media streams shall be encrypted then create the required numbers of
ZRTPConnectors and set these in the RTPManagers.
Remember: A ZRTPConnector behaves like a standard JMF RTP connector
until it is initialized to use ZRTP.
Now the more tricky part:
The application has to decide which media stream is the first one - in
ZRTP terms this will be the ZRTP exchange that must use a DH mode
exchange. Usually this is the audio stream. Thus the client (SC) shall
initialize the according ZRTPTransformer and it's associated ZRTP
engine to use ZRTP. Without specific configuration this will be a
DH mode exchange.
All other ZRTPTransformers stay in "non-ZRTP" mode (not initialized)
and just send the media (RTP) data if their RTP session is up and
If the first media stream is up and running and both clients support
ZRTP the key negotiation starts. After a short time this is done and
the first media stream (lets call it the "master stream") switches to
secure mode. ZRTP4J reports this event using the showMessage(...)
callback method with appropriate information codes. This callback
method shall prepare to switch on security for all other streams.
This is done as follows:
The first ZRTP exchange, the "master stream", computed a set of data
that all multi-stream ZRTP exchanges must use.
- The showMessage(...) callback method calls the ZRTP engine's
method "getMultiStrParams()" to read this data from the master stream
and sends it to all other ZRTPTransformers and their associated ZRTP
engines using their "setMultiStrParams(...) method. This enables
multi-stream processing for these streams.
- After this was done the client (SC) can initialize the remaining
ZRTP engines as usual. The multi-stream negotiations may run in
Examples how this works in reality refer to the examples in ZRTP4J
demo directory .
*** Notes on the current implementation of SC CallSessionImpl ***
The current implementation in SC's CallSessionImpl was done before the
multi-stream mode was ready in ZRTP4J, thus we probably need to revise
some code and mechanisms in SC's CallSessionImpl as well as in the SC
specific ZRTPTransformer classes. The latter ones need a small update
only as far as I can see. The mechanisms in CallSessionImpl are nearly
available, however because I don't know all the callback and event
handling mechanisms in SC during call setup I cannot propose a way to
do it but are ready to start discussions.