- Made a basic setup for a Linux (openSUSE 11) partition in order to test SC - Twinkle (available only on Linux) intercommunication using ZRTP (the setup took a bit longer than planned due to some partition losing which needed recovery)
- Applied the Twinkle patches sent by Werner in order to build it with the latest libzrtpcpp version
- Done SC-Twinkle tests in no-registrar mode: the ZRTP based encryption activated successfully, and even if there were some codec related problems on one audio channel at first, after repeating the tests these dissapeared (G.711a was selected in the successfull case if I recall correctly)
- Done SC-Twinkle tests in registrar mode: for registrar I've used this time a very basic configuration of OpenSER on Linux; ZRTP based encryption activated successfully and the calls went fine
- Registered two accounts at Free World Dialup in order to test using an external SIP service provider
- Done SC-Twinkle tests through FWD: calling Twinkle from SC went fine regarding the ZRTP activation and encryption; however the SC->Twinkle audio channel was "empty" (the selected codec was GSM this time so I'll probably have to retest trying some codec limitations on Twinkle to see what happens); calling SC from Twinkle hanged unfortunately (I didn't investigate yet the problem further)
- Done few SC-SC tests through FWD (on Windows platform): all went ok - no problems encountered yet in this case to report (should test some more however)
- All tests done included calling with ZRTP activated from start and also with ZRTP activation during the call (for the SC peer)
- All problems reported were encountered also in unsecured calls
- Werner made an extensive test report also for SC - Minisip/Zfone calls; basically the ZRTP activation and encryption seem to pose no problem; however there were some problems as in my tests regarding general SC communication
This is pretty much all for the testing done until now. I plan to repeat some of them (especially the ones which had problems even if these weren't ZRTP related).
Also I've started at the end of the last week, and went on this week with the debugging of the no-registrar patch. I'm still stuck with the problem of permitting both registrar mode and no-registrar accounts. Essentially this manifests by selecting the wrong (registrar mode account) service provider when two of them, of different types, are present. I've done some debugging on this, didn't found a specific reason yet but managed to finally relate the behaviour with the accounts random generated identifiers. This isn't apparently as strange as it seems at the first sight. Based on the identifiers the order of the accounts at loading seems to differ, and this is the only difference I found so far between calls which go on normally and the ones which fail due to wrong service provider selection. I'll probably post soon a more detailed report on the SC main dev list.