This pages focuses on the relationship between Widgets, MPEG-U and UPnP, and on the usage of these standards in the GPAC project.

UPnP

As part of the implementation of GPAC, we have developed a UPnP module, thanks to the Platinum stack. The UPnP consortium produced several specifications. The device architecture specification defines several mechanisms:

• addressing: how a device gets an IP address;
• discovery: how a device discovers or gets discoverd by the other UPnP devices in its local network;
• description: an XML language enabling devices to understand the available services offered by other devices;
• control: how a device (Control Point) can control other devices (Controlled Device);
• eventing: how a device can be notified of events happening in an other device;
• presentation: how to retrieve a content associated with the device.

UPnP also defines a set of standard Device Control Protocols (DCP), i.e. standard services (described using the UPnP XML language) that UPnP devices may implement. Among these DCP, we have Media Servers, Media Renderers, Printers, Lighting Controls …

UPnP and MPEG-U in GPAC

The approach in GPAC for the use of UPnP with widgets is divided in three aspects:

Widgets communications with standard UPnP devices

In GPAC, one can design widgets that can easily control or be notified by standard UPnP devices. For that, a widget author has to modify its widget configuration document as follows:

• declare an MPEG-U “interface” element (in the MPEG-U namespace) whose “type” attribute is a standard UPnP service type (such as “urn:schemas-upnp-org:device:BinaryLight:1” for a UPnP Binary Light, or “urn:schemas-upnp-org:service:SwitchPower:1” for a UPnP Switch Power);
• declare “messageIn” and “messageOut” elements (in the MPEG-U namespace) with the name of the UPnP actions and events;
• connect the input/output parameters from the interface with some constructs in the associated wigdet start file (e.g. the index.html or index.svg).  These constructs can be attributes in the DOM, or events, or ECMAScript functions.

The main advantage of this approach is that the discovery of the device is made seamlessly by the UPnP stack and the widget author does not need to care about constructing UPnP messages, nor about finding the IP address. The author only needs to care about how to use the events it will receive (notification that the device is connected/disconnected, notification of input messages or reply messages) and about what he/she wants to send in the output messages.

Here is an example of a UPnP Light Switch widget. The associated snippet of the configuration document:

<content src="index.html">
<mw:interface type="urn:schemas-upnp-org:service:SwitchPower:1">
<mw:messageOut name="SetTarget" outputTrigger="command.click">
<mw:output name="newTargetValue" attributeModified="lightElement.value"/>
</mw:messageOut>
<mw:messageIn name="Status" inputAction="command1.begin">
<mw:input name="Status" setAttribute="lightElement.status"/>
</mw:messageIn>
</mw:interface>
</content>

Widget to widget communications

In order to enable widget to widget communications, for widgets located in different devices, we use the same mechanism. The interfaces declared in the configuration document are used to declare, on the fly, non-standard UPnP devices, but compliant with the XML language of the UPnP standard. The Widget Engine provides this description to the UPnP Platinum stack which uses it as if it was a standard UPnP device. However, in order to limit the advertising of unnecessary/unwanted widgets on the network, authors can use the  “serviceProvider” attribute on the interface element and set it to “false”. In other words, only widgets declaring interface with serviceProvider=”true” will be advertised on the network as Controlled Devices.

Widget discovery

For discovering widgets, we use the “Presentation URL” indicated in the UPnP Device Description, which is set to point to the widget.

Examples

To be added.