Understanding the network impact of UPnP
Pelco Cameras, Pelco Video Management
How Universal Plug and Play Search works
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 (188.8.131.52: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.
Search request with M-SEARCH
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: 184.108.40.206: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.
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.
- UPnP Device Architecture Specification: http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
- RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. Available at: http://www.ietf.org/rfc/rfc2119.txt
- RFC 2710 Multicast Listener Discovery for IPv6. Available at: http://www.ietf.org/rfc/rfc2710.txt
- RFC 2616 HTTP: Hypertext Transfer Protocol 1.1. Available at: http://www.ietf.org/rfc/rfc2616.txt.
- RFC 2279 UTF-8, a transformation format of ISO 10646 (character encoding). Available at: http://www.ietf.org/rfc/rfc2279.txt