How a UPnP Search works

Issue

Understanding the network impact of UPnP

Product Line

Pelco Cameras, Pelco Video Management

Environment

Cameras, Endura

Cause

How Universal Plug and Play Search works

Resolution

When a control point, such as Endura Utilities, is added to the network, the UPnP discovery protocol allows that control point to search for devices of interest on the network. It does this by multicasting on the reserved address and port (239.255.255.250:1900) a search message with a pattern, or target, equal to a type or identifier for a device or service. Responses from devices contain discovery messages essentially identical to those advertised by newly connected devices; the former are unicast while the latter are multicast. Control points can also send a unicast search message to a known IP address and port 1900 or the port indicated by SEARCHPORT.UPNP.ORG, to verify the existence of UPnP device(s) and service(s) at the IP address. For example, a unicast search may be used to quickly check whether a known UPnP device or service is still available on the network. Multi-homed control points MAY choose to send discovery messages on any, some or all of its UPnP-enabled interfaces.

When a control point desires to search the network for devices, it MUST send a multicast request with method M-SEARCH in the following format. Control points that know the address of a specific device MAY also use a similar format to send unicast requests with method M-SEARCH.

For multicast M-SEARCH, the message format is defined below. Values in italics are placeholders for actual values.

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: seconds to delay response
ST: search target
USER-AGENT: OS/version UPnP/1.1 product/version

Note: No body is present in requests with method M-SEARCH.

For unicast M-SEARCH, the message format is defined below. Values in asterisks are placeholders for actual values.

M-SEARCH * HTTP/1.1
HOST: hostname:portNumber
MAN: "ssdp:discover"
ST: search target
USER-AGENT: OS/version UPnP/1.1 product/version

For a multicast request, the control point SHOULD wait at least the amount of time specified in the MX header field for responses to arrive from devices. The random distribution of responses over the MX interval means that a responder MAY send a response at MX seconds after receiving the M-SEARCH request. The MX field value MAY be adjusted by heuristics at the requester based on, for example, observed number of responders. Network characteristics affecting the propagation of traffic cannot be addressed by increasing the MX field value because of the reason cited above. A requester MAY adapt to network characteristics with heuristics based on observed network behavior (the exact heuristics are out of scope). The net effect is that the M-SEARCH request persists at the requester for a period of time exceeding MX such that the characteristics of the network are properly accommodated to minimize lost responses.

When a device receives a unicast M-SEARCH, it SHOULD respond within 1 second and it MAY respond sooner. The sender of the unicast request SHOULD wait at least 1 second for the response.

Search response

To be found by a network search, a device MUST send a unicast UDP response to the source IP address and port that sent the request to the multicast address. Devices respond if the ST header field of the M-SEARCH request is "ssdp:all", "upnp:rootdevice", "uuid:" followed by a UUID that exactly matches the one advertised by the device, or if the M-SEARCH request matches a device type or service type supported by the device. Multi-homed devices MUST send the search response using the same UPnP-enabled interface on which the search request was received. The URL specified in the LOCATION field value MUST specify an address that is reachable on that interface.

Devices responding to a multicast M-SEARCH SHOULD wait a random period of time between 0 seconds and the number of seconds specified in the MX field value of the search request before responding, in order to avoid flooding the requesting control point with search responses from multiple devices. If the search request results in the need for a multiple part response from the device, those multiple part responses SHOULD be spread at random intervals through the time period from 0 to the number of seconds specified in the MX header field. Devices MAY assume an MX field value less than that specified in the MX header field. If the MX header field specifies a field value greater than 5, the device SHOULD assume that it contained the value 5 or less. Devices MUST NOT stop responding to other requests while waiting the random delay before sending a response.

Any device responding to a unicast M-SEARCH SHOULD respond within 1 second.

The URL specified in the LOCATION header field of the M-SEARCH response MUST be reachable by the control point to which the response is directed.

The response MUST be sent in the following format. Values in italics are placeholders for actual values.

HTTP/1.1 200 OK
CACHE-CONTROL: max-age = seconds until advertisement expires
DATE: when response was generated
EXT:
LOCATION: URL for UPnP description for root device
SERVER: OS/version UPnP/1.1 product/version
ST: search target
USN: composite identifier for the advertisement BOOTID.UPNP.ORG: number increased each time device sends an initial announce or an update message

Note: No body is present in a response to a request with method M-SEARCH.

 

References