摘要：操作請求只能由啟動器設備發起事件被響應端設備用于把有關它狀態的改變通知啟動器設備。會話將在啟動器設備請求操作事務時被關閉，并且使用響應端設備發出的一個有效響應成功結束該請求。標準協議節斷開事件。

歡迎關注公眾號: nullobject 。
文章首發在個人博客 https://www.nullobject.cn，公眾號nullobject同步更新。

PTP/IP (PTP over IP) 是一個通過IP連接,建立在 Picture Transfer Protocol (PTP) 上的傳輸層
英文原版協議下載

本文檔由nullobject對應PTP-IP標準協議1.0版本進行學習整理，原版協議為英文版，學習時依靠自己理解和使用有道云翻譯，對理解不到位、翻譯有問題的地方麻煩批評指正。—— by nullobject in 2019-06-03 15:29

本文檔描述了一個基于IP網絡的ISO-15740/PIMA 1574:2000/圖片傳輸協議(PTP)的實現。

PTP被設計用來提供與數字靜止攝影設備的標準通信。該協議指定了標準的圖像引用行為、操作、響應、事件、設備屬性、數據集和數據格式，以確保互操作性，還提供了可選的操作和格式，以及擴展機制。

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].

下表列舉了本文檔的參考資料：

Petronel Bigioi – FotoNation Ireland

George Susanu – FotoNation Ireland

Alexei Pososin – FotoNation Ireland

Denis McHugh – FotoNation Ireland

Eran Steinberg – FotoNation US

Yury Prilusky – FotoNation US

PTP規范定義了設備角色、操作、圖像格式和其他相機特定的數據類型和結構。在PTP的TCP/IP實現中，所有術語和定義都按照PTP規范中定義的那樣使用。

從通信的角度來看，設備可以充當啟動器設備(Initiator)或響應端設備(Responder)，啟動器設備相當于一個客戶端，響應端設備相當于服務端。啟動器設備是向響應端設備發起操作請求的設備。響應端設備則是能夠響應這些操作請求的設備。一個設備可能只是一個啟動器設備，或者只是一個響應端設備，或者兩者兼備，但不能在同一個設備連接上同時擔任兩種角色。

操作請求只能由啟動器設備發起；事件被響應端設備用于把有關它狀態的改變通知啟動器設備。

根據PTP協議，會話被定義為兩個設備之間的邏輯連接，操作和事件事務可以通過該邏輯連接進行通信。根據PTP規范，一個響應端設備可以支持多個并發會話，每個會話都有自己的狀態。

當啟動器設備請求OpenSession操作事務時將會打開一個會話，并且使用響應端設備發出的一個有效響應成功結束該請求。

會話將在啟動器設備請求CloseSession操作事務時被關閉，并且使用響應端設備發出的一個有效響應成功結束該請求。當啟動器設備和響應端設備之間的連接被關斷開時會話也會被關閉(例如通信超時)。

大多數操作需要在一個開放會話上下文中執行。不過，不需要打開會話就可以通過GetDeviceInfo操作獲取設備功能。

支持多會話的設備必須能夠使它們彼此保持異步和不透明。

通常，如果使用相同傳輸級別的通信通道，則會話ID旨在使響應端設備能夠按適當的順序分發來自不同啟動器設備的請求。對于打開不同通信通道的傳輸，對于每個會話，不需要重新設置會話ID，因為響應端設備將能夠處理多個會話。

PTP的PTP- IP傳輸實現不會將會話ID發送到響應端設備。響應端設備可以通過控制它允許的最大PTP- IP連接數來限制并發PTP會話的數量。

如果啟動器設備的PTP-IP層發現響應端設備不接受新的PTP-IP連接，它將向PTP層發送傳輸特定的錯誤代碼。在建立傳輸指定連接之后，啟動端設備可以向遠程響應端設備發出GetDeviceInfo和OpenSession請求。在這個階段中，響應端設備可能返回一個設備繁忙(Device_Busy)的PTP錯誤作為對OpenSession的響應(如果響應端設備對它能夠支持的并發PTP會話的數量有限制)。在這種情況下，啟動端設備應該釋放PTP連接，并稍后重試。

事務是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，但同一個操作中數據只能在一個方向上傳輸。

事務ID(TransactionID)用于在一個給定的會話中標識不同事務，與在PTP協議的第9.3.1項中定義的事務ID相同，是一個32位無符號整型數字。事務ID在給定的會話中是唯一且連續的數字序列，其范圍從0x00000001到0xFFFFFFFE，0x00000000和0xFFFFFFFF作為保留值不被使用。

在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傳輸。

在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]節中為設備標準的一致性確定了一組操作和事件。

PTP標準協議文檔的7 [1]節定義了PTP標準傳輸需求，而PTP-IP則是基于使用TCP層作為傳輸層實現：

與PTP一樣，PTP-IP也期望從其傳輸層獲得可靠、穩定無錯誤的通信通道，而TCP(位于TCP/IP協議棧中)正是可以滿足這些需求的自然傳輸層。TCP是一個基于流的傳輸層，它提供多個通信通道(TCP Connection)和無錯誤的數據傳輸。

在PTP-IP中，兩個設備之間的所有通信都通過兩個TCP連接(邏輯數據通道)進行：

由于事件本身具有異步性質，事件的數據包與操作/數據事務數據包分開分別通過兩個多帶帶的通道傳輸。

PTP-IP的 命令/數據連接用于傳輸PTP操作請求、響應和數據事務，以及特定于PTP-IP的數據包。該連接由啟動器設備(Initiator)建立，并標志本地及響應端設備(Responder)的IP地址和端口號。響應端設備(Responder)的IP地址和端口號通常是通過設備發現機制來確定。

PTP-IP的事件連接作為啟動器設備(Initiator)開啟的與響應端設備(Responder)之間的第二個連接，用于傳輸PTP事件，以及特定于PTP-IP的數據包。與命令/數據連接相同，事件連接由啟動器設備(Initiator)發起建立， 并標志本地和響應端設備(Responder)的IP地址和端口號，響應端設備(Responder)的IP地址和端口號通常是通過設備發現機制來確定。

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連接應遵循上圖所示順序進行：

啟動器設備(Initiator)發起命令/數據的TCP連接：指定響應端設備(Responder)的IP地址和端口號，并連接到響應端設備(Responder)；

TCP連接建立成功后，啟動器設備(Initiator)立即發送一個Init Command Request包，數據包中需要包含啟動器設備(Initiator)的唯一標識(GUID和啟動器設備的用戶友好名稱)，例如：

響應端設備(Responder)程序根據實際情況，回復啟動器設備一個Init Command Ack包以告知啟動器設備請求成功并且可以繼續進行連接；或者回復Init Fail數據包表示請求失敗，以告知啟動器設備請求訪問被拒絕，并且斷開命令/數據的TCP連接，同時啟動器設備接收到請求失敗的回應后也應該斷開相應的的命令/數據連接。

啟動器設備(Initiator)接收到Init Command Ack包后，繼續發起一個事件的TCP連接：指定響應端設備(Responder)的IP地址和端口號，并連接到響應端設備(Responder)。注意該連接與第1步中的連接是區別開的。

一旦連接建立成功，啟動器設備(Initiator)立即發送一個Init Event Request包，數據包需要包含第4步驟中接收到的連接號(Connection Number)。響應端設備(Responder)需要根據這個連接號將命令/數據和事件兩個TCP連接關聯同一個PTP-IP連接和同一個PTP會話。

與步驟3類似，請求成功則回復一個Init Event Ack包，在響應端設備(Responder)資源不足時，回復Init Fail包告知啟動端請求失敗。

一旦啟動器設備(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連接(命令/數據連接和事件連接)都必須要關閉。

本節主要介紹用于在啟動器設備(Initiator)和響應端設備(Responder)間通信的一組數據包類型。PTP-IP的數據包類型相當于PTP協議中定義的操作請求(Operation Request)、響應(Response)、數據(Data)和事件(Event)事務類型。PTP-IP數據包中的所有多字節值都使用小端(Little-Endian)格式表示，通常一個PTP-IP數據包的格式如下：

長度(Length)：4字節，長度參數決定了包含包頭在內的整個數據包的大小；

包類型(Packet Type)：4字節，該字段標志了數據包的類型，該參數有下列可選的值：0x0000NNNN*表示隱藏值。

負載(Payload)：包含協議更上層的或者是傳輸特定的數據。

該數據包在命令/數據傳輸通道被建立后立即被啟動器設備(Initiator)發送。該數據包通過命令/數據連接傳輸，用于通知響應端設備(Responder)對啟動器進行標識，從而使響應端設備(Responder)能夠實現過濾機制。數據包結構如下：

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字段。

該數據包由響應端設備(Responder)回傳給啟動器設備，以響應啟動器設備發送的Init Command Request Packet，并為接下來的PTP-IP會話分配一個連接號(Connection Number)，該數據包在命令/數據連接上傳輸。

包結構如下：

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字段。

命令/數據連接被成功建立后，該數據包被啟動器設備發送至響應端設備用于建立事件連接。啟動器設備在接收到一個有效的Init Command Ack Packet數據包后，立即建立事件的TCP連接并發送Init Event Request Packet數據包，包中攜帶的連接號即前面步驟中接收到的在Init Command Ack數據包中返回的連接號。Init Event Request數據包通過事件連接傳輸。

包結構如下：

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字段

該數據包由響應端設備(Responder)通過事件連接通道回傳給啟動器設備，以告知啟動器設備PTP-IP連接建立成功。

包結構如下：

數據包示例：

對應地：

08 00 00 00：第0~3字節表示Length字段

04 00 00 00：第4~7字節表示Packet Type字段

初始化失敗數據包。當PTP-IP連接建立失敗時，該數據包由響應端設備(Responder)回傳給啟動器設備，以告知啟動器設備連接建立失敗及失敗原因，失敗原因被記錄在Reason字段。接收到該數據包之后，啟動器設備必須關閉先前步驟中建立的命令/數據連接。該數據包發出后，響應端設備亦應關閉相應的PTP-IP連接(由啟動器設備發起的被拒絕的TCP連接)。Init Fail Packet可以通過任意的TCP連接傳輸。更多有關PTP-IP連接的建立可以參考PTP-IP連接一節內容。

Reason字段包含了連接拒絕的錯誤碼，該字段定義的錯誤碼有以下幾種：

0x0000NNNN*：FAIL_REJECTED_INITIATOR，表示響應端設備實現了一個設備綁定的機制，但請求連接的啟動器設備不在允許的設備集合內。參考附錄5.3了解綁定機制詳情。

0x0000NNNN*：FAIL_BUSY，表示響應端設備繁忙：響應端設備的活動連接數過多。啟動器設備可以稍后再嘗試連接。

0x0000NNNN*：FAIL_UNSPECIFIED，其他原因。

操作請求數據包。該數據包在PTP-IP協議中用于傳輸在PTP標準協議9.3.2 [1]節定義的PTP操作請求。PTP-IP Operation Request Packet由啟動器設備發送至響應端設備，并通過命令/數據通道傳輸。

包結構如下：

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字段

操作響應數據包。該數據包在PTP-IP協議中用于傳輸在PTP標準協議9.3.4 [1]節定義的PTP操作響應。PTP-IP Operation Response Packet數據包由響應端設備通過命令/數據通道回應給啟動器設備。操作響應數據包僅在需要指示操作請求事務已經結束并且需要傳遞操作結果時才由響應端設備發送給啟動器設備。

包結構如下：

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字段

事件數據包。該數據包用于傳輸在PTP標準協議12.2 [1]節中定義的事件。這些事件由響應端設備通過事件連接通道發送給啟動器設備，以通知啟動器設備響應端的狀態變更。

包結構如下：

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]節。

開始數據傳輸數據包。該數據包在PTP-IP中用于標識數據傳輸的開始。其通過命令/數據通道傳輸，可以由任意一設備端發送，另一端接收。

包結構如下：

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字段

該數據包在PTP-IP中用于傳輸數據。Data Packet包只在數據階段使用，且可以由當前數據流方向上的任意一端發送，另一端接收：在數據讀(data-in)階段由響應端設備發送給啟動器設備；在數據寫(data-out)階段由啟動器設備發送給響應端設備。Data Packet數據包走的是命令/數據的連接通道。

由于TCP傳輸是無錯誤、基于流的協議，通常不需要對大型的數據包進行拆包和粘包操作。不過可以使用基本的碎片機制來實現一個簡單的數據傳輸取消機制，Data Packet不需要進行錯誤校驗。

包結構如下：

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字段。

終結數據傳輸的數據包。End Data Packet數據包在PTP-IP中用于標識數據階段的結束，該數據包中也可以攜帶一些有用數據。該數據包只在一個事務的數據階段使用，可以由數據流方向上的任意一端發送，另一端接收：在數據讀(data-in)階段由響應端設備發送給啟動器設備；在數據寫(data-out)階段由啟動器設備發送給響應端設備。

包結構如下：

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字段。

Cancel Packet數據包用于取消傳輸事務，由啟動器設備發送至響應端設備。該數據包在命令/數據連接通道和事件連接通道上發送。

包結構如下：

心跳包。該數據包可用于PTP-IP的啟動器設備和響應端設備，以檢查對等設備是否仍然有效。當接收到該數據包時，設備必須立即響應一個Probe Response Packet數據包。如果在一段合理的時間內沒有收到響應，則發出該數據包的設備將關閉與對端設備的PTP-IP會話。

包結構如下：

數據包示例：

其中前、后四個字節分別為Length字段和Packet Type字段。

使用該數據包時應要注意控制發送的頻率以避免造成局域網過載：


啟動器設備發送至響應端設備(I–>R)：建議這個包只在PTP事務中使用(例如，當發出格式命令時，如果存儲介質很大，響應時間可能會很長)，以便檢查響應端設備是否仍然處于活躍狀態。

響應端設備發送至啟動器設備(R–>I)：建議僅當響應端設備接收到一個新的PTP-IP會話的請求，而另一個或多個其他會話處于活動狀態時，才使用此包。在這種情況下，響應端設備可以檢查現有的PTP-IP連接是否仍然處于活動狀態。
建議在發送Probe Request Packet數據包和接收Probe Response Packet包之間設置10秒的超時時間。

心跳包的回應數據包。該數據包可用于PTP-IP的啟動器設備和響應端設備，作為另一端的Probe Request Packet請求的響應。當接收到一個Probe Request Packet請求時應當立即回復這個數據包。

包結構如下：

數據包示例：

其中前、后四個字節分別為Length字段和Packet Type字段。

由啟動器設備在PTP層發起的新會話請求將生成兩個新的TCP連接，這兩個連接即對應于PTP-IP層的命令/數據(Command/Data)連接和事件(Event)連接。這兩個TCP連接足夠用來唯一標識其所屬的會話，因此不需要將會話ID(SessionID)作為獨立的值從啟動器設備發送到響應端設備。

在PTP-IP協議中，對設備的斷開或者網絡丟失的檢測基于以下一些標準：

網絡層通知應用程序有關網絡連接斷開(例如媒體斷開連接)的功能。

任意一個PTP-IP連接通道丟失(命令/數據通道或事件通道)，例如socket被破壞。

任意一個PTP-IP通道傳輸超時。

為了防止一個設備在事務的數據階段用數據重載另一個設備，通常會實現一個數據流控制機制。不過在PTP-IP中不需要實現這樣的機制，因為底層的TCP層會執行流控制操作。

TCP層在兩個級別實現流控制：接收設備和網絡，避免在低速接收和低速網絡下數據泛濫。因此，在PTP-IP中采用TCP連接作為通信通道，直接解決了流量控制的問題。

有兩種可能取消事務的情況：啟動器設備請求取消或者響應端設備請求取消。

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.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以在事務的任意階段退出事務。

啟動器設備為了取消一個異步操作，必須同時在命令/數據通道和事件通道發送一個包含該異步操作所屬的事務ID的Cancel Packet數據包，啟動器設備可以在任意時候發送這些數據包。

響應端設備將以PTP事件(例如Capture Complete event)結束操作。解釋取消請求的邏輯由響應端設備的應用層負責。

該PTP-IP規范的二進制協議版本(BINARY PROTOCOL VERSION)是0x00010000(1.0版)。二進制協議版本由一個主要數字(高16位表示)和一個次要數字(低16位表示)組成。這個數字將增加，以表示較新的協議版本，方法如下:

次要版本進行了增加，以反映協議規范中的次要更改。實現新次要版本的設備必須完全支持同一主要版本的所有次要版本。

主要版本增加了，以反映協議規范中的主要更改。新協議規范可能與主號碼較小的舊規范版本不兼容。

如果沒有實現設備發現協議，則每一個響應端設備和啟動器設備應該通過以下端口號來初始化：

PTP-IP協議的基礎是TCP/IP協議，該協議的關鍵是尋址機制。響應端設備和啟動端程序都將獲得有效的IP地址。獲取有效IP地址的方法有以下幾種:

手動配置： IP地址和其他網絡屬性由用戶手動配置，以反映圖像設備將在其中工作的局域網的拓撲結構和地址模式；

基于DHCP配置：圖像設備應實現一個DHCP客戶端，DHCP客戶端將自動從網絡中的DHCP服務器獲取IP地址。

IPv4鏈路本地地址(v4LL)的動態配置：一個描述了一種在TCP/IP局域網上自動自配置網絡設備的機制，而無需設置DHCP服務器的標準。

為了處理設備的TCP/IP屬性配置，建議執行以下步驟：

如果屬性是手動配置的，則使用該配置；

否則設備應使用DHCP協議獲取IP地址以及其他配置參數(設備需要實現一個DHCP客戶端)；

如果網絡中沒有DHCP服務器，則可以部署v4LL動態配置。

在PTP-IP中，啟動器設備可以通過以下幾種方式配置連接到響應端設備的地址：

手動配置：啟動器設備將手動配置它可以連接的響應端設備的一個或一組地址。啟動器設備會嘗試根據IP地址建立一個PTP-IP連接，如果連接成功則說明響應端設備存在，此時可以建立一個PTP會話。

Zeroconf：一族提供自動配置、設備和服務發現的協議和建議，在IETF Zeroconf Working Group.[4]中發表。

UPnP：一組發表在UPnP Forum[3]用于簡化設備配置、服務發現和調用的協議。僅可以使用該協議的設備和服務發現功能。

其他設備發現機制。

PTP規范第7.4條要求從其傳輸中支持設備發現和枚舉。因此，PTP-IP 層應該至少實現以上這些服務中的一種。

不管使用什么服務發現和枚舉，我們建議將設備的GUID作為廣播包的一部分，這樣啟動端設備就能夠過濾(如果需要的話)特定的設備，并生成選擇性通知。

認證并不是PTP-IP層的職責。如果需要身份驗證，則應該依賴于底層網絡(物理/數據鏈路層)中可用的解決方案。設備綁定可以依賴于底層網絡可用的機制或者基于PTP-IP層提供的機制在應用層實現，如下：

PTP-IP上下文中每一個設備都需要由一個可被用于設備綁定的全局唯一的標識：GUID(16字節的唯一數字)。對于這些設備，PTP-IP層提供了一個允許啟動器設備和響應端設備互相交換GUID的機制。這進而允許應用層實現設備級訪問控制(例如，一個新設備到達并被網絡發現，該設備只能接受來自已知啟動器設備的的選擇性連接，或者只能啟動到已知響應端設備的連接)。

無論使用什么服務發現和枚舉方法，都建議將設備的GUID作為廣播包的一部分，這樣啟動端設備就能夠過濾(如果需要的話)特定的設備，并生成選擇性通知。

本節不屬于PTP-IP協議的范圍。數據安全將依賴于底層網絡(物理/數據鏈路層)中可用的解決方案。