抓包分析DLNA——（2）设备及服务描述

“设备发现”完成之后，control point已经知晓的信息包括：

（1）    设备的IP地址，从接收到的SSDP广播报文的源IP地址中获得。

（2）    设备的UPnP设备类型，UUID，以及设备描述的URL。

（3）    设备能够提供的服务。

但这时control point对设备所了解的信息仍然很少——仅限于SSDP通告报文里包含的那一丁点。为进一步增进了解，促进沟通，在接下来的这个步骤里，control point将通过一系列HTTP GET/GET response来先后获取设备及设备所能提供服务的详细描述。

设备描述的数据传输过程比上一个步骤更容易理解，所对应的协议栈如图所示：

首先，control point根据SSDP报文中的LOCATION字段提供的URL发起HTTP GET请求：

DMS接收到请求之后返回即rootdevice的详细描述，这是一个由设备商编写的xml文档，通常是基于UPnP提供的设备描述模板。这是一个基本的HTTP GET请求以及响应过程，但返回的xml文件需要我们仔细分析一下。

设备描述中主要包含一系列与设备制造商相关的信息，embedded device的定义（本例中没有），用于步骤五presentation的URL（本例中为空），以及device所支持的全部服务的列表，包括服务描述URL，以及用于步骤三control和步骤四eventing的URL。

关于device description xml的详细介绍请参考文档[1]的2.3小节。

接下来，control point根据各个服务描述的URL，通过HTTP GET逐个获取各个服务的详细描述。以ContentDirectory服务为例，HTTP GET请求如下：

和设备描述一样，服务描述也是由设备制造商编写的xml文档，基于UPnP提供的服务描述模板。服务描述文档里主要定义了：

（1）    服务所包含的动作（action）以及每个动作所包含的参数（argument）。

（2）    状态变量（state variable），包括数据类型，范围，以及event characteristics（状态变量改变时是否向control point发送event信息等）。

关于服务描述xml各个字段的详细定义请参考文档[1]的2.5小节。仍然以ContentDirectory为例，我们仔细看一下它的服务描述xml：

之后，control point继续重复上述HTTP GET操作，获得另外两个service的详细描述文档。

总结：

（1）    在步骤二description中，control point先后通过HTTPGET方法获得设备以及每个服务的描述文档。其中设备描述URL来自于步骤一的SSDP报文，服务描述的URL来自于设备描述文档。

（2）    设备描述文档包括设备制造商相关的信息，设备支持的服务列表，以及每个服务的描述URL及用于control/eventing的URL。

（3）    服务描述文档包含了该服务所支持的动作的详细定义，以及服务包含的状态变量的详细定义等。

在接下来的步骤中，control point将根据设备所支持的服务及服务中包含的动作对设备发起操作，同时接收设备的event信息。

[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