PTPIP协议中文版

欢迎关注公众号: nullobject 。
文章首发在我的博客 https://www.nullobject.cn，公众号 nullobject同步更新。

PTP/IP (PTP over IP) 是一个经过IP链接,创建在 Picture Transfer Protocol (PTP) 上的传输层
英文原版协议下载

0 说明

本文档由nullobject对应PTP-IP标准协议1.0版本进行学习整理，原版协议为英文版，学习时依靠本身理解和使用有道云翻译，对理解不到位、翻译有问题的地方麻烦批评指正。—— by nullobject in 2019-06-03 15:29

1 PTP-IP协议简介

1.1 目的

本文档描述了一个基于IP网络的ISO-15740/PIMA 1574:2000/图片传输协议(PTP)的实现。

PTP被设计用来提供与数字静止摄影设备的标准通讯。该协议指定了标准的图像引用行为、操做、响应、事件、设备属性、数据集和数据格式，以确保互操做性，还提供了可选的操做和格式，以及扩展机制。

1.2 格式规范

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, “OPTIONAL” in this document are to be interpreted as described in “Key words for use in RFCs to Indicate Requirement Levels”[5].

1.3 参考

下表列举了本文档的参考资料：

ID/Description
[1] PTP protocol, PIMA 15740:2000
[2] Computer Networks, Andrew S. Tanenbaum, ISBN:0130661023, Prentice Hall Aug 09,2002
[3] UPnP Standard, http://www.upnp.org/resources/documents.asp
[4] ZeroConf Standard, http://www.zeroconf.org
[5] Formatting Conventions. http://www.faqs.org/rfcs/rfc21129.html

1.4 手写字母缩写和缩写词

缩写	含义
TCP	Transfer Control Protocol
UDP	User Datagram Protocol
IP	Internet Procotol
PnP	Plug and Play
PTP	Picture Transfer Protocol
PTP-IP	IP Picture Transfer Protocol
PIMA	Photographic and Imaging Manufacture Association
DHCP	Dynamic Host Configuration Protocol
v4LL	IPv4 Link-Local Address

1.5 参与人员

• Petronel Bigioi – FotoNation Ireland
• George Susanu – FotoNation Ireland
• Alexei Pososin – FotoNation Ireland
• Denis McHugh – FotoNation Ireland
• Eran Steinberg – FotoNation US
• Yury Prilusky – FotoNation US

1.6 照片传输协议(“PTP”)条款

PTP规范定义了设备角色、操做、图像格式和其余相机特定的数据类型和结构。在PTP的TCP/IP实现中，全部术语和定义都按照PTP规范中定义的那样使用。

1.6.1 设备规则

从通讯的角度来看，设备能够充当启动器设备(Initiator)或响应端设备(Responder)，启动器设备至关于一个客户端，响应端设备至关于服务端。启动器设备是向响应端设备发起操做请求的设备。响应端设备则是可以响应这些操做请求的设备。一个设备可能只是一个启动器设备，或者只是一个响应端设备，或者二者兼备，但不能在同一个设备链接上同时担任两种角色。

操做请求只能由启动器设备发起；事件被响应端设备用于把有关它状态的改变通知启动器设备。

1.6.2 会话(Session)

根据PTP协议，会话被定义为两个设备之间的逻辑链接，操做和事件事务能够经过该逻辑链接进行通讯。根据PTP规范，一个响应端设备能够支持多个并发会话，每一个会话都有本身的状态。

当启动器设备请求OpenSession操做事务时将会打开一个会话，而且使用响应端设备发出的一个有效响应成功结束该请求。

会话将在启动器设备请求CloseSession操做事务时被关闭，而且使用响应端设备发出的一个有效响应成功结束该请求。当启动器设备和响应端设备之间的链接被关断开时会话也会被关闭(例如通讯超时)。

大多数操做须要在一个开放会话上下文中执行。不过，不须要打开会话就能够经过GetDeviceInfo操做获取设备功能。

支持多会话的设备必须可以使它们彼此保持异步和不透明。

1.6.3 会话ID(SessionID)

一般，若是使用相同传输级别的通讯通道，则会话ID旨在使响应端设备可以按适当的顺序分发来自不一样启动器设备的请求。对于打开不一样通讯通道的传输，对于每一个会话，不须要从新设置会话ID，由于响应端设备将可以处理多个会话。

PTP的PTP- IP传输实现不会将会话ID发送到响应端设备。响应端设备能够经过控制它容许的最大PTP- IP链接数来限制并发PTP会话的数量。

若是启动器设备的PTP-IP层发现响应端设备不接受新的PTP-IP链接，它将向PTP层发送传输特定的错误代码。在创建传输指定链接以后，启动端设备能够向远程响应端设备发出GetDeviceInfo和OpenSession请求。在这个阶段中，响应端设备可能返回一个设备繁忙(Device_Busy)的PTP错误做为对OpenSession的响应(若是响应端设备对它可以支持的并发PTP会话的数量有限制)。在这种状况下，启动端设备应该释放PTP链接，并稍后重试。

1.6.4 事务(Transactions)

事务是PTP协议中操做的基本单位，PTP协议规定的全部操做都基于事务进行。事务操做请求由启动器设备(Initiator)发起，传送到到响应端设备(Responder)，在一个会话(Session)中，同一时间只能有一个事务操做在执行，操做事务在一个会话中默认是同步的。

一个事务一般由三个阶段组成：Operation Request、Operation Response、Data Phase，以下图：

取决于事务操做自己，Data Phase这一可选阶段可能不会存在于一个事务流程中，即事务只有Operation Request和Operation Response。而当事务中存在Data Phase时，数据可能从初始化器Initiator发送到响应设备Responder(即I–>R)，或者反过来R–>I，但同一个操做中数据只能在一个方向上传输。

1.6.5 事务ID(TransactionID)

事务ID(TransactionID)用于在一个给定的会话中标识不一样事务，与在PTP协议的第9.3.1项中定义的事务ID相同，是一个32位无符号整型数字。事务ID在给定的会话中是惟一且连续的数字序列，其范围从0x00000001到0xFFFFFFFE，0x00000000和0xFFFFFFFF做为保留值不被使用。

1.7 与PTP协议一致性

在PTP标准协议的7[1]节中，为底层传输层定义了这些需求。

• PTP标准协议 7.1节：断开事件。PTP协议的这一节要求传输层必须向上层的报告设备断开。这是经过PTP-IP 层生成设备断开通知来实现的。
• PTP标准协议 7.2节：稳定、无错误通道。PTP协议的这节要求须要可靠，无错误的通道。在PTP-IP中，这经过使用配置了Keep Alive选项的TCP链接来实现。
• PTP标准协议 7.3节：异步事件的支持。PTP要求支持异步事件，在PTP-IP中，事件链接被定义为用于传输异步事件，而且与命令/数据通道是异步的。
• PTP标准协议 7.4节：设备发现和枚举。PTP要求支持设备发现和枚举服务，在PTP-IP中，设备发现和枚举使用对IP网络可用的通用解决方案来实现，可使用一个基于设备发现协议[5]的自定义UDP协议。
• PTP标准协议 7.5节：传输特定。PTP要求图像设备传输的实现符合相关机构发布的特定使用传输规范。本文档说明了如何使用位于TCP/IP协议栈上层的PTP-IP传输。

2 PTP-IP实现

2.1 PTP-IP协议模型

在PTP-IP的实现中，用户程序与PTP-IP层之间的通讯基于PTP事务模型实现，参考PTP协议的9.3[1]节，该通讯模型以下图：

本文档的目的在于制定和说明PTP-IP通讯协议，应用程序和PTP-IP层（编程接口，API）之间交互的实现并不在本文档的内容范围内。本文档仅以互操做性的方式规定两个PTP-IP实体之间的通讯。不过，PTP层（用户应用程序）和PTP-IP层之间的接口可能由如下基本类型组成：

• 操做请求(Operation Request)

  每当进行请求操做时，启动器设备(Initiator)中的应用程序就会发送一个操做请求，随即该请求被响应端设备(Responder)接受。操做请求中一般包含一组与该操做相关的参数。

• 操做响应(Operation Responses)

  每当接收到一个操做请求，响应端设备(Responder)会发送一个操做响应做为该操做请求的回应。对于启动器设备(Initiator)中应用程序发起的每一个操做请求，都须要回复一个操做响应。操做响应中老是会包含其对应的操做请求的结果代码，而且可能会包含一组参数。

• 数据读入(Data-In)

  数据读入(Data-In)是相对于用于应用程序而言的，即数据流向是从响应端设备(Responder)到启动器设备(Initiator)。

• 数据写出(Data-Out)

  数据写出(Data-Out)的数据流与数据读入(Data-In)相反。

• 事件(Events)

  PTP-IP中的事件是指有关响应端设备(Responder)的状态变动的通知，事件由响应端设备启动。

• 设备链接/断开(Device Connect/Disconnect)

  设备的链接/断开是平台相关类型的事件。这两个事件并不直接在启动器设备和响应端设备之间通讯，而是当检测到设备被链接/断开时由各自的PTP-IP层生成。

操做和事件两种事务的类型的定义在PTP协议文档的10.11、12 [1]节中能够找到，而且PTP协议在14 [1]节中为设备标准的一致性肯定了一组操做和事件。

2.2 PTP-IP传输模型

PTP标准协议文档的7 [1]节定义了PTP标准传输需求，而PTP-IP则是基于使用TCP层做为传输层实现：

与PTP同样，PTP-IP也指望从其传输层得到可靠、稳定无错误的通讯通道，而TCP(位于TCP/IP协议栈中)正是能够知足这些需求的天然传输层。TCP是一个基于流的传输层，它提供多个通讯通道(TCP Connection)和无错误的数据传输。

在PTP-IP中，两个设备之间的全部通讯都经过两个TCP链接(逻辑数据通道)进行：

因为事件自己具备异步性质，事件的数据包与操做/数据事务数据包分开分别经过两个单独的通道传输。

2.2.1 命令/数据链接(Command/Data TCP Connection)

PTP-IP的 命令/数据链接用于传输PTP操做请求、响应和数据事务，以及特定于PTP-IP的数据包。该链接由启动器设备(Initiator)创建，并标志本地及响应端设备(Responder)的IP地址和端口号。响应端设备(Responder)的IP地址和端口号一般是经过设备发现机制来肯定。

2.2.2 事件链接(Event TCP Connection)

PTP-IP的事件链接做为启动器设备(Initiator)开启的与响应端设备(Responder)之间的第二个链接，用于传输PTP事件，以及特定于PTP-IP的数据包。与命令/数据链接相同，事件链接由启动器设备(Initiator)发起创建， 并标志本地和响应端设备(Responder)的IP地址和端口号，响应端设备(Responder)的IP地址和端口号一般是经过设备发现机制来肯定。

2.2.3 传输通道管理

2.2.3.1 创建PTP-IP链接

在启动器设备(Initiator)与响应端设备(Responder)之间的通讯中，每当须要这些传输通道时，启动器设备(Initiator)将负责发起与响应端设备(Responder)的PTP-IP/TCP链接。如前文所述，PTP-IP的传输通道使用TCP链接实现：一个通道用于命令/数据传输，另外一个则用于事件传输。每一个通道都会标志本地以及响应端设备(Responder)IP地址和端口号。从PTP-IP的通讯模型中能够看到，启动器设备(Initiator)的PTP-IP其实是一个TCP客户端，对应地响应端设备(Responder)的PTP-IP则是一个TCP服务器。响应端设备(Responder)轮询等待链接请求，而且预约义(或者动态分配)了一个TCP链接端口号.PTP-IP服务端默认端口号为15740。PTP-IP链接创建过程：

PTP-IP中的TCP链接应遵循上图所示顺序进行：

1. 启动器设备(Initiator)发起命令/数据的TCP链接：指定响应端设备(Responder)的IP地址和端口号，并链接到响应端设备(Responder)；
2. TCP链接创建成功后，启动器设备(Initiator)当即发送一个Init Command Request包，数据包中须要包含启动器设备(Initiator)的惟一标识(GUID和启动器设备的用户友好名称)，例如：

3. 响应端设备(Responder)程序根据实际状况，回复启动器设备一个Init Command Ack包以告知启动器设备请求成功而且能够继续进行链接；或者回复Init Fail数据包表示请求失败，以告知启动器设备请求访问被拒绝，而且断开命令/数据的TCP链接，同时启动器设备接收到请求失败的回应后也应该断开相应的的命令/数据链接。
4. 启动器设备(Initiator)接收到Init Command Ack包后，继续发起一个事件的TCP链接：指定响应端设备(Responder)的IP地址和端口号，并链接到响应端设备(Responder)。注意该链接与第1步中的链接是区别开的。
5. 一旦链接创建成功，启动器设备(Initiator)当即发送一个Init Event Request包，数据包须要包含第4步骤中接收到的链接号(Connection Number)。响应端设备(Responder)须要根据这个链接号将命令/数据和事件两个TCP链接关联同一个PTP-IP链接和同一个PTP会话。
6. 与步骤3相似，请求成功则回复一个Init Event Ack包，在响应端设备(Responder)资源不足时，回复Init Fail包告知启动端请求失败。
7. 一旦启动器设备(Initiator)接收到步骤6中回传的Init Event Ack包则认为请求成功，此时PTP-IP链接真正创建完成，接着便可进行进一步的数据通讯。

在第二个TCP链接(事件链接)创建失败的状况下，第一个TCP链接(命令/数据链接)须要被关闭，稍后启动器设备(Initiator)应再次尝试创建PTP-IP链接。建议每次建立PTP-IP链接的时间间隔为30s。

2.2.3.2 传输通道配置

根据PTP协议7 [1]节，PTP-IP层要求传输通道可靠、无错误。这种传输通道能够经过正确配置TCP链接来实现。

PTP-IP的TCP链接应该使用一下选项建立：

• Keep Alive 选项：启动器和响应端须要同时须要同时开启这个选项，以确保两端的TCP实体在非活跃时期可以维持链接。开启这个选项后，启动器和响应端各自的TCP栈会经过TCP协议特定的方式来检查所配对的设备是否仍旧可以响应。这种检查方式是在TCP层进行，对上层的PTP-IP来讲是透明的。
• 禁用Nagle算法：须要在启动器和响应端程序的TCP/IP协议栈上禁用Nagle算法，以免在传输命令代码和响应时出现没必要要的延迟。

总的来讲就是须要设置以下选项(Qt为例)：

// 禁用Nable算法
mTcpSocket->setSocketOption(QAbstractSocket::SocketOption::LowDelayOption,1);
// 开启Keep Alive选项
mTcpSocket->setSocketOption(QAbstractSocket::SocketOption::KeepAliveOption,1);

2.2.3.3 关闭PTP-IP链接

当再也不须要PTP-IP时，由启动器设备(Initiator)关闭链接。当启动器设备(Initiator)或者响应端设备(Responder)在打开的传输通道上发生错误而致使这些通道不稳定时，也应关闭PTP-IP链接。关闭PTP-IP链接时两个TCP链接(命令/数据链接和事件链接)都必需要关闭。

2.3 传输的数据包类型

本节主要介绍用于在启动器设备(Initiator)和响应端设备(Responder)间通讯的一组数据包类型。PTP-IP的数据包类型至关于PTP协议中定义的操做请求(Operation Request)、响应(Response)、数据(Data)和事件(Event)事务类型。PTP-IP数据包中的全部多字节值都使用小端(Little-Endian)格式表示，一般一个PTP-IP数据包的格式以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Payload	根据Length计算	？

• 长度(Length)：4字节，长度参数决定了包含包头在内的整个数据包的大小；
• 包类型(Packet Type)：4字节，该字段标志了数据包的类型，该参数有下列可选的值：0x0000NNNN*表示隐藏值。

Value	Description
0x00000000	保留值
0x0000NNNN*	Init Command Request Packet
0x0000NNNN*	Init Command Ack
0x0000NNNN*	Init Event Request Packet
0x0000NNNN*	Init Event Ack Packet
0x0000NNNN*	Init Fail Packet
0x0000NNNN*	Operaqion Request Packet
0x0000NNNN*	Operation Response Packet
0x0000NNNN*	Event Packet
0x0000NNNN*	Start Data Packet
0x0000NNNN*	Data Packet
0x0000NNNN*	Cancel Packet
0x0000NNNN*	End Data Packet
0x0000NNNN*	Probe Request Packet
0x0000NNNN*	Probe Response Packet
0x0000NNNN* - 0xFFFFFFFF	保留值

• 负载(Payload)：包含协议更上层的或者是传输特定的数据。

2.3.1 Init Command Request Packet

该数据包在命令/数据传输通道被创建后当即被启动器设备(Initiator)发送。该数据包经过命令/数据链接传输，用于通知响应端设备(Responder)对启动器进行标识，从而使响应端设备(Responder)可以实现过滤机制。数据包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Initiator GUID	16	UINT8
Initiator Friendly Name	Variable	UINT16
Initiator Protocol Version	4	UINT32

• Initiator GUID：16字节，启动器设备的全局惟一标识符；
• Initiator Friendly Name：启动器设备的用户友好名称，该字段是一个包含启动器设备描述信息的Unicode字符串，该字串一般用于响应端设备的UI显示上(以确认或拒绝来自给定启动器设备的链接请求)；
• Initiator Protocol Version：4字节，启动器设备端实现的协议版本号。该字段由一个主版本号(高16位)和一个子版本号(低16位)组成。该字段应该被设置成第3节中定义的BINARY PROTOCOL VERSION。

• 启动器设备的GUID和响应端设备的GUID可用于进行设备绑定。若启动器设备的GUID的16个字节全由0xFF组成，则表示该启动器设备是一个匿名设备，此时由响应端设备决定是否容许链接。更多信息参考附录5.3。
• 启动器设备的用户友好名称是一个以空(NULL)字符结尾的Unicode字符串。包括结尾的空字符，其最大长度位40个字节。不使用该字段时，必须使用一个空(NULL)字符填充该字段。

数据包示例：

对应地：

• 30 00 00 00：第0~3字节表示Length字段
• 01 00 00 00：第4~7字节表示Packet Type字段
• fc 47 f8 4e 30 97 ee 64 1c 26 38 ae b0 1a 9e ac：第8~23字节表示Initiator GUID字段
• 44 00 53 00 43 00 2d 00 52 00 58 00 30 00 4d 00 32 00 00 00：第24~(Length-4-4-16-4-1)字节表示Initiator Friendly Name字段
• 00 00 01 00：最后4字节表示Initiator Protocol Version字段。

2.3.2 Init Command ACK Packet

该数据包由响应端设备(Responder)回传给启动器设备，以响应启动器设备发送的Init Command Request Packet，并为接下来的PTP-IP会话分配一个链接号(Connection Number)，该数据包在命令/数据链接上传输。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Connection Number	4	UINT32
Responder GUID	16	UINT6
Responder Friendly Name	Variable	UINT16
Responder Protocol Version	4	UINT32

• Connection Number：链接号，是响应端设备生成的用于关联全部属于同一个PTP会话的TCP链接通道的惟一值。
• Responder GUID：响应端设备的GUID。
• Responder Friendly Name：响应端设备的用户友好名称，可用于启动器设备端的UI显示。
• Responder Protocol Version：响应端设备实现的协议版本号。该字段由一个主版本号(高16位)和一个子版本号(低16位)组成。该字段应该被设置成第3节中定义的BINARY PROTOCOL VERSION。

• 响应端设备的用户友好名称是一个以空(NULL)字符结尾的Unicode字符串。包括结尾的空字符，其最大长度位40个字节。不使用该字段时，必须使用一个空(NULL)字符填充该字段。
• 链接号在启动器设备和响应端设备链接被创建的期间保持有效。一旦响应端设备成功关联属于同一个PTP-IP链接的两个TCP链接，链接号便可被从新使用。

实际该数据包结构看起来以下：

对应地：

• 34 00 00 00：第0~3字节表示Length字段
• 02 00 00 00：第4~7字节表示Packet Type字段
• 01 00 00 00：第8~11字节表示Connection Number字段
• 00 00 00 00 00 00 00 00 ff ff 10 98 c3 d1 5f 45：第12~27字节表示Responder GUID字段
• 44 00 53 00 43 00 2d 00 52 00 58 00 30 00 4d 00 32 00 00 00：第28~(Length-4-4-4-16-4-1)字节表示Responder Friendly Name字段
• 00 00 01 00：最后4字节表示Responder Protocol Version字段。

2.3.3 Init Event Request Packet

命令/数据链接被成功创建后，该数据包被启动器设备发送至响应端设备用于创建事件链接。启动器设备在接收到一个有效的Init Command Ack Packet数据包后，当即创建事件的TCP链接并发送Init Event Request Packet数据包，包中携带的链接号即前面步骤中接收到的在Init Command Ack数据包中返回的链接号。Init Event Request数据包经过事件链接传输。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Connection Number	4	UINT32

• Connection Number：链接号，从Init Command Ack Packet包数据中得到。

数据包示例：

对应地：

• 0c 00 00 00：第0~3字节表示Length字段
• 03 00 00 00：第4~7字节表示Packet Type字段
• 01 00 00 00：第8~11字节表示Connection Number字段

2.3.4 Init Event ACK Packet

该数据包由响应端设备(Responder)经过事件链接通道回传给启动器设备，以告知启动器设备PTP-IP链接创建成功。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32

数据包示例：

对应地：

• 08 00 00 00：第0~3字节表示Length字段
• 04 00 00 00：第4~7字节表示Packet Type字段

2.3.5 Init Fail Packet

初始化失败数据包。当PTP-IP链接创建失败时，该数据包由响应端设备(Responder)回传给启动器设备，以告知启动器设备链接创建失败及失败缘由，失败缘由被记录在Reason字段。接收到该数据包以后，启动器设备必须关闭先前步骤中创建的命令/数据链接。该数据包发出后，响应端设备亦应关闭相应的PTP-IP链接(由启动器设备发起的被拒绝的TCP链接)。Init Fail Packet能够经过任意的TCP链接传输。更多有关PTP-IP链接的创建能够参考PTP-IP链接一节内容。

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Reason	4	UINT32

Reason字段包含了链接拒绝的错误码，该字段定义的错误码有如下几种：

• 0x0000NNNN*：FAIL_REJECTED_INITIATOR，表示响应端设备实现了一个设备绑定的机制，但请求链接的启动器设备不在容许的设备集合内。参考附录5.3了解绑定机制详情。
• 0x0000NNNN*：FAIL_BUSY，表示响应端设备繁忙：响应端设备的活动链接数过多。启动器设备能够稍后再尝试链接。
• 0x0000NNNN*：FAIL_UNSPECIFIED，其余缘由。

2.3.6 Operation Request Packet

操做请求数据包。该数据包在PTP-IP协议中用于传输在PTP标准协议9.3.2 [1]节定义的PTP操做请求。PTP-IP Operation Request Packet由启动器设备发送至响应端设备，并经过命令/数据通道传输。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Data Phase Info	4	UINT32
Operation Code	2	UINT16
TransactionID	4	UINT32
Parameter1	4	UINT32
Parameter2	4	UINT32
Parameter3	4	UINT32
Parameter4	4	UINT32
Parameter5	4	UINT32

• Data Phase Info：指示下一个数据阶段是数据写(data out)阶段仍是数据读/数据(data in/no)阶段，该字段值被定义为下列几种：

  • 0x0000NNNN*：无数据或数据读(data in/no)阶段：启动器设备不知道响应端设备是否会提供一些数据或者提供一个响应；
  • 0x0000NNNN*：数据写(data out)阶段
  • 0x0000NNNN*：未知的数据阶段
• Operation Code：操做码，包含定义在PTP标准协议第10.2和10.3 [1]节的PTP操做码。
• TransactionID：事务ID，它在当前链接的响应端设备的开放会话上下文中是惟一的，如PTP第9.3.1 [1]节中定义。TransactionID是一个从0x00000000到0xFFFFFFFF的连续数值。0x00000000做为特殊的值，只能被用于OpenSession或GetDeviceInfo两个操做请求，每次当此参数不适用于包时，必须使用另外一个特殊值0xFFFFFFFF。
• Parameter 1~5：这些字段包含特定于操做的参数，这些参数的解释取决于操做码(Operation Code)参数，一个操做最多能够容纳5个参数。这些参数的使用方式定义在PTP标准协议的10.1和10.4 [1]节。

• 若是Data Phase Info字段被设置为Data Out Phase，则在发送该数据包后接着必需要发送一个Start Data Packet包。
• 若是启动器设备须要发送空数据对象到响应端设备，有两个选项可选：1.将Data Phase Info字段设置为No data or data in phase，在这状况下响应端设备将会直接回应一个Operation Response Packet包，而不会等待Data Packet；2.将Data Phase Info字段设置为Data out Phase.在这种状况下，数据写阶段(data out phase)必须只包含一个Start Data Packet包，并将该包的Total Data Length字段设置为0x00000000，而且启动器设备必须不能发送后续的End Data Packet数据包。

实际该数据包结构以下：

对应地：

• 16 00 00 00：第0~3字节表示Length字段
• 06 00 00 00：第4~7字节表示Packet Type字段
• 02 00 00 00：第8~11字节表示Data Phase Info字段
• 05 92：第12~13字节为Operation Code字段
• 06 00 00 00：第14~17字节为Transaction ID字段
• 0e 50 00 00：第18~21字节为Parameter 1字段

2.3.7 Operation Response Packet

操做响应数据包。该数据包在PTP-IP协议中用于传输在PTP标准协议9.3.4 [1]节定义的PTP操做响应。PTP-IP Operation Response Packet数据包由响应端设备经过命令/数据通道回应给启动器设备。操做响应数据包仅在须要指示操做请求事务已经结束而且须要传递操做结果时才由响应端设备发送给启动器设备。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Response Code	2	UINT16
TransactionID	4	UINT32
Parameter1	4	UINT32
Parameter2	4	UINT32
Parameter3	4	UINT32
Parameter4	4	UINT32
Parameter5	4	UINT32

• Response Code：响应码，包含定义在PTP标准协议第11.1和11.3 [1]节的操做响应码。
• TransactionID：事务ID，它在链接到响应端设备的开放会话上下文中是惟一的，如PTP第9.3.1[11]节中定义。TransactionID是一个从0x00000001到0xFFFFFFFE的连续数值。0x00000000做为特殊的值，只能被用于OpenSession或GetDeviceInfo两个操做请求，每次当此参数不适用于包时，必须使用另外一个特殊值0xFFFFFFFF。
• Parameter 1~5：这些字段包含特定于操做的参数，这些参数的解释取决于生成响应的操做以及特定的响应代码值。一个操做响应的数据包最多能够容纳5个参数。这些参数的使用方式定义在PTP标准协议的9.3.4 [1]节。

实际该数据包结构以下：

对应地：

• 0e 00 00 00：第0~3字节表示Length字段
• 07 00 00 00：第4~7字节表示Packet Type字段
• 01 20：第8~9字节表示Response Code字段
• 05 00 00 00：第10~13字节为Transaction ID字段

2.3.8 Event Packet

事件数据包。该数据包用于传输在PTP标准协议12.2 [1]节中定义的事件。这些事件由响应端设备经过事件链接通道发送给启动器设备，以通知启动器设备响应端的状态变动。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
Event Code	2	UINT16
TransactionID	4	UINT32
Parameter1	4	UINT32
Parameter2	4	UINT32
Parameter3	4	UINT32

• Event Code：事件码，包含定义在PTP标准协议第12.3和12.4 [1]节的事件码。
• TransactionID：事务ID，它在当前链接到响应端设备的开放会话上下文中是惟一的，其定义在PTP标准协议的9.3.1 [1]节。若是事件数据包对应于先前发起的事务，则该字段应该被设为操做所对应的事务ID。若是事件没有指定于特定的事务，则该字段应设为0xFFFFFFFF。
• Parameter 1~3：这些字段包含特定于事件的参数。这些参数的解释却决于事件码(Event Code)字段。一个Event Packet数据包最多能容纳3个参数，有关这些参数的使用说明定义在PTP标准协议的12.5 [1]节。

2.3.9 Start Data Packet

开始数据传输数据包。该数据包在PTP-IP中用于标识数据传输的开始。其经过命令/数据通道传输，能够由任意一设备端发送，另外一端接收。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
TransactionID	4	UINT32
Total Data Length	8	UINT64

• Total Data Length：包含即将在数据读(data in)阶段或数据写(data out)阶段中被传输的数据大小。特定的值0xFFFFFFFFFFFFFFFF表示在数据阶段的开始并不知道数据的大小，该值的使用仅限于传输对象的大小未知的状况(例如：传输流数据)。

数据包示例：

其中：

• 14 00 00 00：第0~3字节表示Length字段
• 09 00 00 00：第4~7字节表示Packet Type字段
• 01 00 00 00：第8~11字节表示Transaction ID字段
• 08 00 00 00 00 00 00 00：第12~19字节为Total Data Length字段

2.3.10 Data Packet

该数据包在PTP-IP中用于传输数据。Data Packet包只在数据阶段使用，且能够由当前数据流方向上的任意一端发送，另外一端接收：在数据读(data-in)阶段由响应端设备发送给启动器设备；在数据写(data-out)阶段由启动器设备发送给响应端设备。Data Packet数据包走的是命令/数据的链接通道。

因为TCP传输是无错误、基于流的协议，一般不须要对大型的数据包进行拆包和粘包操做。不过可使用基本的碎片机制来实现一个简单的数据传输取消机制，Data Packet不须要进行错误校验。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
TransactionID	4	UINT32
Data Payload	?	UINT8

• Data Payload：包含数据包中须要传输的数据。

数据包示例：

其中：

• 14 00 00 00：第0~3字节表示Length字段
• 0a 00 00 00：第4~7字节表示Packet Type字段
• 01 00 00 00：第8~11字节表示Transaction ID字段
• 00 00 00 00 00 00 00 00 0c 00 00 00 0c 00 00 00 01 00 00 00 0e 00 00 00 07 00 00 00 01 20 01 00 00 00：第12~N字节为Data Payload字段。

2.3.11 End Data Packet

终结数据传输的数据包。End Data Packet数据包在PTP-IP中用于标识数据阶段的结束，该数据包中也能够携带一些有用数据。该数据包只在一个事务的数据阶段使用，能够由数据流方向上的任意一端发送，另外一端接收：在数据读(data-in)阶段由响应端设备发送给启动器设备；在数据写(data-out)阶段由启动器设备发送给响应端设备。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
TransactionID	4	UINT32
Data Payload	?	UINT8

• Data Payload：若是数据包中包含有数据则放在这个字段。

数据包示例：

其中：

• 10 00 00 00：第0~3字节表示Length字段
• 0c 00 00 00：第4~7字节表示Packet Type字段
• 06 00 00 00：第8~11字节表示Transaction ID字段
• 02 00 01 00：第12~(Length-4-4-4)字节为Data Payload字段。

2.3.12 Cancel Packet

Cancel Packet数据包用于取消传输事务，由启动器设备发送至响应端设备。该数据包在命令/数据链接通道和事件链接通道上发送。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32
TransactionID	4	UINT32

2.3.13 Probe Request Packet

心跳包。该数据包可用于PTP-IP的启动器设备和响应端设备，以检查对等设备是否仍然有效。当接收到该数据包时，设备必须当即响应一个Probe Response Packet数据包。若是在一段合理的时间内没有收到响应，则发出该数据包的设备将关闭与对端设备的PTP-IP会话。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32

数据包示例：

其中前、后四个字节分别为Length字段和Packet Type字段。

使用该数据包时应要注意控制发送的频率以免形成局域网过载：

• 启动器设备发送至响应端设备(I–>R)：建议这个包只在PTP事务中使用(例如，当发出格式命令时，若是存储介质很大，响应时间可能会很长)，以便检查响应端设备是否仍然处于活跃状态。
• 响应端设备发送至启动器设备(R–>I)：建议仅当响应端设备接收到一个新的PTP-IP会话的请求，而另外一个或多个其余会话处于活动状态时，才使用此包。在这种状况下，响应端设备能够检查现有的PTP-IP链接是否仍然处于活动状态。
• 建议在发送Probe Request Packet数据包和接收Probe Response Packet包之间设置10秒的超时时间。

2.3.14 Probe Response Packet

心跳包的回应数据包。该数据包可用于PTP-IP的启动器设备和响应端设备，做为另外一端的Probe Request Packet请求的响应。当接收到一个Probe Request Packet请求时应当当即回复这个数据包。

包结构以下：

Field	Size[Bytes]	Data Type
Length	4	UINT32
Packet Type	4	UINT32

数据包示例：

其中前、后四个字节分别为Length字段和Packet Type字段。

2.4 会话的实现

由启动器设备在PTP层发起的新会话请求将生成两个新的TCP链接，这两个链接即对应于PTP-IP层的命令/数据(Command/Data)链接和事件(Event)链接。这两个TCP链接足够用来惟一标识其所属的会话，所以不须要将会话ID(SessionID)做为独立的值从启动器设备发送到响应端设备。

2.5 设备断开和网络丢失处理

在PTP-IP协议中，对设备的断开或者网络丢失的检测基于如下一些标准：

• 网络层通知应用程序有关网络链接断开(例如媒体断开链接)的功能。
• 任意一个PTP-IP链接通道丢失(命令/数据通道或事件通道)，例如socket被破坏。
• 任意一个PTP-IP通道传输超时。

2.6 数据流控制

为了防止一个设备在事务的数据阶段用数据重载另外一个设备，一般会实现一个数据流控制机制。不过在PTP-IP中不须要实现这样的机制，由于底层的TCP层会执行流控制操做。

TCP层在两个级别实现流控制：接收设备和网络，避免在低速接收和低速网络下数据泛滥。所以，在PTP-IP中采用TCP链接做为通讯通道，直接解决了流量控制的问题。

2.7 事务取消机制

有两种可能取消事务的状况：启动器设备请求取消或者响应端设备请求取消。

2.7.1 启动器设备产生的取消

2.7.1.1 数据写阶段

启动器设备为了取消正在进行的数据写阶段传输，必须在命令/数据通道和事件通道上发出一个Cancel Packet数据包，并中止任何正在命令/数据通道上的数据传输。当响应端设备在命令/数据通道或事件通道上收到Cancel Packet数据包时，必须尽量快地中断并取消正在进行的事务，同时读取和丢弃全部属于当前事务(若是有)的剩余的数据包，而且向启动器设备回应一个附带有Transaction_Cancelled响应码的Operation Response Packet数据包。

2.7.1.2 数据读阶段

启动器设备为了取消正在进行的数据读阶段传输，必须在命令/数据通道和事件通道上发出一个Cancel Packet数据包。响应端设备在命令/数据通道或事件通道上收到Cancel Packet数据包时，必须尽量快地中断并取消正在进行的事务，而且向启动器设备回应一个附带有Transaction_Cancelled响应码的Operation Response Packet数据包。

2.7.1.3 其余事务阶段

启动器设备能够经过在命令/数据通道和事件通道上发出一个Cancel Packet数据包以在事务的任意阶段退出事务。若是取消的是当前的事务，则响应端设备必须回应一个附带有Transaction_Cancelled响应码的Operation Response Packet数据包。

2.7.2 响应端设备产生的退出

2.7.2.1 数据写阶段

响应端设备为了取消正在进行的数据写阶段传输，必须发送一个附带有Transaction_Cancelled或者其余标识数据传输中断缘由的响应码的Operation Response Packet数据包。而后，响应端设备必须读取和丢弃全部属于当前事务的在命令/数据通道中的Data Packet数据包。

2.7.2.2 数据读阶段

响应端设备为了取消正在进行的数据读阶段传输，必须在命令/数据通道上发送一个Operation Response Packet数据包，而且附带Transaction_Cancelled响应码或其余标识数据传输中断缘由的响应码。

2.7.2.3 其余事务阶段

响应端设备能够经过发送附带Transaction_Cancelled响应码或其余标识数据传输中断缘由的响应码的Operation Response Packet以在事务的任意阶段退出事务。

2.7.3 异步操做退出机制

启动器设备为了取消一个异步操做，必须同时在命令/数据通道和事件通道发送一个包含该异步操做所属的事务ID的Cancel Packet数据包，启动器设备能够在任意时候发送这些数据包。

响应端设备将以PTP事件(例如Capture Complete event)结束操做。解释取消请求的逻辑由响应端设备的应用层负责。

3 协议版本

该PTP-IP规范的二进制协议版本(BINARY PROTOCOL VERSION)是0x00010000(1.0版)。二进制协议版本由一个主要数字(高16位表示)和一个次要数字(低16位表示)组成。这个数字将增长，以表示较新的协议版本，方法以下:

• 次要版本进行了增长，以反映协议规范中的次要更改。实现新次要版本的设备必须彻底支持同一主要版本的全部次要版本。
• 主要版本增长了，以反映协议规范中的主要更改。新协议规范可能与主号码较小的旧规范版本不兼容。

4 PTP-IP端口

若是没有实现设备发现协议，则每个响应端设备和启动器设备应该经过如下端口号来初始化：

Port Name	Port No.	Type	Description
PTP-IP service	15740	TCP	响应端设备等待TCP链接的默认端口，该端口由IANA批准。

5 附录

5.1 地址配置

PTP-IP协议的基础是TCP/IP协议，该协议的关键是寻址机制。响应端设备和启动端程序都将得到有效的IP地址。获取有效IP地址的方法有如下几种:

• 手动配置： IP地址和其余网络属性由用户手动配置，以反映图像设备将在其中工做的局域网的拓扑结构和地址模式；
• 基于DHCP配置：图像设备应实现一个DHCP客户端，DHCP客户端将自动从网络中的DHCP服务器获取IP地址。
• IPv4链路本地地址(v4LL)的动态配置：一个描述了一种在TCP/IP局域网上自动自配置网络设备的机制，而无需设置DHCP服务器的标准。

为了处理设备的TCP/IP属性配置，建议执行如下步骤：

• 若是属性是手动配置的，则使用该配置；
• 不然设备应使用DHCP协议获取IP地址以及其余配置参数(设备须要实现一个DHCP客户端)；
• 若是网络中没有DHCP服务器，则能够部署v4LL动态配置。

5.2 设备发现和枚举

在PTP-IP中，启动器设备能够经过如下几种方式配置链接到响应端设备的地址：

• 手动配置：启动器设备将手动配置它能够链接的响应端设备的一个或一组地址。启动器设备会尝试根据IP地址创建一个PTP-IP链接，若是链接成功则说明响应端设备存在，此时能够创建一个PTP会话。
• Zeroconf：一族提供自动配置、设备和服务发现的协议和建议，在IETF Zeroconf Working Group.[4]中发表。
• UPnP：一组发表在UPnP Forum[3]用于简化设备配置、服务发现和调用的协议。仅可使用该协议的设备和服务发现功能。
• 其余设备发现机制。

PTP规范第7.4条要求从其传输中支持设备发现和枚举。所以，PTP-IP 层应该至少实现以上这些服务中的一种。

无论使用什么服务发现和枚举，咱们建议将设备的GUID做为广播包的一部分，这样启动端设备就可以过滤(若是须要的话)特定的设备，并生成选择性通知。

5.3 设备绑定和认证

认证并非PTP-IP层的职责。若是须要身份验证，则应该依赖于底层网络(物理/数据链路层)中可用的解决方案。设备绑定能够依赖于底层网络可用的机制或者基于PTP-IP层提供的机制在应用层实现，以下：

PTP-IP上下文中每个设备都须要由一个可被用于设备绑定的全局惟一的标识：GUID(16字节的惟一数字)。对于这些设备，PTP-IP层提供了一个容许启动器设备和响应端设备互相交换GUID的机制。这进而容许应用层实现设备级访问控制(例如，一个新设备到达并被网络发现，该设备只能接受来自已知启动器设备的的选择性链接，或者只能启动到已知响应端设备的链接)。

不管使用什么服务发现和枚举方法，都建议将设备的GUID做为广播包的一部分，这样启动端设备就可以过滤(若是须要的话)特定的设备，并生成选择性通知。

5.4 数据安全

本节不属于PTP-IP协议的范围。数据安全将依赖于底层网络(物理/数据链路层)中可用的解决方案。

5.5 The End :)