Compartilhar via

Implementar projeção sem fio em uma rede Wi-Fi existente

Desde o lançamento da Atualização para Criadores, o Windows foi atualizado para dar suporte à Projeção Sem Fio em uma rede Wi-Fi existente. Ele é implementado em todos os dispositivos Windows que executam a Atualização para Criadores, incluindo Windows, Surface Hub, Surface Hub 2S e Xbox.

A Projeção Sem Fio do Windows em uma funcionalidade de rede existente aproveita e se baseia na funcionalidade originalmente fornecida pelo Miracast, como usar Wi-Fi Direct para descoberta e usar RTSP para transportar o fluxo de vídeo, mas inclui um mecanismo separado para identificar a rota para o receptor pela conexão de rede existente.

Recomendamos que os fabricantes do coletor Miracast sigam a especificação, pois ela é definida no MS-MICE e as diretrizes fornecidas na seção a seguir para implementar funcionalidades semelhantes do lado do coletor.

Os aspectos obrigatórios da projeção sem fio em uma rede Wi-Fi existente

Com o tempo, a especificação de MS_MICE cresceu e se tornou mais complexa à medida que funcionalidades adicionais foram adicionadas. A próxima seção desta documentação foi projetada para ajudar um implementador a entender a funcionalidade de linha de base mínima necessária para fornecer a Projeção Sem Fio em um método de rede existente em um receptor.

Apenas um pequeno número de alterações precisa ser feita ao receptor para dar suporte à projeção sem fio em uma rede existente. Eles quebram da seguinte maneira:

  1. Modificar os elementos de informações (IEs) que o receptor emite

  2. Habilitar o respondente mDNS para enviar a resposta adequada

  3. Implementar um ouvinte TCP na porta 7250 e manipular duas mensagens específicas

Modificar os IEs no receptor

O primeiro conjunto de alterações que você deve fazer ao receptor é implementar o atributo de extensão Vendor definido na seção 2.2.3 da especificação MS-MICE. É necessário que cada Beacon e Resposta de Investigação que o Receptor envia inclua o atributo Extensão do Fornecedor.

Dentro do atributo de extensão do fornecedor, você precisa definir dois sub-atributos para habilitar a funcionalidade básica:

  1. O atributo nome do host

  2. O atributo Capability

Além disso, dentro do Atributo de Funcionalidade, apenas dois valores precisam ser definidos:

  • A - MiracastOverInfrastructureSupport (1 bit): 0 = sem suporte, 1 = com suporte

  • C – Versão (3 bits): a versão deste protocolo, que é 0x1

Todos os outros bits podem ser definidos como 0

Respondendo a consultas mDNS

O Receptor Miracast DEVE registrar os seguintes registros com a implementação de mDNS local do receptor.

  • Um registro SRV associado à porta 7250

    • <nome> da instância._display._tcp.local

    • Onde o nome> da <instância é o nome amigável do Receptor

  • E o seguinte par chave-valor TXT

    • Chave: container_id

    • Valor: um GUID que identifica o Receptor.

Tratamento de protocolo

O Receptor precisa executar duas etapas:

  1. O receptor deve começar a escutar na porta TCP 7250 para uma conexão de entrada.

  2. O Receptor precisa ser capaz de receber e responder ao conjunto mínimo de mensagens de protocolo definidas na próxima seção.

Embora 6 mensagens sejam definidas na especificação MS-MICE, o Receptor só precisa receber e responder às duas mensagens a seguir para implementar a funcionalidade básica:

  • SOURCE_READY

  • STOP_PROJECTION

Mensagens Seção Descrição
SOURCE_READY 0x01 [2.2.1] Indica que a Origem miracast está pronta para aceitar uma conexão na porta RTSP. Obrigatório
STOP_PROJECTION 0x02 [2.2.2] Indica o final da projeção. Obrigatório
SECURITY_HANDSHAKE 0x03 [2.2.3] Usado para trocar mensagens de handshake DTLS para iniciar uma conexão com a criptografia do fluxo multimídia. Opcional
SESSION_REQUEST 0x04 [2.2.4] Indica que a Origem miracast pretende se conectar ao coletor usando as opções especificadas. Opcional
PIN_CHALLENGE 0x05 [2.2.5] Enviado pela Fonte miracast para iniciar a sessão usando o PIN exibido pelo Coletor Miracast. Opcional
PIN_RESPONSE 0x06 [2.2.6] Enviado pelo Coletor Miracast em resposta a um PIN_CHALLENGE recebido da Fonte miracast. Opcional

Embora 7 TLVs sejam definidas na especificação MS-MICE, somente as três TLVs a seguir são necessárias para a funcionalidade básica:

  1. FRIENDLY_NAME

  2. RTSP_PORT

  3. SOURCE_ID

TLV Seção Descrição
FRIENDLY_NAME 0x00 [2.2.7.1] Especifica o nome amigável da Fonte miracast. Obrigatório
RTSP_PORT 0x02 [2.2.7.2] Especifica a porta na qual a Origem está escutando conexões RTSP. Obrigatório
SOURCE_ID 0x03 [2.2.7.3] Especifica um identificador para a Origem, que é usada para todas as mensagens enviadas durante uma sessão miracast. Obrigatório
SECURITY_TOKEN 0x04 [2.2.7.4] Contém uma mensagem de handshake DTLS. Opcional
SECURITY_OPTIONS 0x05 [2.2.7.5] Especifica se a criptografia de fluxo e/ou a entrada de PIN serão usadas para a sessão. Opcional
PIN_CHALLENGE 0x06 [2.2.7.6] Contém um hash salgado do PIN quando a entrada pin é usada para estabelecer a conexão. Opcional
PIN_RESPONSE_REASON 0x07 [2.2.7.7] Especifica se a resposta pin indica uma conexão bem-sucedida. Opcional