The purpose of the document is to outline the tasks required, and issues involved in incorporating third-party UPnP implementations. One of the first questions to ask is what parts of the implementation are going to be replaced. The OCAP RI implements several aspects of UPnP in order to be a DLNA compliant DMS and DMP. On top of that, it implements the HN-EXT API in terms of this underlying implementation. Here is an enumeration of several of the functional areas implemented, please refer to the HNP specification for details.
- UPnP Control Point discovery, action invocation, subscription requests and notifications
- UPnP Device advertisement as well as handling state variable and subscription requests
- UPnP Device listening for and dispatching of action requests
- UPnP Connection Management Service implementation (CMS)
- UPnP Content Directory Service implementation (CDS)
- UPnP Scheduled Recording Service implementation (SRS)
- HTTP requests for icons
- HTTP requests for recorded content
- HTTP requests for live content
The 3rd party implementation may account for some or all of the above areas of functionality.
RI Internals
The RI implements most UPnP related activities in the OCAP Java stack. The exception to this is servicing HTTP requests for recorded and live content. In the case of content delivery the RI listens and takes the request in from the Java stack and then passes the socket through the MPE porting layer to a native C implementation that is responsible for reading and writing HTTP headers and content.
All advertisement and listening to incoming requests is done using an open-source 3rd party library called Cybergarage. The version of Cybergarage we use is 1.6, but it has been heavily modified in order to satisfy requirements unique to OCAP as well as to be compliant and pass UPnP & DLNA certification tests. In OCAP 1.2, the UPnP Diagnostics API was introduced and includes unique requirements that call for the ability to view and modify all incoming and outgoing message traffic, including SSDP and SOAP requests and responses. This low level API is not traditionally found in 3rd party libraries and can represent a substantial amount of work by integrators in order to satisfy the specification.
Approaches
There are several approaches that can be taken. Each has a different level of involvement and risk.
- Implement that UPnP Diagnostics API from scratch, native in Java. The approach is rather involved, but will allow for a complete and proper implementation.
- Replace the cybergarage stack with another Java API. This approach avoids complications with JNI implementations, however the OCAP specifications for message manipulation may be prohibitive or require special access to code or functionality. The port will all become more difficult the less similar the API is to Cybergarage.
- Replace the Cybergarage stack with a C library.
- Replace the Cybergarage stack and implementation of the CMS, CDS and SRS.