“PacketCable 電子監控規范”顯示，安全傳輸模式由 CMTS 執行，而不是由 PC 或 IP 電話 (IPP)等端點執行。但是，目前 VoP 市場上的安全性大多數實施于端點上，且其中大部分為隧道模式，因此 PacketCable 必須處理這種安全架構。
前面各部分中列出的 CALEA 面臨的其它安全問題同樣也是 PacketCable 的問題。
解決方案
為了解決 CALEA 的安全問題，CALEA 截取盒必須在 SA 建立的初期截取發自目標設備的數據包，以獲得所需的密鑰以及其它安全參數。在哪里進行截取取決于以下諸多因素：NAT、動態主機配置協議 (DHCP)、VPN/安全端點等。
如果 VPN/安全端點為 PC 或 IPP，則端點如何獲得 IP 地址非常重要。如果端點 IP 地址通過動態主機配置協議 (DHCP) 獲得，則不存在 NAT，截取可在任何設備中進行。但是，來自相同設備的數據包可能選擇不同的路由，因此，我們最好在數據包選擇另一路徑前（通常是從 CMTS 到因特網）截取數據包。
有 NAT 時，最好的截取處就是 NAT 功能所在的地方。正如“PacketCable 電子監控規范”定義的一樣，這常常是 MTA，而不是 CMTS。但是，NAT 也可能在 CMTS 上。NAT 單元將專用 IP 地址映射到公用 IP 地址上，反之亦然，因此數據包應在執行 NAT 之前在 LAN 站點上截取。否則，截取盒就要在相同公用 IP 地址的混合消息流中進行數據包過濾。此外，NAT 單元帶有應用算法 (ALG)，可處理專用的轉換功能。例如，最初傳送進來的 SIP 呼叫只有公用 IP 地址。NAT 單元如何知道應該映射到哪個專用 IP 地址呢？它必須運行 SIP ALG，其以 SIP 消息中的用戶 ID（如alice@wonderlane.com）或報頭中的 CallerID 來查找 Alice 的專用 IP 地址。請注意，Alice 必須已經以她專用的 IP 地址及其姓名和/或 CallerID 在 NAT 器件上注冊。
一旦 CALEA 截取盒能夠截取目標設備的數據包，則其應設法獲得 SA建立消息。如果安全機制不是基于標準協議之上，則執法人員解釋安全消息以及隨后進行 SA 消息與媒體數據包的解密就會面臨很大的困難。如果安全消息基于標準協議之上，則 CALEA 截取盒應該可從 SA 建立消息計算出密鑰、密鑰大小以及加密方法。
美國 TIA 發布了一系列 PSTN 中 CALEA 的消息格式。由于因特網的架構、協議集、消息格式與呼叫流程 (call flow) 完全不同，因此 TIA 必須發布因特網 CALEA 傳輸的全新系列規范。PacketCable 規范可作為子集，事實上 TIA 也提到了這些情況。但是，PacketCable 安全規范與 PacketCable 電子監控的修改必須滿足許多 VoP 安全要求。此外，盡管原理相同，非基于線纜的 VoP 安全解決方案應在 PacketCable 規范外另行規定。
