<specVersion> problem

[simoncn]

The <specVersion> in the generated device and service XML appears to be incorrect. DviProtocolUpnpDeviceXmlWriter::Write and DviProtocolUpnpServiceXmlWriter::WriteServiceXml both contain this code:

Code:

iWriter.Write("<?xml version=\"1.0\" encoding=\"utf-8\"?>");
iWriter.Write("<root xmlns=\"urn:schemas-upnp-org:device-1-0\">");
iWriter.Write("<specVersion>");
iWriter.Write("<major>1</major>");
iWriter.Write("<minor>1</minor>");
iWriter.Write("</specVersion>");

I believe the <major> and <minor> values should be taken from the device and service attributes, rather than being hard coded.

[simonc]

(20-07-2012 08:25 AM)simoncn Wrote:  I believe the <major> and <minor> values should be taken from the device and service attributes, rather than being hard coded.

ohNet attempts to implement UPnP v1.1. The spec isn't exactly helpful here:

<minor>
REQUIRED. Minor version of the UPnP Device Architecture. MUST be 1 for services implemented on a UPnP 1.1 architecture. MUST accurately reflect the version number of the UPnP Device Architecture supported by the device. Control points MUST be prepared to accept a higher version number than the control point itself implements.

could be taken to demand that the minor version is both hard-coded to 1 (since the services are implemented on top of a UPnP 1.1 architecture) and taken from a per-device attribute.

I don't feel strongly about this and can read the version from a device attribute if that'd help you. Is the current implementation causing you problems or does it just feel wrong?

I can't see anything in the 1.1 device architecture doc that'd allow a per-service specVersion. If you think this is required, can you point me to the relevant part of the spec please?

[simoncn]

(20-07-2012 09:55 AM)simonc Wrote:  

(20-07-2012 08:25 AM)simoncn Wrote:  I believe the <major> and <minor> values should be taken from the device and service attributes, rather than being hard coded.

ohNet attempts to implement UPnP v1.1. The spec isn't exactly helpful here:

<minor>
REQUIRED. Minor version of the UPnP Device Architecture. MUST be 1 for services implemented on a UPnP 1.1 architecture. MUST accurately reflect the version number of the UPnP Device Architecture supported by the device. Control points MUST be prepared to accept a higher version number than the control point itself implements.

could be taken to demand that the minor version is both hard-coded to 1 (since the services are implemented on top of a UPnP 1.1 architecture) and taken from a per-device attribute.

I don't feel strongly about this and can read the version from a device attribute if that'd help you. Is the current implementation causing you problems or does it just feel wrong?

I can't see anything in the 1.1 device architecture doc that'd allow a per-service specVersion. If you think this is required, can you point me to the relevant part of the spec please?

Thanks for clarifying how this works.

I was under the incorrect impression that a service defined with a service template containing <major>1</major><minor>0</minor> should have the same numbers exposed in its service.xml. From reading the spec section that you quoted, I understand now that this isn't the case.

I also thought that devices that were defined by UPnP 1.0 (such as MediaServer:1) should have <major>1</major><minor>0</minor> in their device.xml. Again, I see now that this was an incorrect assumption.

This was reported to me as a compatibility issue with certain control points (specifically, the PS3) that are able to accept <major>1</major><minor>0</minor> in device.xml but are unable to accept <major>1</major><minor>1</minor>.

I can tell people who have these control points that MinimServer/ohNet is correct and their control points are incorrect, but this won't help them to get their control points to interoperate with MinimServer.

The same issue is likely to service.xml as well, though I don't currently have any reports of this.

To solve this problem, would it be possible/reasonable to allow the appliaction to configure the minor version that ohNet advertises in device.xml and service.xml, with 0 and 1 as legal values? I think there are (at least) two issues here:

1) Is there anything that ohNet does that would cause problems for a UPnP 1.0 control point if it thinks it's talking to a UPnP 1.0 device which is actually a UPnP 1.1 ohNet device? Given that control points that implement UPnP 1.0 are required by the spec to accept UPnP devices that implement UPnP 1.1, I wouldn't expect this to cause any problems.

2) Is there anything that ohNet does that would cause problems for a UPnP 1.1 control point if it thinks it's talking to a UPnP 1.0 device which is actually a UPnP 1.1 ohNet device? To put this another way, what are the differences between UPnP 1.1 devices and UPnP 1.0 devices that would be visible to a UPnP 1.1 control point?

[simoncn]

Further tests have confirmed that the interoperability problem with the PS3 isn't caused by the <minor>1</minor> value, so there's no need to make this configurable.

I'd still be interested in a brief summary of what's different between UPnP 1.0 and UPnP 1.1.

[simonc]

(22-07-2012 07:52 AM)simoncn Wrote:  Further tests have confirmed that the interoperability problem with the PS3 isn't caused by the <minor>1</minor> value, so there's no need to make this configurable.

I vaguely remember mention of some Sony products using alive/byebye messages but failing to make use of msearches. This may be part of the justification for Twonky and Asset sending announcements so frequently (every minute rather than every 10-15 minutes). It might be worth trying InitParams.SetDvMaxUpdateTime with a low value (possibly alongside your earlier version changes) to see if that helps your server be detected.

(22-07-2012 07:52 AM)simoncn Wrote:  I'd still be interested in a brief summary of what's different between UPnP 1.0 and UPnP 1.1.

There aren't many differences that I can remember:

• A new NOTIFY SSDP message which can be used in place of byebye followed by alive in certain circumstances. ohNet only uses this on IP address changes.
• Changes in evented state variables can be announced via multicast in addition to traditional subscriptions. ohNet doesn't provide these yet.
• Minor changes in device xml. The only one I can remember offhand concerns use of absolute vs relative urls. There may be some others but they'll be pretty minor.
  

I don't think any of these should cause problems for a v1.0 CP. If the suggestion above doesn't help, you could consider reviewing DviProtocolUpnpDeviceXmlWriter::Write against the v1.0 spec, changing any deviations. I doubt this'd help but its possible that a fussy CP might object to something here.

[simonc]

I've committed a change which allows clients to set "Upnp.Version.Major" and "Upnp.Version.Minor" attributes on a device. These both default to 1 so only need to be called if you come across a control point which assumes the version describes device rather than stack capabilities. I haven't included any way to modify service xml yet.

[simoncn]

(23-07-2012 09:04 AM)simonc Wrote:  I've committed a change which allows clients to set "Upnp.Version.Major" and "Upnp.Version.Minor" attributes on a device. These both default to 1 so only need to be called if you come across a control point which assumes the version describes device rather than stack capabilities. I haven't included any way to modify service xml yet.

Is there any situation where the values in service.xml and device.xml shouldn't be the same? If not, could these new attributes apply to both places?

[simonc]

(23-07-2012 10:37 AM)simoncn Wrote:  Is there any situation where the values in service.xml and device.xml shouldn't be the same? If not, could these new attributes apply to both places?

Not that I know of. I'll change service xml generation too then. We can always reconsider when we find a CP this confuses.