其他WS-Discovery功能
在某些情況下， Web 服務的裝置設定檔 (DPWS) 和相關規格不會明確定義實作功能。 例如， WS-Discovery 規格不會在多主控環境中定義用戶端和主機行為。 實作 WSDAPI 時，某些探索功能已新增到規格中定義的功能之外。
WSDAPI 也會實作 WS-Discovery v1.1 CD1 的選取部分，以便透過 HTTP 與探索 Proxy 通訊。
本主題的目的是描述 WSDAPI 所實作的探索功能，但不如 DPWS 或WS-Discovery規格中所述。
IPv6 位址和 soap.udp URI 格式
SOAP-over-UDP 和 WS-Discovery不會明確描述以 soap.udp URI 格式表示常值 IPv6 位址的方式。 RFC 2396，標題為「統一資源識別項 (URI) ：一般語法」，表示 soap.udp URI 格式不支援常值 IPv6 位址。
為了簡單起見，WSDAPI 會辨識 soap.udp 配置中以方括弧括住的 IPv6 位址。 例如，WSDAPI 會辨識位址 soap.udp://[2001:abcd:0001:0002:0003:0004:0005:0032]:3702 。 這類似于在 HTTP 中處理 IPv6 位址的方式。
Hello 和 XAddrs
WSDAPI 的 DPWS 主控物件永遠不會在訊息本文中使用XAddrs傳送WS-Discovery Hello訊息。 如果用戶端需要取得 XAddrs，用戶端一律會在收到 Hello 訊息之後傳送 Resolve 訊息。
此方法有兩個優點。 首先，以 WSDAPI 建置的裝置永遠不會公開 XAddrs，以揭露私人網路的 IP 位址。 其次，以 WSDAPI 建置的裝置只會公開用戶端可存取的 XAddrs，這表示 IPv6 位址永遠不會傳送至 IPv4 用戶端。
收到 探查 或解析訊息時，回應中只會傳送單一 XAddr。 傳送的 XAddr 會對應至收到要求的本機位址。 如果透過 IPv6 在子網之間收到要求，WSDAPI 會在回應中提供全域 IPv6 位址。
慣用位址
裝置可以在 Hello、 ProbeMatch或 ResolveMatch 訊息中提供多個 XAddrs。 服務也可以在具有不同傳輸位址的多個端點上取得。 在這些情況下，WSDAPI 會嘗試在找到的第一個可用位址上與裝置通訊。 如果位址來自可用的通訊協定，例如 IPv4 安裝在已安裝 IPv4 的電腦上，或是安裝 IPv6 的機器上的 IPv6，就可以使用位址。 此外，如果位址來自不在本機子網上的裝置或服務，則只有在位址是 IPv4、IPv6 網站本機或 IPv6 連結本機時，才能使用。
中繼資料交換中的 WSDL
除非應用程式擴充以提供這項資訊，否則以 WSDAPI 建置的裝置和服務不會在中繼資料交換中提供其 WSDL。 根據預設，WSDL 布建不是程式設計模型的一部分。
APP_MAX_DELAY
DPWS 會定義APP_MAX_DELAY，這是接收 探查 和傳送 ProbeMatch之間延遲的隨機間隔，以 5，000 毫秒為單位。 Windows 防火牆要求 UDP 的多播要求/單播回應模型只能在 4 秒防火牆視窗中運作。 因此，WSDAPI 會在 2，500 毫秒或更少時傳輸回應，而不是APP_MAX_DELAY所描述的 5，000 毫秒視窗。
IANA 埠保留
WSDAPI 預設會針對 HTTP 流量使用 TCP 埠 5357，而 HTTPS 流量則使用 TCP 埠 5358。 這些埠會透過HTTP.sys中的 URL 保留來保留較低許可權的程式，而且也會與 IANA 一起保留。
UDP 埠共用
WSDAPI 使用埠共用。 所有 WSDAPI 型應用程式可能無法正確處理傳送至埠 3702 的單播訊息。 如果應用程式以獨佔方式系結至埠 3702，它可能會防止以 WSDAPI 為基礎的應用程式正確使用該埠。
WS-Discovery v1.1 CD1 Proxy
WSDAPI 會搜尋並與實作 WS-Discovery v1.1 CD1 受控模式通訊協定的探索 Proxy 通訊。 WS-Discovery v1.1 CD1 是WS-Discovery的第一個修訂，包含 HTTP 通訊協定的明確描述，以用於 Proxy 與用戶端或裝置之間的通訊。
為了限制多播要求中使用的並行版本數目，WSDAPI 會在 2005/04 命名空間中傳送WS-Discovery探查要求，但搜尋 WS-Discovery v1.1 CD1 DiscoveryProxy 類型。 如果 Proxy 回應，WSDAPI 會將 HTTP 探查或解析要求傳送至指定的 Proxy 端點，如 WS-Discovery v1.1 CD1 中所定義。