[sip-comm-dev] ZRTP integration revision and few changes


#1

Hello,

I took some time this week to review the ZRTP integration in almost all its aspects.

This mail was meant to be shorter, but finally it got (again..) longer than I thought it will gonna be, so I'll add a summarry of the main ideas in the start:

I. GUI code restructuring II. Future multistream enhancement issues (and video securing)
III. Patches: ZRTP4J as JAR integration and provisionaly no-registrar IV. Tests summarry
V. Other revision points

--- I ---

About the code itself, even if it isn't very much added in terms of new classes, and besides the GoClear - GoSecure changes, which meant modifications in many parts of ZRTP4J (temporarily disabled), the rest of the code was pretty convoluted at some points. So, I've done another modification regarding to the GUI part, in order to simplify things a bit,
and also provide better means of extension for other possible future security solutions. More exactly, I've refactored the ZRTPGUI plugin under the name of SecurityGUI and I've moved all the button related ZRTP actions inside the SCCallback (ZRTP user callback class - in the media.transform.zrtp package). The movement was pretty logical; that class was already handling the changes on the label. Due to this change, the current architecture leaves the former ZRTPGUI plugin (now SecurityGUI) as a simple container for GUI items. These GUI items (now only for ZRTP) can be obtained and used by future various security solutions' GUI handling classes (like SCCallback now for ZRTP). Actually this was the idea from the first place - because of this, being designed also the general security change event, handled in CallSessionImpl, before ZRTP is selected as the default securing algorithm. In conclusion the effect of this GUI code restructuring (which actually isn't pretty much because the only element affected is the secure button) can be resumed for now as:

- as long the secure button is in initial state (command) of "startSecureMode", it has the role of a "general" toggle on/off security button and it's basic send secure change event action is handled in the SecurityGUI plugin;

- in case there is a call session active, setting the security on makes the button being "caught" in the SCCallback class, and after the ZRTP engine initiliazes, to "become" a ZRTP specific security button; this means that the ActionListener for the button is temporarilly set as being the SCCallback and the button will act by switching between ZRTP specific commands until the call is over; then it will go back to the "startSecureMode" command and the status of a general security button

(All this design is in particular very useful, probably among others, for the GoClear part in case will be re-enabled, because the button needs more commands there). I hope, it's clear enough because it's already too much talk about a single (yet complicated...) button :), so I'll get on to the next subject.

--- II ---

I've temporarily disabled also the security for the video RTP manager, like I actually was thinking at some point in the previous mail. This is based mainly on the fact that ZRTP4J doesn't support yet multistream mode, and the way this integration part was implemented until now could cause some unexpected results in case of simultaneous video securing (may probably work, as it is, with some more flags eventually added to the GUI part, but this doesn't comply with the standard which implies using multistream).
The disabling is done in CallSessionImpl and can be re-enabled by removing the comments which are pointed out at specific places by "Video securing related code" text.

I actually gave some thought about the multistream extension this week, and some basic opinions about the integration would be:

- The ZRTPTransformEngine variable used at ZRTPConnector creation in the TransformManager class should be a static variable, instantiated once and passed to all connectors (audio and video - one multistream engine for all streams)
- The SCCallback (ZRTP user callback class) should follow the same idea as one static variable in the TransformManager class
- The ZRTPTransformEngine should have an addConnector method instead an setConnector one and manage an array of connectors (one connector per stream)

This is the "binding"/integration part, between ZRTP4J and SC. Further, the connector array management should probably start to relate closely to the standard.
I personally intend to continue also after GSoC, when time permits, like I said in the previous mail, to further focus on the ZRTP integration enhancement, and I think multistream is the next part I'll consider in more detail.

--- III ---

One other thing I've done this week was to build SC with ZRTP4J included as a JAR. The ZRTP4J JAR was built from the ZRTP4J sources I've worked on, these containing also the (disabled) modifications for GoClear-GoSecure. In order to reduce the JAR's size I've removed the test package, which isn't used anyway in the integration. I didn't commit yet this build version to the encryption branch. For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).
However, for commiting the GSOC changes into the the main trunk, it might be better to use the JAR version. I've added to this mail a patch which applies to the current encryption branch transforming it into the JAR build version.

The other patch added to this mail as attachment is another update of the provisional no-registrar patch for the current encryption branch, which has the same problems as it did until now, but it also includes a minor fix for the account registration wizard part added to the initial Michael Koch's version. (Related to this patch also, I'll try to add an entry about the problems described a few weeks ago on the issue tracker soon)

--- IV ---

I've tried this weekend to redo some of the tests previously done to have a final GSOC situation. I gathered the ( all successfull :slight_smile: ) results in a Google spreadsheet at the address: http://spreadsheets.google.com/pub?key=pISWJIBcSpdFFBkkNNKpvCQ
(it's my first Google spreadsheet so please don't be too critic on how it looks). I've added also some previous older tests I didn't do anymore, including also the one done by Werner with Minisip/Zfone (hope I got the basic data accurately). Since Free World Dialup seems to switch on fee-based status soon, I've searched for another free SIP provider service. The first one I've found was Free IP Call ( www.freeipcall.com ... if I remember correctly ) and the secure call test was successfully.

--- V ---

Other things done as a final GSoC revision for ZRTP4J integration:

- added resource support for all (hope I didn't missed any...) hard-coded strings used for tooltips, label, etc; I've translated these in Romanian also (unfortunately my German is pretty bad :slight_smile: and the other languages are more or less unknown to me, so somebody else should handle this in case of a merge with the main trunk);
- done some more error handling and other fixes;
- added a few logger entries and some more comments;

Well, this is pretty much all about the final GSoC revision done this week. However, despite the "final GSoC" above, like I said, when I'll find some free time I'll try to continue the development for the multistream enhancement.
If there are any unclear points or other issues to be discussed about anything in this mail, please let me know.

This being said, because is the final GSoC week (but most probably not the final ZRTP4J-integration-related-way-too-long mail I'll send to the SC dev list :slight_smile: ), I'd like to add many many thanks to Werner, Romain, Emil, Michael, and all the other SC dev team members, for support, guidance and providing a very useful learning experience in what I'm concerned throughout all the GSoC period.

Kind regards,
Emanuel

ZRTP4J-jar-integration.patch (348 KB)

no-registrar-updated-for-final-gsoc-encryption-branch.patch (228 KB)

···

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

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


#2

Emanuel,

great news - thanks alot :slight_smile: .

Regarding multi-stream - I'm currently working on the issue to implement
the multi-stream functions into the state engine, the ZRtp main class.

The interfaces to the "application", in this case the SC classes are already
defined and implemented. As you know multi-stream depens on the data that
a previous DH session computed. Thus the flow how to use multi-stream would
be something like that:

- create a first sessions, probably an Audio session using the standard
   way, this session mus be up and running before one can create a second
   session, for example video. All key material must be available

- to create a second session first get a new ZRTP connector. Get the
   "multi-stream" data from the existing session (the one set-uo using
   DH mode

- use this data and set it into the second, newly created ZRTP connector.
   This automatically enables the multi-stream mode for this ZRTP connector
   and it will negotiate the proper way.

- otherwise the sessions are independent, you can close the second session
   independent of the DH session, you may even close the DH session and leave
   the second session. However, in the later case you can't create another
   multi-stream any more because the necessary key data is gone.

- you may create several "secondary" sessions using the key material from
   the DH session

As said, the interface to get/set the multi-stream data is available, also
and interface to get the status if a session was set-up using multi-stream
or DH mode. The interfaces are stubs mainly, not filled in.

Attached is a PNG file that shows the ZRTP protocol state event diagram
(somewhat simplified) with the multi-stream mode states and transitions.
The multi-stream transitions are currently being implemented - during the
next two weeks or so because next weekend I'm at FrOSCon 2008 to give a
short speech about ZRTP et al.

Regards,
Werner

Onica S. Emanuel schrieb:

···

Hello,

I took some time this week to review the ZRTP integration in almost all its aspects.

This mail was meant to be shorter, but finally it got (again..) longer than I thought it will gonna be, so I'll add a summarry of the main ideas in the start:

I. GUI code restructuring II. Future multistream enhancement issues (and video securing)
III. Patches: ZRTP4J as JAR integration and provisionaly no-registrar IV. Tests summarry
V. Other revision points

--- I ---

About the code itself, even if it isn't very much added in terms of new classes, and besides the GoClear - GoSecure changes, which meant modifications in many parts of ZRTP4J (temporarily disabled), the rest of the code was pretty convoluted at some points. So, I've done another modification regarding to the GUI part, in order to simplify things a bit,
and also provide better means of extension for other possible future security solutions. More exactly, I've refactored the ZRTPGUI plugin under the name of SecurityGUI and I've moved all the button related ZRTP actions inside the SCCallback (ZRTP user callback class - in the media.transform.zrtp package). The movement was pretty logical; that class was already handling the changes on the label. Due to this change, the current architecture leaves the former ZRTPGUI plugin (now SecurityGUI) as a simple container for GUI items. These GUI items (now only for ZRTP) can be obtained and used by future various security solutions' GUI handling classes (like SCCallback now for ZRTP). Actually this was the idea from the first place - because of this, being designed also the general security change event, handled in CallSessionImpl, before ZRTP is selected as the default securing algorithm. In conclusion the effect of this GUI code restructuring (which actually isn't pretty much because the only element affected is the secure button) can be resumed for now as:

- as long the secure button is in initial state (command) of "startSecureMode", it has the role of a "general" toggle on/off security button and it's basic send secure change event action is handled in the SecurityGUI plugin;

- in case there is a call session active, setting the security on makes the button being "caught" in the SCCallback class, and after the ZRTP engine initiliazes, to "become" a ZRTP specific security button; this means that the ActionListener for the button is temporarilly set as being the SCCallback and the button will act by switching between ZRTP specific commands until the call is over; then it will go back to the "startSecureMode" command and the status of a general security button

(All this design is in particular very useful, probably among others, for the GoClear part in case will be re-enabled, because the button needs more commands there). I hope, it's clear enough because it's already too much talk about a single (yet complicated...) button :), so I'll get on to the next subject.

--- II ---

I've temporarily disabled also the security for the video RTP manager, like I actually was thinking at some point in the previous mail. This is based mainly on the fact that ZRTP4J doesn't support yet multistream mode, and the way this integration part was implemented until now could cause some unexpected results in case of simultaneous video securing (may probably work, as it is, with some more flags eventually added to the GUI part, but this doesn't comply with the standard which implies using multistream).
The disabling is done in CallSessionImpl and can be re-enabled by removing the comments which are pointed out at specific places by "Video securing related code" text.

I actually gave some thought about the multistream extension this week, and some basic opinions about the integration would be:

- The ZRTPTransformEngine variable used at ZRTPConnector creation in the TransformManager class should be a static variable, instantiated once and passed to all connectors (audio and video - one multistream engine for all streams)
- The SCCallback (ZRTP user callback class) should follow the same idea as one static variable in the TransformManager class
- The ZRTPTransformEngine should have an addConnector method instead an setConnector one and manage an array of connectors (one connector per stream)

This is the "binding"/integration part, between ZRTP4J and SC. Further, the connector array management should probably start to relate closely to the standard.
I personally intend to continue also after GSoC, when time permits, like I said in the previous mail, to further focus on the ZRTP integration enhancement, and I think multistream is the next part I'll consider in more detail.

--- III ---

One other thing I've done this week was to build SC with ZRTP4J included as a JAR. The ZRTP4J JAR was built from the ZRTP4J sources I've worked on, these containing also the (disabled) modifications for GoClear-GoSecure. In order to reduce the JAR's size I've removed the test package, which isn't used anyway in the integration. I didn't commit yet this build version to the encryption branch. For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).
However, for commiting the GSOC changes into the the main trunk, it might be better to use the JAR version. I've added to this mail a patch which applies to the current encryption branch transforming it into the JAR build version.

The other patch added to this mail as attachment is another update of the provisional no-registrar patch for the current encryption branch, which has the same problems as it did until now, but it also includes a minor fix for the account registration wizard part added to the initial Michael Koch's version. (Related to this patch also, I'll try to add an entry about the problems described a few weeks ago on the issue tracker soon)

--- IV ---

I've tried this weekend to redo some of the tests previously done to have a final GSOC situation. I gathered the ( all successfull :slight_smile: ) results in a Google spreadsheet at the address: http://spreadsheets.google.com/pub?key=pISWJIBcSpdFFBkkNNKpvCQ
(it's my first Google spreadsheet so please don't be too critic on how it looks). I've added also some previous older tests I didn't do anymore, including also the one done by Werner with Minisip/Zfone (hope I got the basic data accurately). Since Free World Dialup seems to switch on fee-based status soon, I've searched for another free SIP provider service. The first one I've found was Free IP Call ( www.freeipcall.com ... if I remember correctly ) and the secure call test was successfully.

--- V ---

Other things done as a final GSoC revision for ZRTP4J integration:

- added resource support for all (hope I didn't missed any...) hard-coded strings used for tooltips, label, etc; I've translated these in Romanian also (unfortunately my German is pretty bad :slight_smile: and the other languages are more or less unknown to me, so somebody else should handle this in case of a merge with the main trunk);
- done some more error handling and other fixes;
- added a few logger entries and some more comments;

Well, this is pretty much all about the final GSoC revision done this week. However, despite the "final GSoC" above, like I said, when I'll find some free time I'll try to continue the development for the multistream enhancement.
If there are any unclear points or other issues to be discussed about anything in this mail, please let me know.

This being said, because is the final GSoC week (but most probably not the final ZRTP4J-integration-related-way-too-long mail I'll send to the SC dev list :slight_smile: ), I'd like to add many many thanks to Werner, Romain, Emil, Michael, and all the other SC dev team members, for support, guidance and providing a very useful learning experience in what I'm concerned throughout all the GSoC period.

Kind regards,
Emanuel

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

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


#3

Hi Emanuel, Werner,

Thanks for this report and above all for all the work you achieved this summer. A few comments inline:

--- I ---
--- II ---

When did you perform the last merge with the trunk? If you have some time, would it be possible to perform a last merge, and create a patch between your branch and the main trunk?

Actually, we should prepare a release version of your project, i.e. a tarball which would include this patch (named with the revision number of the main trunk on which it apply) and others few things listed in the rest of the mail.

Note that you'll be able to use this release tarball as the one you'll submit to google too.

--- III ---

One other thing I've done this week was to build SC with ZRTP4J included as a JAR.

That's great, thanks for taking care of that.

The ZRTP4J JAR was built from the ZRTP4J sources I've worked on, these containing also the (disabled) modifications for GoClear-GoSecure. In order to reduce the JAR's size I've removed the test package, which isn't used anyway in the integration. I didn't commit yet this build version to the encryption branch.

Could you also commit the jar to your branch, and include it with your release tarball?

For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).

I'm not really sure yet how I will proceed here.
I think I'll commit the jar version to the main trunk, but for the sources I'd need Werner's advice. Maintaining a source branch separately from Werner's repository may become a tedious task while Werner will update the code on his side. One option would be to keep a patch of the modified ZRTP4J that we can regularly apply to new versions released by Werner. Maintaining a special ZRTP4J branch would also be possible but I wonder in that case if it would not be easier to get this branch hosted by Werner, so that he could easily push his code regularly to the branch. I'm not sure what overhead it would represent though, any opinion on that?

--- IV ---

I've tried this weekend to redo some of the tests previously done to have a final GSOC situation. I gathered the ( all successfull :slight_smile: ) results in a Google spreadsheet at the address: http://spreadsheets.google.com/pub?key=pISWJIBcSpdFFBkkNNKpvCQ

That's a good summary. Could you make a PDF of it and include it in the release?

This being said, because is the final GSoC week (but most probably not the final ZRTP4J-integration-related-way-too-long mail I'll send to the SC dev list :slight_smile: ), I'd like to add many many thanks to Werner, Romain, Emil, Michael, and all the other SC dev team members, for support, guidance and providing a very useful learning experience in what I'm concerned throughout all the GSoC period.

Let me join your greetings, and especially thank Werner for his help and his work on ZRTP4J, which was of a great help for the success of this project.

Cheers,

···

On 2008/08/17, at 16:15, Onica S. Emanuel wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

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


#4

Hello Werner,

Thanks for the very useful informations and for the state diagram sent as feedback.

In my last mail I mentioned that the second connector (and future others) should be initialized with the same ZRTPTransformEngine object (and SCCallback too) in the TransformManager class. So there would be one ZRTPTransformEngine to manage an array of connectors, instead of one, by getting and setting the multistream params. For this, the idea was that I should change the engine and the callback too as static members of the manager. After looking more carefully at the getMultiStrParams and setMultiStrParams you mentioned (I think these are the methods you refered as the interfaces for getting and setting the multistream params), another idea might also be not to set the ZRTPTransformEngine as a single static instance, leave it manage a single connector/stream, and instead set the internal ZRTPTransformEngine variables zrtpEngine and userCallback as single static instances. This is another option to use a single engine and user callback instance for managing multiple connectors. Every one of them would in this case use the same mentioned get and set methods for the multistream params in order to get and set the data obtained from the single instance of the engine and there won't be anymore the need to change the ZRTPTransformEngine to support an array of connectors. However, by using one ZRTPTransformEngine instance per stream might rise other conflicts, so I should analyze both of the options in more detail.

I will have also a pretty busy schedule starting from this Thursday at least for a couple of weeks but I'll try to make some time and think more at the problem meanwhile.

Regards,
Emanuel

···

On Mon, 18 Aug 2008, Werner Dittmann wrote:

Emanuel,

great news - thanks alot :slight_smile: .

Regarding multi-stream - I'm currently working on the issue to implement
the multi-stream functions into the state engine, the ZRtp main class.

The interfaces to the "application", in this case the SC classes are already
defined and implemented. As you know multi-stream depens on the data that
a previous DH session computed. Thus the flow how to use multi-stream would
be something like that:

- create a first sessions, probably an Audio session using the standard
way, this session mus be up and running before one can create a second
session, for example video. All key material must be available

- to create a second session first get a new ZRTP connector. Get the
"multi-stream" data from the existing session (the one set-uo using
DH mode

- use this data and set it into the second, newly created ZRTP connector.
This automatically enables the multi-stream mode for this ZRTP connector
and it will negotiate the proper way.

- otherwise the sessions are independent, you can close the second session
independent of the DH session, you may even close the DH session and leave
the second session. However, in the later case you can't create another
multi-stream any more because the necessary key data is gone.

- you may create several "secondary" sessions using the key material from
the DH session

As said, the interface to get/set the multi-stream data is available, also
and interface to get the status if a session was set-up using multi-stream
or DH mode. The interfaces are stubs mainly, not filled in.

Attached is a PNG file that shows the ZRTP protocol state event diagram
(somewhat simplified) with the multi-stream mode states and transitions.
The multi-stream transitions are currently being implemented - during the
next two weeks or so because next weekend I'm at FrOSCon 2008 to give a
short speech about ZRTP et al.

Regards,
Werner

Onica S. Emanuel schrieb:

Hello,

I took some time this week to review the ZRTP integration in almost all its aspects.

This mail was meant to be shorter, but finally it got (again..) longer than I thought it will gonna be, so I'll add a summarry of the main ideas in the start:

I. GUI code restructuring II. Future multistream enhancement issues (and video securing)
III. Patches: ZRTP4J as JAR integration and provisionaly no-registrar IV. Tests summarry
V. Other revision points

--- I ---

About the code itself, even if it isn't very much added in terms of new classes, and besides the GoClear - GoSecure changes, which meant modifications in many parts of ZRTP4J (temporarily disabled), the rest of the code was pretty convoluted at some points. So, I've done another modification regarding to the GUI part, in order to simplify things a bit,
and also provide better means of extension for other possible future security solutions. More exactly, I've refactored the ZRTPGUI plugin under the name of SecurityGUI and I've moved all the button related ZRTP actions inside the SCCallback (ZRTP user callback class - in the media.transform.zrtp package). The movement was pretty logical; that class was already handling the changes on the label. Due to this change, the current architecture leaves the former ZRTPGUI plugin (now SecurityGUI) as a simple container for GUI items. These GUI items (now only for ZRTP) can be obtained and used by future various security solutions' GUI handling classes (like SCCallback now for ZRTP). Actually this was the idea from the first place - because of this, being designed also the general security change event, handled in CallSessionImpl, before ZRTP is selected as the default securing algorithm. In conclusion the effect of this GUI code restructuring (which actually isn't pretty much because the only element affected is the secure button) can be resumed for now as:

- as long the secure button is in initial state (command) of "startSecureMode", it has the role of a "general" toggle on/off security button and it's basic send secure change event action is handled in the SecurityGUI plugin;

- in case there is a call session active, setting the security on makes the button being "caught" in the SCCallback class, and after the ZRTP engine initiliazes, to "become" a ZRTP specific security button; this means that the ActionListener for the button is temporarilly set as being the SCCallback and the button will act by switching between ZRTP specific commands until the call is over; then it will go back to the "startSecureMode" command and the status of a general security button

(All this design is in particular very useful, probably among others, for the GoClear part in case will be re-enabled, because the button needs more commands there). I hope, it's clear enough because it's already too much talk about a single (yet complicated...) button :), so I'll get on to the next subject.

--- II ---

I've temporarily disabled also the security for the video RTP manager, like I actually was thinking at some point in the previous mail. This is based mainly on the fact that ZRTP4J doesn't support yet multistream mode, and the way this integration part was implemented until now could cause some unexpected results in case of simultaneous video securing (may probably work, as it is, with some more flags eventually added to the GUI part, but this doesn't comply with the standard which implies using multistream).
The disabling is done in CallSessionImpl and can be re-enabled by removing the comments which are pointed out at specific places by "Video securing related code" text.

I actually gave some thought about the multistream extension this week, and some basic opinions about the integration would be:

- The ZRTPTransformEngine variable used at ZRTPConnector creation in the TransformManager class should be a static variable, instantiated once and passed to all connectors (audio and video - one multistream engine for all streams)
- The SCCallback (ZRTP user callback class) should follow the same idea as one static variable in the TransformManager class
- The ZRTPTransformEngine should have an addConnector method instead an setConnector one and manage an array of connectors (one connector per stream)

This is the "binding"/integration part, between ZRTP4J and SC. Further, the connector array management should probably start to relate closely to the standard.
I personally intend to continue also after GSoC, when time permits, like I said in the previous mail, to further focus on the ZRTP integration enhancement, and I think multistream is the next part I'll consider in more detail.

--- III ---

One other thing I've done this week was to build SC with ZRTP4J included as a JAR. The ZRTP4J JAR was built from the ZRTP4J sources I've worked on, these containing also the (disabled) modifications for GoClear-GoSecure. In order to reduce the JAR's size I've removed the test package, which isn't used anyway in the integration. I didn't commit yet this build version to the encryption branch. For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).
However, for commiting the GSOC changes into the the main trunk, it might be better to use the JAR version. I've added to this mail a patch which applies to the current encryption branch transforming it into the JAR build version.

The other patch added to this mail as attachment is another update of the provisional no-registrar patch for the current encryption branch, which has the same problems as it did until now, but it also includes a minor fix for the account registration wizard part added to the initial Michael Koch's version. (Related to this patch also, I'll try to add an entry about the problems described a few weeks ago on the issue tracker soon)

--- IV ---

I've tried this weekend to redo some of the tests previously done to have a final GSOC situation. I gathered the ( all successfull :slight_smile: ) results in a Google spreadsheet at the address: http://spreadsheets.google.com/pub?key=pISWJIBcSpdFFBkkNNKpvCQ
(it's my first Google spreadsheet so please don't be too critic on how it looks). I've added also some previous older tests I didn't do anymore, including also the one done by Werner with Minisip/Zfone (hope I got the basic data accurately). Since Free World Dialup seems to switch on fee-based status soon, I've searched for another free SIP provider service. The first one I've found was Free IP Call ( www.freeipcall.com ... if I remember correctly ) and the secure call test was successfully.

--- V ---

Other things done as a final GSoC revision for ZRTP4J integration:

- added resource support for all (hope I didn't missed any...) hard-coded strings used for tooltips, label, etc; I've translated these in Romanian also (unfortunately my German is pretty bad :slight_smile: and the other languages are more or less unknown to me, so somebody else should handle this in case of a merge with the main trunk);
- done some more error handling and other fixes;
- added a few logger entries and some more comments;

Well, this is pretty much all about the final GSoC revision done this week. However, despite the "final GSoC" above, like I said, when I'll find some free time I'll try to continue the development for the multistream enhancement.
If there are any unclear points or other issues to be discussed about anything in this mail, please let me know.

This being said, because is the final GSoC week (but most probably not the final ZRTP4J-integration-related-way-too-long mail I'll send to the SC dev list :slight_smile: ), I'd like to add many many thanks to Werner, Romain, Emil, Michael, and all the other SC dev team members, for support, guidance and providing a very useful learning experience in what I'm concerned throughout all the GSoC period.

Kind regards,
Emanuel

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

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


#5

Hello Romain,

When did you perform the last merge with the trunk? If you have some time, would it be possible to perform a last merge, and create a patch between your branch and the main trunk?

Actually, we should prepare a release version of your project, i.e. a tarball which would include this patch (named with the revision number of the main trunk on which it apply) and others few things listed in the rest of the mail.

Actually I did the last merge as part of the revision done last week (I forgot to mention this in the mail I've sent). It was against revision 4240 of the main trunk and done last Saturday if I remember correctly. If I should update it please let me know.

I've made the tarball and added it as attachment to this mail. It's contents are:

- ZRTP4J-integration-for-SC-main-trunk-rev-4240.patch

The patch containing the additions done to the SiP Communicator's main trunk for the ZRTP4J integration. This contains ZRTP4J library as a jar, (with the ZRTP4J unpacked sources removed) including the modifications and additions done to it during development.

- ZRTP4J-modifications-for-SC-integration.patch

This is a patch for the ZRTP4J library containing the modifications and enhancements done to it. These are included in the jar prezent in the previous patch and are added only for code reference.

- no-registrar-provisional-for-rev-4240.patch

The no-registrar patch I've added also to the last mail.

- SIP Communicator - ZRTP4J integration tests.pdf

A pdf version of the test results.

- README

A tarball contents description file slightly detailed than the above description.

Could you also commit the jar to your branch, and include it with your release tarball?

I've commited the jar in the lib/installer-exclude folder, along with a bugfix. The jar it's only added to the branch, but the branch is still left to be built based on the unpacked ZRTP4J sources (so it's not like the patch to be commited to the main trunk; the jar is not added to the classpath). If you want me to commit the jar based built version please let me know (this probably means I should delete the unpacked sources in order not to raise any duplicate import conflicts - not very sure about this though)

For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).

I'm not really sure yet how I will proceed here.
I think I'll commit the jar version to the main trunk, but for the sources I'd need Werner's advice. Maintaining a source branch separately from Werner's repository may become a tedious task while Werner will update the code on his side. One option would be to keep a patch of the modified ZRTP4J that we can regularly apply to new versions released by Werner. Maintaining a special ZRTP4J branch would also be possible but I wonder in that case if it would not be easier to get this branch hosted by Werner, so that he could easily push his code regularly to the branch. I'm not sure what overhead it would represent though, any opinion on that?

The jar version is also what I thought it's the option for commiting to the main trunk. For the rest, I think I can handle maintaining a copy of the main trunk using the ZRTP4J sources unpacked myself for eventual future additions and easier debugging, and keeping an updated patch with the changes for ZRTP4J as you said.

Regards,
Emanuel

gsoc-ZRTP4J-SC-integration.tar.gz (511 KB)

···

On Tue, 19 Aug 2008, Romain KUNTZ wrote:

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

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


#6

Emanuel,

thanks for the patches. In you mail you wrote: the jar (I assume
ZRTP4J jar) is included in the patch. Howvere, I cant' locate it
in the *.tar.gz nor in the *.ptach file. Can you check please?

Regards,
Werner

Onica S. Emanuel schrieb:

···

Hello Romain,

On Tue, 19 Aug 2008, Romain KUNTZ wrote:

When did you perform the last merge with the trunk? If you have some time, would it be possible to perform a last merge, and create a patch between your branch and the main trunk?

Actually, we should prepare a release version of your project, i.e. a tarball which would include this patch (named with the revision number of the main trunk on which it apply) and others few things listed in the rest of the mail.

Actually I did the last merge as part of the revision done last week (I forgot to mention this in the mail I've sent). It was against revision 4240 of the main trunk and done last Saturday if I remember correctly. If I should update it please let me know.

I've made the tarball and added it as attachment to this mail. It's contents are:

- ZRTP4J-integration-for-SC-main-trunk-rev-4240.patch

The patch containing the additions done to the SiP Communicator's main trunk for the ZRTP4J integration. This contains ZRTP4J library as a jar, (with the ZRTP4J unpacked sources removed) including the modifications and additions done to it during development.

- ZRTP4J-modifications-for-SC-integration.patch

This is a patch for the ZRTP4J library containing the modifications and enhancements done to it. These are included in the jar prezent in the previous patch and are added only for code reference.

- no-registrar-provisional-for-rev-4240.patch

The no-registrar patch I've added also to the last mail.

- SIP Communicator - ZRTP4J integration tests.pdf

A pdf version of the test results.

- README

A tarball contents description file slightly detailed than the above description.

Could you also commit the jar to your branch, and include it with your release tarball?

I've commited the jar in the lib/installer-exclude folder, along with a bugfix. The jar it's only added to the branch, but the branch is still left to be built based on the unpacked ZRTP4J sources (so it's not like the patch to be commited to the main trunk; the jar is not added to the classpath). If you want me to commit the jar based built version please let me know (this probably means I should delete the unpacked sources in order not to raise any duplicate import conflicts - not very sure about this though)

For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).

I'm not really sure yet how I will proceed here.
I think I'll commit the jar version to the main trunk, but for the sources I'd need Werner's advice. Maintaining a source branch separately from Werner's repository may become a tedious task while Werner will update the code on his side. One option would be to keep a patch of the modified ZRTP4J that we can regularly apply to new versions released by Werner. Maintaining a special ZRTP4J branch would also be possible but I wonder in that case if it would not be easier to get this branch hosted by Werner, so that he could easily push his code regularly to the branch. I'm not sure what overhead it would represent though, any opinion on that?

The jar version is also what I thought it's the option for commiting to the main trunk. For the rest, I think I can handle maintaining a copy of the main trunk using the ZRTP4J sources unpacked myself for eventual future additions and easier debugging, and keeping an updated patch with the changes for ZRTP4J as you said.

Regards,
Emanuel

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

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


#7

Hi Emanuel,

Actually I did the last merge as part of the revision done last week (I forgot to mention this in the mail I've sent). It was against revision 4240 of the main trunk and done last Saturday if I remember correctly. If I should update it please let me know.

Ok I don't think you need to merge it again.

I've made the tarball and added it as attachment to this mail.

Thanks!

The jar version is also what I thought it's the option for commiting to the main trunk. For the rest, I think I can handle maintaining a copy of the main trunk using the ZRTP4J sources unpacked myself for eventual future additions and easier debugging, and keeping an updated patch with the changes for ZRTP4J as you said.

If you're interested in maintaining this part that would be neat. Best would be to integrate it to the main SC trunk. I'll check with Emil how we can handle that.

PS: don't forget to fill in your GSoC final evaluation!

Cheers,

···

On 2008/08/20, at 12:36, Onica S. Emanuel wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

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

thanks for the patches. In you mail you wrote: the jar (I assume
ZRTP4J jar) is included in the patch. Howvere, I cant' locate it
in the *.tar.gz nor in the *.ptach file. Can you check please?

The jar should appear in the lib/installer-exclude directory of SC after applying the ZRTP4J-integration-for-SC-main-trunk-rev-4240.patch to the main trunk (rev 4240). I'm not very experienced with the patch structure, but from the readable contents it looks like it should be there:

Index: D:/workspace/gsocfinal/lib/installer-exclude/zrtp4j-0.9.0.jar

zrtp4j-0.9.0.jar (77.7 KB)

···

===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream

Property changes on: D:\workspace\gsocfinal\lib\installer-exclude\zrtp4j-0.9.0.jar
___________________________________________________________________
Name: svn:mime-type
    + application/octet-stream

However, I'm attaching it also to this mail as a "stand alone" jar, to be able to access it without applying the patch (it is also present in the lib/installer-exclude folder of the encryption branch). Please let me know if you encounter any other problems.

Regards,
Emanuel

Onica S. Emanuel schrieb:

Hello Romain,

On Tue, 19 Aug 2008, Romain KUNTZ wrote:

When did you perform the last merge with the trunk? If you have some time, would it be possible to perform a last merge, and create a patch between your branch and the main trunk?

Actually, we should prepare a release version of your project, i.e. a tarball which would include this patch (named with the revision number of the main trunk on which it apply) and others few things listed in the rest of the mail.

Actually I did the last merge as part of the revision done last week (I forgot to mention this in the mail I've sent). It was against revision 4240 of the main trunk and done last Saturday if I remember correctly. If I should update it please let me know.

I've made the tarball and added it as attachment to this mail. It's contents are:

- ZRTP4J-integration-for-SC-main-trunk-rev-4240.patch

The patch containing the additions done to the SiP Communicator's main trunk for the ZRTP4J integration. This contains ZRTP4J library as a jar, (with the ZRTP4J unpacked sources removed) including the modifications and additions done to it during development.

- ZRTP4J-modifications-for-SC-integration.patch

This is a patch for the ZRTP4J library containing the modifications and enhancements done to it. These are included in the jar prezent in the previous patch and are added only for code reference.

- no-registrar-provisional-for-rev-4240.patch

The no-registrar patch I've added also to the last mail.

- SIP Communicator - ZRTP4J integration tests.pdf

A pdf version of the test results.

- README

A tarball contents description file slightly detailed than the above description.

Could you also commit the jar to your branch, and include it with your release tarball?

I've commited the jar in the lib/installer-exclude folder, along with a bugfix. The jar it's only added to the branch, but the branch is still left to be built based on the unpacked ZRTP4J sources (so it's not like the patch to be commited to the main trunk; the jar is not added to the classpath). If you want me to commit the jar based built version please let me know (this probably means I should delete the unpacked sources in order not to raise any duplicate import conflicts - not very sure about this though)

For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).

I'm not really sure yet how I will proceed here.
I think I'll commit the jar version to the main trunk, but for the sources I'd need Werner's advice. Maintaining a source branch separately from Werner's repository may become a tedious task while Werner will update the code on his side. One option would be to keep a patch of the modified ZRTP4J that we can regularly apply to new versions released by Werner. Maintaining a special ZRTP4J branch would also be possible but I wonder in that case if it would not be easier to get this branch hosted by Werner, so that he could easily push his code regularly to the branch. I'm not sure what overhead it would represent though, any opinion on that?

The jar version is also what I thought it's the option for commiting to the main trunk. For the rest, I think I can handle maintaining a copy of the main trunk using the ZRTP4J sources unpacked myself for eventual future additions and easier debugging, and keeping an updated patch with the changes for ZRTP4J as you said.

Regards,
Emanuel

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

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


#9

Hello Romain,

The jar version is also what I thought it's the option for commiting to the main trunk. For the rest, I think I can handle maintaining a copy of the main trunk using the ZRTP4J sources unpacked myself for eventual future additions and easier debugging, and keeping an updated patch with the changes for ZRTP4J as you said.

If you're interested in maintaining this part that would be neat. Best would be to integrate it to the main SC trunk. I'll check with Emil how we can handle that.

Actually, to be more clear, the bottom line idea was to keep the jar itself, that will be committed to the main trunk, updated through the patch I mentioned and also suggested by you in a previous mail (this patch should apply to Werner's ZRTP4J current svn branch, and any SC main trunk updates regarding ZRTP4J will be done by periodically rebuilding the jar and commiting it). I don't think that integrating the modified unpacked sources along with the jar to the main trunk would be a good idea (it would at least cause confusion having ZRTP4J as jar and as unpacked sources also); but I'm far from being an experienced person in maintaining projects :slight_smile: so this is only a humble opinion.
So, the detailed idea was (even it will be probably more difficult..) that I can try keeping a main trunk working copy built using the unpacked ZRTP4J sources for myself, for easier debugging, and when I'll manage to make some time and work on any additions:

- if there are in the SC part, I'll provide you an SC main trunk patch
- if there are in the ZRTP4J part, I'll separately rebuild the jar and provide you the new version, and also a patch to Werner

Again, this is only an idea, I'm not sure how good it is (like I said I don't have any extensive experience in maintaining online projects), so if you, Werner or Emil have other options it's ok for me.

Regards,
Emanuel

···

On Fri, 22 Aug 2008, Romain KUNTZ wrote:

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

"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

That was the way I had in mind also:

- keep the ZRTP4J jar as own library. This includes the
   packages gnu.java.zrtp* and don't include them into SC
   as sources. This enables use to maintain ZRTP as an
   independent lib und perform updates on a regular basis
   I'll create a "standard" ZRTP4J jar file that contains
   the necessary calsses only, without the test and example
   classes to keep it small.
   Another jar file will contain also the classes that a developer
   may use to connect ZRTP directly to JMF or FMJ without using
   SC.

- Emanuel did a great job in spearating the SC specific stuff
   and keep it in an own package space, here the
   net.java.sip.communicator.impl.media.transform* packages. These
   should live withing the SC source tree because they contain
   SC specific stuff.

Regards,
Werer

Onica S. Emanuel schrieb:

···

Hello Romain,

On Fri, 22 Aug 2008, Romain KUNTZ wrote:

The jar version is also what I thought it's the option for commiting to the main trunk. For the rest, I think I can handle maintaining a copy of the main trunk using the ZRTP4J sources unpacked myself for eventual future additions and easier debugging, and keeping an updated patch with the changes for ZRTP4J as you said.

If you're interested in maintaining this part that would be neat. Best would be to integrate it to the main SC trunk. I'll check with Emil how we can handle that.

Actually, to be more clear, the bottom line idea was to keep the jar itself, that will be committed to the main trunk, updated through the patch I mentioned and also suggested by you in a previous mail (this patch should apply to Werner's ZRTP4J current svn branch, and any SC main trunk updates regarding ZRTP4J will be done by periodically rebuilding the jar and commiting it). I don't think that integrating the modified unpacked sources along with the jar to the main trunk would be a good idea (it would at least cause confusion having ZRTP4J as jar and as unpacked sources also); but I'm far from being an experienced person in maintaining projects :slight_smile: so this is only a humble opinion.
So, the detailed idea was (even it will be probably more difficult..) that I can try keeping a main trunk working copy built using the unpacked ZRTP4J sources for myself, for easier debugging, and when I'll manage to make some time and work on any additions:

- if there are in the SC part, I'll provide you an SC main trunk patch
- if there are in the ZRTP4J part, I'll separately rebuild the jar and provide you the new version, and also a patch to Werner

Again, this is only an idea, I'm not sure how good it is (like I said I don't have any extensive experience in maintaining online projects), so if you, Werner or Emil have other options it's ok for me.

Regards,
Emanuel

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


#11

Hi,

Ok, this sounds like the best way to proceed. I'll take care of including the jar to the main SC trunk when I'll integrate Emanuel's patch.

Cheers,
romain

···

On 2008/08/25, at 9:58, Werner Dittmann wrote:

That was the way I had in mind also:

- keep the ZRTP4J jar as own library. This includes the
packages gnu.java.zrtp* and don't include them into SC
as sources. This enables use to maintain ZRTP as an
independent lib und perform updates on a regular basis
I'll create a "standard" ZRTP4J jar file that contains
the necessary calsses only, without the test and example
classes to keep it small.
Another jar file will contain also the classes that a developer
may use to connect ZRTP directly to JMF or FMJ without using
SC.

- Emanuel did a great job in spearating the SC specific stuff
and keep it in an own package space, here the
net.java.sip.communicator.impl.media.transform* packages. These
should live withing the SC source tree because they contain
SC specific stuff.

Regards,
Werer

Onica S. Emanuel schrieb:

Hello Romain,
On Fri, 22 Aug 2008, Romain KUNTZ wrote:

The jar version is also what I thought it's the option for commiting to the main trunk. For the rest, I think I can handle maintaining a copy of the main trunk using the ZRTP4J sources unpacked myself for eventual future additions and easier debugging, and keeping an updated patch with the changes for ZRTP4J as you said.

If you're interested in maintaining this part that would be neat. Best would be to integrate it to the main SC trunk. I'll check with Emil how we can handle that.

Actually, to be more clear, the bottom line idea was to keep the jar itself, that will be committed to the main trunk, updated through the patch I mentioned and also suggested by you in a previous mail (this patch should apply to Werner's ZRTP4J current svn branch, and any SC main trunk updates regarding ZRTP4J will be done by periodically rebuilding the jar and commiting it). I don't think that integrating the modified unpacked sources along with the jar to the main trunk would be a good idea (it would at least cause confusion having ZRTP4J as jar and as unpacked sources also); but I'm far from being an experienced person in maintaining projects :slight_smile: so this is only a humble opinion.
So, the detailed idea was (even it will be probably more difficult..) that I can try keeping a main trunk working copy built using the unpacked ZRTP4J sources for myself, for easier debugging, and when I'll manage to make some time and work on any additions:
- if there are in the SC part, I'll provide you an SC main trunk patch
- if there are in the ZRTP4J part, I'll separately rebuild the jar and provide you the new version, and also a patch to Werner
Again, this is only an idea, I'm not sure how good it is (like I said I don't have any extensive experience in maintaining online projects), so if you, Werner or Emil have other options it's ok for me.
Regards,
Emanuel

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

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


#12

Hey Emmanuel,

I've been looking through your source code these days. You've done quite
a lot of work! I am looking forward to seeing it all integrated in SC
and trying ZRTP myself. Hope you'll stick around with us and keep it up
to date.

Other than that, about a month or so ago you posted a
no-registrar-support patch based on Michael Koch's contribution from
last year. I've been playing with it lately and started integrating it
in SIP Communicator. Sorry for taking so long. I am very grateful for
your efforts on this one as your work has allowed me to determine all
the elements we need in order to support accounts with no registrar.

Now, Sebastien Mazy is currently working on the implementation of stack
instance sharing (another patch that I need to review ASAP). This would
resolve one of the other problems you uncovered in your previous mails,
involving incoming calls that do not always get to the P2P provider.

However, this would probably require us to handle "no registrar"
accounts a bit differently or otherwise the code in the sip package
would become too convoluted.

We can allow users to to create "no registrar" accounts in a more
transparent way like for example by not entering a server name after
their SIP user id. When instantiated for a serverless account SIP
providers could simply use a different registrar connection class that
would always indicate a connected state without ever sending a single
Register request.

There are a few more details to pin down here but we'll discuss them
when we get there. In the mean time I'd like us to first integrate and
test the stack sharing code.

I have committed a first version of the SipRegistrarlessConnection class
in case you would like to have a look at it. Would you be interested in
completing the "no registrar" functionality using this new approach?
(After we integrate the stack sharing code though.)

Cheers
Emil

Romain KUNTZ написа:

···

Hi,

Ok, this sounds like the best way to proceed. I'll take care of
including the jar to the main SC trunk when I'll integrate Emanuel's
patch.

Cheers,
romain

On 2008/08/25, at 9:58, Werner Dittmann wrote:

That was the way I had in mind also:

- keep the ZRTP4J jar as own library. This includes the
packages gnu.java.zrtp* and don't include them into SC
as sources. This enables use to maintain ZRTP as an
independent lib und perform updates on a regular basis
I'll create a "standard" ZRTP4J jar file that contains
the necessary calsses only, without the test and example
classes to keep it small.
Another jar file will contain also the classes that a developer
may use to connect ZRTP directly to JMF or FMJ without using
SC.

- Emanuel did a great job in spearating the SC specific stuff
and keep it in an own package space, here the
net.java.sip.communicator.impl.media.transform* packages. These
should live withing the SC source tree because they contain
SC specific stuff.

Regards,
Werer

Onica S. Emanuel schrieb:

Hello Romain,
On Fri, 22 Aug 2008, Romain KUNTZ wrote:

The jar version is also what I thought it's the option for
commiting to the main trunk. For the rest, I think I can handle
maintaining a copy of the main trunk using the ZRTP4J sources
unpacked myself for eventual future additions and easier
debugging, and keeping an updated patch with the changes for
ZRTP4J as you said.

If you're interested in maintaining this part that would be neat.
Best would be to integrate it to the main SC trunk. I'll check
with Emil how we can handle that.

Actually, to be more clear, the bottom line idea was to keep the
jar itself, that will be committed to the main trunk, updated
through the patch I mentioned and also suggested by you in a
previous mail (this patch should apply to Werner's ZRTP4J current
svn branch, and any SC main trunk updates regarding ZRTP4J will be
done by periodically rebuilding the jar and commiting it). I don't
think that integrating the modified unpacked sources along with the
jar to the main trunk would be a good idea (it would at least cause
confusion having ZRTP4J as jar and as unpacked sources also); but
I'm far from being an experienced person in maintaining projects :slight_smile:
so this is only a humble opinion.
So, the detailed idea was (even it will be probably more
difficult..) that I can try keeping a main trunk working copy built
using the unpacked ZRTP4J sources for myself, for easier debugging,
and when I'll manage to make some time and work on any additions:
- if there are in the SC part, I'll provide you an SC main trunk
patch
- if there are in the ZRTP4J part, I'll separately rebuild the jar
and provide you the new version, and also a patch to Werner
Again, this is only an idea, I'm not sure how good it is (like I
said I don't have any extensive experience in maintaining online
projects), so if you, Werner or Emil have other options it's ok for
me.
Regards,
Emanuel

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


#13

Hello Emil,

Please check my comments inline.

Hey Emmanuel,

I've been looking through your source code these days. You've done quite
a lot of work! I am looking forward to seeing it all integrated in SC
and trying ZRTP myself. Hope you'll stick around with us and keep it up
to date.

Thank you for your appreciation! Related with keeping up-to-date the ZRTP part, I think I'll try a new merge of the branch this weekend or next week (the last one was done during the last GSoC week).

Other than that, about a month or so ago you posted a
no-registrar-support patch based on Michael Koch's contribution from
last year. I've been playing with it lately and started integrating it
in SIP Communicator. Sorry for taking so long. I am very grateful for
your efforts on this one as your work has allowed me to determine all
the elements we need in order to support accounts with no registrar.

Now, Sebastien Mazy is currently working on the implementation of stack
instance sharing (another patch that I need to review ASAP). This would
resolve one of the other problems you uncovered in your previous mails,
involving incoming calls that do not always get to the P2P provider.

Actually Sebastien suggested around a week ago, after I've posted the no-registar found issues on the issue tracker, to try using his patch in order to solve the mentioned problem. I took some time last weekend to combine his patch (found here: https://sip-communicator.dev.java.net/servlets/ReadMsg?list=dev&msgNo=4310 ) with the latest no-registrar version. After the first tests it seems the problem is indeed solved (though more tests should be done to be certain it's all ok). I'm adding the new patch to this mail (it's nothing more than Sebastien's and the latest no-registrar update put together). The patch was done against revision 4362 of the main trunk (also the revision on which Sebastien's patch is based).

However, this would probably require us to handle "no registrar"
accounts a bit differently or otherwise the code in the sip package
would become too convoluted.

We can allow users to to create "no registrar" accounts in a more
transparent way like for example by not entering a server name after
their SIP user id. When instantiated for a serverless account SIP
providers could simply use a different registrar connection class that
would always indicate a connected state without ever sending a single
Register request.

The older Michael Koch's no-registrar patch, which is still very much the base for the current version, had a somehow similar approach. The different registrar connection class used for no-registrar mode is the ProtocolProviderServiceSipNoRegistrar. This class, in it's register method, simply fires a registration change which indicates that the state is switched to REGISTERED. I'm not very sure this is entirely the same with your suggestion though, but like I said, seems to cover at least a part of it, and remained the same from Michael Koch's earlier patch version to the one that's attached to this mail.
Related to the account registration for SIP no-registrar mode, I've added a GUI part (a checkbox) in the registration wizard through which the user can create no-registrar accounts. I don't think it will be very hard to adapt the existent background programming logic of this part to a more transparent way, as you suggested (= not entering a server name), so I'll check what changes does imply.

There are a few more details to pin down here but we'll discuss them
when we get there. In the mean time I'd like us to first integrate and
test the stack sharing code.

I have committed a first version of the SipRegistrarlessConnection class
in case you would like to have a look at it. Would you be interested in
completing the "no registrar" functionality using this new approach?
(After we integrate the stack sharing code though.)

Unfortunately I was pretty caught up with some other problems (and I still am ..) these days, and I didn't have the time to take a look yet. I'll try to do it this weekend when I'll have some free time.
Meanwhile, if you (or some other developer) can and have the time, you could take a look at the "combined" patch I mentioned attached to this mail, maybe it will prove to be of some use (like I said, needs more testing, but at the first look it seems to solve the wrong provider at destination bug). I must mention again, even if I did also in the last mails on the no-registrar subject, that I'm far from being experienced with SIP as protocol, so a double check from someone with more background in this area on any addition/change I'm doing, it's more than welcome :).

Regards,
Emanuel

single-stack-no-registrar.patch (268 KB)

···

On Sun, 7 Sep 2008, Emil Ivov wrote:

Cheers
Emil

Romain KUNTZ ������������:

Hi,

Ok, this sounds like the best way to proceed. I'll take care of
including the jar to the main SC trunk when I'll integrate Emanuel's
patch.

Cheers,
romain

On 2008/08/25, at 9:58, Werner Dittmann wrote:

That was the way I had in mind also:

- keep the ZRTP4J jar as own library. This includes the
packages gnu.java.zrtp* and don't include them into SC
as sources. This enables use to maintain ZRTP as an
independent lib und perform updates on a regular basis
I'll create a "standard" ZRTP4J jar file that contains
the necessary calsses only, without the test and example
classes to keep it small.
Another jar file will contain also the classes that a developer
may use to connect ZRTP directly to JMF or FMJ without using
SC.

- Emanuel did a great job in spearating the SC specific stuff
and keep it in an own package space, here the
net.java.sip.communicator.impl.media.transform* packages. These
should live withing the SC source tree because they contain
SC specific stuff.

Regards,
Werer

Onica S. Emanuel schrieb:

Hello Romain,
On Fri, 22 Aug 2008, Romain KUNTZ wrote:

The jar version is also what I thought it's the option for
commiting to the main trunk. For the rest, I think I can handle
maintaining a copy of the main trunk using the ZRTP4J sources
unpacked myself for eventual future additions and easier
debugging, and keeping an updated patch with the changes for
ZRTP4J as you said.

If you're interested in maintaining this part that would be neat.
Best would be to integrate it to the main SC trunk. I'll check
with Emil how we can handle that.

Actually, to be more clear, the bottom line idea was to keep the
jar itself, that will be committed to the main trunk, updated
through the patch I mentioned and also suggested by you in a
previous mail (this patch should apply to Werner's ZRTP4J current
svn branch, and any SC main trunk updates regarding ZRTP4J will be
done by periodically rebuilding the jar and commiting it). I don't
think that integrating the modified unpacked sources along with the
jar to the main trunk would be a good idea (it would at least cause
confusion having ZRTP4J as jar and as unpacked sources also); but
I'm far from being an experienced person in maintaining projects :slight_smile:
so this is only a humble opinion.
So, the detailed idea was (even it will be probably more
difficult..) that I can try keeping a main trunk working copy built
using the unpacked ZRTP4J sources for myself, for easier debugging,
and when I'll manage to make some time and work on any additions:
- if there are in the SC part, I'll provide you an SC main trunk
patch
- if there are in the ZRTP4J part, I'll separately rebuild the jar
and provide you the new version, and also a patch to Werner
Again, this is only an idea, I'm not sure how good it is (like I
said I don't have any extensive experience in maintaining online
projects), so if you, Werner or Emil have other options it's ok for
me.
Regards,
Emanuel

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

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


#14

Hi Emanuel,

Just a quick note:

···

On 2008/09/09, at 17:13, Onica S. Emanuel wrote:

Thank you for your appreciation! Related with keeping up-to-date the ZRTP part, I think I'll try a new merge of the branch this weekend or next week (the last one was done during the last GSoC week).

Let me know when it's done and I'll then start integrating your work. It's a great job and it's working fine, so there's no reason to further wait to integrate it in the main tree :slight_smile:

Cheers,
romain


#15

Hi Emanuel,

Sorry for not replying sooner on your mail. First of all thank your for maintaining this patch so far.

We've discussed again the no-registrar feature with Emil recently, and he came up with a design that would reduce the duplicated code between registrar/registrarless accounts.

Michael Koch's and your contribution will nevertheless be of great help when implementing this new design. I wanted to let you know beforehand so you won't be surprised that the implemented feature is not exactly what you have contributed.

Cheers,

···

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

On 2008/09/09, at 17:13, Onica S. Emanuel wrote:

Hello Emil,

Please check my comments inline.

On Sun, 7 Sep 2008, Emil Ivov wrote:

Hey Emmanuel,

I've been looking through your source code these days. You've done quite
a lot of work! I am looking forward to seeing it all integrated in SC
and trying ZRTP myself. Hope you'll stick around with us and keep it up
to date.

Thank you for your appreciation! Related with keeping up-to-date the ZRTP part, I think I'll try a new merge of the branch this weekend or next week (the last one was done during the last GSoC week).

Other than that, about a month or so ago you posted a
no-registrar-support patch based on Michael Koch's contribution from
last year. I've been playing with it lately and started integrating it
in SIP Communicator. Sorry for taking so long. I am very grateful for
your efforts on this one as your work has allowed me to determine all
the elements we need in order to support accounts with no registrar.

Now, Sebastien Mazy is currently working on the implementation of stack
instance sharing (another patch that I need to review ASAP). This would
resolve one of the other problems you uncovered in your previous mails,
involving incoming calls that do not always get to the P2P provider.

Actually Sebastien suggested around a week ago, after I've posted the no-registar found issues on the issue tracker, to try using his patch in order to solve the mentioned problem. I took some time last weekend to combine his patch (found here: https://sip-communicator.dev.java.net/servlets/ReadMsg?list=dev&msgNo=4310 ) with the latest no-registrar version. After the first tests it seems the problem is indeed solved (though more tests should be done to be certain it's all ok). I'm adding the new patch to this mail (it's nothing more than Sebastien's and the latest no-registrar update put together). The patch was done against revision 4362 of the main trunk (also the revision on which Sebastien's patch is based).

However, this would probably require us to handle "no registrar"
accounts a bit differently or otherwise the code in the sip package
would become too convoluted.

We can allow users to to create "no registrar" accounts in a more
transparent way like for example by not entering a server name after
their SIP user id. When instantiated for a serverless account SIP
providers could simply use a different registrar connection class that
would always indicate a connected state without ever sending a single
Register request.

The older Michael Koch's no-registrar patch, which is still very much the base for the current version, had a somehow similar approach. The different registrar connection class used for no-registrar mode is the ProtocolProviderServiceSipNoRegistrar. This class, in it's register method, simply fires a registration change which indicates that the state is switched to REGISTERED. I'm not very sure this is entirely the same with your suggestion though, but like I said, seems to cover at least a part of it, and remained the same from Michael Koch's earlier patch version to the one that's attached to this mail.
Related to the account registration for SIP no-registrar mode, I've added a GUI part (a checkbox) in the registration wizard through which the user can create no-registrar accounts. I don't think it will be very hard to adapt the existent background programming logic of this part to a more transparent way, as you suggested (= not entering a server name), so I'll check what changes does imply.

There are a few more details to pin down here but we'll discuss them
when we get there. In the mean time I'd like us to first integrate and
test the stack sharing code.

I have committed a first version of the SipRegistrarlessConnection class
in case you would like to have a look at it. Would you be interested in
completing the "no registrar" functionality using this new approach?
(After we integrate the stack sharing code though.)

Unfortunately I was pretty caught up with some other problems (and I still am ..) these days, and I didn't have the time to take a look yet. I'll try to do it this weekend when I'll have some free time.
Meanwhile, if you (or some other developer) can and have the time, you could take a look at the "combined" patch I mentioned attached to this mail, maybe it will prove to be of some use (like I said, needs more testing, but at the first look it seems to solve the wrong provider at destination bug). I must mention again, even if I did also in the last mails on the no-registrar subject, that I'm far from being experienced with SIP as protocol, so a double check from someone with more background in this area on any addition/change I'm doing, it's more than welcome :).

Regards,
Emanuel

Cheers
Emil

Romain KUNTZ ÿÿÿÿÿÿÿÿÿÿÿÿ:

Hi,

Ok, this sounds like the best way to proceed. I'll take care of
including the jar to the main SC trunk when I'll integrate Emanuel's
patch.

Cheers,
romain

On 2008/08/25, at 9:58, Werner Dittmann wrote:

That was the way I had in mind also:

- keep the ZRTP4J jar as own library. This includes the
packages gnu.java.zrtp* and don't include them into SC
as sources. This enables use to maintain ZRTP as an
independent lib und perform updates on a regular basis
I'll create a "standard" ZRTP4J jar file that contains
the necessary calsses only, without the test and example
classes to keep it small.
Another jar file will contain also the classes that a developer
may use to connect ZRTP directly to JMF or FMJ without using
SC.

- Emanuel did a great job in spearating the SC specific stuff
and keep it in an own package space, here the
net.java.sip.communicator.impl.media.transform* packages. These
should live withing the SC source tree because they contain
SC specific stuff.

Regards,
Werer

Onica S. Emanuel schrieb:

Hello Romain,
On Fri, 22 Aug 2008, Romain KUNTZ wrote:

The jar version is also what I thought it's the option for
commiting to the main trunk. For the rest, I think I can handle
maintaining a copy of the main trunk using the ZRTP4J sources
unpacked myself for eventual future additions and easier
debugging, and keeping an updated patch with the changes for
ZRTP4J as you said.

If you're interested in maintaining this part that would be neat.
Best would be to integrate it to the main SC trunk. I'll check
with Emil how we can handle that.

Actually, to be more clear, the bottom line idea was to keep the
jar itself, that will be committed to the main trunk, updated
through the patch I mentioned and also suggested by you in a
previous mail (this patch should apply to Werner's ZRTP4J current
svn branch, and any SC main trunk updates regarding ZRTP4J will be
done by periodically rebuilding the jar and commiting it). I don't
think that integrating the modified unpacked sources along with the
jar to the main trunk would be a good idea (it would at least cause
confusion having ZRTP4J as jar and as unpacked sources also); but
I'm far from being an experienced person in maintaining projects :slight_smile:
so this is only a humble opinion.
So, the detailed idea was (even it will be probably more
difficult..) that I can try keeping a main trunk working copy built
using the unpacked ZRTP4J sources for myself, for easier debugging,
and when I'll manage to make some time and work on any additions:
- if there are in the SC part, I'll provide you an SC main trunk
patch
- if there are in the ZRTP4J part, I'll separately rebuild the jar
and provide you the new version, and also a patch to Werner
Again, this is only an idea, I'm not sure how good it is (like I
said I don't have any extensive experience in maintaining online
projects), so if you, Werner or Emil have other options it's ok for
me.
Regards,
Emanuel

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

"Life is full of unexpected but nothing happens without a reason..."<single-stack-no-registrar.patch>---------------------------------------------------------------------
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


#16

Hi Romain, Emanuel,

would be great to have it in the main branch of SC :slight_smile: .

Currently I'm working on the multi-stream feature of ZRTP to be
prepared for audio and video streams in parallel. It's a bit
more complex than I thought but I'm making progress. Multi-stream
is an add on in the ZRTP4J jar mainly - no changes in SC necessary
if only audio is used.

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi Emanuel,

Just a quick note:

On 2008/09/09, at 17:13, Onica S. Emanuel wrote:

Thank you for your appreciation! Related with keeping up-to-date the ZRTP part, I think I'll try a new merge of the branch this weekend or next week (the last one was done during the last GSoC week).

Let me know when it's done and I'll then start integrating your work. It's a great job and it's working fine, so there's no reason to further wait to integrate it in the main tree :slight_smile:

Cheers,
romain

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

Like I said in the last mail, I took some time the past weekend to update (merge) the encryption branch state to the latest main trunk. Due to the latest GUI additions there were more problems than I imagined there will be, so I didn't commit yet the merge but I have attached to this mail the patch done for the main trunk (which might not be final, please read forward).

I'll start with some bugs found in the latest trunk which prevent among other things, the encryption additions to work proper. I've solved these, the solution is included in the attached patch, but the fixes were done pretty much in, let's say so, quick hacking style, so probably there should be re-solved in a more elegant way.

For clarity I'll take the next use case (in which the bugs are present):

- endpoint A calls endpoint B

- for endpoint A: when the call is closed (by any of the both endpoints), all goes fine

- for endpoint B: when the call is closed by endpoint A the code never reaches stopStreaming inside CallSessionImpl class; related to the ZRTP integration this makes that a notification used to bring the integration state back to the initial point, not to be sent anymore; I didn't actually check deeper all the other unwanted results the stopStreaming skip may cause, but among these might be not closing the streams, and not removing the targets from the RTPManager, or in my case the ZRTPConnector. Again, I'm not 100% sure about how critical are these for further calls (it's just a very quick overview of what might happen). However the notification problem is certain, so, in order to quick-fix it I've commented the check in the OperationSetBasicTelephonySipImpl which prevents the stopStreaming call:

// if (dialogIsAlive)
// {
             ((CallSipImpl) callParticipant.getCall()).getMediaCallSession()
                 .stopStreaming();
// }
// else
// {
             callParticipant.setState(CallParticipantState.DISCONNECTED);
// }

Again, I remind what I mentioned in the start, that this is more a quick-hack fix without deeper analysis, but it seems to go on ok (however I'm far from being sure it doesn't cause other problems).

- also for endpoint B: when the call is closed by endpoint B there is a miscast exception thrown which again prevents reaching stopStreaming(); the wrong cast is inside CallManager class in the callEnded method at the line: CallDialog callDialog = (CallDialog) activeCalls.get(sourceCall); the callDialog is in this case actually a ReceivedCallDialog; again I've fixed this with a quick hack by changing the derivation (extension) for ReceivedCallDialog from SIPCommFrame to CallDialog; I know this is for sure not the way to solve the problem but it was the quicker and seems to work (probably another common base class should be defined, or the SIPCommFrame which is already common for both dialogs should be used in the CallManager code instead CallDialog in some places, but I didn't have the time for a deeper analysis). The change done implied defining also a default constructor in CallDialog (which probably isn't really necessary...). I also added a check inside the getCall() method from CallDialog to return null in case the callPanel is null, because I got an exception there too, after fixing the miscast one.

These are the bugs encountered, which for the moment even if I don't know if the solution applied is the best, seem to be solved. However, these represent only half of the problem. The other half is that the ZRTP GUI integration (and consequently also a part from the internal ZRTP integration) was designed for the main SC window/application - meaning also to be active (visible and changeable) also when no call is in progress, to make the secure setting for the next call that will follow. Now, after the GUI changes, it probably will be more appropriate to move the ZRTP activation button in the new separate call window (and fully "bound" the internal logic for ZRTP securing with the CallSessionImpl active instances - meaning probably to drop the static part, which was developed for no calls active case). However this probably will need to rethink some parts, and I'd also like some second opinions about it. You can check for now the attached patch which integrates ZRTP as it was before in the current trunk (activating and deactivating from the main GUI) and give me some feedback if the mentioned modification should be done ( and it probably should :slight_smile: ).

Regards,
Emanuel

PS1: The patch was done against revision 4443 of the main trunk (if I recall correctly...) checked out last Saturday

PS2: I still have quite a busy schedule (the main reason for the quick hack-style fixes :slight_smile: ) but I'll try going on with the dev at least in the weekends when I have some free time

updated-zrtp-integration.patch (204 KB)

···

On Wed, 10 Sep 2008, Romain KUNTZ wrote:

Hi Emanuel,

Just a quick note:

On 2008/09/09, at 17:13, Onica S. Emanuel wrote:

Thank you for your appreciation! Related with keeping up-to-date the ZRTP part, I think I'll try a new merge of the branch this weekend or next week (the last one was done during the last GSoC week).

Let me know when it's done and I'll then start integrating your work. It's a great job and it's working fine, so there's no reason to further wait to integrate it in the main tree :slight_smile:

Cheers,
romain

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


#18

Hello,

Following what I've mentioned in the end part of my last mail, I've adapted the ZRTP4J integration part by switching from the main application GUI control to a per call GUI. This, from the GUI appearance point of view, reflects mainly by the movement of the secure GUI elements (the secure button and the SAS label) from the quick menu into the Call Panel which appears when a call is made by an user or is received. The secure button is now placed after the other buttons (hold, mute, transfer) and the SAS label below the other labels in the panel. This aspect and also functionality change implied the modifications in the sources which I'll describe in this mail.

Until this point the secure button and the SAS label (actually more generally used for secure status) were integrated through a GUI plugin in the QuickMenu of the application. The GUI plugin was designed to reflect a more general approach of the GUI elements contained, meaning that, depending on the securing algorithm used (for now only ZRTP available) the elements contained (for now only the button and secure label) could be used in different ways. Because the CallParticipantPanel, where the secure GUI elements reside now, doesn't implement PluginComponentListener, and also because the other buttons and information labels present here don't require a plugin, I've added directly the GUI elements (meaning the plugin doesn't exist anymore), pretty much in the same manner the other GUI elements inside a ParticipantPanel are added. This implied:

- creating a SecureButton class inside the impl.gui.main.call package
- adding the secure label and also the secure button instances in the CallParticipantPanel class

The secure GUI elements continue to keep their "general" functionality, meaning that, until the selection of a securing algorithm is done (inside the CallSessionImpl class) after toggleing on secure mode, the GUI elements aren't associated with ZRTP. Only after inside the call session ZRTP is selected as securing algorithm the security GUI elements "become" ZRTP GUI elements (used in SCCallback class inside the transform.zrtp package, just as before, by placing ZRTP specific actions to the button and displaying ZRTP specific info through the label). This (also mentioned in earlier development phases) adds some more complexity to the code but keeps it extensible for other secure algorithms, which may use the same GUI elements in their specific ways.

So, the secure GUI elements, are in conclusion, associated now as separate instances (as it should be done earlier probably), with every call it's made. The secure button inits the secure change event triggering inside the CallSessionImpl pretty much the same way the Mute or Hold buttons function also. It gets a telephony basic operation set, and through it gets and sets the secure status for the current call. The getSecured and setSecured functions were consequently moved from the media service interface to the OperationSetBasicTelephony interface (which actually makes more sense in a way in case of further extensions since not all securing algorithms act only at the media stream level; also, following the same idea the SecureEvent class and SecureEventListener were moved from the media.impl package to the service.protocol package - though I'm not totally sure about this). From this point forward, after changing the secure status of the call, the things go on pretty much the same as before inside the CallSessionImpl class. The changes done here are, to explain it shortly, related only to setting the securing status only for the current call session instance and not in a global way as it was done before.

Getting to the actual ZRTP functionality, there weren't any significant changes. All the modifications are inside the GUI related SCCallback. The main change is that, the GUI elements used by the ZRTP user callback aren't obtained as before, because the security GUI plugin doesn't exist anymore. The way that these GUI elements are obtained is based on a function added inside the Call abstract class. I don't know if this is really the best way or best place or even the best solution for the problem, but I didn't have another better idea. The Call abstract class maintains a HashTable of secure GUI elements, which are added in the GUI related classes (in this case CallParticipantPanel) and are used further by any securing algorithms present, depending on the algorithm, like ZRTP's user callback class for now. Practically the simple container role had by the security GUI plugin before, which didn't do more than providing GUI elements for usage to the security algorithms, is taken now by the Call abstract class (it seemed proper to do it here because ZRTP and any other further security algorithms that may need GUI elements are related with the Call, and also the SC architecture permitted using this class in the current case without any additional service imports which could have increased the dependency).

These are (shortly described) the main modifications done. The patch attached in the tarball applies to revision 4466 (middle of last week). The patch also contains the secure button icons and the zrtp4j jar (all inside the paths were should be added). A newer version of the bouncycastlea jar than the one inside the main trunk should be added too (I didn't include it in the mail since it's too big - I'm using bcprov-jdk14-139.jar , this is the one included in the classpath also).

Regarding the bugs mentioned in the previous mail, seems that until revision 4466 they dissapeared (I don't know exactly how and were :slight_smile: ) so I've removed from the patch the modifications done related to the sources that I've described last time.

Regards,
Emanuel

PS: I will probably be pretty difficult to contact since Wednesday until the next week's weekend, but I'll try to check my mails at least one or two times in this interval, so please send any feedback you have (however I'm not totally sure yet about the dates between I'll be "offline").

zrtp-rev4466-integration.tar.gz (115 KB)

···

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

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


#19

Hi Emanuel,

Sorry for not replying sooner to your previous mails, I was out of the office last week.
Long story short, I'll apply your patch this evening, so you'll hopefully be able to use it from the nightly builds from tomorrow!

More comments below:

Following what I've mentioned in the end part of my last mail, I've adapted the ZRTP4J integration part by switching from the main application GUI control to a per call GUI. This, from the GUI appearance point of view, reflects mainly by the movement of the secure GUI elements (the secure button and the SAS label) from the quick menu into the Call Panel which appears when a call is made by an user or is received. The secure button is now placed after the other buttons (hold, mute, transfer) and the SAS label below the other labels in the panel.

That's great, and it's the ideal place to put those buttons!

[snip]

These are (shortly described) the main modifications done.

Thanks for those detailed explanations, it will help me during the integration. I may come back tomorrow with a few comments/changes I have operated to your code.

The patch attached in the tarball applies to revision 4466 (middle of last week). The patch also contains the secure button icons and the zrtp4j jar (all inside the paths were should be added). A newer version of the bouncycastlea jar than the one inside the main trunk should be added too (I didn't include it in the mail since it's too big - I'm using bcprov-jdk14-139.jar , this is the one included in the classpath also).

Ok, I'll take care of adding them to the main trunk.

Regarding the bugs mentioned in the previous mail, seems that until revision 4466 they dissapeared (I don't know exactly how and were :slight_smile: ) so I've removed from the patch the modifications done related to the sources that I've described last time.

Yes, a few commits were done last week to solve the problem you described. Thanks for merging and testing again!

PS: I will probably be pretty difficult to contact since Wednesday until the next week's weekend, but I'll try to check my mails at least one or two times in this interval, so please send any feedback you have (however I'm not totally sure yet about the dates between I'll be "offline").

No problem. I'll probably send you some feedback and questions, but fell free to reply when you'll have time.

Cheers,
romain

···

On 2008/09/22, at 13:03, Onica S. Emanuel wrote:

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


#20

Hi Emanuel.

I've been merging most of your code to the trunk. What a piece of work :slight_smile:
ZRTP is not usable yet though (the button des not appear in the call panel yet), I'd have a few questions first.
Few comments below:

Following what I've mentioned in the end part of my last mail, I've adapted the ZRTP4J integration part by switching from the main application GUI control to a per call GUI. This, from the GUI appearance point of view, reflects mainly by the movement of the secure GUI elements (the secure button and the SAS label) from the quick menu into the Call Panel which appears when a call is made by an user or is received. The secure button is now placed after the other buttons (hold, mute, transfer) and the SAS label below the other labels in the panel.

I did not merge the code from /src/net/java/sip/communicator/impl/gui/main/call/CallParticipantPanel.java yet, which is why it does not appear.
I don't have any problem with this code, I just wanted to avoid people using ZRTP as long as all the code has not been merged.

I had a few compilation errors with the patch you provided: it seems that it did not reflect the latest version of your branch. I took some code from your branch to fix the errors (especially from impl/media/CallSessionImpl.java and impl/media/transform/zrtp/SCCallback.java), but I'm not sure though if I have merged all the differences between the patch you sent me and the current revision of your branch.

Until this point the secure button and the SAS label (actually more generally used for secure status) were integrated through a GUI plugin in the QuickMenu of the application. The GUI plugin was designed to reflect a more general approach of the GUI elements contained, meaning that, depending on the securing algorithm used (for now only ZRTP available) the elements contained (for now only the button and secure label) could be used in different ways. Because the CallParticipantPanel, where the secure GUI elements reside now, doesn't implement PluginComponentListener, and also because the other buttons and information labels present here don't require a plugin, I've added directly the GUI elements (meaning the plugin doesn't exist anymore), pretty much in the same manner the other GUI elements inside a ParticipantPanel are added. This implied:

- creating a SecureButton class inside the impl.gui.main.call package
- adding the secure label and also the secure button instances in the CallParticipantPanel class

I'm fine with this. I don't think a separate plugin for this would be justified.
I'll check with Yana if she is happy with the location of the button and the new dimensions of the window.

These are (shortly described) the main modifications done. The patch attached in the tarball applies to revision 4466 (middle of last week). The patch also contains the secure button icons and the zrtp4j jar (all inside the paths were should be added). A newer version of the bouncycastlea jar than the one inside the main trunk should be added too (I didn't include it in the mail since it's too big - I'm using bcprov-jdk14-139.jar , this is the one included in the classpath also).

FYI I have update bouncycastle to bcprov-jdk14-140.jar in the trunk.

A few more questions/comments about your code:

- in impl/media/MediaActivator.java, you have added a private attribute that is never used, any reason for that?
(around line 35) private static UIService uiService = null;

- At a first glance I don't understand what you do in impl/gui/main/call/ReceivedCallDialog.java and impl/gui/main/call/CallDialog.java:

       public class ReceivedCallDialog
     - extends SIPCommFrame
    + extends CallDialog

- I've seen that you have modified a bit some of the code from Su Bing (SRTP), could you say a few workds about it? (problem with the specifications? improvements?)

- About the convention code, I found a few tabs and corrected a few things that were not matching the coding convention - very little though, compared to the amount of code you produced.

Again, congratulations, and I hope I'll be able to commit & ack the few last things really soon!

Cheers,

···

On 2008/09/22, at 13:03, Onica S. Emanuel wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

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