Activity Log : GSoC Week #04-#05 (12.V - 25.V)

Unfortunately I didn't have more than a weekend free these weeks so this entry will be quite short:

• Regarding the problem I was talking about in my last post about how JMF (or FMJ) will handle the ZRTP packets, I think I've reached a conclusion, after I read the JMF samples here: http://java.sun.com/javase/technologies/desktop/media/jmf/2.1.1/solutions/ (the RTP streaming section) and took another quick look into the JMF API Guide (which wasn't of very much help though because it doesn't contain the RTP Manager/Connector additions). As a reminder: the RTPConnector "acts" on the packets passed by the RTPManager before these are sent into network and on the receiver side, before these are passed to the receiver's RTPManager. So, I believe there shouldn't be a problem with the different ZRTP header (as I thought it might be) as long as all ZRTP traffic is being held in the boundary of a ZRTP RTPConnector dedicated implementation, in a similar way like SRTP is. Otherwise, if the packets would "reach" the RTPManager, there will be a problem probably with the unknown Format, resulting in the need of registering a new one, and things might get a bit to complicated. In conclusion, I think the idea of using a ZRTP dedicated Connector and consequently keeping most of the ZRTP management related to it remains the best option.
• I also managed to make another comparison between the FMJ API and JMF one, on a few RTP related classes (did it once more at the start of GSoC), and as discussed on the dev list I can't find any differences (RTPConnector, RTPManager and few other classes included here). This, anyway, is only in rough API terms = looked at the function signatures provided by one and compared to the other. I decided to do this once more, after the problems Werner reported on the dev list with FMJ. I didn't manage to get deeper (I wanted actually to investigate a bit further about what are the differences related to the way ReceiveStreamEvent is handled - Werner's reported problem - between JMF and FMJ, but it seems that the JMF sources aren't available any longer on the Sun site: http://www.sun.com/software/communitysource/jmf/download.xml - eventually I'll look for them in other place). Anyway, as I said also on the mailing list, if the ZRTP solution will be based on the common API parts used by JMF and FMJ (which will be almost certain according to the comparison made above), it shouldn't be a problem on which of them is run and tested. Just as a fact, I personally did read a bit more about JMF in this first GSoC phase, so many assumptions are based on this knowledge - hope it applies on both of them (I tried to find some FMJ tutorials but there seems there aren't any - or I didn't look for them enough) .
• The next steps: fortunately this week I'll be over with my exams (one more research project next Tuesday but that won't be a problem), and I'll finally be able to use most of my time for GSoC beginning with the next week, so probably this weekend (or next Monday latest) I'll try writing the starting code for the RTPConnector based ideas mentioned above. I still must talk to Werner about what exactly his library ZRTP4J provides and any integration issues related to this (probably also Monday) and must see how I'll use the UIService to connect the GUI to the Connector part. All these probably in my next activity log entry :).