I'll try to cover three topics in this mail, two of them being discussed this week on the dev list.
1. First of all, related to the ZRTP label and button access from SCCallback (in the media bundle). I'll explain one more time very shortly the general idea behind implementing it like this (described in detail one or two times in the GSoC activity logs and I think also in some the mails sent some time ago):
The security related elements defined in the GUI bundle are in essence general security elements which may be used by various security algorithms. Therefore the reduced functionality contained in the GUI bundle. ZRTP is an instance, let's say, of such a security algorithm which uses the GUI elements in it's own particular way according to the ZRTP4J UserCallback support which is extended through the SCCallback class. Practically, when ZRTP is used for securing it just "gets" the secure GUI elements it needs from the GUI bundle and uses them afterwards in the SCCallback class. Let's say, hypothetically, that at some moment in the future we will have another type of key management protocol implemented in SC, which will have it's own way of using the secure GUI elements, and will function at the signaling level, not at the media one like ZRTP. That protocol, in case of it's selection for securing will "get" the secure GUI elements like ZRTP does, from the GUI bundle, through the Call which is currently used to provide them, and will handle the button, label and maybe other elements associated with the current Call in other specific way than ZRTP does, probably in it's own Callback class.
To summarize, the idea was to make a set of general GUI secure elements instances for one call, specific to the key management used for the respective call - the button and label "become" ZRTP button and ZRTP label (regarding the functionality) after they are got inside the SCCallback.
I agree that this may not be the best approach, but in order to maintain the whole idea and to move the functionality in the GUI bundle if it's necessary, I must give some serious thought on how to change the implementation. I'm very short on time lately being involved in lots of activities (including a lab teaching assistant position) for this semester at my faculty, but I'll eventually try to find some free hours to think on Emil's ideas.
2. Related to the problem mentioned this week regarding the CallSessionImpl reference inside the SecureEvent, thanks to Lubomir for taking care of it. Also the location of the SecureEvent would be as suggested more appropriate in service.protocol.event than in service.protocol . Sorry for these mistakes. These appeared due to a late refactoring of some sources I made in order to rearrange some of them. I've changed the location of both the SecureEvent and SecureEventListener as an additional fix inside the patch discussed below.
3. As Werner suggested almost two weeks ago as I remember, I've tried to add the option for default securing = the user sets the default call encryption at the account creation inside the SIP account registration wizard through a checkbox, and call securing is activated by default without needing to press the button anymore. The patch attached adds this functionality. It seems to work well at the first sight. However I probably must make some more tests and revise some pieces of the other securing related code to be sure I didn't miss something.
defaultencryption.patch (22 KB)