[sip-comm-dev] Proposal to enhance SIP Communicator with ZRTP


#1

All,

I would like to make a proposal to enhance SIP Communicator to use
Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
exchange keys and crypto configuration data to setup a Secure RTP
(SRTP) session. Last year Bing Su implemented SRTP into the SIP
Comminucator but this implementation is not used because of the
missing features to setup the necessary keys for SRTP.

Currently I'm porting my C++ implementation for ZRTP [2] to Java,
several parts are already done but it is far from being complete :-).
The following picture shows how the integration into SC may look
like. The layout is the same as for the C++ implementation an
proved to be ok:

···

+-------------+
                          > JMF |
                          > RTPConnector>
                          > >
                          +-------------+
                               ^
                               > extends
                               >
+----------------+ +-----+----------+
> SIP Commun. | | | +-----------------+
> instantiates | uses | ZrtpConnector | uses | |
> ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> and provides | | ZrtpCallback | | core |
>ZrtpUserCallback> > > > implementation |
+----------------+ +----------------+ | (ZRtp et al) |
                                                 > >
                                                 +-----------------+

Here a short explanation:

A complete GNU ZRTP4J implementation consists of two parts, the GNU
ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
underlying RTP/SRTP stack, the operating system, and the application:

- The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
   operating system and consists of the ZRTP protocol state
   engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
   GNU ZRTP engine provides methods to setup ZRTP message and to
   analyze received ZRTP messages, to compute the crypto data required
   for SRTP, and to maintain the required hashes and HMAC.

- The second part of an implementation is specific code that binds
   the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
   operating system specific services such as timers, etc.

* ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *

ZRTP4J either re-uses or extends Bing Su's SRTP Connector implementation.
The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
this connection to exchangeZRTP data. After ZRTP negotiated the the keys
and created the SRTP it steps out of the data exchange. The ZrtpConnector
also provides additional methods that enable the application to control
ZRTP and the connector accepts a callback class that the connector uses
to report events to the application. In case of SIP Communicator the setup
of the ZrtpConnector will (could) be done in the CallSessionImpl class in
the same way as Bing Su implmented it for SRTP. The SIP Communicator
specific ZrtpConnector would be part of the SC source code. My
proposal is to place it parallel to Bing Su's SRTP connector code.

* GNU ZRTP4J *

This is the ZRTP implmentation for Java. It's an own library (jar)
that is independent of the (S)RTP protocol implmentation. The
ZrtpConnector uses the libary to perform the ZRTP specific tasks and
the ZRTP4J core uses the connector to send/receive data, create the
SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
is an own library (jar). As its name suggests GNU ZRTP4J will be
available under GPL.

* SC specific question and requirements *

To be able to efficiently use ZRTP it is strongly recommened to have a
user interface to inform the user about the status of ZRTP and to
provide some commnnds to conrol ZRTP:

- a small icon inside the SC GUI (a padlock?) to show if security is
  enabled or not

- attached to this icon a text field (minimum 4 characters) to display
  the Short Authentication Code (SAS)

- a button or similar action field that the user may select if he/she
  verified the SAS with the other user.

As noted above ZRTP connector uses a callback mechanism to inform the
SC GUI when to display the padlock or to show the SAS and other
information. The ZRTP Connector also provides methods that the SC GUI
can call to inform about SAS verification.

Because my know-how with respect to SC is rather limited I would
appreciate to have a discussion with some "hard-core" SC prgrammer how
and where to provide the hooks for the callback class, also the GUI
designer/implmentor shall have a look at this issue :slight_smile: .

Best regards,
Werner

[1] http://zfoneproject.com/
[2] http://www.gnutelephony.org/index.php/GNU_ZRTP

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


#2

Hello,

I am a student enrolled in the Google Summer of Code 2008 program with a project related to SIP Communicator that regards solving the issue of the key management, in order to make the current SRTP implementation usable.

I actually thought on using ZRTP for this also, and following Su Bing's work to use as a reference libzrtpcpp. I am currently in my analysis phase of the project (this week is planned for reading the ZRTP standard in detail), but until now I can say that I've had pretty similar ideas regarding the integration as you did (except actually porting the C++ implementation to a Java library, which makes you quite advanced from me at this point).

Like I said, I am currently in the phase of the project analysis for this month, and I was planning to start the dev part from June. I have a blog related to the project http://sipcommkeysharing.blogspot.com. I'll post there during this day the discussion had in the evaluation phase with my mentor Romain Kuntz, which might give you some more information.

I am actually new to SIP Communicator architecture and to the ZRTP standard also. I don't know how or if it would be possible a collaboration to the project (we are both interested in the same thing) due to my GSoC student status. Regarding the fact that you seem quite advanced in the key management problem, I personally will wait for an opinion from my mentor Romain Kuntz in this matter.

Regards,
E. Onica

···

On Fri, 9 May 2008, Werner Dittmann wrote:

All,

I would like to make a proposal to enhance SIP Communicator to use
Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
exchange keys and crypto configuration data to setup a Secure RTP
(SRTP) session. Last year Bing Su implemented SRTP into the SIP
Comminucator but this implementation is not used because of the
missing features to setup the necessary keys for SRTP.

Currently I'm porting my C++ implementation for ZRTP [2] to Java,
several parts are already done but it is far from being complete :-).
The following picture shows how the integration into SC may look
like. The layout is the same as for the C++ implementation an
proved to be ok:

                         +-------------+
                         > JMF |
                         > RTPConnector>
                         > >
                         +-------------+
                              ^
                              > extends
                              >
+----------------+ +-----+----------+
> SIP Commun. | | | +-----------------+
> instantiates | uses | ZrtpConnector | uses | |
> ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> and provides | | ZrtpCallback | | core |
>ZrtpUserCallback> > > > implementation |
+----------------+ +----------------+ | (ZRtp et al) |
                                                > >
                                                +-----------------+

Here a short explanation:

A complete GNU ZRTP4J implementation consists of two parts, the GNU
ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
underlying RTP/SRTP stack, the operating system, and the application:

- The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
  operating system and consists of the ZRTP protocol state
  engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
  GNU ZRTP engine provides methods to setup ZRTP message and to
  analyze received ZRTP messages, to compute the crypto data required
  for SRTP, and to maintain the required hashes and HMAC.

- The second part of an implementation is specific code that binds
  the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
  operating system specific services such as timers, etc.

* ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *

ZRTP4J either re-uses or extends Bing Su's SRTP Connector implementation.
The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
this connection to exchangeZRTP data. After ZRTP negotiated the the keys
and created the SRTP it steps out of the data exchange. The ZrtpConnector
also provides additional methods that enable the application to control
ZRTP and the connector accepts a callback class that the connector uses
to report events to the application. In case of SIP Communicator the setup
of the ZrtpConnector will (could) be done in the CallSessionImpl class in
the same way as Bing Su implmented it for SRTP. The SIP Communicator
specific ZrtpConnector would be part of the SC source code. My
proposal is to place it parallel to Bing Su's SRTP connector code.

* GNU ZRTP4J *

This is the ZRTP implmentation for Java. It's an own library (jar)
that is independent of the (S)RTP protocol implmentation. The
ZrtpConnector uses the libary to perform the ZRTP specific tasks and
the ZRTP4J core uses the connector to send/receive data, create the
SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
is an own library (jar). As its name suggests GNU ZRTP4J will be
available under GPL.

* SC specific question and requirements *

To be able to efficiently use ZRTP it is strongly recommened to have a
user interface to inform the user about the status of ZRTP and to
provide some commnnds to conrol ZRTP:

- a small icon inside the SC GUI (a padlock?) to show if security is
enabled or not

- attached to this icon a text field (minimum 4 characters) to display
the Short Authentication Code (SAS)

- a button or similar action field that the user may select if he/she
verified the SAS with the other user.

As noted above ZRTP connector uses a callback mechanism to inform the
SC GUI when to display the padlock or to show the SAS and other
information. The ZRTP Connector also provides methods that the SC GUI
can call to inform about SAS verification.

Because my know-how with respect to SC is rather limited I would
appreciate to have a discussion with some "hard-core" SC prgrammer how
and where to provide the hooks for the callback class, also the GUI
designer/implmentor shall have a look at this issue :slight_smile: .

Best regards,
Werner

[1] http://zfoneproject.com/
[2] http://www.gnutelephony.org/index.php/GNU_ZRTP

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

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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


#3

If you don't already know, you might be interested to look at ZFone
( http://zfoneproject.com/ ), the ZRTP project Phil Zimmerman (PGP, etc)
produces that publishes source code, and just released a new beta last
month.

···

On Fri, 2008-05-09 at 12:33 +0300, Onica S. Emanuel wrote:

On Fri, 9 May 2008, Werner Dittmann wrote:

Hello,

I am a student enrolled in the Google Summer of Code 2008 program with a
project related to SIP Communicator that regards solving the issue of the
key management, in order to make the current SRTP implementation usable.

I actually thought on using ZRTP for this also, and following Su Bing's
work to use as a reference libzrtpcpp. I am currently in my analysis
phase of the project (this week is planned for reading the ZRTP standard
in detail), but until now I can say that I've had pretty similar ideas
regarding the integration as you did (except actually porting the C++
implementation to a Java library, which makes you quite advanced from me
at this point).

Like I said, I am currently in the phase of the project analysis for
this month, and I was planning to start the dev part from June. I have a
blog related to the project http://sipcommkeysharing.blogspot.com. I'll
post there during this day the discussion had in the evaluation phase with
my mentor Romain Kuntz, which might give you some more information.

I am actually new to SIP Communicator architecture and to the ZRTP
standard also. I don't know how or if it would be possible a collaboration
to the project (we are both interested in the same thing) due to my GSoC
student status. Regarding the fact that you seem quite advanced in the
key management problem, I personally will wait for an opinion from my
mentor Romain Kuntz in this matter.

Regards,
E. Onica

> All,
>
> I would like to make a proposal to enhance SIP Communicator to use
> Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
> exchange keys and crypto configuration data to setup a Secure RTP
> (SRTP) session. Last year Bing Su implemented SRTP into the SIP
> Comminucator but this implementation is not used because of the
> missing features to setup the necessary keys for SRTP.
>
> Currently I'm porting my C++ implementation for ZRTP [2] to Java,
> several parts are already done but it is far from being complete :-).
> The following picture shows how the integration into SC may look
> like. The layout is the same as for the C++ implementation an
> proved to be ok:
>
>
> +-------------+
> > JMF |
> > RTPConnector>
> > >
> +-------------+
> ^
> > extends
> >
> +----------------+ +-----+----------+
> > SIP Commun. | | | +-----------------+
> > instantiates | uses | ZrtpConnector | uses | |
> > ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> > and provides | | ZrtpCallback | | core |
> >ZrtpUserCallback> > > > implementation |
> +----------------+ +----------------+ | (ZRtp et al) |
> > >
> +-----------------+
>
> Here a short explanation:
>
> A complete GNU ZRTP4J implementation consists of two parts, the GNU
> ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
> underlying RTP/SRTP stack, the operating system, and the application:
>
> - The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
> operating system and consists of the ZRTP protocol state
> engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
> GNU ZRTP engine provides methods to setup ZRTP message and to
> analyze received ZRTP messages, to compute the crypto data required
> for SRTP, and to maintain the required hashes and HMAC.
>
> - The second part of an implementation is specific code that binds
> the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
> operating system specific services such as timers, etc.
>
> * ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *
>
> ZRTP4J either re-uses or extends Bing Su's SRTP Connector implementation.
> The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
> this connection to exchangeZRTP data. After ZRTP negotiated the the keys
> and created the SRTP it steps out of the data exchange. The ZrtpConnector
> also provides additional methods that enable the application to control
> ZRTP and the connector accepts a callback class that the connector uses
> to report events to the application. In case of SIP Communicator the setup
> of the ZrtpConnector will (could) be done in the CallSessionImpl class in
> the same way as Bing Su implmented it for SRTP. The SIP Communicator
> specific ZrtpConnector would be part of the SC source code. My
> proposal is to place it parallel to Bing Su's SRTP connector code.
>
> * GNU ZRTP4J *
>
> This is the ZRTP implmentation for Java. It's an own library (jar)
> that is independent of the (S)RTP protocol implmentation. The
> ZrtpConnector uses the libary to perform the ZRTP specific tasks and
> the ZRTP4J core uses the connector to send/receive data, create the
> SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
> is an own library (jar). As its name suggests GNU ZRTP4J will be
> available under GPL.
>
> * SC specific question and requirements *
>
> To be able to efficiently use ZRTP it is strongly recommened to have a
> user interface to inform the user about the status of ZRTP and to
> provide some commnnds to conrol ZRTP:
>
> - a small icon inside the SC GUI (a padlock?) to show if security is
> enabled or not
>
> - attached to this icon a text field (minimum 4 characters) to display
> the Short Authentication Code (SAS)
>
> - a button or similar action field that the user may select if he/she
> verified the SAS with the other user.
>
> As noted above ZRTP connector uses a callback mechanism to inform the
> SC GUI when to display the padlock or to show the SAS and other
> information. The ZRTP Connector also provides methods that the SC GUI
> can call to inform about SAS verification.
>
> Because my know-how with respect to SC is rather limited I would
> appreciate to have a discussion with some "hard-core" SC prgrammer how
> and where to provide the hooks for the callback class, also the GUI
> designer/implmentor shall have a look at this issue :slight_smile: .
>
> Best regards,
> Werner
>
> [1] http://zfoneproject.com/
> [2] http://www.gnutelephony.org/index.php/GNU_ZRTP
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>

--

(C) Matthew Rubenstein

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


#4

actually I know Phil's ZRTP project quite well and I'm in close contact
with Phil. I did many interoperability tests with Zfone code.

The are some differences between Phil's Zfone code and GNU ZRTP:

Zfone is implmented in plain C and is a "bump-in-the-wire" implementation
that requires that both clients use SIP to negotiate the RTP parameters. The
basic ZRTP library of Zfone may be used as a basis for other implementations.
It also contains an own RTP implementation (sort of at least).

GNU ZRTP was designed to by a "native" implementation directly linked to
an application that needs (S)RTP. The overall design was done in a way to
enable various RTP implementations to use GNU ZRTP just by adding the
glue code. Thus the impact to the existing (S)RTP stack is kept to a
minumium. Also because it's a "native" implementation you may use GNU ZRTP
even withou any signaling and achieve security, or use other signaling protocols
to negotiate RTP parameters first.

As for the status of the "port": already all packets are implemented in Java
already, some untility classes such as CRC32C, the Base32 (for SAS), the ZID
file implementation are also done. The others are "under construction".

To support testing I also did some RTP stuff that implements RTP data sources,
Push sources, etc. This stuff will serve as test and debug tools to test and
debug the connectors. Interop tests will be done using the C++ (and later the
Zfone) implementation.

Regards,
Werner

Matthew Rubenstein schrieb:

···

  If you don't already know, you might be interested to look at ZFone
( http://zfoneproject.com/ ), the ZRTP project Phil Zimmerman (PGP, etc)
produces that publishes source code, and just released a new beta last
month.

On Fri, 2008-05-09 at 12:33 +0300, Onica S. Emanuel wrote:

On Fri, 9 May 2008, Werner Dittmann wrote:

Hello,

I am a student enrolled in the Google Summer of Code 2008 program with a
project related to SIP Communicator that regards solving the issue of the
key management, in order to make the current SRTP implementation usable.

I actually thought on using ZRTP for this also, and following Su Bing's
work to use as a reference libzrtpcpp. I am currently in my analysis
phase of the project (this week is planned for reading the ZRTP standard
in detail), but until now I can say that I've had pretty similar ideas
regarding the integration as you did (except actually porting the C++
implementation to a Java library, which makes you quite advanced from me
at this point).

Like I said, I am currently in the phase of the project analysis for
this month, and I was planning to start the dev part from June. I have a
blog related to the project http://sipcommkeysharing.blogspot.com. I'll
post there during this day the discussion had in the evaluation phase with
my mentor Romain Kuntz, which might give you some more information.

I am actually new to SIP Communicator architecture and to the ZRTP
standard also. I don't know how or if it would be possible a collaboration
to the project (we are both interested in the same thing) due to my GSoC
student status. Regarding the fact that you seem quite advanced in the
key management problem, I personally will wait for an opinion from my
mentor Romain Kuntz in this matter.

Regards,
E. Onica

All,

I would like to make a proposal to enhance SIP Communicator to use
Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
exchange keys and crypto configuration data to setup a Secure RTP
(SRTP) session. Last year Bing Su implemented SRTP into the SIP
Comminucator but this implementation is not used because of the
missing features to setup the necessary keys for SRTP.

Currently I'm porting my C++ implementation for ZRTP [2] to Java,
several parts are already done but it is far from being complete :-).
The following picture shows how the integration into SC may look
like. The layout is the same as for the C++ implementation an
proved to be ok:

                         +-------------+
                         > JMF |
                         > RTPConnector>
                         > >
                         +-------------+
                              ^
                              > extends
                              >
+----------------+ +-----+----------+
> SIP Commun. | | | +-----------------+
> instantiates | uses | ZrtpConnector | uses | |
> ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> and provides | | ZrtpCallback | | core |
>ZrtpUserCallback> > > > implementation |
+----------------+ +----------------+ | (ZRtp et al) |
                                                > >
                                                +-----------------+

Here a short explanation:

A complete GNU ZRTP4J implementation consists of two parts, the GNU
ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
underlying RTP/SRTP stack, the operating system, and the application:

- The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
  operating system and consists of the ZRTP protocol state
  engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
  GNU ZRTP engine provides methods to setup ZRTP message and to
  analyze received ZRTP messages, to compute the crypto data required
  for SRTP, and to maintain the required hashes and HMAC.

- The second part of an implementation is specific code that binds
  the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
  operating system specific services such as timers, etc.

* ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *

ZRTP4J either re-uses or extends Bing Su's SRTP Connector implementation.
The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
this connection to exchangeZRTP data. After ZRTP negotiated the the keys
and created the SRTP it steps out of the data exchange. The ZrtpConnector
also provides additional methods that enable the application to control
ZRTP and the connector accepts a callback class that the connector uses
to report events to the application. In case of SIP Communicator the setup
of the ZrtpConnector will (could) be done in the CallSessionImpl class in
the same way as Bing Su implmented it for SRTP. The SIP Communicator
specific ZrtpConnector would be part of the SC source code. My
proposal is to place it parallel to Bing Su's SRTP connector code.

* GNU ZRTP4J *

This is the ZRTP implmentation for Java. It's an own library (jar)
that is independent of the (S)RTP protocol implmentation. The
ZrtpConnector uses the libary to perform the ZRTP specific tasks and
the ZRTP4J core uses the connector to send/receive data, create the
SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
is an own library (jar). As its name suggests GNU ZRTP4J will be
available under GPL.

* SC specific question and requirements *

To be able to efficiently use ZRTP it is strongly recommened to have a
user interface to inform the user about the status of ZRTP and to
provide some commnnds to conrol ZRTP:

- a small icon inside the SC GUI (a padlock?) to show if security is
enabled or not

- attached to this icon a text field (minimum 4 characters) to display
the Short Authentication Code (SAS)

- a button or similar action field that the user may select if he/she
verified the SAS with the other user.

As noted above ZRTP connector uses a callback mechanism to inform the
SC GUI when to display the padlock or to show the SAS and other
information. The ZRTP Connector also provides methods that the SC GUI
can call to inform about SAS verification.

Because my know-how with respect to SC is rather limited I would
appreciate to have a discussion with some "hard-core" SC prgrammer how
and where to provide the hooks for the callback class, also the GUI
designer/implmentor shall have a look at this issue :slight_smile: .

Best regards,
Werner

[1] http://zfoneproject.com/
[2] http://www.gnutelephony.org/index.php/GNU_ZRTP

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


#5

Hi Werner,

Sorry for this delayed reply and thank you for this great news! As Emanuel said, ZRTP was our candidate as the key negotiation and exchange mechanism for SC, and we were planning to use GNU ZRTP as a reference.

You seem to have already a pretty good idea on how to port your code into a Java library and on how to integrate this in SC, thanks for sharing your thoughts on that. I think supporting ZRTP in SIP Communicator is quite a piece of work if we consider the ZRTP library implementation, the connection with SC's SRTP and the SC GUI part, definition of unit tests, and interop' tests.

This makes me think that if both Emanuel and you are positive to work together on that topic, we would be very happy to let Emanuel work with you as part of his GSoC project. I understand that working together remotely may not be easy, but as you said in your mail there are multiple distinct parts to work on, both on the libray side and on the SC side. This would be really great if we could have a functional and interoperable ZRTP/SRTP/SC system at the end of the summer :slight_smile:

Let us know what you think about this.
And again, thank you for your interest in SC!

Cheers,
romain

···

On 2008/05/09, at 11:33, Onica S. Emanuel wrote:

On Fri, 9 May 2008, Werner Dittmann wrote:

Hello,

I am a student enrolled in the Google Summer of Code 2008 program with a project related to SIP Communicator that regards solving the issue of the key management, in order to make the current SRTP implementation usable.

I actually thought on using ZRTP for this also, and following Su Bing's work to use as a reference libzrtpcpp. I am currently in my analysis phase of the project (this week is planned for reading the ZRTP standard in detail), but until now I can say that I've had pretty similar ideas regarding the integration as you did (except actually porting the C++ implementation to a Java library, which makes you quite advanced from me at this point).

Like I said, I am currently in the phase of the project analysis for this month, and I was planning to start the dev part from June. I have a blog related to the project http://sipcommkeysharing.blogspot.com. I'll post there during this day the discussion had in the evaluation phase with my mentor Romain Kuntz, which might give you some more information.

I am actually new to SIP Communicator architecture and to the ZRTP standard also. I don't know how or if it would be possible a collaboration to the project (we are both interested in the same thing) due to my GSoC student status. Regarding the fact that you seem quite advanced in the key management problem, I personally will wait for an opinion from my mentor Romain Kuntz in this matter.

Regards,
E. Onica

All,

I would like to make a proposal to enhance SIP Communicator to use
Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
exchange keys and crypto configuration data to setup a Secure RTP
(SRTP) session. Last year Bing Su implemented SRTP into the SIP
Comminucator but this implementation is not used because of the
missing features to setup the necessary keys for SRTP.

Currently I'm porting my C++ implementation for ZRTP [2] to Java,
several parts are already done but it is far from being complete :-).
The following picture shows how the integration into SC may look
like. The layout is the same as for the C++ implementation an
proved to be ok:

                        +-------------+
                        > JMF |
                        > RTPConnector>
                        > >
                        +-------------+
                             ^
                             > extends
                             >
+----------------+ +-----+----------+
> SIP Commun. | | | +-----------------+
> instantiates | uses | ZrtpConnector | uses | |
> ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> and provides | | ZrtpCallback | | core |
>ZrtpUserCallback> > > > implementation |
+----------------+ +----------------+ | (ZRtp et al) |
                                               > >
                                               +-----------------+

Here a short explanation:

A complete GNU ZRTP4J implementation consists of two parts, the GNU
ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
underlying RTP/SRTP stack, the operating system, and the application:

- The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
operating system and consists of the ZRTP protocol state
engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
GNU ZRTP engine provides methods to setup ZRTP message and to
analyze received ZRTP messages, to compute the crypto data required
for SRTP, and to maintain the required hashes and HMAC.

- The second part of an implementation is specific code that binds
the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
operating system specific services such as timers, etc.

* ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *

ZRTP4J either re-uses or extends Bing Su's SRTP Connector implementation.
The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
this connection to exchangeZRTP data. After ZRTP negotiated the the keys
and created the SRTP it steps out of the data exchange. The ZrtpConnector
also provides additional methods that enable the application to control
ZRTP and the connector accepts a callback class that the connector uses
to report events to the application. In case of SIP Communicator the setup
of the ZrtpConnector will (could) be done in the CallSessionImpl class in
the same way as Bing Su implmented it for SRTP. The SIP Communicator
specific ZrtpConnector would be part of the SC source code. My
proposal is to place it parallel to Bing Su's SRTP connector code.

* GNU ZRTP4J *

This is the ZRTP implmentation for Java. It's an own library (jar)
that is independent of the (S)RTP protocol implmentation. The
ZrtpConnector uses the libary to perform the ZRTP specific tasks and
the ZRTP4J core uses the connector to send/receive data, create the
SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
is an own library (jar). As its name suggests GNU ZRTP4J will be
available under GPL.

* SC specific question and requirements *

To be able to efficiently use ZRTP it is strongly recommened to have a
user interface to inform the user about the status of ZRTP and to
provide some commnnds to conrol ZRTP:

- a small icon inside the SC GUI (a padlock?) to show if security is
enabled or not

- attached to this icon a text field (minimum 4 characters) to display
the Short Authentication Code (SAS)

- a button or similar action field that the user may select if he/she
verified the SAS with the other user.

As noted above ZRTP connector uses a callback mechanism to inform the
SC GUI when to display the padlock or to show the SAS and other
information. The ZRTP Connector also provides methods that the SC GUI
can call to inform about SAS verification.

Because my know-how with respect to SC is rather limited I would
appreciate to have a discussion with some "hard-core" SC prgrammer how
and where to provide the hooks for the callback class, also the GUI
designer/implmentor shall have a look at this issue :slight_smile: .

Best regards,
Werner

[1] http://zfoneproject.com/
[2] http://www.gnutelephony.org/index.php/GNU_ZRTP

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

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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


#6

Although S-C doesn't require an intermediary server (it can SIP and
stream media as P2P), Asterisk is a good (de facto industry standard)
SIP server/gateway. But Asterisk's ZRTP support project stalled at the
end of last year, despite some contact with the ZFone project. Anyone in
the S-C community want to take a crack at completing ZRTP support for
Asterisk?

···

On Fri, 2008-05-09 at 18:59 +0200, Werner Dittmann wrote:

actually I know Phil's ZRTP project quite well and I'm in close contact
with Phil. I did many interoperability tests with Zfone code.

The are some differences between Phil's Zfone code and GNU ZRTP:

Zfone is implmented in plain C and is a "bump-in-the-wire" implementation
that requires that both clients use SIP to negotiate the RTP parameters. The
basic ZRTP library of Zfone may be used as a basis for other implementations.
It also contains an own RTP implementation (sort of at least).

GNU ZRTP was designed to by a "native" implementation directly linked to
an application that needs (S)RTP. The overall design was done in a way to
enable various RTP implementations to use GNU ZRTP just by adding the
glue code. Thus the impact to the existing (S)RTP stack is kept to a
minumium. Also because it's a "native" implementation you may use GNU ZRTP
even withou any signaling and achieve security, or use other signaling protocols
to negotiate RTP parameters first.

As for the status of the "port": already all packets are implemented in Java
already, some untility classes such as CRC32C, the Base32 (for SAS), the ZID
file implementation are also done. The others are "under construction".

To support testing I also did some RTP stuff that implements RTP data sources,
Push sources, etc. This stuff will serve as test and debug tools to test and
debug the connectors. Interop tests will be done using the C++ (and later the
Zfone) implementation.

Regards,
Werner

Matthew Rubenstein schrieb:
> If you don't already know, you might be interested to look at ZFone
> ( http://zfoneproject.com/ ), the ZRTP project Phil Zimmerman (PGP, etc)
> produces that publishes source code, and just released a new beta last
> month.
>
> On Fri, 2008-05-09 at 12:33 +0300, Onica S. Emanuel wrote:
>> On Fri, 9 May 2008, Werner Dittmann wrote:
>>
>> Hello,
>>
>> I am a student enrolled in the Google Summer of Code 2008 program with a
>> project related to SIP Communicator that regards solving the issue of the
>> key management, in order to make the current SRTP implementation usable.
>>
>> I actually thought on using ZRTP for this also, and following Su Bing's
>> work to use as a reference libzrtpcpp. I am currently in my analysis
>> phase of the project (this week is planned for reading the ZRTP standard
>> in detail), but until now I can say that I've had pretty similar ideas
>> regarding the integration as you did (except actually porting the C++
>> implementation to a Java library, which makes you quite advanced from me
>> at this point).
>>
>> Like I said, I am currently in the phase of the project analysis for
>> this month, and I was planning to start the dev part from June. I have a
>> blog related to the project http://sipcommkeysharing.blogspot.com. I'll
>> post there during this day the discussion had in the evaluation phase with
>> my mentor Romain Kuntz, which might give you some more information.
>>
>> I am actually new to SIP Communicator architecture and to the ZRTP
>> standard also. I don't know how or if it would be possible a collaboration
>> to the project (we are both interested in the same thing) due to my GSoC
>> student status. Regarding the fact that you seem quite advanced in the
>> key management problem, I personally will wait for an opinion from my
>> mentor Romain Kuntz in this matter.
>>
>> Regards,
>> E. Onica
>>
>>> All,
>>>
>>> I would like to make a proposal to enhance SIP Communicator to use
>>> Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
>>> exchange keys and crypto configuration data to setup a Secure RTP
>>> (SRTP) session. Last year Bing Su implemented SRTP into the SIP
>>> Comminucator but this implementation is not used because of the
>>> missing features to setup the necessary keys for SRTP.
>>>
>>> Currently I'm porting my C++ implementation for ZRTP [2] to Java,
>>> several parts are already done but it is far from being complete :-).
>>> The following picture shows how the integration into SC may look
>>> like. The layout is the same as for the C++ implementation an
>>> proved to be ok:
>>>
>>>
>>> +-------------+
>>> > JMF |
>>> > RTPConnector>
>>> > >
>>> +-------------+
>>> ^
>>> > extends
>>> >
>>> +----------------+ +-----+----------+
>>> > SIP Commun. | | | +-----------------+
>>> > instantiates | uses | ZrtpConnector | uses | |
>>> > ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
>>> > and provides | | ZrtpCallback | | core |
>>> >ZrtpUserCallback> > > > implementation |
>>> +----------------+ +----------------+ | (ZRtp et al) |
>>> > >
>>> +-----------------+
>>>
>>> Here a short explanation:
>>>
>>> A complete GNU ZRTP4J implementation consists of two parts, the GNU
>>> ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
>>> underlying RTP/SRTP stack, the operating system, and the application:
>>>
>>> - The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
>>> operating system and consists of the ZRTP protocol state
>>> engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
>>> GNU ZRTP engine provides methods to setup ZRTP message and to
>>> analyze received ZRTP messages, to compute the crypto data required
>>> for SRTP, and to maintain the required hashes and HMAC.
>>>
>>> - The second part of an implementation is specific code that binds
>>> the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
>>> operating system specific services such as timers, etc.
>>>
>>> * ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *
>>>
>>> ZRTP4J either re-uses or extends Bing Su's SRTP Connector implementation.
>>> The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
>>> this connection to exchangeZRTP data. After ZRTP negotiated the the keys
>>> and created the SRTP it steps out of the data exchange. The ZrtpConnector
>>> also provides additional methods that enable the application to control
>>> ZRTP and the connector accepts a callback class that the connector uses
>>> to report events to the application. In case of SIP Communicator the setup
>>> of the ZrtpConnector will (could) be done in the CallSessionImpl class in
>>> the same way as Bing Su implmented it for SRTP. The SIP Communicator
>>> specific ZrtpConnector would be part of the SC source code. My
>>> proposal is to place it parallel to Bing Su's SRTP connector code.
>>>
>>> * GNU ZRTP4J *
>>>
>>> This is the ZRTP implmentation for Java. It's an own library (jar)
>>> that is independent of the (S)RTP protocol implmentation. The
>>> ZrtpConnector uses the libary to perform the ZRTP specific tasks and
>>> the ZRTP4J core uses the connector to send/receive data, create the
>>> SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
>>> is an own library (jar). As its name suggests GNU ZRTP4J will be
>>> available under GPL.
>>>
>>> * SC specific question and requirements *
>>>
>>> To be able to efficiently use ZRTP it is strongly recommened to have a
>>> user interface to inform the user about the status of ZRTP and to
>>> provide some commnnds to conrol ZRTP:
>>>
>>> - a small icon inside the SC GUI (a padlock?) to show if security is
>>> enabled or not
>>>
>>> - attached to this icon a text field (minimum 4 characters) to display
>>> the Short Authentication Code (SAS)
>>>
>>> - a button or similar action field that the user may select if he/she
>>> verified the SAS with the other user.
>>>
>>> As noted above ZRTP connector uses a callback mechanism to inform the
>>> SC GUI when to display the padlock or to show the SAS and other
>>> information. The ZRTP Connector also provides methods that the SC GUI
>>> can call to inform about SAS verification.
>>>
>>> Because my know-how with respect to SC is rather limited I would
>>> appreciate to have a discussion with some "hard-core" SC prgrammer how
>>> and where to provide the hooks for the callback class, also the GUI
>>> designer/implmentor shall have a look at this issue :slight_smile: .
>>>
>>> Best regards,
>>> Werner
>>>
>>> [1] http://zfoneproject.com/
>>> [2] http://www.gnutelephony.org/index.php/GNU_ZRTP
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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

--

(C) Matthew Rubenstein

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


#7

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java specific
optimizations. If all goes well then a "first call" may be possible during
the next week or so.

Thus the base would be available and Emanuel can work on the integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi Werner,

Sorry for this delayed reply and thank you for this great news! As
Emanuel said, ZRTP was our candidate as the key negotiation and exchange
mechanism for SC, and we were planning to use GNU ZRTP as a reference.

You seem to have already a pretty good idea on how to port your code
into a Java library and on how to integrate this in SC, thanks for
sharing your thoughts on that. I think supporting ZRTP in SIP
Communicator is quite a piece of work if we consider the ZRTP library
implementation, the connection with SC's SRTP and the SC GUI part,
definition of unit tests, and interop' tests.

This makes me think that if both Emanuel and you are positive to work
together on that topic, we would be very happy to let Emanuel work with
you as part of his GSoC project. I understand that working together
remotely may not be easy, but as you said in your mail there are
multiple distinct parts to work on, both on the libray side and on the
SC side. This would be really great if we could have a functional and
interoperable ZRTP/SRTP/SC system at the end of the summer :slight_smile:

Let us know what you think about this.
And again, thank you for your interest in SC!

Cheers,
romain

On 2008/05/09, at 11:33, Onica S. Emanuel wrote:

On Fri, 9 May 2008, Werner Dittmann wrote:

Hello,

I am a student enrolled in the Google Summer of Code 2008 program with
a project related to SIP Communicator that regards solving the issue
of the key management, in order to make the current SRTP
implementation usable.

I actually thought on using ZRTP for this also, and following Su
Bing's work to use as a reference libzrtpcpp. I am currently in my
analysis phase of the project (this week is planned for reading the
ZRTP standard in detail), but until now I can say that I've had pretty
similar ideas regarding the integration as you did (except actually
porting the C++ implementation to a Java library, which makes you
quite advanced from me at this point).

Like I said, I am currently in the phase of the project analysis for
this month, and I was planning to start the dev part from June. I have
a blog related to the project http://sipcommkeysharing.blogspot.com.
I'll post there during this day the discussion had in the evaluation
phase with my mentor Romain Kuntz, which might give you some more
information.

I am actually new to SIP Communicator architecture and to the ZRTP
standard also. I don't know how or if it would be possible a
collaboration to the project (we are both interested in the same
thing) due to my GSoC student status. Regarding the fact that you seem
quite advanced in the key management problem, I personally will wait
for an opinion from my mentor Romain Kuntz in this matter.

Regards,
E. Onica

All,

I would like to make a proposal to enhance SIP Communicator to use
Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
exchange keys and crypto configuration data to setup a Secure RTP
(SRTP) session. Last year Bing Su implemented SRTP into the SIP
Comminucator but this implementation is not used because of the
missing features to setup the necessary keys for SRTP.

Currently I'm porting my C++ implementation for ZRTP [2] to Java,
several parts are already done but it is far from being complete :-).
The following picture shows how the integration into SC may look
like. The layout is the same as for the C++ implementation an
proved to be ok:

                        +-------------+
                        > JMF |
                        > RTPConnector>
                        > >
                        +-------------+
                             ^
                             > extends
                             >
+----------------+ +-----+----------+
> SIP Commun. | | | +-----------------+
> instantiates | uses | ZrtpConnector | uses | |
> ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> and provides | | ZrtpCallback | | core |
>ZrtpUserCallback> > > > implementation |
+----------------+ +----------------+ | (ZRtp et al) |
                                               > >
                                               +-----------------+

Here a short explanation:

A complete GNU ZRTP4J implementation consists of two parts, the GNU
ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
underlying RTP/SRTP stack, the operating system, and the application:

- The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
operating system and consists of the ZRTP protocol state
engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
GNU ZRTP engine provides methods to setup ZRTP message and to
analyze received ZRTP messages, to compute the crypto data required
for SRTP, and to maintain the required hashes and HMAC.

- The second part of an implementation is specific code that binds
the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
operating system specific services such as timers, etc.

* ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *

ZRTP4J either re-uses or extends Bing Su's SRTP Connector
implementation.
The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
this connection to exchangeZRTP data. After ZRTP negotiated the the keys
and created the SRTP it steps out of the data exchange. The
ZrtpConnector
also provides additional methods that enable the application to control
ZRTP and the connector accepts a callback class that the connector uses
to report events to the application. In case of SIP Communicator the
setup
of the ZrtpConnector will (could) be done in the CallSessionImpl
class in
the same way as Bing Su implmented it for SRTP. The SIP Communicator
specific ZrtpConnector would be part of the SC source code. My
proposal is to place it parallel to Bing Su's SRTP connector code.

* GNU ZRTP4J *

This is the ZRTP implmentation for Java. It's an own library (jar)
that is independent of the (S)RTP protocol implmentation. The
ZrtpConnector uses the libary to perform the ZRTP specific tasks and
the ZRTP4J core uses the connector to send/receive data, create the
SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
is an own library (jar). As its name suggests GNU ZRTP4J will be
available under GPL.

* SC specific question and requirements *

To be able to efficiently use ZRTP it is strongly recommened to have a
user interface to inform the user about the status of ZRTP and to
provide some commnnds to conrol ZRTP:

- a small icon inside the SC GUI (a padlock?) to show if security is
enabled or not

- attached to this icon a text field (minimum 4 characters) to display
the Short Authentication Code (SAS)

- a button or similar action field that the user may select if he/she
verified the SAS with the other user.

As noted above ZRTP connector uses a callback mechanism to inform the
SC GUI when to display the padlock or to show the SAS and other
information. The ZRTP Connector also provides methods that the SC GUI
can call to inform about SAS verification.

Because my know-how with respect to SC is rather limited I would
appreciate to have a discussion with some "hard-core" SC prgrammer how
and where to provide the hooks for the callback class, also the GUI
designer/implmentor shall have a look at this issue :slight_smile: .

Best regards,
Werner

[1] http://zfoneproject.com/
[2] http://www.gnutelephony.org/index.php/GNU_ZRTP

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

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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


#8

Hello Werner and Romain,

I agree with Werner about the parts I should work on (integration into SC, GUI, configurations) and finally testing. I think/hope this would be ok regarding the GSoC project/students status. The GSoC official schedule was planned for three months (and I made my timeline related to that, Romain knows about this as my mentor). Like I said in the previous mail, Werner seems to be quite advanced from me in the ZRTP integration problem (and I'm refering here also to general experience regarding ZRTP not only to this integration; I'm just a beginner :slight_smile: actually have read the full standard for the first time last week, as specified in the set timeline). So, I really don't know, regarding the advancement Werner made with the library, if this project will still last as long as the GSoC official timeline but like I said in start, I personally think I'll have enough to do for this entire time. The only thing that I'm concerned is that I hope not to slow Werner down, so the separation: me working on the SC integration issues and Werner further on what's left to do on the library seems to be ok from this point of view (= I may take quite longer than him to do what I have to do, but my part depends on his, not his on mine so I hope this is ok).

I'm actually glad to be able to work to someone more experienced than I am, and I hope I won't stress Werner with to many newbie questions related to ZRTP :).

To Werner: Regarding the PBX support needed, I would very much want to help you, but I'm entering the next week into my final Master semester evaluation period (for the last two weeks of May) and I'll probably be quite unavailable (my next week is actually full of exams; I was planning to work on the basic SC integration design between them :slight_smile: ; like stated im my previous mail I was planning to start coding from June because of my exams - which actually fits with the GSoC program official timeline ). After, this period I'll be glad to help you on the library on what is needed.
Anyway, I'm not experienced at all with Asterisk, actually was planning to let the PBX enrollment for the late part of the integration because of this. Regarding the GUI part I suppose it's related to prompting the user to trust or not the PBX, when the Confirm message is received with the E flag set (or is something else ?). Anyway, I made a short list with main GUI related ZRTP interaction I found to be needed, in my last GSoC blog entry ( http://sipcommkeysharing.blogspot.com/ <- here you can find my entire activity status until now, I know it isn't much but all started quite recently for me :slight_smile: ; from my last post you can see how aware I am <or I'm not> of the ZRTP integration issues ). The basic idea was to design a GUI SC plugin which should handle most of the communication aspects between the ZRTP implementation and the application GUI (I'll try to focus on the design for this part if I get the time in the next two weeks).
In the end I'd like to know if you are using BouncyCastle library for the cryptography parts of your implementation, or your own implementation (or something else). Also it would be of very much help for design if you could provide me a JavaDoc of your current library implementation (or the library sources; doesn't matter it's not complete yet) in order to figure out how I'll integrate it in SIP Communicator.

To Romain: Thank you for the modified BouncyCastle library. It works with it. Unfortunately I didn't have yet the time to investigate the differences in depth. Anyway, I made a quick comparison between the logs of the two library versions and it seems that the MediaActivator doesn't start, so the problem at a first sight probably relies on how the bundle (media.jar) is constructed for the two separate versions. If I have time I'll check it thorough (I'm planning to focus more on design in what time I have left until the end of May. Like said above next week I'm entering my final examination period for my Master semester so I won't have many free hours during the next two weeks. After these I'll be able to fully focus on the GSoC project).

Regards,
Emanuel

···

On Wed, 14 May 2008, Werner Dittmann wrote:

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java specific
optimizations. If all goes well then a "first call" may be possible during
the next week or so.

Thus the base would be available and Emanuel can work on the integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

Romain KUNTZ schrieb:

Hi Werner,

Sorry for this delayed reply and thank you for this great news! As
Emanuel said, ZRTP was our candidate as the key negotiation and exchange
mechanism for SC, and we were planning to use GNU ZRTP as a reference.

You seem to have already a pretty good idea on how to port your code
into a Java library and on how to integrate this in SC, thanks for
sharing your thoughts on that. I think supporting ZRTP in SIP
Communicator is quite a piece of work if we consider the ZRTP library
implementation, the connection with SC's SRTP and the SC GUI part,
definition of unit tests, and interop' tests.

This makes me think that if both Emanuel and you are positive to work
together on that topic, we would be very happy to let Emanuel work with
you as part of his GSoC project. I understand that working together
remotely may not be easy, but as you said in your mail there are
multiple distinct parts to work on, both on the libray side and on the
SC side. This would be really great if we could have a functional and
interoperable ZRTP/SRTP/SC system at the end of the summer :slight_smile:

Let us know what you think about this.
And again, thank you for your interest in SC!

Cheers,
romain

On 2008/05/09, at 11:33, Onica S. Emanuel wrote:

On Fri, 9 May 2008, Werner Dittmann wrote:

Hello,

I am a student enrolled in the Google Summer of Code 2008 program with
a project related to SIP Communicator that regards solving the issue
of the key management, in order to make the current SRTP
implementation usable.

I actually thought on using ZRTP for this also, and following Su
Bing's work to use as a reference libzrtpcpp. I am currently in my
analysis phase of the project (this week is planned for reading the
ZRTP standard in detail), but until now I can say that I've had pretty
similar ideas regarding the integration as you did (except actually
porting the C++ implementation to a Java library, which makes you
quite advanced from me at this point).

Like I said, I am currently in the phase of the project analysis for
this month, and I was planning to start the dev part from June. I have
a blog related to the project http://sipcommkeysharing.blogspot.com.
I'll post there during this day the discussion had in the evaluation
phase with my mentor Romain Kuntz, which might give you some more
information.

I am actually new to SIP Communicator architecture and to the ZRTP
standard also. I don't know how or if it would be possible a
collaboration to the project (we are both interested in the same
thing) due to my GSoC student status. Regarding the fact that you seem
quite advanced in the key management problem, I personally will wait
for an opinion from my mentor Romain Kuntz in this matter.

Regards,
E. Onica

All,

I would like to make a proposal to enhance SIP Communicator to use
Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
exchange keys and crypto configuration data to setup a Secure RTP
(SRTP) session. Last year Bing Su implemented SRTP into the SIP
Comminucator but this implementation is not used because of the
missing features to setup the necessary keys for SRTP.

Currently I'm porting my C++ implementation for ZRTP [2] to Java,
several parts are already done but it is far from being complete :-).
The following picture shows how the integration into SC may look
like. The layout is the same as for the C++ implementation an
proved to be ok:

                        +-------------+
                        > JMF |
                        > RTPConnector>
                        > >
                        +-------------+
                             ^
                             > extends
                             >
+----------------+ +-----+----------+
> SIP Commun. | | | +-----------------+
> instantiates | uses | ZrtpConnector | uses | |
> ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> and provides | | ZrtpCallback | | core |
>ZrtpUserCallback> > > > implementation |
+----------------+ +----------------+ | (ZRtp et al) |
                                               > >
                                               +-----------------+

Here a short explanation:

A complete GNU ZRTP4J implementation consists of two parts, the GNU
ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
underlying RTP/SRTP stack, the operating system, and the application:

- The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
operating system and consists of the ZRTP protocol state
engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
GNU ZRTP engine provides methods to setup ZRTP message and to
analyze received ZRTP messages, to compute the crypto data required
for SRTP, and to maintain the required hashes and HMAC.

- The second part of an implementation is specific code that binds
the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
operating system specific services such as timers, etc.

* ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *

ZRTP4J either re-uses or extends Bing Su's SRTP Connector
implementation.
The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
this connection to exchangeZRTP data. After ZRTP negotiated the the keys
and created the SRTP it steps out of the data exchange. The
ZrtpConnector
also provides additional methods that enable the application to control
ZRTP and the connector accepts a callback class that the connector uses
to report events to the application. In case of SIP Communicator the
setup
of the ZrtpConnector will (could) be done in the CallSessionImpl
class in
the same way as Bing Su implmented it for SRTP. The SIP Communicator
specific ZrtpConnector would be part of the SC source code. My
proposal is to place it parallel to Bing Su's SRTP connector code.

* GNU ZRTP4J *

This is the ZRTP implmentation for Java. It's an own library (jar)
that is independent of the (S)RTP protocol implmentation. The
ZrtpConnector uses the libary to perform the ZRTP specific tasks and
the ZRTP4J core uses the connector to send/receive data, create the
SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
is an own library (jar). As its name suggests GNU ZRTP4J will be
available under GPL.

* SC specific question and requirements *

To be able to efficiently use ZRTP it is strongly recommened to have a
user interface to inform the user about the status of ZRTP and to
provide some commnnds to conrol ZRTP:

- a small icon inside the SC GUI (a padlock?) to show if security is
enabled or not

- attached to this icon a text field (minimum 4 characters) to display
the Short Authentication Code (SAS)

- a button or similar action field that the user may select if he/she
verified the SAS with the other user.

As noted above ZRTP connector uses a callback mechanism to inform the
SC GUI when to display the padlock or to show the SAS and other
information. The ZRTP Connector also provides methods that the SC GUI
can call to inform about SAS verification.

Because my know-how with respect to SC is rather limited I would
appreciate to have a discussion with some "hard-core" SC prgrammer how
and where to provide the hooks for the callback class, also the GUI
designer/implmentor shall have a look at this issue :slight_smile: .

Best regards,
Werner

[1] http://zfoneproject.com/
[2] http://www.gnutelephony.org/index.php/GNU_ZRTP

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

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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


#9

Hi,

I agree with Werner about the parts I should work on (integration into SC, GUI, configurations) and finally testing. I think/hope this would be ok regarding the GSoC project/students status. The GSoC official schedule was planned for three months (and I made my timeline related to that, Romain knows about this as my mentor).

Regarding GSoC, we do not have much constraints on how the topic initially assigned to the student could evolve during the summer. Hence, the here topic here is quite large and gather multiple aspects. On my side, I also don't have any problem to slightly move your work from ZRTP-level code to the application/integration level. This also requires much attention, so I don't think you'll get bored this summer :wink:

To Romain: Thank you for the modified BouncyCastle library. It works with it. Unfortunately I didn't have yet the time to investigate the differences in depth. Anyway, I made a quick comparison between the logs of the two library versions and it seems that the MediaActivator doesn't start, so the problem at a first sight probably relies on how the bundle (media.jar) is constructed for the two separate versions.

That's great you could already have a look at it.

If I have time I'll check it thorough (I'm planning to focus more on design in what time I have left until the end of May. Like said above next week I'm entering my final examination period for my Master semester so I won't have many free hours during the next two weeks. After these I'll be able to fully focus on the GSoC project).

For now your final exams are of course more important. Once they are over, come back to us, and I think the best would be to organize a little chat meeting with Werner to further discuss how we could interact together on this topic.

BTW, about your latest post on your blog, you're talking about the interaction with JMF. Note that we plan to use FMJ instead eventually, so if it better provides or handle what you need (I think there are some FMJ expert here to who you may ask your questions), it might be better to depend on FMJ instead.

Good luck for your exams!

Cheers,
romain

···

On 2008/05/15, at 23:33, Onica S. Emanuel wrote:

On Wed, 14 May 2008, Werner Dittmann wrote:

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java specific
optimizations. If all goes well then a "first call" may be possible during
the next week or so.

Thus the base would be available and Emanuel can work on the integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

Romain KUNTZ schrieb:

Hi Werner,

Sorry for this delayed reply and thank you for this great news! As
Emanuel said, ZRTP was our candidate as the key negotiation and exchange
mechanism for SC, and we were planning to use GNU ZRTP as a reference.

You seem to have already a pretty good idea on how to port your code
into a Java library and on how to integrate this in SC, thanks for
sharing your thoughts on that. I think supporting ZRTP in SIP
Communicator is quite a piece of work if we consider the ZRTP library
implementation, the connection with SC's SRTP and the SC GUI part,
definition of unit tests, and interop' tests.

This makes me think that if both Emanuel and you are positive to work
together on that topic, we would be very happy to let Emanuel work with
you as part of his GSoC project. I understand that working together
remotely may not be easy, but as you said in your mail there are
multiple distinct parts to work on, both on the libray side and on the
SC side. This would be really great if we could have a functional and
interoperable ZRTP/SRTP/SC system at the end of the summer :slight_smile:

Let us know what you think about this.
And again, thank you for your interest in SC!

Cheers,
romain

On 2008/05/09, at 11:33, Onica S. Emanuel wrote:

On Fri, 9 May 2008, Werner Dittmann wrote:

Hello,

I am a student enrolled in the Google Summer of Code 2008 program with
a project related to SIP Communicator that regards solving the issue
of the key management, in order to make the current SRTP
implementation usable.

I actually thought on using ZRTP for this also, and following Su
Bing's work to use as a reference libzrtpcpp. I am currently in my
analysis phase of the project (this week is planned for reading the
ZRTP standard in detail), but until now I can say that I've had pretty
similar ideas regarding the integration as you did (except actually
porting the C++ implementation to a Java library, which makes you
quite advanced from me at this point).

Like I said, I am currently in the phase of the project analysis for
this month, and I was planning to start the dev part from June. I have
a blog related to the project http://sipcommkeysharing.blogspot.com.
I'll post there during this day the discussion had in the evaluation
phase with my mentor Romain Kuntz, which might give you some more
information.

I am actually new to SIP Communicator architecture and to the ZRTP
standard also. I don't know how or if it would be possible a
collaboration to the project (we are both interested in the same
thing) due to my GSoC student status. Regarding the fact that you seem
quite advanced in the key management problem, I personally will wait
for an opinion from my mentor Romain Kuntz in this matter.

Regards,
E. Onica

All,

I would like to make a proposal to enhance SIP Communicator to use
Phil Zimmermann's ZRTP [1]. ZRTP is a mechanisms to negotiate and
exchange keys and crypto configuration data to setup a Secure RTP
(SRTP) session. Last year Bing Su implemented SRTP into the SIP
Comminucator but this implementation is not used because of the
missing features to setup the necessary keys for SRTP.

Currently I'm porting my C++ implementation for ZRTP [2] to Java,
several parts are already done but it is far from being complete :-).
The following picture shows how the integration into SC may look
like. The layout is the same as for the C++ implementation an
proved to be ok:

                      +-------------+
                      > JMF |
                      > RTPConnector>
                      > >
                      +-------------+
                           ^
                           > extends
                           >
+----------------+ +-----+----------+
> SIP Commun. | | | +-----------------+
> instantiates | uses | ZrtpConnector | uses > >
> ZrtpConnector +------+ implements +------+ GNU ZRTP4J |
> and provides | | ZrtpCallback | | core |
>ZrtpUserCallback> > > > implementation |
+----------------+ +----------------+ | (ZRtp et al) |
                                             > >
                                             +-----------------+

Here a short explanation:

A complete GNU ZRTP4J implementation consists of two parts, the GNU
ZRTP4J core and specific glue code that binds the GNU ZRTP4J core to the
underlying RTP/SRTP stack, the operating system, and the application:

- The GNU ZRT4JP core is independent of a specific RTP/SRTP stack and
operating system and consists of the ZRTP protocol state
engine, the ZRTP protocol messages, and the GNU ZRTP engine. The
GNU ZRTP engine provides methods to setup ZRTP message and to
analyze received ZRTP messages, to compute the crypto data required
for SRTP, and to maintain the required hashes and HMAC.

- The second part of an implementation is specific code that binds
the GNU ZRTP4J core to the actual RTP/SRTP implementation and other
operating system specific services such as timers, etc.

* ZrtpConnector - the glue between ZRTP4J core and JMF RTP / SC *

ZRTP4J either re-uses or extends Bing Su's SRTP Connector
implementation.
The ZrtpConnector hooks into the RTP/SRTP data stream to be able to use
this connection to exchangeZRTP data. After ZRTP negotiated the the keys
and created the SRTP it steps out of the data exchange. The
ZrtpConnector
also provides additional methods that enable the application to control
ZRTP and the connector accepts a callback class that the connector uses
to report events to the application. In case of SIP Communicator the
setup
of the ZrtpConnector will (could) be done in the CallSessionImpl
class in
the same way as Bing Su implmented it for SRTP. The SIP Communicator
specific ZrtpConnector would be part of the SC source code. My
proposal is to place it parallel to Bing Su's SRTP connector code.

* GNU ZRTP4J *

This is the ZRTP implmentation for Java. It's an own library (jar)
that is independent of the (S)RTP protocol implmentation. The
ZrtpConnector uses the libary to perform the ZRTP specific tasks and
the ZRTP4J core uses the connector to send/receive data, create the
SRTP crypto contexts, etc. GNU ZRTP4J is not part of the SC source but
is an own library (jar). As its name suggests GNU ZRTP4J will be
available under GPL.

* SC specific question and requirements *

To be able to efficiently use ZRTP it is strongly recommened to have a
user interface to inform the user about the status of ZRTP and to
provide some commnnds to conrol ZRTP:

- a small icon inside the SC GUI (a padlock?) to show if security is
enabled or not

- attached to this icon a text field (minimum 4 characters) to display
the Short Authentication Code (SAS)

- a button or similar action field that the user may select if he/she
verified the SAS with the other user.

As noted above ZRTP connector uses a callback mechanism to inform the
SC GUI when to display the padlock or to show the SAS and other
information. The ZRTP Connector also provides methods that the SC GUI
can call to inform about SAS verification.

Because my know-how with respect to SC is rather limited I would
appreciate to have a discussion with some "hard-core" SC prgrammer how
and where to provide the hooks for the callback class, also the GUI
designer/implmentor shall have a look at this issue :slight_smile: .

Best regards,
Werner

[1] http://zfoneproject.com/
[2] http://www.gnutelephony.org/index.php/GNU_ZRTP

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

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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


#10

Just a short info:

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Romain, just a short question (before I dig into Google): whar are
the differences between JMF and FMJ (in terms of connectors and
other low-layer socket implementation)?

Regards,
Werner

Romain KUNTZ schrieb:

Hi,

I agree with Werner about the parts I should work on (integration into
SC, GUI, configurations) and finally testing. I think/hope this would
be ok regarding the GSoC project/students status. The GSoC official
schedule was planned for three months (and I made my timeline related
to that, Romain knows about this as my mentor).

Regarding GSoC, we do not have much constraints on how the topic
initially assigned to the student could evolve during the summer. Hence,
the here topic here is quite large and gather multiple aspects. On my
side, I also don't have any problem to slightly move your work from
ZRTP-level code to the application/integration level. This also requires
much attention, so I don't think you'll get bored this summer :wink:

To Romain: Thank you for the modified BouncyCastle library. It works
with it. Unfortunately I didn't have yet the time to investigate the
differences in depth. Anyway, I made a quick comparison between the
logs of the two library versions and it seems that the MediaActivator
doesn't start, so the problem at a first sight probably relies on how
the bundle (media.jar) is constructed for the two separate versions.

That's great you could already have a look at it.

If I have time I'll check it thorough (I'm planning to focus more on
design in what time I have left until the end of May. Like said above
next week I'm entering my final examination period for my Master
semester so I won't have many free hours during the next two weeks.
After these I'll be able to fully focus on the GSoC project).

For now your final exams are of course more important. Once they are
over, come back to us, and I think the best would be to organize a
little chat meeting with Werner to further discuss how we could interact
together on this topic.

BTW, about your latest post on your blog, you're talking about the
interaction with JMF. Note that we plan to use FMJ instead eventually,
so if it better provides or handle what you need (I think there are some
FMJ expert here to who you may ask your questions), it might be better
to depend on FMJ instead.

Good luck for your exams!

Cheers,
romain

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java specific
optimizations. If all goes well then a "first call" may be possible
during
the next week or so.

Thus the base would be available and Emanuel can work on the integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also
requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

< snip ---- snap >

···

On 2008/05/15, at 23:33, Onica S. Emanuel wrote:

On Wed, 14 May 2008, Werner Dittmann wrote:

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


#11

JMF and FMJ use the same public API for RTP. So they should be interchangeable.

However, I don't see exactly how the SRTP implementation is hooked into SC, so I can't say for sure whether it is being hooked in in an FMJ-compatible manner.

If anyone has any details on how SRTP is hooked in, that would be useful to me in answering this.

Ken Larson
FMJ project.

Werner Dittmann wrote:

···

Just a short info:

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Romain, just a short question (before I dig into Google): whar are
the differences between JMF and FMJ (in terms of connectors and
other low-layer socket implementation)?

Regards,
Werner

Romain KUNTZ schrieb:
  

Hi,

On 2008/05/15, at 23:33, Onica S. Emanuel wrote:
    

I agree with Werner about the parts I should work on (integration into
SC, GUI, configurations) and finally testing. I think/hope this would
be ok regarding the GSoC project/students status. The GSoC official
schedule was planned for three months (and I made my timeline related
to that, Romain knows about this as my mentor).
      

Regarding GSoC, we do not have much constraints on how the topic
initially assigned to the student could evolve during the summer. Hence,
the here topic here is quite large and gather multiple aspects. On my
side, I also don't have any problem to slightly move your work from
ZRTP-level code to the application/integration level. This also requires
much attention, so I don't think you'll get bored this summer :wink:

To Romain: Thank you for the modified BouncyCastle library. It works
with it. Unfortunately I didn't have yet the time to investigate the
differences in depth. Anyway, I made a quick comparison between the
logs of the two library versions and it seems that the MediaActivator
doesn't start, so the problem at a first sight probably relies on how
the bundle (media.jar) is constructed for the two separate versions.
      

That's great you could already have a look at it.

If I have time I'll check it thorough (I'm planning to focus more on
design in what time I have left until the end of May. Like said above
next week I'm entering my final examination period for my Master
semester so I won't have many free hours during the next two weeks.
After these I'll be able to fully focus on the GSoC project).
      

For now your final exams are of course more important. Once they are
over, come back to us, and I think the best would be to organize a
little chat meeting with Werner to further discuss how we could interact
together on this topic.

BTW, about your latest post on your blog, you're talking about the
interaction with JMF. Note that we plan to use FMJ instead eventually,
so if it better provides or handle what you need (I think there are some
FMJ expert here to who you may ask your questions), it might be better
to depend on FMJ instead.

Good luck for your exams!

Cheers,
romain

On Wed, 14 May 2008, Werner Dittmann wrote:

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java specific
optimizations. If all goes well then a "first call" may be possible
during
the next week or so.

Thus the base would be available and Emanuel can work on the integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also
requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

< 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


#12

OK, now I see where the hook is, the SRTP code takes advantage of JMF's (and FMJ's)

RTPSessionMgr.initialize(RTPConnector connector)

This appears to be implemented in FMJ, and is API-compatible with JMF. I have not tested it myself, though.

I have gotten SC to use FMJ, however, see my previous post with a patch

···

on the subject. Ken Werner Dittmann wrote:

Just a short info:

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Romain, just a short question (before I dig into Google): whar are
the differences between JMF and FMJ (in terms of connectors and
other low-layer socket implementation)?

Regards,
Werner

Romain KUNTZ schrieb:
  

Hi,

On 2008/05/15, at 23:33, Onica S. Emanuel wrote:
    

I agree with Werner about the parts I should work on (integration into
SC, GUI, configurations) and finally testing. I think/hope this would
be ok regarding the GSoC project/students status. The GSoC official
schedule was planned for three months (and I made my timeline related
to that, Romain knows about this as my mentor).
      

Regarding GSoC, we do not have much constraints on how the topic
initially assigned to the student could evolve during the summer. Hence,
the here topic here is quite large and gather multiple aspects. On my
side, I also don't have any problem to slightly move your work from
ZRTP-level code to the application/integration level. This also requires
much attention, so I don't think you'll get bored this summer :wink:

To Romain: Thank you for the modified BouncyCastle library. It works
with it. Unfortunately I didn't have yet the time to investigate the
differences in depth. Anyway, I made a quick comparison between the
logs of the two library versions and it seems that the MediaActivator
doesn't start, so the problem at a first sight probably relies on how
the bundle (media.jar) is constructed for the two separate versions.
      

That's great you could already have a look at it.

If I have time I'll check it thorough (I'm planning to focus more on
design in what time I have left until the end of May. Like said above
next week I'm entering my final examination period for my Master
semester so I won't have many free hours during the next two weeks.
After these I'll be able to fully focus on the GSoC project).
      

For now your final exams are of course more important. Once they are
over, come back to us, and I think the best would be to organize a
little chat meeting with Werner to further discuss how we could interact
together on this topic.

BTW, about your latest post on your blog, you're talking about the
interaction with JMF. Note that we plan to use FMJ instead eventually,
so if it better provides or handle what you need (I think there are some
FMJ expert here to who you may ask your questions), it might be better
to depend on FMJ instead.

Good luck for your exams!

Cheers,
romain

On Wed, 14 May 2008, Werner Dittmann wrote:

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java specific
optimizations. If all goes well then a "first call" may be possible
during
the next week or so.

Thus the base would be available and Emanuel can work on the integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also
requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

< 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


#13

Hi Werner,

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

That's great to hear!

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Don't hesitate to send patches on the ML, I can review and integrate them.

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Ok, I'll let Emanuel contact us again once he'll have finished his exams.

Cheers,
romain

···

On 2008/05/19, at 16:20, Werner Dittmann wrote:

Romain KUNTZ schrieb:

Hi,

On 2008/05/15, at 23:33, Onica S. Emanuel wrote:

I agree with Werner about the parts I should work on (integration into
SC, GUI, configurations) and finally testing. I think/hope this would
be ok regarding the GSoC project/students status. The GSoC official
schedule was planned for three months (and I made my timeline related
to that, Romain knows about this as my mentor).

Regarding GSoC, we do not have much constraints on how the topic
initially assigned to the student could evolve during the summer. Hence,
the here topic here is quite large and gather multiple aspects. On my
side, I also don't have any problem to slightly move your work from
ZRTP-level code to the application/integration level. This also requires
much attention, so I don't think you'll get bored this summer :wink:

To Romain: Thank you for the modified BouncyCastle library. It works
with it. Unfortunately I didn't have yet the time to investigate the
differences in depth. Anyway, I made a quick comparison between the
logs of the two library versions and it seems that the MediaActivator
doesn't start, so the problem at a first sight probably relies on how
the bundle (media.jar) is constructed for the two separate versions.

That's great you could already have a look at it.

If I have time I'll check it thorough (I'm planning to focus more on
design in what time I have left until the end of May. Like said above
next week I'm entering my final examination period for my Master
semester so I won't have many free hours during the next two weeks.
After these I'll be able to fully focus on the GSoC project).

For now your final exams are of course more important. Once they are
over, come back to us, and I think the best would be to organize a
little chat meeting with Werner to further discuss how we could interact
together on this topic.

BTW, about your latest post on your blog, you're talking about the
interaction with JMF. Note that we plan to use FMJ instead eventually,
so if it better provides or handle what you need (I think there are some
FMJ expert here to who you may ask your questions), it might be better
to depend on FMJ instead.

Good luck for your exams!

Cheers,
romain

On Wed, 14 May 2008, Werner Dittmann wrote:

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java specific
optimizations. If all goes well then a "first call" may be possible
during
the next week or so.

Thus the base would be available and Emanuel can work on the integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also
requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

< 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


#14

Ken,

using a small, simple test program that receives data using a RTP connection
I saw that FMJ is _not_ a 1-to-1 replacement to JMF. I'm using the version
daten September 2007, dwonloaded from SourceForge. As a simple example: JMF
sends a "NewReceiveStreamEvent" if it see a new receive stream. FMJ does not
send such an event, not even a "ReceiveStreamEvent". Looking at the communication
using wireshark I see even "bogous IP headers". After a first glance of the
source code FMJ has some problems binding the local address, etc. (not digged
into the problem, just a first impression).

Maybe we can discuss this if SC likes to use FMJ.

Regards,
Werner

Ken Larson schrieb:

···

OK, now I see where the hook is, the SRTP code takes advantage of JMF's
(and FMJ's)

RTPSessionMgr.initialize(RTPConnector connector)

This appears to be implemented in FMJ, and is API-compatible with JMF.
I have not tested it myself, though.

I have gotten SC to use FMJ, however, see my previous post with a patch
on the subject. > > Ken > > Werner Dittmann wrote:

Just a short info:

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Romain, just a short question (before I dig into Google): whar are
the differences between JMF and FMJ (in terms of connectors and
other low-layer socket implementation)?

Regards,
Werner

Romain KUNTZ schrieb:

Hi,

On 2008/05/15, at 23:33, Onica S. Emanuel wrote:
   

I agree with Werner about the parts I should work on (integration into
SC, GUI, configurations) and finally testing. I think/hope this would
be ok regarding the GSoC project/students status. The GSoC official
schedule was planned for three months (and I made my timeline related
to that, Romain knows about this as my mentor).
      

Regarding GSoC, we do not have much constraints on how the topic
initially assigned to the student could evolve during the summer. Hence,
the here topic here is quite large and gather multiple aspects. On my
side, I also don't have any problem to slightly move your work from
ZRTP-level code to the application/integration level. This also requires
much attention, so I don't think you'll get bored this summer :wink:

To Romain: Thank you for the modified BouncyCastle library. It works
with it. Unfortunately I didn't have yet the time to investigate the
differences in depth. Anyway, I made a quick comparison between the
logs of the two library versions and it seems that the MediaActivator
doesn't start, so the problem at a first sight probably relies on how
the bundle (media.jar) is constructed for the two separate versions.
      

That's great you could already have a look at it.

If I have time I'll check it thorough (I'm planning to focus more on
design in what time I have left until the end of May. Like said above
next week I'm entering my final examination period for my Master
semester so I won't have many free hours during the next two weeks.
After these I'll be able to fully focus on the GSoC project).
      

For now your final exams are of course more important. Once they are
over, come back to us, and I think the best would be to organize a
little chat meeting with Werner to further discuss how we could interact
together on this topic.

BTW, about your latest post on your blog, you're talking about the
interaction with JMF. Note that we plan to use FMJ instead eventually,
so if it better provides or handle what you need (I think there are some
FMJ expert here to who you may ask your questions), it might be better
to depend on FMJ instead.

Good luck for your exams!

Cheers,
romain

On Wed, 14 May 2008, Werner Dittmann wrote:

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java
specific
optimizations. If all goes well then a "first call" may be possible
during
the next week or so.

Thus the base would be available and Emanuel can work on the
integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also
requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

< 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


#15

Romain KUNTZ schrieb:

Hi Werner,

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

That's great to hear!

I use standard JMF to do this - see my e-mail about the problems I had
with FMJ.

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Don't hesitate to send patches on the ML, I can review and integrate them.

I prepare a diff - need to "re-port" the changes to the SC code first. I copied
the original code from SC to the ZRTP implementation to create a "ready-to-run"
package even for users that just need ZRTP together with JMF but not SC.

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Ok, I'll let Emanuel contact us again once he'll have finished his exams.

Great, let's cross fingers that all goes well :slight_smile: .

Cheers,
romain

< SNIP ---SNAP >

Regards,
Werner

···

On 2008/05/19, at 16:20, Werner Dittmann wrote:

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


#16

Yes, I remember someone reporting that issue a while back. We have not released a new version of FMJ in a long time, so CVS is quite far ahead of the last "official" release. I'd suggest getting FMJ from CVS and trying that; it may be that that particular issue is already solved.

But any such observations are very useful. Yes, the plan is to use FMJ in SC ultimately, and as FMJ is a work in progress, part of that means we have to identify differences between FMJ and JMF when it comes to functionality that SC relies on.

Ken

Werner Dittmann wrote:

···

Ken,

using a small, simple test program that receives data using a RTP connection
I saw that FMJ is _not_ a 1-to-1 replacement to JMF. I'm using the version
daten September 2007, dwonloaded from SourceForge. As a simple example: JMF
sends a "NewReceiveStreamEvent" if it see a new receive stream. FMJ does not
send such an event, not even a "ReceiveStreamEvent". Looking at the communication
using wireshark I see even "bogous IP headers". After a first glance of the
source code FMJ has some problems binding the local address, etc. (not digged
into the problem, just a first impression).

Maybe we can discuss this if SC likes to use FMJ.

Regards,
Werner

Ken Larson schrieb:
  

OK, now I see where the hook is, the SRTP code takes advantage of JMF's
(and FMJ's)

RTPSessionMgr.initialize(RTPConnector connector)

This appears to be implemented in FMJ, and is API-compatible with JMF. I have not tested it myself, though.

I have gotten SC to use FMJ, however, see my previous post with a patch
on the subject. >> >> Ken >> >> Werner Dittmann wrote:
    

Just a short info:

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Romain, just a short question (before I dig into Google): whar are
the differences between JMF and FMJ (in terms of connectors and
other low-layer socket implementation)?

Regards,
Werner

Romain KUNTZ schrieb:

Hi,

On 2008/05/15, at 23:33, Onica S. Emanuel wrote:
   

I agree with Werner about the parts I should work on (integration into
SC, GUI, configurations) and finally testing. I think/hope this would
be ok regarding the GSoC project/students status. The GSoC official
schedule was planned for three months (and I made my timeline related
to that, Romain knows about this as my mentor).
      

Regarding GSoC, we do not have much constraints on how the topic
initially assigned to the student could evolve during the summer. Hence,
the here topic here is quite large and gather multiple aspects. On my
side, I also don't have any problem to slightly move your work from
ZRTP-level code to the application/integration level. This also requires
much attention, so I don't think you'll get bored this summer :wink:

To Romain: Thank you for the modified BouncyCastle library. It works
with it. Unfortunately I didn't have yet the time to investigate the
differences in depth. Anyway, I made a quick comparison between the
logs of the two library versions and it seems that the MediaActivator
doesn't start, so the problem at a first sight probably relies on how
the bundle (media.jar) is constructed for the two separate versions.
      

That's great you could already have a look at it.

If I have time I'll check it thorough (I'm planning to focus more on
design in what time I have left until the end of May. Like said above
next week I'm entering my final examination period for my Master
semester so I won't have many free hours during the next two weeks.
After these I'll be able to fully focus on the GSoC project).
      

For now your final exams are of course more important. Once they are
over, come back to us, and I think the best would be to organize a
little chat meeting with Werner to further discuss how we could interact
together on this topic.

BTW, about your latest post on your blog, you're talking about the
interaction with JMF. Note that we plan to use FMJ instead eventually,
so if it better provides or handle what you need (I think there are some
FMJ expert here to who you may ask your questions), it might be better
to depend on FMJ instead.

Good luck for your exams!

Cheers,
romain

On Wed, 14 May 2008, Werner Dittmann wrote:

Romain,

thanks for response.

Apparently the port of the C++ lib to Java was easier than expected,
at least for a very first version without making too much Java
specific
optimizations. If all goes well then a "first call" may be possible
during
the next week or so.

Thus the base would be available and Emanuel can work on the
integration
into SC, the GUI, configuration options and alike. Together with
Emanuel we can perform the necessary interop tests.

If Emanual has some time left and likes to work on the ZRTP Java code
I would appreciate some help here to clean up and to bring in some
missing features, for example the Astrisk (PBX) support which also
requires
integration into SC, in particular some GUI enhancements.

Regards,
Werner

< 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


#17

Hello,

Just a quick basic opinion. I knew SC plans to use FMJ (did find out actually seeing a project related to that between this years GSoC projects). So I did take a quick look about three weeks ago on the FMJ API and as far as I remember I didn't see any differences between it and the JMF one (related to the part that concerns the SRTP/ZRTP implementation like RTPConnector or RTPManager <correct me if I'm wrong> - in API terms of course, didn't check deeper). Anyway, if I'm correct FMJ is still in development phase in some parts (don't know exactly which ones), so it may be possible to encounter some problems because of that (maybe the ones Werner described in his mail are related to this issue, and will be solved in the future - just a supposition). I wonder if it won't be ok to stick for the moment on the current JMF implementation, taking into consideration that FMJ intends to be fully compliant with the JMF in API terms, so related to this part it shouldn't be a problem - just an idea. Of course, a more qualified opinion from Ken or other FMJ expert about the low level differences in implementation and the problems Werner encountered should be very useful (again, unfortunately I'm too new to working with these APIs to be able to tell more; anyway, if I find the time I'll try to take another look on them this weekend).

Regards,
Emanuel

PS: About the chat session, should indeed be really ok to have one. I'll mail to agree about the date and place for it probably at the next week's end (around 1st of June), after I'm through with my semester evaluation period.
Until then, if I find the time to advance with the SC work I'll post about it on my blog.

···

On Tue, 20 May 2008, Werner Dittmann wrote:

Romain KUNTZ schrieb:

Hi Werner,

On 2008/05/19, at 16:20, Werner Dittmann wrote:

during the weekend I had a first "ZRTP call" using my test programs (not
with SC of course) and did some interops with the C++ implementation
of ZRTP (similar test programs).

That's great to hear!

I use standard JMF to do this - see my e-mail about the problems I had
with FMJ.

During these tests I also fixed some parts of Bing Su's SRTP code, in
particular the PushDataSoure. The SRTP code now accepts the standard
key length of 128, 192, and 256 bits (was fixed to 128 bits).

Don't hesitate to send patches on the ML, I can review and integrate them.

I prepare a diff - need to "re-port" the changes to the SC code first. I copied
the original code from SC to the ZRTP implementation to create a "ready-to-run"
package even for users that just need ZRTP together with JMF but not SC.

Also I support to have a chat after Emanuel has done his exams
(all A grade of course :slight_smile: ) to sychronize activities. Just give
a notice some days before that we can agree on a date and place.

Ok, I'll let Emanuel contact us again once he'll have finished his exams.

Great, let's cross fingers that all goes well :slight_smile: .

Cheers,
romain

< SNIP ---SNAP >

Regards,
Werner

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

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


#18

Ken,

coming back to the issue: today I downloaded FMJ from CVS and checked
if it works in the same way s JMF with respect to simple RTP. Answer
is NO :slight_smile: . Digging into the problem revealed the cause of this:

Using the standard way to setup and initialize RTPManager is handeled
differently in FMJ. Just a short code snippet to show what I mean.

...
  SessionAddress sa = new SessionAddress(ia, 5002);
  SessionAddress target = new SessionAddress(ia, 5004);
  try {

      mgr = RTPManager.newInstance();

      mgr.initialize(sa);

      mgr.addSessionListener(this);
      mgr.addReceiveStreamListener(this);

      mgr.addTarget(target);
  } catch (Exception e) {
      System.err.println("Cannot create the RTP Session: " + e.getMessage());
  }

...

This is the normal way to setup RTP and add a target. Well, FMJ also opens the
*target port* number on the local system - which is wrong because this is a port
on the *remote system* that may not be available on the local system.
This behaviour may cause spurious problems on the local system. The problem is
located in FMJ's classes RTPSocketAdapter and EncryptedRTPSocket.

FMJ must open the port number of the session address given in initialize(...) only.
The target address is written into the DatagramPacket only and this DatagramPacket
is sent using this open port given during initialize(...).

Hope this finding helps to fix this in FMJ.

Regards,
Werner

PS: when using an own connector, that is initialize is called with an connector
and setting the target at this connector works well - communication was established
(tested with my modifed and bug fixed SRTP connector). This also proves that the
connector implementation of FMJ's RTPSocketAdapter is buggy.

Werner

Ken Larson schrieb:

Yes, I remember someone reporting that issue a while back. We have not released a new version of FMJ in a long time, so CVS is quite far ahead of the last "official" release. I'd suggest getting FMJ from CVS and trying that; it may be that that particular issue is already solved.

But any such observations are very useful. Yes, the plan is to use FMJ in SC ultimately, and as FMJ is a work in progress, part of that means we have to identify differences between FMJ and JMF when it comes to functionality that SC relies on.

Ken

Werner Dittmann wrote:

Ken,

using a small, simple test program that receives data using a RTP connection
I saw that FMJ is _not_ a 1-to-1 replacement to JMF. I'm using the version
daten September 2007, dwonloaded from SourceForge. As a simple example: JMF
sends a "NewReceiveStreamEvent" if it see a new receive stream. FMJ does not
send such an event, not even a "ReceiveStreamEvent". Looking at the communication
using wireshark I see even "bogous IP headers". After a first glance of the
source code FMJ has some problems binding the local address, etc. (not digged
into the problem, just a first impression).

Maybe we can discuss this if SC likes to use FMJ.

Regards,
Werner

Ken Larson schrieb:

OK, now I see where the hook is, the SRTP code takes advantage of JMF's
(and FMJ's)

RTPSessionMgr.initialize(RTPConnector connector)

<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