1.1 Does UPnP provide querying capability for specific device types and/or services?

Yes. UPnP SSDP allows a control point to query for a type or ID for a device or type for a service. This allows discovery (and advertisement) of a standard UPnP device or service type or, optionally, a specific instance of a device based on a unique ID. Definition of UPnP device and service types is the responsibility of UPnP Task Groups. In summary, the search hierarchy includes:

• Standard device or service type – for example, BinaryLight 1.0
• Unique device identifier – for example, a unique device ID

It is not a goal for SSDP to provide advanced query facilities. Following discovery of a device or service, a control point may perform a finer-grain search through access to a URL for a device or service description. For example, discovery of particular media content may be resolved through a Search() on a ContentDirectoryService on a discovered MediaServer.

1.2 Does UPnP allow discovery of optional services?

Yes. When a UPnP device is attached to the network, it multicasts a discovery message “ssdp:alive” to advertise its availability including the availability of any embedded devices and services. This advertisement includes optional services. The presence of optional services is not implied by a standard UPnP device or service type. Therefore, they must be discovered through access to the device (or service) description URL. The definition of required versus optional services for a standard UPnP device type is the responsibility of the UPnP Task Groups.

1.3 Does the UPnP query capability allow differentiation between common service types in different device application contexts?

Yes. A discovery response may include 0, 1, or more instances of a service type. For differentiation, each service discovery response includes a USN: ID of the root device. Within the same device, multiple instances of a service type may be identified using a relative service identifier, which includes a USN:ID.

For example, a light switch and a power switch share a common switch service. Explicit searching for a switch service would not differentiate the lighting application context. It is up to the UPnP Forum working committees to differentiate the application context of a service for purposes of discovery by defining the appropriate device hierarchy and UPnP device or service type identifiers. The fallback is to rely on the device description URL.

1.4 What value should a service advertise in the NT/ST header of SSDP packet?

The NT or ST header should specify the UPnP: type or ID of the device or service per the definition provided by the UPnP Task Groups. See the Discovery section of the UPnP V1.0 Device Architecture for additional details.

1.5 Does an SSDP Discovery Request require both the LOCATION and AL headers in the response?

In reference to the UPnP Device Architecture, the LOCATION URL for the UPnP description of the root device and the Unique Service Name (USN) must be provided in each discovery advertisement. In addition, the Search Target (ST) must be provided along with the LOCATION URL and the USN for each response to method M-SEARCH. The AL (Alternate Location) header which is a trial an error option is not required.

1.6 How are the SSDP fields “service type” and “subtype” used in UPnP Discovery?

In reference to the UPnP Device Architecture, the Notification Type (NT) and Notification Subtype (NTS) are required headers in an SSDP discovery advertisement. The NT is used to specify the device UUID, device type and if applicable, upnp:rootdevice. For announcement of services, NT is used to specify the service type. The NTS is used to specify the type of SSDP announcement which is either: ssdp:alive or ssdp:byebye.

1.7 Do SSDP discovery advertisements apply to transient services (such as handling of a single print job)?

UPnP does not support transient services. Services are enumerated in the device description, which is a semi-static description of the device and its capabilities. The requirement as well as the capability to support advertisements of transient services is a consideration for future.

1.8 Can we use UPnP in a sensor network based on a fieldbus network?

Yes, the UPnP SensorManagement DCP provides a bridge to any sensor network. A mapping between the services and devices on that network are mapped to UPnP functionality through this sensor bridge.

1.9 How can a proprietary device or service be discovered?

A proprietary device or service is one that by definition does not conform to a standard UPnP template.

However, if the device or service provides all the components of UPnP discovery, description, control and eventing, it may be discovered just like a standarqad UPnP device or service. The name of a proprietary device must include a prefix other than the UPnP domain:  “urn:schemas-upnp-org” to avoid naming collisions. Integer version numbers should be used just the same as it is for standard templates. But the benefits of re-usability and logo certification are not available to devices and services that do not conform to a standard UPnP template.

1.10  IPv6

UPnP architecture supports IPv6 and IPv4 through a dual-stack design that is based on IETF specifications. This capability is described in Annex A of the UPnP Device Architecture. Support for dual-stack IPv4/IPv6 is required in UDA 1.1 and recommended for all implementations of UPnP functionality.

2.1 Will UPnP state variables support an Enum type?

Different people mean different things when they say Enum:

• Some people mean the ability to specify a list of possible values from which a user should choose. The related scenario is a list box where an Enum would be used to supply values in the list.
• Others use Enum to mean a state variable that can have one of a specified set of values. For example, one could specify a state variable that can only contain the values "CD," "Radio," or "TurnTable.” This state variable would then be used to specify the mode into which a stereo system should place itself.

Enums as Arrays

The first case refers to scenarios where a state variable needs to contain multiple values simultaneously. We believe that this scenario is addressed by the addition of arrays to future version of UPnP.

A related scenario is one where a user needs to select multiple values from a single list box and return the selected values to the service. Again, it is believed that array support addresses this scenario, because the Control point can send in an array that contains the values back to the service.

Enums as Used in Programming Languages

The second case covers the more traditional concept of an Enum as understood by programmers. That is, a variable whose value must be one of a selected set of values. All version of UPnP support Enums for string data types via the “AllowedValueList”.

2.2 How will UPnP support specifying the unit of a state variable such as Fahrenheit or Celsius?

In the base case, a state variable will have its unit predefined. That is, a state variable's value will be expected to always be in meters, grams, Celsius, and so on.

However, in some cases it may be desirable to have a state variable whose unit can alter. For example, a device may want to be able to list temperature in either Kelvin or Celsius depending on the sensitivity of its thermometer. In those cases, a second state variable will be created that specifies the unit currently being used.

Future versions of UPnP may be extended to support marking up of a service description to specify either which predefined unit a state variable is using or, if the state variable might be using different units, which state variable specifies the units in use by the first state variable.

2.3 May a UPnP vendor add state variables to a standard service?

Yes. The syntax used to define the service, uses FXPP.

FXPP specifies how to ignore information that is not understood. Therefore, it is possible to add new information to the service description, such as a state variable, and be sure that down-level systems will safely ignore it. Vendor extensions are explicitly supported through the use of the X_prefix convention described in the UPnP Device Architecture.

2.4 Will UPnP support notifications of changes to the description document?

Yes. Changes in the state of a device can cause changes in its description document. For example, a Control point may send an action to change the human-friendly name of the device. Alternatively, the device itself may be upgraded.

2.5 Do clients have to reload the description document when they receive an ssdp:alive from a device with which they are interacting?

No, they do not. An ssdp:alive message is used to announce the presence of a device/service, not to necessarily announce any changes in its state. As such, receiving an ssdp:alive message from a device/service must not be interpreted as meaning that the device/service has changed in anyway. It only means that the device/service is available. If a bye-bye message is received followed by a ssdp:alive message, the device/service will need to be reloaded.

2.6 What is the difference between a device and a service?

The UPnP architecture recognizes that devices tend to consist of containers that may have other containers, services, or both. A service is differentiated from a device in that a service "does" something while a device only "contains" something. Differentiating between a "container" and "non-containers" is an old tradition that is seen, for example, in file systems where directories are a different "thing" than files. As such, UPnP decided to adopt two basic types in UPnP: a device (a container) and a service.

In practice, a service will most likely be any set of highly coherent functions that could be reasonably reused. This is a fuzzy phrase, because the lines are themselves fuzzy and alter based on the problem you are trying to solve.

Rather than creating some arbitrary set of rules that will not fit all situations and will not contribute to interoperability, the UPnP architecture provides for both devices and services. The UPnP Work Group must determine when which abstraction is best used.

2.7 Can one physical device have multiple root devices?

Yes. A physical device may be modeled as a single root device with multiple embedded logical devices or services. Alternately, a physical device may be modeled as multiple root devices. In either case, each root device provides one UPnP description with embedded device (or service) descriptions as needed. The exact modeling is the responsibility of the UPnP Task Groups.

2.8 Can one have more than one instance of the same service type in the same device? How are Service IDs handled?

Yes. UPnP technology supports Service IDs. This will enable a device to have multiple distinguishable instances of the same service on a single device.

Some device types are envisioned to have multiple embedded devices, such as WAN and LAN devices, in the case of IGDs. In cases where there are multiple embedded devices within a single root device, it is acceptable to have multiple instances of a service with the same serviceID so long as the services are in different embedded devices. Because each embedded device has its own device UUID, there is no ambiguity.

2.9 Can standard UPnP device types support optional services?

Yes. Standard UPnP device types are defined in terms of a minimum set of required services. Optional services may be specified by UPnP Forum working committees in the standard UPnP device or service description. In addition, optional services may be added by the device or service vendor to extend the capabilities of a standard UPnP type. For example, a MediaServer device may optionally include a DeviceProtection service. In general, service types should be defined to enable flexible packaging into a variety of devices. See question 1.2 for related information.

2.10 Should there be size limitations on a device (or service) description?

No. UPnP device descriptions are defined in a hierarchical manner using embedded URLs such as the description URL, presentation URL, and so on. These URL references may be used to minimize the size of the resident device (or service) descriptions with the additional requirement for Internet connectivity. It is up to the device implementer to define the actual contents and resulting size of the device description using URL references as appropriate.

2.11 Is there a limit on string length supported by UPnP?

No. For UPnP, a string is an unbounded sequence of UNICODE characters. However, the device programming environment may impose some limitations. Similarly, there may be parts of the UDA or the various DCPs that include explicit limits on the string size.

2.12 What is the syntax for specifying the allowedValueRange for a string?

Currently, has not been defined for a string. The applies to values of type “Number”(4 byte integer) and Real (IEEE 64 Bit Floating Point). Extensions for use of for datetime and strings is a consideration for subsequent versions of UPnP.

2.13 What is the UPnP method of assigning devices to a certain zone or system („House Code“, „Zone Code“)?

Groups of devices may be defined in the SensorManagement Architecture.

2.14 Should device (or service) descriptions contain device capabilities?

For example, should a printer description specify PDLs (PCL, PS, TIFF, JPEG and so) or protocol support (IPP, LPD, and so on)?

Yes. UPnP device (or service) templates defined by UPnP Forum working committees must specify UPnP device and service types (or state variables and action list) in accordance with sections 2 and 3 respectively of the UPnP Device Architecture. UPnP extensions may be added in the form of optional services, added service state variables, and actions. Capabilities beyond these are outside the scope of UPnP device (or service) templates.

2.15 How are options handled in a UPnP template?

A UPnP device template may include optional embedded devices and services. A service template may include optional state variables and actions. Approved UPnP XML templates must include specification of all options. Sample implementations of a UPnP template submitted to the UPnP Forum must include implementation of all options specified in the template.

In general, if an optional component is specified in an XML description at implementation time, it must be implemented. There are no optional components in an XML description. See the UPnP Template Guidelines for additional information on dealing with options and vendor extensions.

2.16 When the version of a service is incremented, should the version of the device that contains the service also be incremented?  And more generally, when should the version of a device be incremented?

The short answer to the first question is “Yes.”  When a service specification is updated, the device specification(s) that need to reference the updated service should also be updated. In general terms, a device spec should be updated anytime new functionality is added to the device. This allows Control Points to be more efficient locating devices that potentially have the capabilities that the Control Point is looking for.

2.17 If a device implements a newer version of a UPnP DCP, is it required to support the previous versions as well?

For example, assuming a PC only supports IGD v1.0 but my router is an IGD v2.0, will that PC be able to interact with the IGD v2.0 device?

Yes. Updated versions of device and service types are REQUIRED to be fully backward compatible with previous versions. In this example, the PC will only send an advertisement for IGD:1 but the IGD:2 router will answer to IGD:1 search requests. Please refer to Section 1 of the UDA 1.1 for more details).

2.18 How can user friendly names be assigned to UPnP devices at run time?

In Version .92 of the UPnP Device Architecture, it is possible to create a generic service option that all devices may include to support this feature. Hooks for changing a name associated with the UPnP device include issuing an ssdp:byebye, change the name in the device description, then issue an ssdp:alive announcement. Dynamic assignment of friendly names to a device is done using the FriendlyInfoUpdate DCP.

3.1 Will UPnP support heartbeats?

In some cases, the control connection between a Control point and service may be up for a long time without any communication. Unfortunately, TCP keep-alives are not sufficient to prove that a service is still up and running. That is, a service could have crashed but its TCP stack may still be operational and automatically maintain the connection. Therefore, in some cases positive action is needed on the part of the service to demonstrate that it is still functional.

The typical solution to this problem is a heartbeat. However, heartbeats are a nasty business, because badly designed ones can quickly consume significant amounts of network bandwidth.

The UPnP architecture can support heartbeats through the mechanism of having a state variable whose value is guaranteed to change at some specified interval. The UPnP Work Group and Task Groups must specify the exact interval used, the ability to adjust this interval, and other related issues.

3.2 Is bulk data transferred in-band or out-of-band in UPnP?

In theory, UPnP can support either. That is, one could transfer a file by specifying its value as a state variable and then either polling the state variable using Query State Variable or by using the eventing mechanism to transfer that value to all interested parties.

Alternatively, one could specify a state variable that contains a URL upon which Control points are expected to perform a HTTP GETs in order to retrieve the value. The two choices roughly match the perennial argument of "by value" or "by reference." The UPnP architecture supports both, so it is left to the UPnP Forum to decide which choice to use in which circumstances.

3.3 How does one read a state table variable without a state change?

When a Control point registers for events with a service, the first event it receives will have all the state variables and their current values for the service. In addition, a control point may poll a state variable by invoking the Get actions defined in the specific DCP.

3.4 How does one find out supported variables for a transient service, device defaults, and so on?

UPnP architecture supports asynchronous event notification in response to Service State Variable changes. In addition, control points may query a service for the value of a specific state variable.

3.5 Can there be optional parameters to an action?

UPnP supports required and optional actions. Optional actions are left to the implementer to determine if those actions will be specified in the service description. Optional parameters are not supported for required actions. If there is a requirement for optional parameters to an action, these actions should be implemented as optional actions.

3.6 How does one indicate increments — for example, the granularity to which volume can be set?

One can imagine a generic volume service that contains a state variable that specifies the volume in decibels. However, the tuner associated with that service might only be able to change the volume in certain predefined increments. Furthermore, these increments might not be standardized. For example, a high-end tuner may be able to handle a very small granularity of change, while a lower end tuner might only support coarse adjustments. To express granularity of control, UPnP defines a step parameter for use with the AllowedValueRange for number (Integer and Real) data types.

3.7 Will UPnP support specifying data flow paths such as a client telling a CD player to send its output to a certain set of speakers?

One can imagine having a UPnP CD player, a UPnP speaker, and a UPnP remote control. A user will expect to be able to use the UPnP remote control to specify that the UPnP speaker should get its signal from the CD player.

UPnP supports creating these sorts of data paths by giving the URL of data sinks/sources to data sources/sinks. For example, the UPnP remote control could give the URL of the UPnP CD player to the UPnP speaker. The UPnP speaker would then be responsible for performing format negotiation with the UPnP CD player in order to get the desired audio stream.

In this manner, a very simple UPnP client can create quite complex data flow paths by passing around URLs. It will be up to the members of the data path to handle the actual negotiations for the delivery of the desired data.

Note that sometimes more information than just a single URL may be necessary. For example, a UPnP remote control may want to specify that a particular CD in a UPnP CD changer be played on a particular speaker. In that case, the UPnP remote control would need to provide the speaker with both the address of the UPnP CD changer and information about the desired CD.

3.8 Will UPnP support a scheduling service such as CRON?

Yes. A ScheduledRecording service is defined in the MediaServer DCP.

3.9 How does UPnP handle state variables whose values are related to each other?

In some cases, the value of one state variable may be related to the value of another state variable. For example, setting the "play" state variable of a CD player to true will cause the "location counter" state variable to be set to a non-zero value.

Such relationships are not and do not need to be specified by the service description. Rather, they will be described in the text accompanying the service template. It is up to the client and the device to ensure that they properly maintain the relationship, but no interoperability benefit is gained by adding complexity to the service description to handle describing relationships among state variables. This is especially true in that the relationships between two state variables may be so complex that it could not be expressed by anything less complicated than code.

3.10 How does UPnP handle shared state variables across state tables?

In some cases, a state variable in one service's state table may represent the exact same quantity as a state variable in another service's state table. For example, one can imagine a television that supports picture-in-picture. The television may have two TV display services that have a brightness state variable. However, there is only one television tube, so a change in the brightness of one service will cause the same change in the other service.

No explicit support will be provided in the service template for specifying these sorts of relationships. Rather, they will be specified in the text accompanying the service template. It is up to the device to ensure that it properly manages the relationships among related state variables across services. It is not felt that providing a mechanism to explicitly call out these relationships is sufficiently compelling to merit complicating the UPnP model.

3.11 How does UPnP handle devices with modal services?

Some devices have a number of sub-devices or services that can operate modally.

The exact manner in which this will be modeled in UPnP is up to the UPnP Forum to specify. Sub-devices can be defined as well as multiple services within a device.

One example of a possible solution is to create a modal service that can list which modes are available and specify which mode is currently in use. This would allow a generic controller to be written that can alter the state of modal services without necessarily knowing anything about the underlying services.

3.12 How should the range for a state variable be expressed if that range can alter dynamically?

In certain scenarios, a Control point may want to be able to change the range of legal values for a variable. For example, a Control point may want to specify to a volume control that it should not offer a volume in excess of a certain decibel. A simple mechanism to allow the Control point to specify changes is to create a state variable that specifies the current range.

However, this begs the question of alterations to the service template. That is, if the range is altered should the service template be updated to specify the new range?

In general the answer is no. Any service that supports dynamically altering the range will also have to support having state variables that specify the current range. As such, any Control point that uses that service will, when it synchronizes with the service's state table, find out the current range, and make sure to stay within that range. The service template's job is only to specify the absolute maximum and minimum, not any transient limitations.

3.13 How does one define a Service Template for a class of services?

A question was raised about how one defines "base" services. That is, one could imagine defining a generic service and then having more advanced versions of that service inherit from the basic service. For example, one could imagine defining a basic Tuner service and then later defining a new service for advanced digital tuners that inherits functionality from the base Tuner service.

Inheritance will be accomplished by exposing both the base interface and the advanced interface. That is, if a device supports the advanced tuner service, then the device will be required to advertise support for both the basic tuner and the advanced tuner services. Because the advanced tuner service is a proper superset of the basic tuner, the device will be able to support clients that support either the basic or the advanced interfaces.

Although it might be nice to add support for explicitly stating that a particular Service description inherits from another service, this feature adds nothing to interoperability because it would still be necessary to declare both interfaces for discovery purposes.

3.14 Can one have actions with no state change?

Yes. A service may define actions that simply request information without making any changes.

3.15 Are there asynchronous calls in UPnP? Can the devices communicate in asynchronous mode?

Whether asynchronous or synchronous calls are available to applications on a particular platform is dependent on the software development environment and protocol stack you are using. It is possible for stacks to accept an action request and return immediately to the application without blocking, and then later deliver a message to the application with the result of the action. However, care must be taken to match a response with its corresponding request.

3.16 How should acceptable values for parameters be specified?

For example, how can a UPnP device template be specified for the pixel resolution properties — such as “640x480” or “320x240” — supported by a range of camera devices?

Currently, the enables explicit definition of supported “string” data types in a service description. Similarly, the enables specification of minimum and maximum values for Numbers (integer) or Reals (floating point) suitable for the application. In either case, optional service state variables may be defined by UPnP Forum working committees to provide flexibility to address implementation specific requirements. State variables defined for this purpose should be augmented by English description in the UPnP service template. To address the multiple pixel resolutions supported by a camera device, a device vendor may add an explicit to the service description depending on the camera specifications.

3.17 Are UPnP numbers floats or doubles?

UPnP supports Numbers and Reals. Numbers are 4-byte fixed point integers. Reals are IEEE 64-bit floating point doubles. In addition, UPnP supports a Hexadecimal representation of binary data.

3.18 What provision does UPnP have for specifying return values in response to an action?

UPnP uses the SOAP message protocol for request messages and it includes an acknowledgement of the command by the service.

To address fault conditions, UPnP defines a coupled with a of up to 256 characters for a return value when a service does not accept an action request. It is up to the UPnP Forum working committees to define the for a UPnP service type. See UPnP Device Architecture section on Control: Messages: Response.

In addition, UPnP uses GENA eventing to asynchronously notify all subscribing Control Points of the current state of a service variable when that variable changes state. In this manner, SST variables can be used to return the status of an action request.

The timing for changes in a service’s SST variables and subsequent event notification in response to a command is determined by the Controlled Device. It is the responsibility of the UPnP Forum working committees to define the set of state variables required to effectively interact with a device or service.

For additional details, see UPnP Device Architecture section on Eventing: Event messages.

3.19 Should DCPs define a standard setup/configuration service?

Yes. See DeviceManagement DCP.

3.20 What about hosting multiple document control protocols? Can one specify several [alternative] protocols such as LPD, IPP, or UPnP?

A UPnP device (or service) description specifies a wire protocol based on SOAP for use in action requests and responses. The UPnP SOAP message protocol is required for UPnP compliance. The means for handling non-UPnP protocols is outside the scope of UPnP.

3.21 Will UPnP provide secure access to device descriptions?

Yes. Please see DeviceProtection DCP.

3.22 Multicast DNS has been taken out of the spec. What will take its place?

The foundation for UPnP networking is IP addressing. Each device must have a Dynamic Host Configuration Protocol (DHCP) client and search for a DHCP server when the device is first connected to the network. If a DHCP server is available, i.e., the network is managed, the device must use the IP address assigned to it. If no DHCP server is available, i.e., the network is unmanaged, the device must use Auto IP to get an address. In brief, Auto IP defines how a device intelligently chooses an IP address from a set of reserved addresses and is able to move easily between managed and unmanaged networks. If during the DHCP transaction, the device obtains a domain name, e.g., through the DHCP FQDN option, the device should use that name in subsequent network operations; otherwise, the device should use its IP address.

3.23 Will UPnP support a time type for state variables?

Yes. UPnP will support a state variable type to specify a time without a date using additional XML Data Types.

3.24 How are comma separated string values treated in UPnP?

State variables may be declared as a string data type in an xml service description. For UPnP, strings are defined by the XML string data type. Thus, all UPnP state variables of datatype string may be represented by an unbounded sequence of Unicode characters. In a string representation, commas within the string body have no special significance to UPnP. The interpretation of a comma delimited string is dependent on the service which parses the data. Array indexing is a feature under consideration for future versions of UPnP.

3.25 What is the relationship between UPnP action arguments and state variables?

State variables define the state of a UPnP service. Each service defines actions that may be invoked by a control point to have some affect on the state of the service. The relationship is: An action’s arguments are used to model an effect the action has on a state variable.

In some cases, the action’s arguments are service state variables. In other cases, action arguments are parameters that determine the effect on a related state variable. For example, a clock service may declare an action “SetDateTime” with an associated argument “NewDateTime” to specify the effect the action has on the “DateTime” related state variable. Thus the action argument “NewDateTime” specifies the resulting value of the “DateTime” state variable in response to invoking the “SetDateTime” action.

Thus for each argument to an action, the RelatedStateVariable that is affected must be specified.

3.26 How can a state variable be specified in a service template for values that must be configured at run-time?

For example, when downloading an image from the web, it is desirable to support MIME types that are unknown at implementation time when the XML description is frozen.

UPnP can provide information in a service description to address this requirement. Choices include use of “allowedValueRange” to specify legal numeric values and “allowedValueList” to explicitly enumerate legal string values. To enable run-time configuration of MIME formats, a service template should be used to specify the “currentFormat” state variable’s “allowedValueList.”

At run-time, a control point may invoke a “SetCurrentFormat” action exposed by the service description to configure the service. When a control point selects an image from the web, it may invoke a QueryStateVariable action to determine the “currentFormat” the service is configured for. Alternately, the control point may check the MIME type against the “allowedValueList” in the service description to determine if it is one of the supported types. Subsequently, the control point invokes a “SetCurrentFormat” action to configure the service for the MIME type.

An image service may go a step further by issuing an SSDP “ByeBye”, and modifying it’s xml description effectively creating a new logical device. This allows the service to re-configure the “allowedValueList” of supported MIME types at run-time.

XML declaration of  “currentFormat” with “allowedValue” enumeration of MIME types.

      currentFormat
    string
     
            Image/png
            Image/jpeg
     

   Actions invoked by control point:
   QueryStateVariable(currentFormat) “image/jpeg”
   SetCurrentFormat(“image/png”)

Alternately, a comma-delimited string may be used instead of an allowedValueList. The advantage of this approach is that the contents of the string may be modified by the service at run-time and eliminates the need to specify supported MIME types at implementation time. Using this approach, the control point invokes QueryStateVariable(supportedMIMEs ) to determine what MIME types are supported followed by a SetCurrentFormat” action to configure the service.

XML declcaration of “currentFormat” with “supportedMimes” comma delimited string

      currentFormat
    string
           

                  supportedMimes
                  string
                  image/png,image/jpeg
           

Actions invoked by control point:
QueryStateVariable(supportedMimes) “image/png, image/jpeg”
SetCurrentFormat(“image/png”)

3.27 How can an image URL data type be specified using UPnP?  

A state variable “targetURL” of string datatype may be declared in the service description at implementation time to contain a URL. If supported URL character strings are known, they may be specified in an allowedValueList associated with “targetURL”. Alternately, if supported URLs are not known at implementation time, a second string variable “SupportedURLs” may be declared for initialization at run time to contain a comma delimited list of supported URLs. See question 3.25 above for related details.

3.28 Is multi-session support required for UPnP services?  How are multiple clients modeled in a UPnP Template?

No, there is no provision for multi-session support in the current UPnP Device Architecture. In the absence of multi-session support, services act on the last action received. Support of multi-sessions is a consideration for future versions.

4.1 How does the GENA framework apply to UPnP?

Please see the UPnP Device Architecture, section 4 for details on UPnP eventing.

5.1 Will UPnP support form-based input validation features?

UPnP Service descriptions tend to focus on providing the information necessary to draw and control a UI for a service/device pair. This is appropriate, because many control scenarios can be accomplished easily and cheaply by remoting high-level UI information.

However, this bias has lead to the mistaken assumption that UPnP is attempting to specify a generic form manipulation language. For example, there have been requests for UPnP to be able to specify in the service template the specific syntax that would be acceptable for a particular state variable. Thus, one could specify a state variable that is to contain a person's first and last name and specify in the service template a regular expression that would validate that the name was in the correct format.

Form validation is out of the scope for UPnP. Although there may be written assumptions in a service template regarding the exact format of a particular string value, the assumption will be given in English rather than in any automated format.

The reason for this decision is that form validation is a slippery slope that very quickly leads to the need to specify Turing complete languages to support full validation. This would mean extending the service description to allow the inclusion of programmatic code/script that could be run by any arbitrary Control point.

Given that one can include directives for validation that can be enforced by both the Control point and the service without extending the service template, it would seem most appropriate to not provide Regular Expression or other validation support programmatically in the service description.

5.2 How will UPnP deal with UI on devices with different user interface characteristics?

The presentation URL through UPnP, allows each device to adopt whichever UI solution is most appropriate for it.

The key to UPnP's generic UI support is HTTP content negotiation. One can specify the characteristics that the response should have, using HTTP headers. For example, one can use the HTTP accept-language header on a request for a presentation URL to specify the language in which the device should present its UI. Similarly, one can use the HTTP accept header to specify the MIME type of the returned data.

The RemoteUI DCP can also be used to address UI features appropriate to a particular device or service.

5.3 How does a control point issue commands to a device if the optional device presentation layer is not present?

Control points do not rely on the presentation layer to issue commands to a target device. Instead, they retrieve the target device’s description in order to invoke actions from its services. Optionally, the target device’s description may include a presentation URL. The presentation URL identifies an HTML presentation page which may be loaded in the control point’s browser for use in controlling the device. The capabilities of the HTML presentation page are vendor specific. The presentation page may invoke some or all of the commands specified in the device’s service descriptions, but it is not required to use this action set.

6.1 Discovery

6.1.1 Will UPnP support discovery through web page and the Cloud?

Yes. See W3C Device API Working Committee draft specification “Discovery API.” An architecture for cloud-based UPnP support is currently being developed.

6.2 Description

6.2.1 Will UPnP support arrays as a data type for state variables?

Yes. Future versions of UPnP will support arrays as a data type for state variables.

6.2.2 Will UPnP support XML as a data type for state variables?

Yes. Future versions of UPnP will support XML as a data type for state variables.

6.2.3 Will the UPnP state table be made hierarchical?

There has been some question as to the sufficiency of a flat state table to describe services. Although no examples have been forthcoming to demonstrate why a flat table is insufficient, there still exists a nagging doubt. It is believed that the addition of support for array and XML data types to future versions of the UPnP state table will address these concerns.

6.3 Control

6.3.1 What kind of streaming support will UPnP provide?

UPnP does not provide for streaming support as part of its architecture. Rather, it provides for a format negotiation framework that allows a Control point and a device to decide between them which streaming protocol they want to use.

6.3.2 Will UPnP only support TCP eventing?

Requests have been made that UPnP support events over UDP. In the short term, UPnP will only support TCP eventing because UPnP's state model requires tight synchronization between the Control point and the service, requiring guaranteed delivery of all events. If eventing used UDP, then events could be lost without the Control point or service knowing; thus, the control point's copy of the service's state table would get out of synch and cause the Control point to send bad actions.

However, the UPnP eventing mechanism -- GENA -- supports UDP events. Therefore, if at a future date the architecture is expanded to support scenarios in which unreliable eventing makes sense, the UDP GENA features can be added.

6.4 Eventing

6.5 Presentation

7.1 Does OCF provide technical support for specific UPnP product implementations?

No. OCF administers the UPnP certification and logo licensing programs and does not offer technical support for specific products or applications. For technical support or questions about specific product features and capabilities, you will need to contact the product manufacturer directly.

7.2 Can OCF offer assistance with UPnP open source code?

No. OCF cannot take responsibility for or assure correctness of open source code implementations that have not been certified and recommends that you refer to the originator of a respective stack for guidance. If you are an open source code provider, we encourage you to join OCF and test your implementations against the UPnP Certification Test Tool to ensure adherence to the UPnP specifications and to prevent potential interoperability problems.

7.3 Can you explain how security is addressed with UPnP technology?

Please see DeviceProtection and IGD:2 DCPs. Also, when security issues are found, the UPnP Steering Committee responds with clarifying information and may initiate immediate changes as necessary.

7.4 Does my company have to be an OCF to implement UPnP DCPs in devices and create applications based on them? What are the limitations of using UPnP technology if I am not an OCF member?

The UPnP Device Architecture Documents and Standardized DCPs are publically available for anyone to access and implement in devices and control points; however, you are encouraged to sign the OCF Membership Agreement which offers shared rights to RANDZ contributions. This benefit offers a balanced protection of member investment in the technology with confidence in the ability to implement under royalty-free terms.

For instructions on how to join OCF or become a Non-Member Licensee, please visit our Join page.

7.5 How can I make my application NAT Traversal?

The specifications needed for NAT traversal are the UPnP Device Architecture and the Internet Gateway Device specification.

Several vendors have SDKs and UPnP open source stacks that may provide a good foundation for implementing these specifications. OCF maintains a list of some, but not all, which can be found here.

7.6 Where can I find an overview on UPnP technology?

There are several resources available on the UPnP Forum website such as the following:

• Presentations and Whitepapers
• Press Releases and Newsletters

8.1 What is the process for UPnP specification development and publication?

New work items may be proposed at any time at the UPnP Work Group within OCF. A charter proposal is first generated with analysis of the market need and inclusion of use cases. If the UPnP Work Group approves of the charter, a Task Group is formed to develop the technical requirements to meet the use cases through the generation of Device Control Protocol (DCP) specifications. Sample implementations are then developed by a variety of Task Group participants to validate the specification. The resulting specifications, sample implementation test logs and sign-off documentation is then reviewed by the UPnP Work Group and then the OCF Board of Directors. Once approved, the specifications then go through a 60-day member ‘comment and disclosure’ period. If there are no substantive issues brought forth by the end of this comment and disclosure period, the Board will vote to approve them for publication. At this point, UPnP Licensees may then submit their devices that adhere to these new Standardized DCPs for UPnP certification.

8.2 How does one go about proposing a new work initiative?

At any time, a Member may petition the UPnP Work Group for establishment of additional Device Classes and corresponding Task Groups.

8.3 Who indicates the services that are implemented within a respective device using UPnP technology? Does the manufacturer or OCF determine the appropriate services?

UPnP® Certified devices must implement the required service(s) as defined in the applicable Device Control Protocol (DCP) standard. These services are defined by the UPnP Task Group; however, the UPnP Device Architecture does allow vendors to make extensions to existing DCPs by implementing their own vendor-defined services. The complete list of the device types for which UPnP® Certification is offered and the standardized service DCPs can be found on this site here.

8.4 Does OCF allow non-Standardized UPnP DCPs (device and service definition) to be created by other standards organizations?

The UPnP Device Architecture allows vendors to make extensions to existing DCPs as well as create their own DCPs. However, if not created within the context of OCF, there are downsides:

• Any DCP created is not certifiable with OCF’s growing range of UPnP test tools
• You may find issues with your DCP approach as you move forward without review within the UPnP Work Group. Similarly, a wider range of potential implementers aren't able to review or implement the DCP
• If you are not a member of OCF, you will not be able to enjoy the member rights and benefits licenses available under OCF.

Another approach would be to standardize your DCP within OCF and then reference it in another standards organization.

9.1 Does UPnP V1.x SSDP work on the WAN?

No. UPnP SSDP messages shall only be used on the LAN side. If SSDP messages are found on the WAN side these messages are not compliant. Even IPv6 SSDP messages are site local only.

9.2 Does UPnP have a predefined HTTP port?

No. UPnP announces HTTP endpoints for SOAP and GENA by means of SSDP messages. The implementation decides which HTTP port it can use and randomizes the port at startup. Randomization of the SOAP port prevents brute force attacks. The only fixed port in the UPnP specifications is the UPnP (SSDP) multicast port 1900.

9.3 Can UPnP traffic on the LAN be secure?

Yes. The UPnP DeviceProtection standard specifies the use of HTTPS for device control.

9.4 Can UPnP be used in the Cloud?

Yes. UPnP+ specifies how devices can be securely discovered and controlled in/from the Cloud. The mechanics to do this are different than those for LAN-based devices. It uses XMPP to talk outside of the LAN. XMPP uses SASL for authentication and TLS for encrypting the link (See also RFC 6120). The link is used to convey all UPnP traffic securely on the WAN, preventing man-in-the-middle attacks. UPnP 1.x specifications are only defined to be used on the LAN (not defined for the WAN).