The Custom Integrator Show Installment 011 is Live. This installment continues our focus on home networking by taking a look at the age old question “Now that our devices are connected together, what will they say to each other?” We hear a lot about the Digital Living Networking Alliance (DLNA) certification for some of the new technologies built into Windows 7 like Play To and FrameIt, but what does DLNA compatibility really mean and how do the protocols actually function on the wire? To understand this, we start by taking a look at the UPnP Technologies, which are the basis for many of the newer peer-to-peer communications services used for communicating with Internet Gateway Devices (IGDs), Digital Media Renderers, Digital Media Servers, and the like.
[mp3]http://blip.tv/file/get/IanDixon-TheCustomIntegratorShow011238.mp3[/mp3]
Direct Download – Subscribe via RSS – Subscribe via iTunes – Subscribe with Zune
As you know, I am a big fan of having a good background on the standards and protocols behind the technologies we are implementing. This knowledge level makes for better designs, interoperability, expandability, and minimizes potential troubleshooting times. The industry has put a lot of effort into making these devices connect seamlessly in addition to making it easy for the average consumer to set up and deploy. As system integrators, however, we need to make sure we take these underlying protocols to the next level by confirming they are working as expected – and that we have implemented them properly so that they provide the appropriate experience as future devices are integrated into the platforms we install.
One of the biggest attributes of UPnP technologies is that they abstract the physical, logical, and User Interface (UI) device characteristics so they can be “self describing.” This means that, once they are connected to the network, they can be discovered dynamically by other peer devices, that they have a standardized way of “advertising” what type of device (what device class) they are, what services they provide, and how to interact and control them. All of this is achieved using the same Internet-based protocols businesses and consumers use everyday like TCP/IP, eXtensible Markup Language (XML), HTTP, and Simple Object Access Protocol (SOAP).
So let’s dive in a little and see how the UPnP architecture provides this dynamic and transparent way of communicating. This text accompanies the audio part of the Podcast, so be sure to listen to it for more details.
I use an acronym-based way of describing the major building blocks that I refer to as ADDCEP. ADDCEP describes the communications processes between the devices:
- Addressing
- Discovery
- Description
- Control
- Eventing
- Presentation
ADDRESSING – This is the way the device obtains an IP address on the network. A device always uses the network’s Dynamic Host Configuration Protocol (DHCP) service whenever possible. If one is not found, it falls back to using Auto-IP, a process where the device usually assigns itself an address on the 169.254.0.0 subnet. It uses the standardized Address Resolution Protocol (ARP) to detect if an address is in use yet before assigning itself one. It continues to check for a DHCP server. Addressing allows the device to be addressable on an IP-based network, just like all of the other computers and Windows Media Center PCs.
DISCOVERY – This process allows a device to join the network and be “discovered” by other devices. For UPnP Technologies, this uses Simple Services Discovery Protocols (SSDP). SSDP uses the IP port of 1900 for its communications and it can be seen as a service in the computer’s Services Control Panel applet. It sends out an “advertisement” on this port using a multicast message that other devices based on UPnP Technologies can see. Additionally, other devices that contain Control Points (the services provided for controlling other devices) can search for “interesting devices” by sending out a discovery request across the network. Devices then respond to this request using unicast messages. As mentioned in several of our related podcasts, one of the cautions you need to be aware of is that these discovery processes usually are limited to a single subnet (they do not support hops across routers). There are more advanced Web Services (WS)-based discovery technologies based on the WS-Discovery standards, but they usually do not apply to the types of devices currently found in the home.
DESCRIPTION – The heart of the “self describing” process is based upon a Device Description Document (DDD). A sample DDD looks similar to the following:
<?xml version=”1.0″?>
<root xmlns=”urn:schemas–upnp–org:device-1-0“>
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>base URL for all relative URLs</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:deviceType:v</deviceType>
<friendlyName>short user-friendly title</friendlyName>
<manufacturer>manufacturer name</manufacturer>
<manufacturerURL>URL to manufacturer site</manufacturerURL>
<modelDescription>long user-friendly title</modelDescription>
<modelName>model name</modelName>
<modelNumber>model number</modelNumber>
<modelURL>URL to model site</modelURL>
<serialNumber>manufacturer’s serial number</serialNumber>
<UDN>uuid:UUID</UDN>
<UPC>Universal Product Code</UPC>
<iconList>
<icon>
<mimetype>image/format</mimetype>
<width>horizontal pixels</width>
<height>vertical pixels</height>
<depth>color depth</depth>
<url>URL to icon</url>
</icon>
XML to declare other icons, if any, go here
</iconList>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:serviceType:v</serviceType>
<serviceId>urn:upnp-org:serviceId:serviceID</serviceId>
<SCPDURL>URL to service description</SCPDURL>
<controlURL>URL for control</controlURL>
<eventSubURL>URL for eventing</eventSubURL>
</service>
Declarations for other services defined by a UPnP Forum working committee (if any)
go here
Declarations for other services added by UPnP vendor (if any) go here
</serviceList>
<deviceList>
Description of embedded devices defined by a UPnP Forum working committee (if any)
go here
Description of embedded devices added by UPnP vendor (if any) go here
</deviceList>
<presentationURL>URL for presentation</presentationURL>
</device>
</root>
The DDD is based upon “tags” similar to HTML tags used for generating web pages. The UPnP Forum has defined a set of standard templates called Device Control Protocols (DCPs) that every certified device must follow for a specific device class (http://www.upnp.org/standardizeddcps/default.asp). These DCPs are the heart of how disparate devices know what services another device possess and the ranges of values for the control variables used when interacting with the devices, the available actions a device supports, and the particular state information for the device at the time the DCP is retrieved. Each device type has a given set of “must include” tags with the ability for a vendor to extend the DCP schemas to incorporate vendor-specific attributes as a way of providing their value-added feature sets.
These DCPs are very structured. In the podcast, we talk about the Microsoft utility that comes with the Windows SDK called Function Discovery Browser (FDBrowser.exe). You will notice how the information discovered through the DCP is consumed by the operating system by taking a look at the Function Instances: Network Explorer / Provider / Microsoft.Networking.SSDP using this tool. FDBrowser is a great way to learn about the underlying protocols and to confirm which devices are discovered and how a device on the network is being viewed by the PC.
CONTROL – Control Points interact with devices using SOAP messages. This is a standardized convention for performing remote procedure calls using HTTP messages over TCP/IP. Any authenticated Control Point (CP) can control the device. Once again, these are XML data structures (and they can be secured through encryption if required). The device sends a reply to the control (SOAP) messages and also can send state change updates back to a Control Point, so the mechanism facilitates true two-way control and monitoring. We will discuss this more when we start to cover the new Play To features in Windows 7.
EVENTING – UPnP Technologies provide a way to subscribe to event (state) changes within a device using an event subscription model called General Event Notification Architecture (GENA). Once again, this is an XML-based communications protocol delivered via HTTP over the TCP/IP network. It provides a way for Control Points to subscribe to specific services within a device so that the device services can update the CP with any state changes. These event subscriptions must be renewed occasionally.
PRESENTATION – Devices can pass a Presentation URL in the DDD (the reference to it is seen in the DDD sample above as <presentationURL>URL for presentation</presentationURL>). Each device has an embedded web server that hosts the specific information about the device and is used for the entry point for all communications to and from the device. The Presentation Page can be used to control or setup of the device using a “standard” web page hosted within the device if enabled as part of the device’s design. Vendors can add value by incorporating a custom user interface across their product line, although not all devices have a Presentation URL.
We will delve further into the DLNA and UPnP Technologies over the next several Installments of The Custom Integrator Show. We will get into how these communications protocols are used for interacting with IGDs for dynamically opening and closing ports and for interacting with Digital Media Renderers for the Windows 7 Play To services.
For those listening to our podcast live, sorry for the delay in getting this one out. We unfortunately will have to skip another week since I still am “on the road,” but please keep an ear out for our next Installment though.
=D-