[sip-comm-dev] GoClear - GoSecure ZRTP4J addition


#1

Hello Werner, Romain,

I've finally commited the updated SC code, containing the implementation of the GoClear-GoSecure enhancement for ZRTP4J on which I've been working. I've tried to detail the main additions/modifications and how they are implemented on my dev blog ( http://sipcommkeysharing.blogspot.com/ ) in the entry made this Tuesday. In addition to what is specified there ( hope it's not too long and boring :slight_smile: ), in the last two days I also fixed the GUI part problems mentioned, so the version present now on the SVN encryption branch is pretty much a fully working implementation.

About the GUI part, I pretty much redesigned the way this is handled inside the code, also regarding to what was done until now. For short, in terms of usability, the padlock button works as it did until now for calls which are not going to be unsecured by a GoClear message. This means, every user can start the call secured or unsecured according of how the button is pressed or not, and can secure it afterwards (if the peer did it of course). The GoClear - GoSecure addition makes possible now that the users can switch to unsecured mode after a call is secured and back to secure mode (with respect to the ZRTP specifications of course). In terms of usability, when an user switches to unsecured mode does it also through the same padlock button by unpressing it. This causes the peer's padlock button also to become unpressed when the call is unsecured. Switching back to secure mode is done as expected by pressing the padlock button again. However, the difference in this case is that the peer's button is again automatically toggled on, not needing the peer to do this. So, the use case when an user switches to secure mode and the call is secured later, when the peer toggles the button too, applies only for the first call securing during a session. (Actually I think this is probably the only possible way for implementing this feature. After all it is based on the fact that at the call beginning, the first peer remains in detecting state after switching to secure mode, and the other initializes later the engine. In case of re-securing the call, this is done at this moment, according to the specifications, by directly sending a Commit packet which leads to immediately re-securing the call). To summarize, probably will be more clear when you actually will see it :).

Ok, all this was a presentation related only to how the padlock button works at this moment in terms of usability. The actual implementation behind it, is more complicated (and maybe could be simplified a bit), and is not presented along with the GoClear-GoSecure additions to ZRTP4J on my blog. I won't describe it here because it will take too long. I'll try detailing it in my next blog entry (probably next week). I needed to make some additions to various classes in order to do it, but I tried and finally almost managed not to change any code from the ZRTP4J packages to acomplish it (it is after all the SC GUI part and should not be related too much with ZRTP4J). However I needed to add an init function to the ZrtpUserCallback class which I've called from ZrtpTransformEngine.
I've done many changes on how the GUI was implemented until now, like adding a source (local, remote) parameter for the SecureEvent dispatched to CallSessionImpl, and others. The most important change was, I think, removing the button code from the quick menu, and integrating it along with the label inside the ZRTPGUI plugin (The components are however placed where they were before on the SC interface, but now are both in the same plugin separate from the SC menus GUI code). I think, I've detailed already pretty much for a short overview. I'll try to add next week on my blog, as I said, a description of how GUI works.

At the moment I managed to perform several successful tests by switching off and on the call in various sequences. There are however some points related to ZRTP on which I'm not totally certain, as I described on my blog. Many of them are related with the exception/error handling conditions present in the additions done to the state engine (there are actually probably some crash or unexpected behavior chances, if SC gets in such a situation - like an error or exceeded timer). I didn't had the time yet to reanalyze those points but I'll try to do it this weekend, and make a list with what isn't totally clear.

I didn't tested yet using the no-registrar mode, but I don't think there will be any difference, the changes not being related to that.
To Werner: if you need it, my latest no-registrar patch can be found at http://students.info.uaic.ro/~eonica/sc/no-registrar.patch ; I didn't apply it on this branch version but there are 90% chances, I think, to be compatible with it; if you try to use it and encounter any problems please mail me about it.

The bottom line ( to end this already-another-too-long mail :slight_smile: ), is for now that the GoClear - GoSecure ZRTP enhancement seems to be pretty stable (at least for the tests I've done, hope will be the same after the next).

Regards,
Emanuel

路路路

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

"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


#2

Hi Emmanuel,

so the version present now on the SVN encryption branch is pretty much a fully working implementation.

That's a great news! This project was not easy to handle and you have taken it very seriously, your commitment is really much appreciated.

About the GUI part, I pretty much redesigned the way this is handled inside the code, also regarding to what was done until now. For short, in terms of usability, the padlock button works as it did until now for calls which are not going to be unsecured by a GoClear message. This means, every user can start the call secured or unsecured according of how the button is pressed or not, and can secure it afterwards (if the peer did it of course). The GoClear - GoSecure addition makes possible now that the users can switch to unsecured mode after a call is secured and back to secure mode (with respect to the ZRTP specifications of course). In terms of usability, when an user switches to unsecured mode does it also through the same padlock button by unpressing it. This causes the peer's padlock button also to become unpressed when the call is unsecured. Switching back to secure mode is done as expected by pressing the padlock button again. However, the difference in this case is that the peer's button is again automatically toggled on, not needing the peer to do this. So, the use case when an user switches to secure mode and the call is secured later, when the peer toggles the button too, applies only for the first call securing during a session. (Actually I think this is probably the only possible way for implementing this feature. After all it is based on the fact that at the call beginning, the first peer remains in detecting state after switching to secure mode, and the other initializes later the engine. In case of re-securing the call, this is done at this moment, according to the specifications, by directly sending a Commit packet which leads to immediately re-securing the call). To summarize, probably will be more clear when you actually will see it :).

I think it's a good way to implement this functionality.

I've done many changes on how the GUI was implemented until now, like adding a source (local, remote) parameter for the SecureEvent dispatched to CallSessionImpl, and others. The most important change was, I think, removing the button code from the quick menu, and integrating it along with the label inside the ZRTPGUI plugin (The components are however placed where they were before on the SC interface, but now are both in the same plugin separate from the SC menus GUI code). I think, I've detailed already pretty much for a short overview. I'll try to add next week on my blog, as I said, a description of how GUI works.

About the location of the buttons, I think we will leave them as it is now - I'm not sure if Yana had the time to implement what was needed to accept new buttons as plugins on the call panel, and she is now in holidays. But I think it'll be easy to move them later, so either I'll take care of that, or, if you're willing to going on committing to the project from time to time, your enhancements will be of course welcome :slight_smile:

At the moment I managed to perform several successful tests by switching off and on the call in various sequences. There are however some points related to ZRTP on which I'm not totally certain, as I described on my blog. Many of them are related with the exception/error handling conditions present in the additions done to the state engine (there are actually probably some crash or unexpected behavior chances, if SC gets in such a situation - like an error or exceeded timer). I didn't had the time yet to reanalyze those points but I'll try to do it this weekend, and make a list with what isn't totally clear.

One week remains before the final evaluation period, so this is a good idea to polish this part and add comments in the code where you think it might need further improvements.

Cheers,

路路路

On 2008/08/08, at 1:10, 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


#3

Hello Romain, Werner,

Please check my comments inline:

Hi Emmanuel,

so the version present now on the SVN encryption branch is pretty much a fully working implementation.

That's a great news! This project was not easy to handle and you have taken it very seriously, your commitment is really much appreciated.

First, thank you for Romain for the appreciation, :slight_smile: but I was just re-checking the optional GoClear - GoSecure part I implemented along with the ZRTP specifications when I got your mail, and I realized that I missed something pretty important I think, and I might need some advice from Werner about it.
According to the section 5.7.2.1 which specifies the key destruction in case of GoClear, there is also specified, I quote, that "if the user later re-initiates secure mode during the same call, the new key negotiation can (and SHOULD) use a Multistream Commit message". Well, like I said, unfortunately I missed that part when I've implemented switching back to secure mode. I did it based on what is specified in the final part of section 5.7.2 - Termination via GoClear message, supposing that normal DH mode should be used, as there isn't specifically mentioned multistream: "After the users have transitioned from SRTP media back to RTP media (clear mode), they may decide later to return to secure mode by manual activation, usually by pressing a GO SECURE button. In that case, a new secure session is initiated by the party that presses the button, by sending a new Commit packet, leadng to a new session key negotiation. It is not necessary to send another Hello packet, as the two parties have already done that at the start of the call and thus have already discovered each other's ZRTP capabilities. It is possible for users to toggle back and forth between clear and secure modes multiple times in the same call, just as they could in the old days of secure PSTN phones."
Well, even if my current implementation of switching back to secure after GoClear isn't probably 100% wrong ( after all it works :slight_smile: ), the "(and SHOULD)" part in the ZRTP specs strongly suggests that Multistream Commit should be used instead the one leading to normal DH mode secret computation. For now, as I've seen there isn't yet full multistream support needed by this in ZRTP4J. I may try, if I've got the time, to add it (or at least give it a thought and start) during the next week. At a first sight, the basic things to do would be:

1) either changing the prepareCommit function by including a branch in it for multistream mode or adding one (like prepareCommitMultiStream) specifically for this case
2) same issue for prepareConfirm1 (but if keeping only one method, in this case, it will process two types of packets according to the mode, either DHPart or Commit)
3) the peer, when receiving a GoSecure request through GUI from the user after a previous GoClear is in the newly added UnsecuredState, and should prepare the Commit using the method at 1) instead the version prepareCommit has now, send the Commit and switch to WaitConfirm1 state instead of CommitSent as it does now
4) the other peer (also in the newly added UnsecuredState), when receiving a Commit should prepare a Confirm1 packet using the method at 2) and switch to WaitConfirm2 state instead WaitDHPart2 as it does now

I think this would be the basic changes needed to support GoSecure after GoClear using a multistream Commit instead the normal DH mode one. However I should check at least the prepareConfirm2 method with respect to the changes needed at 2) to be sure the state engine goes on normally with the transitions after a GoSecure switch. Also, this is a basic view centered on securing the call back after switching to unsecured mode, and I didn't analyze it in detail regarding other possible cases of multistream usage, so I'll need an opinion from Werner if possible if it sounds ok or not.

Also, I've seen there is a newly published draft on 8th of August regarding ZRTP, not yet submitted to IETF. I didn't check it yet in detail, but related to the GoClear part there doesnt't seem to be any change.

About the GUI part, I pretty much redesigned the way this is handled inside the code, also regarding to what was done until now.

I think it's a good way to implement this functionality.

In case I manage to add the above changes, these shouldn't affect the GUI modifications done in any way besides keeping the SAS unchanged I think. (I'll try as I wrote last time to detail how the GUI works on my blog soon)

I've done many changes on how the GUI was implemented until now, like adding a source (local, remote) parameter for the SecureEvent dispatched to CallSessionImpl, and others. The most important change was, I think, removing the button code from the quick menu, and integrating it along with the label inside the ZRTPGUI plugin (The components are however placed where they were before on the SC interface, but now are both in the same plugin separate from the SC menus GUI code). I think, I've detailed already pretty much for a short overview. I'll try to add next week on my blog, as I said, a description of how GUI works.

About the location of the buttons, I think we will leave them as it is now - I'm not sure if Yana had the time to implement what was needed to accept new buttons as plugins on the call panel, and she is now in holidays. But I think it'll be easy to move them later, so either I'll take care of that, or, if you're willing to going on committing to the project from time to time, your enhancements will be of course welcome :slight_smile:

Sure, I'll try, if my time allows it, to maintain support and service for the ZRTP integration in SC, also after GSoC is over, and eventually to add further enhancements (again, when I have the time, I got quite a busy year ahead :slight_smile: ).

At the moment I managed to perform several successful tests by switching off and on the call in various sequences. There are however some points related to ZRTP on which I'm not totally certain, as I described on my blog. Many of them are related with the exception/error handling conditions present in the additions done to the state engine (there are actually probably some crash or unexpected behavior chances, if SC gets in such a situation - like an error or exceeded timer). I didn't had the time yet to reanalyze those points but I'll try to do it this weekend, and make a list with what isn't totally clear.

One week remains before the final evaluation period, so this is a good idea to polish this part and add comments in the code where you think it might need further improvements.

I'll try, if I have the time, to add the part related to switching back to secure comm through multistream mode, as I've mentioned in the beginning of the mail, but after I'll finish with checking the error handling conditions I've mentioned (like I said in the last mail I'll probably be back Tuesday with some more questions for Werner if I still have unclear points). Also, I'll add some more comments as suggested, on some parts, resource support for some hard-coded strings, and more general code revision & cleanup where is necessary.

Regards,
Emanuel

路路路

On Sun, 10 Aug 2008, Romain KUNTZ wrote:

On 2008/08/08, at 1:10, Onica S. Emanuel 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


#4

Emanuel,

thanks very much for implementing the goClear/goSecure mode
at all. I'll check it during the next days and give you feedback.

Let's discuss the multi-stream feature and if and how to use it
in ZRTP4J a bit later (it does not exist in ZRTP4J yet :slight_smile: ).

As said by the spec using the multi-stream mode is a SHOULD her,
not a must. Because ZRTP4J does not implement multi-stream ZRTP4J
is not fully compliant with the spec anyhow.

However, this missing feature does not harm security.

Using Multi-stream saves a DH computation when re-establishing
security or when adding another media stream, for example
video, to an existing session. There is a caveat: this has to be
the same "signaling" session (in SIP terms a re-invite). Saving
a DH computation may be useful for devices with low CPU power
such as mobile devices. For fully fledged computers it is IMHO
not necessary :slight_smile: . I'll discuss that matter again with Phil
and get his opinion about it.

Regards,
Werner

Onica S. Emanuel schrieb:

路路路

Hello Romain, Werner,

Please check my comments inline:

On Sun, 10 Aug 2008, Romain KUNTZ wrote:

Hi Emmanuel,

On 2008/08/08, at 1:10, Onica S. Emanuel wrote:

so the version present now on the SVN encryption branch is pretty much a fully working implementation.

That's a great news! This project was not easy to handle and you have taken it very seriously, your commitment is really much appreciated.

First, thank you for Romain for the appreciation, :slight_smile: but I was just re-checking the optional GoClear - GoSecure part I implemented along with the ZRTP specifications when I got your mail, and I realized that I missed something pretty important I think, and I might need some advice from Werner about it.
According to the section 5.7.2.1 which specifies the key destruction in case of GoClear, there is also specified, I quote, that "if the user later re-initiates secure mode during the same call, the new key negotiation can (and SHOULD) use a Multistream Commit message". Well, like I said, unfortunately I missed that part when I've implemented switching back to secure mode. I did it based on what is specified in the final part of section 5.7.2 - Termination via GoClear message, supposing that normal DH mode should be used, as there isn't specifically mentioned multistream: "After the users have transitioned from SRTP media back to RTP media (clear mode), they may decide later to return to secure mode by manual activation, usually by pressing a GO SECURE button. In that case, a new secure session is initiated by the party that presses the button, by sending a new Commit packet, leadng to a new session key negotiation. It is not necessary to send another Hello packet, as the two parties have already done that at the start of the call and thus have already discovered each other's ZRTP capabilities. It is possible for users to toggle back and forth between clear and secure modes multiple times in the same call, just as they could in the old days of secure PSTN phones."
Well, even if my current implementation of switching back to secure after GoClear isn't probably 100% wrong ( after all it works :slight_smile: ), the "(and SHOULD)" part in the ZRTP specs strongly suggests that Multistream Commit should be used instead the one leading to normal DH mode secret computation. For now, as I've seen there isn't yet full multistream support needed by this in ZRTP4J. I may try, if I've got the time, to add it (or at least give it a thought and start) during the next week. At a first sight, the basic things to do would be:

1) either changing the prepareCommit function by including a branch in it for multistream mode or adding one (like prepareCommitMultiStream) specifically for this case
2) same issue for prepareConfirm1 (but if keeping only one method, in this case, it will process two types of packets according to the mode, either DHPart or Commit)
3) the peer, when receiving a GoSecure request through GUI from the user after a previous GoClear is in the newly added UnsecuredState, and should prepare the Commit using the method at 1) instead the version prepareCommit has now, send the Commit and switch to WaitConfirm1 state instead of CommitSent as it does now
4) the other peer (also in the newly added UnsecuredState), when receiving a Commit should prepare a Confirm1 packet using the method at 2) and switch to WaitConfirm2 state instead WaitDHPart2 as it does now

I think this would be the basic changes needed to support GoSecure after GoClear using a multistream Commit instead the normal DH mode one. However I should check at least the prepareConfirm2 method with respect to the changes needed at 2) to be sure the state engine goes on normally with the transitions after a GoSecure switch. Also, this is a basic view centered on securing the call back after switching to unsecured mode, and I didn't analyze it in detail regarding other possible cases of multistream usage, so I'll need an opinion from Werner if possible if it sounds ok or not.

Also, I've seen there is a newly published draft on 8th of August regarding ZRTP, not yet submitted to IETF. I didn't check it yet in detail, but related to the GoClear part there doesnt't seem to be any change.

About the GUI part, I pretty much redesigned the way this is handled inside the code, also regarding to what was done until now.

I think it's a good way to implement this functionality.

In case I manage to add the above changes, these shouldn't affect the GUI modifications done in any way besides keeping the SAS unchanged I think. (I'll try as I wrote last time to detail how the GUI works on my blog soon)

I've done many changes on how the GUI was implemented until now, like adding a source (local, remote) parameter for the SecureEvent dispatched to CallSessionImpl, and others. The most important change was, I think, removing the button code from the quick menu, and integrating it along with the label inside the ZRTPGUI plugin (The components are however placed where they were before on the SC interface, but now are both in the same plugin separate from the SC menus GUI code). I think, I've detailed already pretty much for a short overview. I'll try to add next week on my blog, as I said, a description of how GUI works.

About the location of the buttons, I think we will leave them as it is now - I'm not sure if Yana had the time to implement what was needed to accept new buttons as plugins on the call panel, and she is now in holidays. But I think it'll be easy to move them later, so either I'll take care of that, or, if you're willing to going on committing to the project from time to time, your enhancements will be of course welcome :slight_smile:

Sure, I'll try, if my time allows it, to maintain support and service for the ZRTP integration in SC, also after GSoC is over, and eventually to add further enhancements (again, when I have the time, I got quite a busy year ahead :slight_smile: ).

At the moment I managed to perform several successful tests by switching off and on the call in various sequences. There are however some points related to ZRTP on which I'm not totally certain, as I described on my blog. Many of them are related with the exception/error handling conditions present in the additions done to the state engine (there are actually probably some crash or unexpected behavior chances, if SC gets in such a situation - like an error or exceeded timer). I didn't had the time yet to reanalyze those points but I'll try to do it this weekend, and make a list with what isn't totally clear.

One week remains before the final evaluation period, so this is a good idea to polish this part and add comments in the code where you think it might need further improvements.

I'll try, if I have the time, to add the part related to switching back to secure comm through multistream mode, as I've mentioned in the beginning of the mail, but after I'll finish with checking the error handling conditions I've mentioned (like I said in the last mail I'll probably be back Tuesday with some more questions for Werner if I still have unclear points). Also, I'll add some more comments as suggested, on some parts, resource support for some hard-coded strings, and more general code revision & cleanup where is necessary.

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


#5

Hello,

Emanuel,

thanks very much for implementing the goClear/goSecure mode
at all. I'll check it during the next days and give you feedback.

Let's discuss the multi-stream feature and if and how to use it
in ZRTP4J a bit later (it does not exist in ZRTP4J yet :slight_smile: ).

As said by the spec using the multi-stream mode is a SHOULD her,
not a must. Because ZRTP4J does not implement multi-stream ZRTP4J
is not fully compliant with the spec anyhow.

However, this missing feature does not harm security.

Using Multi-stream saves a DH computation when re-establishing
security or when adding another media stream, for example
video, to an existing session. There is a caveat: this has to be
the same "signaling" session (in SIP terms a re-invite). Saving
a DH computation may be useful for devices with low CPU power
such as mobile devices. For fully fledged computers it is IMHO
not necessary :slight_smile: . I'll discuss that matter again with Phil
and get his opinion about it.

Regards,
Werner

Thanks for the quick reply.

Ok, I understand that, for the moment I should let re-securing the call, as I've initiated it (through a normal Commit not a multistream one, followed by the DH exchange and the usual state transitions).

I'll take some more time then to revise the other parts of the GoClear implementation.

Regards,
Emanuel

路路路

On Mon, 11 Aug 2008, Werner Dittmann wrote:

Onica S. Emanuel schrieb:

Hello Romain, Werner,

Please check my comments inline:

On Sun, 10 Aug 2008, Romain KUNTZ wrote:

Hi Emmanuel,

On 2008/08/08, at 1:10, Onica S. Emanuel wrote:

so the version present now on the SVN encryption branch is pretty much a fully working implementation.

That's a great news! This project was not easy to handle and you have taken it very seriously, your commitment is really much appreciated.

First, thank you for Romain for the appreciation, :slight_smile: but I was just re-checking the optional GoClear - GoSecure part I implemented along with the ZRTP specifications when I got your mail, and I realized that I missed something pretty important I think, and I might need some advice from Werner about it.
According to the section 5.7.2.1 which specifies the key destruction in case of GoClear, there is also specified, I quote, that "if the user later re-initiates secure mode during the same call, the new key negotiation can (and SHOULD) use a Multistream Commit message". Well, like I said, unfortunately I missed that part when I've implemented switching back to secure mode. I did it based on what is specified in the final part of section 5.7.2 - Termination via GoClear message, supposing that normal DH mode should be used, as there isn't specifically mentioned multistream: "After the users have transitioned from SRTP media back to RTP media (clear mode), they may decide later to return to secure mode by manual activation, usually by pressing a GO SECURE button. In that case, a new secure session is initiated by the party that presses the button, by sending a new Commit packet, leadng to a new session key negotiation. It is not necessary to send another Hello packet, as the two parties have already done that at the start of the call and thus have already discovered each other's ZRTP capabilities. It is possible for users to toggle back and forth between clear and secure modes multiple times in the same call, just as they could in the old days of secure PSTN phones."
Well, even if my current implementation of switching back to secure after GoClear isn't probably 100% wrong ( after all it works :slight_smile: ), the "(and SHOULD)" part in the ZRTP specs strongly suggests that Multistream Commit should be used instead the one leading to normal DH mode secret computation. For now, as I've seen there isn't yet full multistream support needed by this in ZRTP4J. I may try, if I've got the time, to add it (or at least give it a thought and start) during the next week. At a first sight, the basic things to do would be:

1) either changing the prepareCommit function by including a branch in it for multistream mode or adding one (like prepareCommitMultiStream) specifically for this case
2) same issue for prepareConfirm1 (but if keeping only one method, in this case, it will process two types of packets according to the mode, either DHPart or Commit)
3) the peer, when receiving a GoSecure request through GUI from the user after a previous GoClear is in the newly added UnsecuredState, and should prepare the Commit using the method at 1) instead the version prepareCommit has now, send the Commit and switch to WaitConfirm1 state instead of CommitSent as it does now
4) the other peer (also in the newly added UnsecuredState), when receiving a Commit should prepare a Confirm1 packet using the method at 2) and switch to WaitConfirm2 state instead WaitDHPart2 as it does now

I think this would be the basic changes needed to support GoSecure after GoClear using a multistream Commit instead the normal DH mode one. However I should check at least the prepareConfirm2 method with respect to the changes needed at 2) to be sure the state engine goes on normally with the transitions after a GoSecure switch. Also, this is a basic view centered on securing the call back after switching to unsecured mode, and I didn't analyze it in detail regarding other possible cases of multistream usage, so I'll need an opinion from Werner if possible if it sounds ok or not.

Also, I've seen there is a newly published draft on 8th of August regarding ZRTP, not yet submitted to IETF. I didn't check it yet in detail, but related to the GoClear part there doesnt't seem to be any change.

About the GUI part, I pretty much redesigned the way this is handled inside the code, also regarding to what was done until now.

I think it's a good way to implement this functionality.

In case I manage to add the above changes, these shouldn't affect the GUI modifications done in any way besides keeping the SAS unchanged I think. (I'll try as I wrote last time to detail how the GUI works on my blog soon)

I've done many changes on how the GUI was implemented until now, like adding a source (local, remote) parameter for the SecureEvent dispatched to CallSessionImpl, and others. The most important change was, I think, removing the button code from the quick menu, and integrating it along with the label inside the ZRTPGUI plugin (The components are however placed where they were before on the SC interface, but now are both in the same plugin separate from the SC menus GUI code). I think, I've detailed already pretty much for a short overview. I'll try to add next week on my blog, as I said, a description of how GUI works.

About the location of the buttons, I think we will leave them as it is now - I'm not sure if Yana had the time to implement what was needed to accept new buttons as plugins on the call panel, and she is now in holidays. But I think it'll be easy to move them later, so either I'll take care of that, or, if you're willing to going on committing to the project from time to time, your enhancements will be of course welcome :slight_smile:

Sure, I'll try, if my time allows it, to maintain support and service for the ZRTP integration in SC, also after GSoC is over, and eventually to add further enhancements (again, when I have the time, I got quite a busy year ahead :slight_smile: ).

At the moment I managed to perform several successful tests by switching off and on the call in various sequences. There are however some points related to ZRTP on which I'm not totally certain, as I described on my blog. Many of them are related with the exception/error handling conditions present in the additions done to the state engine (there are actually probably some crash or unexpected behavior chances, if SC gets in such a situation - like an error or exceeded timer). I didn't had the time yet to reanalyze those points but I'll try to do it this weekend, and make a list with what isn't totally clear.

One week remains before the final evaluation period, so this is a good idea to polish this part and add comments in the code where you think it might need further improvements.

I'll try, if I have the time, to add the part related to switching back to secure comm through multistream mode, as I've mentioned in the beginning of the mail, but after I'll finish with checking the error handling conditions I've mentioned (like I said in the last mail I'll probably be back Tuesday with some more questions for Werner if I still have unclear points). Also, I'll add some more comments as suggested, on some parts, resource support for some hard-coded strings, and more general code revision & cleanup where is necessary.

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