HowTo: Nokia N95
- Nokia N95 8GB UPnP blues
- Management Summary
- The long story
- Conclusion
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.
