Implementing Wireless Projection over an existing Wi-Fi network

Since the release of the Creators Update, Windows has been updated to support Wireless Projection over an existing Wi-Fi network. It is implemented on all Windows devices running the Creators Update including Windows, Surface Hub, Surface Hub 2S and Xbox.

Windows Wireless Projection over an existing network functionality leverages and builds upon functionality originally provided by Miracast such as using Wi-Fi Direct for discovery and using RTSP for transporting the video stream but includes a separate mechanism to identify the route to the receiver over the existing network connection.

We recommend that Miracast sink manufacturers follow the specification as it is defined in MS-MICE and the guidelines provided in the following section to implement similar sink side functionality.

The Mandatory aspects of Wireless Projection over an existing Wi-Fi network

Over time the MS_MICE specification has grown and become more complex as additional functionality has been added. The next section of this documentation is designed to help an implementor understand the minimal baseline functionality needed to deliver the Wireless Projection over an existing network method on a receiver.

Only a small number of changes need to be made to your Receiver in order to support wireless projection over an existing network. They break down as follows:

  1. Modify the Information Elements (IEs) that your receiver emits

  2. Enable your mDNS responder to send the proper response

  3. Implement a TCP listener on port 7250 and handle 2 specific messages

Modify the IEs in your Receiver

The first set of changes you should make to your receiver is to implement the Vendor extension attribute defined in section 2.2.3 of the MS-MICE spec. It is required that every Beacon and Probe Response the Receiver sends MUST include the Vendor Extension attribute.

Within the vendor extension attribute you need to define two sub-attributes to enable basic functionality:

  1. The Host Name Attribute

  2. The Capability Attribute

Additionally, within the Capability Attribute only two values need to be set:

  • A - MiracastOverInfrastructureSupport (1 bit): 0 = not supported, 1 = supported

  • C - Version (3 bits): The version of this protocol, which is 0x1

All other bits can be set to 0

Responding to mDNS queries

The Miracast Receiver MUST register the following records with the Receiver's local mDNS implementation.

  • An SRV record associated with port 7250

    • <instance name>._display._tcp.local

    • Where the <instance name> is the friendly name of the Receiver

  • And the following TXT key-value pair

    • Key: container_id

    • Value: A GUID that identifies the Receiver.

Protocol Handling

The Receiver needs to perform two steps:

  1. The Receiver MUST start listening on TCP port 7250 for an inbound connection.

  2. The Receiver needs to be able to receive and respond to the minimal set of protocol messages defined in the next section.

While 6 Messages are defined in the MS-MICE specification, the Receiver only needs to receive and respond to the following 2 Messages in order to implement basic functionality:



Messages Section Description
SOURCE_READY 0x01 [2.2.1] Indicates the Miracast Source is ready to accept a connection on the RTSP port. Mandatory
STOP_PROJECTION 0x02 [2.2.2] Indicates the end of the projection. Mandatory
SECURITY_HANDSHAKE 0x03 [2.2.3] Used to exchange DTLS handshake messages to initiate a connection with encryption of the multimedia stream. Optional
SESSION_REQUEST 0x04 [2.2.4] Indicates the Miracast Source intends to connect to the Sink using the specified options. Optional
PIN_CHALLENGE 0x05 [2.2.5] Sent by the Miracast Source to initiate the session using the PIN displayed by the Miracast Sink. Optional
PIN_RESPONSE 0x06 [2.2.6] Sent by the Miracast Sink in response to a PIN_CHALLENGE received from the Miracast Source. Optional

While 7 TLVs are defined in the MS-MICE specification, only the following 3 TLVs are required for basic functionality:




TLV Section Description
FRIENDLY_NAME 0x00 [] Specifies the friendly name of the Miracast Source. Mandatory
RTSP_PORT 0x02 [] Specifies the port on which the Source is listening for RTSP connections. Mandatory
SOURCE_ID 0x03 [] Specifies an identifier for the Source, which is used for all messages sent during a Miracast session. Mandatory
SECURITY_TOKEN 0x04 [] Contains a DTLS handshake message. Optional
SECURITY_OPTIONS 0x05 [] Specifies whether stream encryption and/or PIN entry will be used for the session. Optional
PIN_CHALLENGE 0x06 [] Contains a salted hash of the PIN when PIN entry is used to establish the connection. Optional
PIN_RESPONSE_REASON 0x07 [] Specifies whether the PIN Response indicates a successful connection. Optional