Nokia N95 8GB UPnP blues

This is so far a summary of my findings trying to establish UPnP communication between Coherence and the Symbian UPnP stack used on the Nokia Nseries mobile phones.

Management Summary

In short, the Symbian stack doesn't react on UPnP devices that announce themselves as version 2 of the UPnP A/V specs.

This is imho a violation of the UPnP specifications.

UPnP A/V Architecture - for instance page 14.

There is now confirmation, that this is due to an error in the Symbian UPnP stack implementation that is immanent up to S60 3rd feature pack 1.

The long story

Coherence implements and announces its devices trying to follow the version 2 of the UPnP A/V specs, which are valid since January 19, 2006.

My testing was done against a

Nokia N95 8GB
V 15.0.015
11-12-07
RM-320
Nokia N95 (02.01)

Update 02.06.2008: Unfortunately nothing has changed with the phones new firmware V 20.0.016.

Test 1: Coherence as a MediaServer:1 and the N95 8GB as the client

Coherence is configured to announce itself as an UPnP A/V MediaServer version 1.

The deviceType in the device description xml file is urn:schemas-upnp-org:device:MediaServer:1.
The serviceType for the services is as urn:schemas-upnp-org:service:ContentDirectory:1.

Discovery

During the discovery phase, the Symbian stack sends out MSEARCH requests for upnp:rootdevice and (seems) to react on SSDP notify messages for that too.

The MSEARCH request has these headers:

host: 239.255.255.250:1900
man: "ssdp:discover"
mx: 1
st: upnp:rootdevice

Description

Upon a response with a notification for an upnp:rootdevice the stack downloads the device description file.

The http request is accompanied by these headers:

host: 192.168.1.163:30020
connection: close
content-length: 0
cache-control: no-cache

Control

After processing the device description and the service descriptions there is a first SOAP UPnP action call.

content-length: 296
soapaction: "urn:schemas-upnp-org:service:ConnectionManager:1#GetProtocolInfo"
host: 192.168.1.163:30020
user-agent: Nokia N95 8GB DLNADOC/1.50 UPnP/1.0
connection: close
content-type: text/xml; charset="utf-8"

Test 2: Coherence as a MediaServer:2 and the N95 8GB as the client

Coherence is configured to announce itself as an UPnP A/V MediaServer version 2.

The deviceType in the device description xml file is urn:schemas-upnp-org:device:MediaServer:2.
The serviceType for the services is as urn:schemas-upnp-org:service:ContentDirectory:2.

The Discovery phase is as above in Test 1, the Symbian stack downloads the device description and does no further processing after that.

Test 3: Coherence as a faked MediaServer:1 and the N95 8GB as the client

Coherence fakes the deviceType to announce itself as an UPnP A/V MediaServer version 1.

The deviceType in the device description xml file is urn:schemas-upnp-org:device:MediaServer:1.
The serviceType for the services is still for version 2 - urn:schemas-upnp-org:service:ContentDirectory:2.

Everything works as in Test 1.

Test 4: The N95 8GB as a Mediaserver and Coherence as the client

Just for the sake of completeness. ;-)

Discovery

The Symbian stack announces its own devices with SSDP notification messages like this:

usn:  uuid:58719f35-2217-10e1-80ae-001CD40A7E1B::urn:schemas-upnp-org:device:MediaServer:1
nts: ssdp:alive
server: Symbian/9.2 UPnP/1.0
host: 239.255.255.250:1900
location: http://192.168.1.229:50002/MediaServer1/MediaServer1.xml
cache-control: max-age=1800
nt: urn:schemas-upnp-org:device:MediaServer:1

Curiously the bye-bye notifications are less informative:

usn: uuid: 58719f35-2217-10e1-80ae-001CD40A7E1B::urn:schemas-upnp-org:service:MediaServer:1
host: 239.255.255.250:1900
nt: urn:schemas-upnp-org:device:MediaServer:1
nts: ssdp:byebye

Coherence does recognize the device and can access it.

Conclusion

From what we see in Test 1-3 the Symbian stack seems on processing the devices description file to only check for and react on the deviceType MediaServer:1.

According to the UPnP specifications this is not the right way to handle that.

As version 2 devices are required to be backward compatible a client device that can handle only version 1 of the specification should have no reason to reject working against a device v2.

Furthermore the lack of any identifiable headers in the SSDP MSEARCH and the HTTP GET requests makes it impossible for an UPnP A/V version 2 device to insinuate a faked description file with a version 1 information.

This is unfortunate in particular, as these identifiable characteristics are available in all other requests, but not in the ones that are used in the initial phase of the communication.