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:
Modify the Information Elements (IEs) that your receiver emits
Enable your mDNS responder to send the proper response
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:
The Host Name Attribute
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:
The Receiver MUST start listening on TCP port 7250 for an inbound connection.
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:
SOURCE_READY
STOP_PROJECTION
| 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:
FRIENDLY_NAME
RTSP_PORT
SOURCE_ID
| TLV | Section | Description |
|---|---|---|
| FRIENDLY_NAME 0x00 | [2.2.7.1] | Specifies the friendly name of the Miracast Source. Mandatory |
| RTSP_PORT 0x02 | [2.2.7.2] | Specifies the port on which the Source is listening for RTSP connections. Mandatory |
| SOURCE_ID 0x03 | [2.2.7.3] | Specifies an identifier for the Source, which is used for all messages sent during a Miracast session. Mandatory |
| SECURITY_TOKEN 0x04 | [2.2.7.4] | Contains a DTLS handshake message. Optional |
| SECURITY_OPTIONS 0x05 | [2.2.7.5] | Specifies whether stream encryption and/or PIN entry will be used for the session. Optional |
| PIN_CHALLENGE 0x06 | [2.2.7.6] | Contains a salted hash of the PIN when PIN entry is used to establish the connection. Optional |
| PIN_RESPONSE_REASON 0x07 | [2.2.7.7] | Specifies whether the PIN Response indicates a successful connection. Optional |