Como usar a interface de fluxo RTSP da OpenAPI do VIGI NVR
Conteúdo
Verifique a configuração RTSP do NVR
Acessando transmissões de visualização ao vivo e reprodução via RTSP
Processo de Transmissão de Áudio de Fala
Introdução
O OpenAPI do NVR VIGI fornece uma interface de fluxo baseada em RTSP para visualização ao vivo, reprodução e transmissão de áudio para bate-papo. A visualização ao vivo e a reprodução permitem que os clientes recebam fluxos de áudio e vídeo ao vivo ou gravados, enquanto a função de bate-papo permite que o áudio do microfone seja transmitido para o canal da câmera selecionada.
Essas funções usam RTSP para estabelecer e controlar as sessões, autenticação Digest para verificar o acesso e RTP para transmitir os dados de mídia. Para visualização ao vivo e reprodução, o RTP pode ser transmitido via TCP ou UDP, dependendo do modo de transporte negociado durante o processo de configuração do RTSP. No fluxo de trabalho de conversação descrito neste artigo, o áudio do microfone é transmitido por meio de uma sessão de conversação separada, através de uma conexão TCP dedicada.
Requisitos
- NVR VIGI compatível com OpenAPI. (Para verificar os modelos compatíveis, consulte Dispositivos compatíveis com a API OpenAPI da VIGI)
- Documento OpenAPI do VIGI NVR
- Um cliente RTSP ou plataforma de terceiros que possa alcançar o NVR pela rede
Configuração
Verifique a configuração RTSP do NVR
A interface de fluxo OpenAPI do NVR VIGI é implementada com base em RTSP. O RTSP está habilitado por padrão no NVR VIGI e a porta RTSP padrão é 554. Antes de acessar os fluxos de visualização ao vivo ou reprodução, ou estabelecer uma sessão de conversação, confirme se o RTSP está habilitado e verifique a porta RTSP configurada.
O procedimento a seguir utiliza a página de gerenciamento web do NVR como exemplo.
Passo 1. Faça login na interface web do NVR usando o endereço IP. Digite o nome de usuário e a senha e clique em Entrar.

Passo 2. Navegue até Configurações > Rede > Serviço de Rede > RTSP(S). Certifique-se de que a opção RTSP esteja ativada e anote a Porta RTSP
Nota: Certifique-se de que o RTSP e o SRTP estejam desativados. Caso contrário, plataformas de terceiros podem não conseguir acessar o fluxo por meio do RTSP padrão.

Acessando transmissões de visualização ao vivo e reprodução via RTSP
As interfaces de visualização ao vivo e reprodução do NVR VIGI utilizam o protocolo RTSP padrão para estabelecer e controlar sessões de streaming, enquanto o RTP transporta os dados de áudio e vídeo. Clientes RTSP padrão ou plataformas de terceiros podem acessar os fluxos utilizando o URL correspondente e concluindo a autenticação RTSP e a configuração da sessão.
O fluxo de trabalho a seguir usa a Visualização ao Vivo como exemplo, pois a Visualização ao Vivo e a Reprodução seguem o mesmo processo geral. Para a Reprodução, use o URL de Reprodução e o intervalo de tempo correspondentes. Para obter informações sobre os métodos, formatos de URL, parâmetros e Autenticação Digest compatíveis, consulte as Seções 5.1–5.3 do Documento OpenAPI do NVR VIGI e a Pergunta 2 na seção de Perguntas e Respostas deste artigo.
Etapa 1. Estabeleça a conexão RTSP e consulte os métodos suportados.
O cliente primeiro estabelece uma conexão TCP com o NVR através da porta RTSP configurada, que por padrão é a 554. Os passos são os seguintes:
(1)O cliente envia uma solicitação OPTIONS inicial não autenticada para consultar os métodos RTSP suportados pelo NVR.
|
/* Nenhuma solicitação de autenticação */ C->S : OPTIONS rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 1\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n \r\n |
(2)O NVR retorna 200 OK e lista os métodos RTSP suportados no cabeçalho público.
|
S->C : RTSP/1.0 200 OK\r\n CSeq: 1\r\n Data: segunda-feira, 20 de julho de 2026, 21:57:33 GMT\r\n User-Agent: vigi\r\n Público: DESCRIBE,SETUP,DEARDOWN,PLAY,PAUSE,GET_PARAMETER,SET_PARAMETER\r\n Content-Length: 0\r\n \r\n |
A seguinte captura do Wireshark mostra a solicitação OPTIONS inicial e a resposta 200 OK correspondente do NVR.

Etapa 2. Solicite a descrição da mídia e conclua a autenticação do Digest.
O cliente envia uma solicitação DESCRIBE não autenticada para obter a descrição da mídia do fluxo solicitado. Como a solicitação não contém informações de autenticação, o NVR responde com 401 Não Autorizado e fornece um desafio de autenticação Digest no cabeçalho WWW-Authenticate.
(1) O cliente envia uma solicitação DESCRIBE não autenticada para a descrição de mídia SDP.
|
/* Nenhuma solicitação de autenticação */ C->S : DESCRIBE rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 2\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Aceitar: application/sdp\r\n \r\n |
(2)O NVR retorna 401 Não Autorizado e fornece o desafio de autenticação Digest no cabeçalho WWW-Authenticate.
|
S->C:\r\n RTSP/1.0 401 Não autorizado\r\n CSeq: 2\r\n User-Agent: vigi\r\n WWW-Authenticate: Digest realm="vigi", nonce="668a48d0", stale="FALSE"\r\n Content-Length: 0\r\n \r\n |
Observação: A resposta 401 Não Autorizado é uma parte esperada do processo de autenticação Digest e não indica uma falha final de autenticação.
(3) O cliente obtém o realm e o nonce do cabeçalho WWW-Authenticate e os utiliza juntamente com o nome de usuário, senha, o método RTSP atual e o URI da solicitação para calcular a resposta Digest. Em seguida, reenvia a solicitação DESCRIBE com o cabeçalho Authorization.
Por exemplo:
Método: DESCRIBE
URI da solicitação: rtsp://192.168.0.110:554/live/1/2/avm
O algoritmo Digest deve corresponder ao Algoritmo de Autenticação configurado no NVR.
Neste exemplo, o NVR está configurado para usar MD5.
HA1 = MD5(nome de usuário:domínio:senha)
HA2 = MD5(método: URI da solicitação)
resposta = MD5(HA1:nonce:HA2)
Nota: Verifique o Algoritmo de Autenticação em Configurações > Rede > Serviço de Rede > RTSP(S). O cliente deve usar o mesmo algoritmo ao calcular a resposta Digest.

O cliente reenvia a solicitação DESCRIBE com as credenciais Digest incluídas no cabeçalho de Autorização.
|
C->S : DESCRIBE rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 3\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Aceitar: application/sdp\r\n Autorização: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm", response=" \r\n |
(4) O NVR verifica a resposta Digest. Se a autenticação for bem-sucedida, ele retorna 200 OK juntamente com a descrição da mídia SDP.
A resposta SDP descreve as faixas de mídia disponíveis e seus codecs. Neste exemplo, a faixa 1 transporta vídeo H.264, enquanto a faixa 2 transporta áudio PCMA. Nota: a faixa 3 transporta dados definidos por um protocolo proprietário da VIGI e não é necessária para streaming padrão de vídeo e áudio.
|
S->C : RTSP/1.0 200 OK\r\n CSeq: 3\r\n Data: segunda-feira, 20 de julho de 2026, 19:01:11 GMT\r\n Content-Type: application/sdp\r\n Content-Length: 395\r\n \r\n v=0\r\n s=Sessão transmitida pelo "Servidor RTSP da TP-Link"\r\n t=0 0\r\n m=vídeo 0 RTP/AVP 96\r\n a=control:track1\r\n a=rtpmap:96 H264/90000\r\n a=fmtp:96 packetization-mode=1; profile-level-id=4D4032; sprop-parameter-sets=Z00AKpY1QPAET8s3AQEBQAABwgAAV+QB,aO48gA==\r\n m=audio 0 RTP/AVP 8\r\n a=control:track2\r\n a=rtpmap:8 PCMA/8000\r\n m=application/TP-LINK 0 RTP/AVP smart/0/25000\r\n a=rtpmap:95 TP-LINK/25000\r\n |

Passo 3. Configure as faixas de mídia e inicie a transmissão RTP.
Após a autenticação bem-sucedida, o cliente configura as faixas de mídia necessárias e negocia o modo de transporte. Tanto o RTP sobre UDP quanto o RTP sobre RTSP/TCP são suportados. Este exemplo usa RTP sobre RTSP/TCP com transporte intercalado.
(1) O cliente envia solicitações SETUP separadas para as faixas de vídeo e áudio necessárias e especifica o modo de transporte para cada faixa. O NVR retorna 200 OK para cada solicitação. Neste exemplo, ambas as faixas usam o mesmo ID de sessão RTSP e o cliente solicita RTP sobre RTSP/TCP. Os canais intercalados 0 e 1 são atribuídos aos fluxos de vídeo RTP e RTCP, enquanto os canais 2 e 3 são atribuídos aos fluxos de áudio RTP e RTCP.
|
C->S:\r\n CONFIGURAÇÃO rtsp://192.168.0.110:554/live/1/2/avm/track1 RTSP/1.0\r\n CSeq: 4\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Transporte: RTP/AVP/TCP;unicast;intercalado=0-1\r\n Autorização: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm/track1", response=" \r\n
S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 4\r\n User-Agent: vigi\r\n Sessão: 0x7fb484; tempo limite = 60\r\n Transporte: RTP/AVP/TCP;intercalado=0-1\r\n Content-Length: 0\r\n \r\n
C->S:\r\n CONFIGURAÇÃO rtsp://192.168.0.110:554/live/1/2/avm/track2 RTSP/1.0\r\n CSeq: 5\r\n Sessão: 0x7fb484\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Transporte: RTP/AVP/TCP;unicast;intercalado=2-3\r\n Autorização: Digest username="admin", realm="vigi", nonce="668a48d0", uri="rtsp://192.168.0.110:554/live/1/2/avm/track2", response=" \r\n
S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 5\r\n User-Agent: vigi\r\n Sessão: 0x7fb484; tempo limite = 60\r\n Transporte: RTP/AVP/TCP;intercalado=2-3\r\n Content-Length: 0\r\n \r\n |

Nota: No transporte intercalado RTSP, os pacotes RTP e RTCP para várias faixas de mídia compartilham a mesma conexão TCP e são diferenciados por seus números de canal intercalados.
(2) O cliente envia uma solicitação PLAY com o ID da Sessão para iniciar a transmissão de mídia.
|
C->S:\r\n PLAY rtsp://192.168.0.110:554/live/1/2/avm RTSP/1.0\r\n CSeq: 6\r\n Sessão: 0x7fb484\r\n User-Agent: VIGI-RTSP-Player/1.0\r\n Autorização: Digest username="admin", realm="vigi", nonce="668a48d0", uri ="rtsp://192.168.0.110:554/live/1/2/avm", response=" \r\n |

(3) O NVR retorna 200 OK e começa a transmitir os pacotes de mídia RTP pela conexão TCP RTSP estabelecida.
Nota: Na visualização "Seguir fluxo TCP" do Wireshark, os dados RTP intercalados aparecem como conteúdo binário após a resposta RTSP.
|
S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 6\r\n Data: segunda-feira, 20 de julho de 2026, 21:57:33 GMT\r\n User-Agent: vigi\r\n Sessão: 0x7fb484; tempo limite = 60\r\n Informações RTP: url=rtsp://192.168.0.110:554/live/1/2/avm;seq=34976;rtptime=2315908260\r\n Content-Length: 0\r\n \r\n |

Após a solicitação PLAY ser aceita, o cliente recebe continuamente pacotes de mídia RTP através do transporte negociado. Neste exemplo, os pacotes de mídia são transmitidos pela conexão TCP RTSP estabelecida usando transporte intercalado.
Etapa 4Analisar e decodificar os pacotes de mídia RTP.
Após receber os pacotes de mídia RTP, o cliente os analisa e decodifica para renderizar o vídeo ao vivo e reproduzir o áudio associado. Os passos são os seguintes:
(1) Analise o cabeçalho do pacote RTP.
O cliente lê campos como o número de sequência, o carimbo de data/hora, o bit marcador e o tipo de carga útil. O número de sequência é usado para detectar a ordem dos pacotes e a perda de pacotes, enquanto o carimbo de data/hora é usado para sincronização e temporização da mídia. O tipo de carga útil é usado em conjunto com os atributos a=rtpmap do SDP para identificar o codec e a taxa de clock correspondentes.
Para os valores de Tipo de Carga Útil definidos ou recomendados para fluxos VIGI NVR, consulte o Apêndice II, Tipo de Carga Útil, no Documento OpenAPI do VIGI NVR. Os Tipos de Carga Útil Dinâmicos podem variar, portanto, as informações SDP retornadas pelo NVR devem ser usadas como referência principal.
Neste exemplo:
a=rtpmap:96 H264/90000
a=rtpmap:8 PCMA/8000
O tipo de carga útil 96 transporta vídeo H.264, enquanto o tipo de carga útil 8 transporta áudio PCMA.
(2) Processar a carga útil RTP.
O cliente remove o cabeçalho RTP e extrai a carga útil de mídia codificada. Para vídeo H.264, o cliente reconstrói unidades NAL completas a partir da carga útil RTP, incluindo unidades NAL fragmentadas ou agregadas, quando aplicável. Para áudio PCMA, o cliente extrai as amostras de áudio G.711 A-law da carga útil RTP.
(3) Decodificar e renderizar a mídia.
O cliente envia os dados de vídeo e áudio reconstruídos para os decodificadores correspondentes. Uma biblioteca de mídia como o FFmpeg pode decodificar o vídeo H.264 em uma sequência de quadros e converter o áudio PCMA em amostras PCM reproduzíveis. O cliente então renderiza os quadros de vídeo e envia o áudio para o dispositivo de reprodução.
Nota: O processo exato de desempacotamento e decodificação depende do codec identificado no SDP. O cliente deve implementar o formato de payload RTP e o decodificador correspondentes para cada codec suportado.
Processo de Transmissão de Áudio
Conforme descrito em Acessando fluxos de visualização ao vivo e reprodução via RTSP, o cliente recebe vídeo e áudio do NVR por meio da sessão de visualização ao vivo. Esta seção descreve o processo de conversação, no qual o cliente captura o áudio do microfone e o transmite para o NVR ou para uma câmera gerenciada pelo NVR para saída pelo alto-falante.
A função Talk utiliza uma extensão RTSP específica do VIGI. O cliente deve estabelecer uma sessão Talk separada e transmitir o áudio de acordo com os comandos de sessão, formato de áudio e regras de encapsulamento RTP exigidos.
Passo 1. Estabeleça uma Conexão RTSP separada para Conversa.
O cliente estabelece uma conexão TCP separada com o NVR através da porta RTSP configurada. Essa conexão é dedicada à transmissão de áudio do Talk e é independente da sessão Live View. Em seguida, o cliente envia uma solicitação MULTITRANS inicial não autenticada para o URI /multitrans.
Nota: MULTITRANS é uma extensão RTSP proprietária implementada pelo VIGI NVR e pode não aparecer no cabeçalho público retornado pela sessão RTSP padrão.
|
C->S:\r\n MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n CSeq: 1\r\n User-Agent: VIGI-Python-Talk/1.0\r\n Content-Type: application/json\r\n Content-Length: 0\r\n \r\n |

Etapa 2. Conclua a autenticação Digest.
A solicitação inicial MULTITRANS não inclui informações de autenticação. Portanto, o NVR retorna 401 Não Autorizado juntamente com um desafio de autenticação Digest. O cliente calcula a resposta Digest conforme descrito na seção anterior e reenvia a solicitação MULTITRANS com o cabeçalho de Autorização.
|
S->C:\r\n RTSP/1.0 401 Não autorizado\r\n CSeq: 1\r\n Data: segunda-feira, 27 de julho de 2026, 22:42:08 GMT \r\n User-Agent: vigi\r\n WWW-Authenticate: Digest realm="vigi", nonce="f62dd168", stale="FALSE"\r\n Content-Length: 0\r\n \r\n
C->S:\r\n MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n CSeq: 2\r\n User-Agent: VIGI-Python-Talk/1.0\r\n Content-Type: application/json\r\n Content-Length: 0\r\n Autorização: Digest username="admin", realm="vigi", nonce="6061d988", uri="rtsp://192.168.0.110:554/multitrans", response=" \r\n |

Etapa 3. Criar a Sessão de Conversa.
Após a solicitação MULTITRANS autenticada ser aceita, o NVR retorna 200 OK e cria uma sessão RTSP dedicada para a conexão de comunicação. A resposta inclui um valor de sessão RTSP e um session_id em JSON. O cliente deve reter esses valores e usá-los conforme necessário em interações de comunicação subsequentes.
|
S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 2\r\n Data: segunda-feira, 27 de julho de 2026, 22:42:08 GMT \r\n User-Agent: vigi\r\n Sessão: 0x822e60\r\n Content-Type: application/json\r\n Content-Length: 80\r\n \r\n {"type":"response","seq":2,"params":{"error_code":0,"session_id":"14684328"}} |
Um valor de código de erro igual a 0 indica que a sessão do Talk foi criada com sucesso.

Passo 4. Envie o comando de fala.
Após a criação da sessão de conversação, o cliente envia outra solicitação autenticada MULTITRANS contendo um comando de conversação JSON. O comando especifica o modo de conversação e o canal NVR de destino, cujo alto-falante da câmera reproduzirá o áudio carregado.
|
C->S:\r\n MULTITRANS rtsp://192.168.0.110:554/multitrans RTSP/1.0\r\n CSeq: 3\r\n User-Agent: VIGI-Python-Talk/1.0\r\n Content-Type: application/json\r\n Content-Length: 93\r\n Sessão 0x822e60\r\n Autorização: Digest username="admin", realm="vigi", nonce="6061d988", uri="rtsp://192.168.0.110:554/multitrans", response=" \r\n {"type":"request","seq":1,"params":{"method":"do","talk":{"mode":"half_duplex","channel":1}}}
S->C:\r\n RTSP/1.0 200 OK\r\n CSeq: 3\r\n Data: segunda-feira, 27 de julho de 2026, 22:42:08 GMT\r\n User-Agent: vigi\r\n Sessão: 0x822e60\r\n Content-Type: application/json\r\n Content-Length: 80\r\n \r\n {"type":"response","seq":3,"params ":{"error_code":0,"session_id":"14684328"}} |
Um valor de código de erro igual a 0 indica que o comando Talk foi aceito com sucesso.

Etapa 5. Preparar, encapsular e transmitir os dados de áudio da fala.
Após o comando Talk ser aceito, o cliente captura o áudio do microfone e o converte para o formato de áudio Talk necessário.
Configurações de áudio recomendadas:
- Codec: G.711 μ-law
- Taxa de amostragem: 16 kHz
- Canal de áudio: Mono
- Tamanho do pacote: 1056 bytes
- Intervalo de transmissão: 66 ms por pacote
Perfil de transmissão alternativo:
- Tamanho do pacote: 640 bytes
- Intervalo de transmissão: 40 ms por pacote
Se o microfone usar um formato de áudio nativo diferente, como PCM de 48 kHz, o aplicativo cliente deverá reamostrar o áudio para 16 kHz, convertê-lo para mono e codificá-lo como G.711 μ-law antes da transmissão.
Cada bloco de áudio codificado é encapsulado em um quadro binário intercalado RTSP e transmitido pela conexão TCP dedicada da Talk.
O exemplo a seguir utiliza o perfil de transmissão recomendado de 1056 bytes.
|
$(1B) |
Chn ID (1B) |
Comprimento (2B) |
Dados de áudio brutos |
|
0x24 |
0x00 |
0x04 0x20 |
Exemplo: payload G.711 &mu-law de 1056 bytes |
Os valores mostrados acima foram obtidos da implementação de teste:
- 0x24 é o identificador de quadro intercalado RTSP.
- 0x00 é o ID do canal intercalado configurado pelo aplicativo cliente para dados de áudio de conversação.
- 0x04 0x20 indica que os seguintes dados de áudio brutos têm 1056 bytes de comprimento.
- Os dados que seguem o cabeçalho intercalado são áudio bruto G.711 μ-law e não contêm um cabeçalho RTP.
O campo Comprimento deve corresponder ao tamanho real da carga útil de áudio. Quando o perfil alternativo é usado, o campo Comprimento é 0x02 0x80, indicando um bloco de áudio de 640 bytes.
Para obter detalhes sobre a estrutura do pacote de áudio Talk, consulte a Seção 5.4 Talk, no documento OpenAPI do NVR da VIGI.

Nota: Os bytes destacados no seguinte dump hexadecimal do Wireshark correspondem ao frame de exemplo mostrado acima
Conclusão
A interface de transmissão VIGI NVR permite que clientes de terceiros acessem transmissões de visualização ao vivo e reprodução por meio de fluxos de trabalho RTSP e RTP padrão. No fluxo de trabalho descrito neste artigo, a transmissão de áudio de conversação utiliza uma sessão de conversação específica da VIGI para enviar o áudio do microfone para o canal da câmera selecionada.
QA
P1: Onde posso encontrar o documento OpenAPI do VIGI NVR?
A1: Acesse a Central de Downloads, procure o modelo do NVR e abra a página de download do produto. Em Manual, baixe o Documento OpenAPI do NVR VIGI correspondente.

P2: Quais são os formatos de URL RTSP para visualização ao vivo e reprodução?
A2: Os formatos de URL RTSP são os seguintes.
Visualização ao vivo:
rtsp://<IP>/live/<channel>/<stream>/avm
Reprodução:
rtsp://
- canal: Número do canal do NVR.
- fluxo: 1 para o fluxo principal e 2 para o subfluxo.
- Hora de início e hora de término: Especifique as horas de início e término da reprodução usando o formato AAAAMMDDtHHMMSSz para UTC+0. Em firmwares compatíveis, substitua z por l e insira a hora de reprodução no fuso horário local do NVR; nenhuma conversão de UTC é necessária.
Exemplos:
Exemplo de URL de visualização ao vivo:
rtsp://192.168.0.240/live/1/1/avm
Exemplo de URL de reprodução usando UTC+0:
rtsp://192.168.0.240/replay/1/1/avm?starttime=20260720t154500z&endtime=20260720t161000z
Exemplo de URL de reprodução usando a hora local do NVR:
rtsp://192.168.0.240/replay/1/1/avm?starttime=20260720t084500l&endtime=20260720t091000l
Observação: o sufixo "l" requer suporte de firmware.
Q3. Por que o fluxo RTSP contém vídeo, mas não áudio?
A3: Se o SDP incluir uma faixa de áudio, o cliente deverá enviar uma solicitação SETUP separada para essa faixa. Se apenas a faixa de vídeo estiver configurada, o cliente receberá o vídeo sem áudio.
Q4:Qual formato de áudio o aplicativo cliente deve usar para a transmissão de áudio do Talk?
A4: O aplicativo cliente deve codificar o áudio do microfone usando as seguintes configurações:
- Codec: G.711 μ-law
- Taxa de amostragem: 16 kHz
- Canais de áudio: Mono
- Tamanho de pacote recomendado: 1056 bytes
- Intervalo de transmissão recomendado: 66 ms
Alternativamente, o aplicativo cliente pode transmitir um bloco de áudio de 640 bytes a cada 40 ms.
Se o microfone usar um formato de áudio nativo diferente, o aplicativo cliente deverá converter o áudio para mono de 16 kHz antes de codificá-lo como G.711 μ-law.
Para saber mais sobre cada função e configuração, visite Página Inicial de Suporte para baixar ou consultar o manual do seu produto.
Procurando por mais
Esta FAQ é útil?
Seu feedback ajuda a melhorar este site.
TP-Link Community
Still need help? Search for answers, ask questions, and get help from TP-Link experts and other users around the world.