Compartir a través de

Implementación de la proyección inalámbrica a través de una red Wi-Fi existente

Desde el lanzamiento de Creators Update, Windows se ha actualizado para admitir la proyección inalámbrica a través de una red Wi-Fi existente. Se implementa en todos los dispositivos Windows que ejecutan Creators Update, incluidos Windows, Surface Hub, Surface Hub 2S y Xbox.

Proyección inalámbrica de Windows a través de una funcionalidad de red existente aprovecha y se basa en la funcionalidad proporcionada originalmente por Miracast, como el uso de Wi-Fi Direct para la detección y el uso de RTSP para transportar la secuencia de vídeo, pero incluye un mecanismo independiente para identificar la ruta al receptor a través de la conexión de red existente.

Se recomienda que los fabricantes de receptores de Miracast sigan la especificación tal y como se define en MS-MICE y las directrices proporcionadas en la sección siguiente para implementar una funcionalidad similar del lado receptor.

Los aspectos obligatorios de la proyección inalámbrica a través de una red Wi-Fi existente

Con el tiempo, la especificación de MS_MICE ha crecido y se ha vuelto más compleja a medida que se ha agregado funcionalidad adicional. La siguiente sección de esta documentación está diseñada para ayudar a un implementador a comprender la funcionalidad de línea base mínima necesaria para entregar la proyección inalámbrica a través de un método de red existente en un receptor.

Solo es necesario realizar un pequeño número de cambios en el receptor para admitir la proyección inalámbrica a través de una red existente. Se desglosan de la siguiente manera:

  1. Modificar los elementos de información (IE) que emite el receptor

  2. Permitir que el respondedor de mDNS envíe la respuesta adecuada

  3. Implementar un agente de escucha TCP en el puerto 7250 y controlar 2 mensajes específicos

Modificación de las IEs en el receptor

El primer conjunto de cambios que debe realizar en el receptor es implementar el atributo de extensión Vendor definido en la sección 2.2.3 de la especificación MS-MICE. Es necesario que cada baliza y respuesta de sondeo que el receptor envíe DEBE incluir el atributo Extensión del proveedor.

En el atributo de extensión de proveedor, debe definir dos sub atributos para habilitar la funcionalidad básica:

  1. Atributo de nombre de host

  2. Atributo de funcionalidad

Además, en el atributo de funcionalidad solo deben establecerse dos valores:

  • A: MiracastOverInfrastructureSupport (1 bit): 0 = no compatible, 1 = compatible

  • C: versión (3 bits): la versión de este protocolo, que es 0x1

Todos los demás bits se pueden establecer en 0

Respuesta a las consultas de mDNS

El receptor de Miracast DEBE registrar los siguientes registros con la implementación local de mDNS del receptor.

  • Un registro SRV asociado al puerto 7250

    • <nombre> de instancia._display._tcp.local

    • Donde el nombre> de la <instancia es el nombre descriptivo del receptor

  • Y el siguiente par clave-valor TXT

    • Clave: container_id

    • Valor: GUID que identifica el receptor.

Control de protocolos

El receptor debe realizar dos pasos:

  1. El receptor DEBE empezar a escuchar en el puerto TCP 7250 para una conexión entrante.

  2. El receptor debe poder recibir y responder al conjunto mínimo de mensajes de protocolo definidos en la sección siguiente.

Aunque se definen 6 mensajes en la especificación MS-MICE, el receptor solo debe recibir y responder a los siguientes 2 mensajes para implementar la funcionalidad básica:

  • SOURCE_READY

  • STOP_PROJECTION

error de Hadoop Sección Descripción
SOURCE_READY 0x01 [2.2.1] Indica que el origen de Miracast está listo para aceptar una conexión en el puerto RTSP. Mandatory
STOP_PROJECTION 0x02 [2.2.2] Indica el final de la proyección. Mandatory
SECURITY_HANDSHAKE 0x03 [2.2.3] Se usa para intercambiar mensajes de protocolo de enlace DTLS para iniciar una conexión con el cifrado de la secuencia multimedia. Opcionales
SESSION_REQUEST 0x04 [2.2.4] Indica que el origen de Miracast pretende conectarse al receptor mediante las opciones especificadas. Opcionales
PIN_CHALLENGE 0x05 [2.2.5] Enviado por el origen de Miracast para iniciar la sesión mediante el PIN mostrado por el receptor de Miracast. Opcionales
PIN_RESPONSE 0x06 [2.2.6] Enviado por el receptor de Miracast en respuesta a un PIN_CHALLENGE recibido del origen de Miracast. Opcionales

Aunque se definen 7 TLV en la especificación MS-MICE, solo se requieren 3 TLV siguientes para la funcionalidad básica:

  1. FRIENDLY_NAME

  2. RTSP_PORT

  3. SOURCE_ID

TLV Sección Descripción
FRIENDLY_NAME 0x00 [2.2.7.1] Especifica el nombre descriptivo del origen de Miracast. Mandatory
RTSP_PORT 0x02 [2.2.7.2] Especifica el puerto en el que el origen está escuchando las conexiones RTSP. Mandatory
SOURCE_ID 0x03 [2.2.7.3] Especifica un identificador para el origen, que se usa para todos los mensajes enviados durante una sesión de Miracast. Mandatory
SECURITY_TOKEN 0x04 [2.2.7.4] Contiene un mensaje de protocolo de enlace DTLS. Opcionales
SECURITY_OPTIONS 0x05 [2.2.7.5] Especifica si el cifrado de secuencias o la entrada de PIN se usarán para la sesión. Opcionales
PIN_CHALLENGE 0x06 [2.2.7.6] Contiene un hash salado del PIN cuando se usa la entrada PIN para establecer la conexión. Opcionales
PIN_RESPONSE_REASON 0x07 [2.2.7.7] Especifica si la respuesta del PIN indica una conexión correcta. Opcionales