Upnp指令

最新推荐文章于 2024-08-15 09:55:07 发布

RationalGo

最新推荐文章于 2024-08-15 09:55:07 发布

阅读量3k

点赞数

分类专栏： DLNA

DLNA 专栏收录该内容

48 篇文章 1 订阅

订阅专栏

UPnP是DLNA里面比较重要的一块，相对也是复杂的一块，大致过了一些协议，发觉确实还是比较复杂，什么SSDP，GENA，HTTPMU，都是很新的东西。相关的协议也没有比较好的中文版，索性装了几个相关软件，对照资料来看这块。

注：下面所写都是最基本的DMS和DMP的交互，未涉及到DMC。

首先是SSDP，说的很玄乎，其实很简单，其实就是HTTP的扩展，跑在UDP层。具体就是DMP启动的时候会对地址239.255.255.250，端口1900进行组播，发送M-SERACH的HTTP包，当局域网内存在DMS的时候，会向DMP回复200OK的UDP回应包，并且将设备信息以XML地址的形式发给DMP。

M-SEARCH包：
M-SEARCH * HTTP/1.1
MX: 5
ST: upnp:rootdevice
MAN: "ssdp:discover"
User-Agent: Platinum/0.4.7
Host: 239.255.255.250:1900
Content-Length: 0

200OK回应包：

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Mon, 07 May 2012 17:45:09 GMT
EXT:
LOCATION: http://192.168.1.1:49152/description.xmlOPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: d8c7247e-1dd1-11b2-800e-aec4589eb099
SERVER: Linux/2.6.32.27, UPnP/1.0, Portable SDK for UPnP devices/1.6.12
X-User-Agent: redsonic
ST: upnp:rootdevice
USN: uuid:898f9738-d930-4db4-a3cf-001fa391140c::upnp:rootdevice

之后就是GET /description.xml HTTP/1.0，取得设备描述文件。另外还取了/web/cms.xml，/web/cds.xml，/web/msr.xml，之后还会SUBSCRIBE cms，cds两个event，说实话，不是很明白这样做的意思。

我看的设备大致有提供下面几种服务，ContentDirectory ，Connection Manager，X_MS_MediaReceiverRegist，我所遇到的，就在DMP浏览的时候，主要就是用到Content Directory，发送SOAP消息过来，DMS回复下级的目录文件。

SOAP命令包如下，发到cds_control 。对应的服务就是ContentDirectory ：

POST /web/cds_control HTTP/1.0
Content-Type: text/xml; charset="utf-8"
SOAPAction: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"
Connection: close
User-Agent: Neptune/1.0.1
Host: 192.168.1.1:49152
Content-Length: 514

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
<ObjectID>0</ObjectID>
<BrowseFlag>BrowseDirectChildren</BrowseFlag>
<Filter>*</Filter>
<StartingIndex>0</StartingIndex>
<RequestedCount>1024</RequestedCount>
<SortCriteria></SortCriteria>
</u:Browse>
</s:Body>
</s:Envelope>

回应是一个BrowseResponse，比较长，就不贴上来了。

至于播放，则是HTTP，直接一个HTTP的GET（非80端口），获取相关的图片，视频，音频文件，然后本地的播放器接收从HTTP过来数据并进行处理。也就是说实际上DMS是把所有的媒体文件都暴露出来的，只是一开始不知道地址而已。个人觉得这样还是有点危险。

（以下报文是抓的WIN7 mediaplayer）
GET /WMPNSSv3/1354046559/1_ezgxQjcwMUM2LTJBMTMtNDM2Qy05RUUyLTY2Njc0NUYyQzlCM30uMC40.mp3 HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: getIfoFileURI.dlna.org
Accept: */*
Range: bytes=0-
UserAgent: NSPlayer/12.00.7601.17514 WMFSDK/12.00.7601.17514
GetContentFeatures.DLNA.ORG: 1
TransferMode.DLNA.ORG: Streaming
Host: 10.2.7.130:10243

回的报文是206而非200，主要是表示了文件范围（貌似迅雷，快车也使用的这个报文回应以实现断点续传），端口也不是标准的80，在这里是49414。
HTTP/1.1 206 Partial Content
Content-Length: 5701842
Content-Type: audio/mpeg
Last-Modified: Fri, 14 Oct 2011 01:17:16 GMT
Server: Microsoft-HTTPAPI/1.0
Accept-Ranges: bytes
ContentFeatures.DLNA.ORG: DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000 Content-Range: bytes 0-5701841/5701842
TransferMode.DLNA.ORG: Streaming
Date: Tue, 08 May 2012 09:18:44 GMT

然后就是具体的MP3内容。

嗯，是不是很简单？嗯，这样看的确不算太复杂。