WBSO » History » Revision 18
Revision 17 (Adrian Georgescu, 11/05/2012 10:20 AM) → Revision 18/21 (Adrian Georgescu, 11/05/2012 10:20 AM)
h1. WBSO status h2. Current Issues (February 17th, 2012) 1. -Cannot correlate session with local and remote end-points state (busy, available, on the phone and type of media supported by the remote end-point) (Tickets 144, 118, 130)- 2. The approach to implement video did not worked as envisaged (Ticket 18, 135) 3. -The address book is unreliable, causing loss of contacts, duplicated contacts or broken synchronization among multiple instances (Ticket 143, 144)- 4. -Presence Chat and file transfer are perceived as being useless because of lack of interoperability with XMPP users (Gmail, Facebook) (no ticket)- 5. Session is unreliable when adding/removing streams and network has packet loss (Ticket 107, 135) 6. TLS transport is not working properly due to assumption that is a general setting (Ticket 120, 135) h2. Solutions 1. -Integration and synchronization of Presence with different media streams (speech, IM, File transfer and video) in only one SIP session- 2. The libraries we relied upon were buggy and poorly supported. It was actually to early to start working on video and it was too complex of a task to approach with only one developer. PJSIP 2.0 has added basic video support in the mean time. We will migrate to PJSIP 2.0 that has support for video libraries that are already integrated into the media layer 3. -The IETF model for contacts management seem to be broken as it allows non-atomic operations. For example when one contact is added, 3 XCAP documents must be saved over the network and if any one fails, there is no way to reliably rollback only parts of the operation. The solution is to use the OMA standards (Open Mobile Alliance) that defines the Presence and Address book together in a main document and the other documents use links to the entries in the main document. This way only one document can be written for a contact add update or delete and this operational can be done atomically- 4. -Presence and Chat must be refactored to support XMPP translation in order to interoperate with other users using other protocols- 5. All operations in the session must be serialized and applied when they can be performed. This requires refactoring of the session model 6. Each SIP account requires its own encrypted transport because TLS connections have per account settings, for example verify_peer and certificate validation depends on foreign domain h2. Performed activities 2012 !20121105-Progress-AgentschapNL.png! h3. Presence Implemented Presence in the middleware, the client side and server side. At over 15,000 lines of Python code, Presence is by far the most complex part of the SDK and the reason it took so long to produce. Presence functionality is now incorporated into an easy to use address book that can be used to develop contact-driven Real Time Communication clients without having to deal with the complexity of SIP signaling, XCAP storage and data replication among multiple devices. http://sipsimpleclient.com/projects/sipsimpleclient/news h3. Implemented XMMP translation for Chat and Presence http://sylkserver.ag-projects.com/news/7 h3. MacOSX version completed (without Video yet) * The MacOSX version now has all Presence integrated http://projects.ag-projects.com/news/15 h2. Roadmap * XMMP translation for audio calls * XMMP translation for file transfers * Multiparty support for MUC add/remove participants * Adding Chat for Linux and Windows client * Adding File Transfer for Linux and Windows client * Adding Screen sharing for Linux and Windows client * Adding Screen sharing for Linux and Windows client * Migration to PJSIP 2.0 that solves many of the outstanding issues * Add Video support in middleware * Add Video to MacOSX client * Add Video to Linux and Window client