[sip-comm-dev] Re: [PATCH] Modifications to support latest ZRTP4J version


#1

Hi Werner,

Your proposal sounds fine but it is not straightforward as a least setUserCallback() use an ZrtpUserCallback object as argument, and and getUserCallback() returns an ZrtpUserCallback object. This cause some incompatible types issues at compilation time. Would you mind proposing a patch for this?

Cheers,
romain

···

On 2008/10/20, at 20:51, Werner Dittmann wrote:

Romain, Emanuel,

just as info to you (not to spam the mail list): before you test
with some other ZRTP implementation, for example using Phil's
latest Zfone you need to update SC with the latest ZRTP4J jar
file (see patches I sent on Sunday, 20th). Otherwise the protocol
versions don't match and the test will fail.

This is true for the latest Zfone and twinkle using libzrtpcpp-1.3.1
which both use protocol version 0.90.

During the upgrade to ZRTP4J 1.3.1 I also modified SCCallback to
exclude goClear, also the ZRTPTrannsformEngine to to use the
SCCallback init() function. IMHO it would be even better to do the
following in ZRTPTransformEngine:

at line 272 we see the following code:

   /**
    * User callback class.
    */
   private ZrtpUserCallback userCallback = null;

instead I would use:

   /**
    * User callback class.
    */
   private SCCallback userCallback = null;

and then use it throughout ZRTPTransformEngine. Because SCCallback
implements the ZrtpUserCallback interface there are no problems to do this.

SCCallback can implement additional SC specific functions on top of the
ZrtpUserCallback interface, which defines the minimum functionality for
all users of ZRTP4J. The SC specific ZRTPTransformEngine can use the
SCCallback specific methods and there is no need to modify the generic
ZrtpUserCallback interface.

Then we can change back the following code at line 457:

       if (userCallback instanceof SCCallback) {
           ((SCCallback)userCallback).init();
       }

to just:

  userCallback.init();

The goCLear stuff, if it will be implemented, needs to be looked at because
of the added multi-stream mode. I'll send another e-mail during the
next days to explain how multi-stream works and could be used inside SC.

Regards,
Werner

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


#2

Here a patch to fix this small problem. Because ZRTPTransformEngine
as well as SCCallback are specific to SC they could be used that way.

The patch also includes small code cleanup in SCCallback to remove
hard-coded Sysem.err.println statements (helped during debugging)

Regards,
Werner

Romain KUNTZ schrieb:

patchSCCallback.txt (5.45 KB)

···

Hi Werner,

Your proposal sounds fine but it is not straightforward as a least setUserCallback() use an ZrtpUserCallback object as argument, and and getUserCallback() returns an ZrtpUserCallback object. This cause some incompatible types issues at compilation time. Would you mind proposing a patch for this?

Cheers,
romain

On 2008/10/20, at 20:51, Werner Dittmann wrote:

Romain, Emanuel,

just as info to you (not to spam the mail list): before you test
with some other ZRTP implementation, for example using Phil's
latest Zfone you need to update SC with the latest ZRTP4J jar
file (see patches I sent on Sunday, 20th). Otherwise the protocol
versions don't match and the test will fail.

This is true for the latest Zfone and twinkle using libzrtpcpp-1.3.1
which both use protocol version 0.90.

During the upgrade to ZRTP4J 1.3.1 I also modified SCCallback to
exclude goClear, also the ZRTPTrannsformEngine to to use the
SCCallback init() function. IMHO it would be even better to do the
following in ZRTPTransformEngine:

at line 272 we see the following code:

   /**
    * User callback class.
    */
   private ZrtpUserCallback userCallback = null;

instead I would use:

   /**
    * User callback class.
    */
   private SCCallback userCallback = null;

and then use it throughout ZRTPTransformEngine. Because SCCallback
implements the ZrtpUserCallback interface there are no problems to do this.

SCCallback can implement additional SC specific functions on top of the
ZrtpUserCallback interface, which defines the minimum functionality for
all users of ZRTP4J. The SC specific ZRTPTransformEngine can use the
SCCallback specific methods and there is no need to modify the generic
ZrtpUserCallback interface.

Then we can change back the following code at line 457:

       if (userCallback instanceof SCCallback) {
           ((SCCallback)userCallback).init();
       }

to just:

    userCallback.init();

The goCLear stuff, if it will be implemented, needs to be looked at because
of the added multi-stream mode. I'll send another e-mail during the
next days to explain how multi-stream works and could be used inside SC.

Regards,
Werner

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


#3

Applied, committed and acked.

Thanks!
Emil

Werner Dittmann написа:

···

Here a patch to fix this small problem. Because ZRTPTransformEngine
as well as SCCallback are specific to SC they could be used that way.

The patch also includes small code cleanup in SCCallback to remove
hard-coded Sysem.err.println statements (helped during debugging)

Regards,
Werner

Romain KUNTZ schrieb:

Hi Werner,

Your proposal sounds fine but it is not straightforward as a least
setUserCallback() use an ZrtpUserCallback object as argument, and and
getUserCallback() returns an ZrtpUserCallback object. This cause some
incompatible types issues at compilation time. Would you mind proposing
a patch for this?

Cheers,
romain

On 2008/10/20, at 20:51, Werner Dittmann wrote:

Romain, Emanuel,

just as info to you (not to spam the mail list): before you test
with some other ZRTP implementation, for example using Phil's
latest Zfone you need to update SC with the latest ZRTP4J jar
file (see patches I sent on Sunday, 20th). Otherwise the protocol
versions don't match and the test will fail.

This is true for the latest Zfone and twinkle using libzrtpcpp-1.3.1
which both use protocol version 0.90.

During the upgrade to ZRTP4J 1.3.1 I also modified SCCallback to
exclude goClear, also the ZRTPTrannsformEngine to to use the
SCCallback init() function. IMHO it would be even better to do the
following in ZRTPTransformEngine:

at line 272 we see the following code:

   /**
    * User callback class.
    */
   private ZrtpUserCallback userCallback = null;

instead I would use:

   /**
    * User callback class.
    */
   private SCCallback userCallback = null;

and then use it throughout ZRTPTransformEngine. Because SCCallback
implements the ZrtpUserCallback interface there are no problems to do
this.

SCCallback can implement additional SC specific functions on top of the
ZrtpUserCallback interface, which defines the minimum functionality for
all users of ZRTP4J. The SC specific ZRTPTransformEngine can use the
SCCallback specific methods and there is no need to modify the generic
ZrtpUserCallback interface.

Then we can change back the following code at line 457:

       if (userCallback instanceof SCCallback) {
           ((SCCallback)userCallback).init();
       }

to just:

    userCallback.init();

The goCLear stuff, if it will be implemented, needs to be looked at
because
of the added multi-stream mode. I'll send another e-mail during the
next days to explain how multi-stream works and could be used inside SC.

Regards,
Werner

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

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

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

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