UPnP協定将整個通信過程分為五個步驟，分别是：
Step0：位址配置設定，也就是裝置通過DHCP等協定擷取IP位址的過程。UPnP通信的前提條件。
Step1：裝置發現（Discovery），controlpoint通過這一步驟找到感興趣的UPnP裝置。
Step2：裝置描述（Description），control point擷取裝置描述資訊，進而了解裝置所能提供的服務類型等具體資訊。
Step3：裝置控制（Control）。
Step4：Eventing。
Step5：Presentation。
本系列執行個體中所使用的環境：
DMS：VMware + Ubuntu14 + MiniDLNA1.13。IP位址是192.168.159.129。
DMP： Win7 + Foobar + foo_upnp插件（0.99.48）。 IP位址是192.168.159.1。
裝置發現是UPnP的第一個步驟。對應協定棧如圖所示：
SSDP的Notification一共有三種類型——ssdp:alive，ssdp:byebye和ssdp:update。當一個新裝置加入到網絡中後，按照協定應向網絡中的控制點廣播ssdp:alive通告，即advertisement。
在我們的環境中，在關閉Foobar的情況下首先啟動miniDLNA。這時DMS立即連續發送了24條SSDP封包，即廣播的advertisement。目的IP為協定中定好的廣播位址239.255.255.250，斷口号則固定為1900（[1]文檔1.2節），如下圖所示：
這24條封包可以分為4組，每組6條。第1-6條封包與第7-12條封包的内容完全一緻。第13-18條封包與19-24條封包的内容一緻。其中第三組封包構成一套完整的ssdp:alive通告，向網絡中的其它裝置宣告自己存在。第一組封包是與第三組封包内容相對應的ssdp:byebye通告。這是為了確定在釋出alive通告之前，清除control point上可能存有的關于本裝置及服務的舊的狀态資訊。第二組與第四組封包分别是第一組與第四組封包的重複，這是因為SSDP是基于非可靠的UDP傳輸，UPnP協定允許裝置在釋出通告的時候重複一兩遍，以確定感興趣的control point能發現自己。
我們主要分析一下第三組封包。
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:uuid:4d696e69-444c-164e-9d41-000c29955b1d
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d
NTS:ssdp:alive
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:upnp:rootdevice
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::upnp:rootdevice
NTS:ssdp:alive
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:device:MediaServer:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:device:MediaServer:1
NTS:ssdp:alive
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:service:ContentDirectory:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:service:ContentDirectory:1
NTS:ssdp:alive
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:service:ConnectionManager:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:service:ConnectionManager:1
NTS:ssdp:alive
NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1
NTS:ssdp:alive
前三條封包一起構成了device的通告，其中CACHE-CONTROL字段描述了這條alive通告的生存時間。網絡中的裝置在發送首條alive通告之後，會每隔一段時間重複發送一套alive通告，或者叫做心跳封包。此條封包中max-age等于1800，即UPnP協定推薦的預設值（1800秒即30分鐘），如果control point超過半個小時仍然沒有收到下一條心跳封包，則會認為這個裝置已經挂掉，并将該裝置從可用裝置清單中移除。
LOCATION字段包含了一個絕對路徑的URL。在UPnP通信的第二個步驟裝置描述中，control point将通過這個URL獲得裝置的描述資訊。
三條封包的NT/USN字段各不相同。UPnP協定規定對于rootdevice來說，每次通告共需要發送三條封包。對應的NT字段分别是rootdevice，UUID和裝置類型。如果裝置還包含有embedded device的話，每個embedded device則隻需要繼續發送後兩種NT字段構成的封包。這一部分的協定具體見文檔[1]的29頁。
後三條封包則分别通告了該裝置所支援的服務（service）。分别是ContentDirectory，ConnectionManager和微軟自己的X_MS_MediaReceiverRegistrar。
ContentDirectory的較長的描述見文檔[3]。主要是定義了mediaserver提供的檔案浏覽服務。miniDLNA支援這一服務後，control point就可以通過ContentDirectory:Browse動作來進行檔案目錄浏覽。
ConnectionManager的較長的描述見文檔[2]。定義了裝置間的流媒體傳輸模型。這兩個實際上是DLNA MediaServer必不可少的service。
X_MS_MediaReceiverRegistrar是微軟自己定義的服務，miniDLNA較新的版本支援這一服務主要是為了提供對Xbox的支援。
miniDLNA啟動之後，再啟動安裝了foo_upnp插件的foobar。這相當于在windows主機中啟動了一個MediaRenderer和一個MediaServer（通過Notify封包内容分析，兩者實際上是作為兩個獨立的rootdevice），提供自己對應的服務。這部分SSDP封包的内容與上面分析的類似，也是在發送一套完整的ssdp:alive封包之前先發送一套完整的ssdp:byebye封包，MediaRenderer和MediaServer兩個裝置分别獨立通告自己的裝置類型，uuid以及提供的service等等。不做具體分析了。
做為control point的MediaRenderer，在廣播完自己的通告封包之後，向相同的廣播位址發送了一條search請求。這部分封包格式的較長的描述見文檔[1]的1.3。封包内容如下：
M-SEARCH * HTTP/1.1
MX: 5
ST: upnp:rootdevice
MAN: "ssdp:discover"
User-Agent: UPnP/1.0 DLNADOC/1.50 Platinum/1.0.4.2-bb / foobar2000
Connection: close
Host: 239.255.255.250:1900
其中第一行M-SEARCH * HTTP/1.1表明這是一條search request資訊。
MX：5是請求的最大等待時間，機關是秒。UPnP協定規定網絡中響應請求的裝置應該随機在0~最大等待時間範圍内作出響應。這是為了避免網絡規模較大時，大家同時給響應造成網絡擁塞。同理control point也可以跟據網絡的規模大小設定适當的最大等待時間。
MAN字段是為了遵守HTTP Ex tension Framework的協定規範，在這裡是一個固定值。
最重要的字段是ST字段，即search target。在本例中target是rootdevice，那麼随後miniDLNA作為rootdevice将給出回應。
前文說作為rootdevice，miniDLNA一共需要三條封包來通告自己的device。那麼為響應control point的searchrequest，它隻需要把對應于search target的一條通告封包重新發送一遍即可。如下：
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Sat, 25 Oct 2014 04:13:26 GMT
ST: upnp:rootdevice
USN: uuid:4d696e69-444c-164e-9d41-000c29955b1d::upnp:rootdevice
EXT:
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
LOCATION: http://192.168.159.129:8200/rootDesc.xml
Content-Length: 0
簡單總結一下，裝置發現過程其實很好了解：
DMS啟動：
大家好，我來了，我是rootdevice，我的uuid是xxx，我是MediaServer哦
我還能支援A服務，B服務和C服務哦~
（此後每隔一段時間發送一遍，表明我還活着）
DMR啟動：
大家好，我來了，我是rootdevice，我的uuid是xxx，我是MediaRenderer哦
我還能支援D服務E服務和F服務哦~
（此後也要每隔一段時間重複發送一遍，生怕别人以為它挂了）
DMR： 對了，我是controlpoint，是rootdevice的吱一聲呗~
DMS：
吱~~
（OK，裝置發現完成！）
[1], UPnP-arch-DeviceArchitecture-v2.0-20140901.pdf
[2], UPnP-av-MediaServer-v1-Device-20020625.pdf
[3], UPnP-av-ContentDirectory-v1-Service-20020625.pdf
[4], UPnP-av-ConnectionManager-v1-Service-20020625.pdf
http://upnp.org/resources/upnpresources.zip
http://upnp.org/resources/upnpresources.zip