Question

i am programming something about upnp and i would like to clear something 🙂
When i search with multicast M-Search message, devices must respond, with something like this(it is not complete message, i shortened it)

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

So, location is some IP and port, from where i can get description. Now, i would like to search for specific device with unicast. My question is: can i use this address when i am trying to search for this device using UNICAST search message? or devices are listening on another address for unicast msearch messages? 🙂 I have read upnp device architecture pdf file

Answer 1

Yes you can and must continue with unicast. LOCATION is not only “some IP and port” but a full resource location of device description. You can’t do multicast to a single address 🙂 There is no more “searching for this device” to do. You simply ask for that URL with HTTP GET. And you will basically get some more URLs of the specific services.

If you are “programming something about upnp” and having this kind of fundamental questions, i recommend downloading UPnP specifications bundle and reading document UPnP-arch-DeviceArchitecture. It describes in understandable steps, how the searching and querying phase of UPnP works.

Update upon OP’s clarification:

Rediscovery of a device happens as unicast request to the IP known from original response (to multicast SEARCH) and either the standard port 1900 or a specific port, if the device announced itself via NOTIFY multicast message with a SEARCHPORT.UPNP.ORG value. So if the device needs rediscovery and didn’t announce itself, the port defaults to 1900. See also the next page 32 in UPnP device architecture, description of HOST header field.

Note however, that such rediscovery should not be necessary, or very rarely. UPnP devices are expected to announce themselves upon connecting to the network with NOTIFY multicast packet of type ssdp:update, and type ssdp:byebye upon disconnecting. Furthermore, most of the devices have evented variables to which control points should subscribe automatically, and renew their subscription by a fixed lease time (by default 30 minutes). So an abrupt disappearance of device will be discovered anyway (by failed subscription renewal).