# Relatorio Tecnico: Falha de Transmissao ao Vivo RTMP - JC400D **Data:** 25/02/2026 **Prioridade:** Alta --- ## 1. Identificacao do Dispositivo | Campo | Valor | |-------|-------| | **Modelo** | JC400D | | **IMEI** | 862798050567391 | | **Firmware** | KMC28_JC400D_FOBA_CUST_V2.3.1_230106.1654 | | **Data Build** | 2023-01-06 05:53 | | **Protocolo** | JIMI (proNo=128) | --- ## 2. Resumo do Problema O dispositivo JC400D esta totalmente online e responde corretamente a todos os comandos de gerenciamento (`STATUS#`, `VERSION#`, `RSERVICE#`, `UPLOAD#`), porem falha consistentemente ao iniciar o stream RTMP ao vivo quando o comando `CAMERA` e enviado. O dispositivo **nunca** estabelece uma conexao RTMP de saida para o servidor de midia configurado, e o comando sempre resulta em timeout (`_code:600`). Nenhuma conexao RTMP deste dispositivo foi registrada no servidor de midia. --- ## 3. Saude do Dispositivo Confirmada Verificado via comando `STATUS#` (retornou `_code:100`): - **GPRS:** Conectado - **Nivel de Sinal GSM:** Forte - **GPS:** Posicionamento bem-sucedido (Satelites em uso: 8 de 12) - **ACC:** Ligado (ON) - **Tipo de Rede:** 4G Todos os comandos nao relacionados a streaming sao entregues ao dispositivo e respondidos sem problemas. Nao ha problema de conectividade ou entrega de comandos. --- ## 4. Configuracao RSERVICE (Servidor RTMP) Valor atual confirmado: ``` rtmp://camera.mine.nu:1936/live ``` - O hostname `camera.mine.nu` resolve corretamente para o IP do servidor de midia `144.76.103.132` - Porta **1936/TCP** no servidor de midia esta confirmada aberta e aceitando conexoes (verificado via teste de conectividade TCP de host externo) - Porta **8080/TCP** tambem foi testada como alternativa; a mesma falha ocorre - A operadora movel **NAO** bloqueia nenhuma porta (confirmado pelo usuario; o mesmo ambiente SIM/rede funciona com outro dispositivo na mesma plataforma) A configuracao `UPLOAD` tambem esta correta e confirmada funcionando: ``` http://144.76.103.132:23010/upload ``` --- ## 5. Servidor de Midia (Confirmado Funcionando) | Servico | Porta Externa | Porta Interna | Status | |---------|--------------|---------------|--------| | RTMP Ingestao | 1936 | 1935 | Ativo, escutando | | RTMP Ingestao (alt) | 8080 | 1935 | Ativo, escutando | | HTTP-FLV Reproducao | 8881 | 8880 | Ativo | | RTP Ingestao | 10002 | 10000 | Ativo | **Prova de que o servidor de midia funciona:** Um dispositivo JC181 (IMEI `860112070372687`, protocolo JT/T 808/1078, proNo=37121) transmite video ao vivo com sucesso para o **mesmo servidor de midia** via RTP na porta 10002. Os logs do servidor de midia confirmam: ``` 860112070372687(177.69.143.158:21040) 允许RTP推流 ``` Um stream FLV valido de 662KB foi recuperado com sucesso do feed CH1 do JC181. A infraestrutura do servidor de midia esta confirmada saudavel e aceitando streams de entrada. --- ## 6. Cronologia Completa de Testes ### 6.1 Tentativas de Streaming (TODAS FALHARAM) | # | Comando | ServerFlagId | Resultado | Observacao | |---|---------|-------------|-----------|------------| | 1 | `CAMERA,1,0` | 100001 | `_code:600` Timeout | Nenhuma conexao RTMP no servidor de midia | | 2 | `CAMERA,2,0` | 100002 | `_code:302` Device Busy | Possivelmente ainda processando tentativa anterior | | 3 | `CAMERA,1,0` | 200010 | `_code:600` Timeout | Apos corrigir RSERVICE para porta 1936 | | 4 | `CAMERA,1,0` | 200020 | `_code:600` Timeout | Apos definir RSERVICE para `camera.mine.nu:1936/live` | | 5 | `CAMERA,1,0` | 200051 | `_code:600` Timeout | Apos definir RSERVICE para `camera.mine.nu:8080/live` | | 6 | `CAMERA,1,0` | 200040 | `_code:600` Timeout | Tentativa final com `camera.mine.nu:1936/live` | **Em todos os casos:** Zero conexoes RTMP publish do IMEI `862798050567391` apareceram nos logs do servidor de midia. O dispositivo simplesmente nao tenta a conexao RTMP de saida. ### 6.2 Comandos de Gerenciamento (TODOS FUNCIONARAM) | Comando | ServerFlagId | Resultado | |---------|-------------|-----------| | `STATUS#` | 200001 | `_code:100` - Status completo retornado | | `RSERVICE#` | 200002 | `_code:100` - URL RTMP atual retornada | | `RSERVICE,camera.mine.nu:1936/live` | 200015 | `_code:100` - Definido e verificado OK | | `VERSION#` | 200011 | `_code:100` - Info firmware retornada | | `RSERVICE,camera.mine.nu:8080/live` | 200050 | `_code:100` - Definido e verificado OK | | `RSERVICE,camera.mine.nu:1936/live` | 200070 | `_code:100` - Restaurado e verificado OK | | `UPLOAD#` | 200073 | `_code:100` - URL upload retornada | ### 6.3 Comportamento do Formato RSERVICE | Comando Enviado | Valor Armazenado | Observacao | |----------------|-----------------|------------| | `RSERVICE,camera.mine.nu:1936/live` | `rtmp://camera.mine.nu:1936/live` | Correto - firmware auto-adiciona `rtmp://` | | `RSERVICE,rtmp://camera.mine.nu:1936` | `rtmp://rtmp://camera.mine.nu:1936` | Prefixo duplicado - confirma formato antigo | | `RSERVICE,camera.mine.nu:1936/live,0` | `command error` | Firmware nao aceita parametro `,0` | --- ## 7. Analise e Observacoes ### 7.1 O dispositivo recebe o comando CAMERA mas nao age Os logs do gateway confirmam que cada comando `CAMERA,1,0` foi entregue com sucesso ao JC400D pela sessao TCP do protocolo JIMI. O dispositivo nao envia nenhum reconhecimento ou resposta de erro para o comando `CAMERA`; ele simplesmente expira apos o periodo de espera da plataforma (`_code:600`). Em contraste, todos os outros comandos (`STATUS#`, `VERSION#`, `RSERVICE#`, `UPLOAD#`) recebem uma resposta imediata `_code:100`. ### 7.2 Nenhuma conexao RTMP de saida e iniciada Os logs do servidor de midia mostram **zero** tentativas de RTMP publish deste IMEI. Nao se trata de rejeicao ou problema de autenticacao no servidor; a conexao TCP do dispositivo para a porta 1936 (ou 8080) simplesmente nunca e estabelecida. O problema ocorre antes de qualquer handshake RTMP em nivel de rede. ### 7.3 O caminho de rede nao esta bloqueado - A operadora movel confirma que nao bloqueia portas - Porta 1936/TCP e acessivel de hosts externos (confirmado) - O dispositivo comunica com sucesso com a plataforma via TCP (protocolo JIMI) e consegue alcancar o endpoint `UPLOAD` no mesmo servidor via HTTP - Um dispositivo diferente (JC181) no mesmo servidor de midia transmite com sucesso, confirmando que o servidor esta pronto ### 7.4 Firmware possivelmente nao suporta streaming RTMP neste build Considerando que: - O dispositivo armazena e reporta corretamente a URL RSERVICE - O dispositivo recebe o comando CAMERA (confirmado pelo gateway) - O dispositivo **NAO** responde ao comando CAMERA (nenhum ACK, nenhum erro, apenas silencio) - O dispositivo **NAO** inicia nenhuma conexao RTMP de saida Este comportamento sugere que a funcionalidade de live streaming RTMP pode estar **desabilitada, nao compilada ou com defeito neste build especifico do firmware** (`KMC28_JC400D_FOBA_CUST_V2.3.1_230106.1654`). A designacao `FOBA_CUST` no nome do firmware sugere um build customizado, que pode ter tido o modulo de streaming RTMP omitido ou mal configurado. --- ## 8. Perguntas para a Engenharia Jimi 1. **O firmware `KMC28_JC400D_FOBA_CUST_V2.3.1_230106.1654` suporta streaming RTMP ao vivo?** O identificador `FOBA_CUST` sugere um build customizado. O modulo de streaming RTMP foi incluido nesta customizacao? 2. **Qual e o comportamento esperado no lado do dispositivo quando `CAMERA,1,0` e recebido?** O dispositivo deveria enviar uma mensagem de reconhecimento de volta a plataforma antes de iniciar a conexao RTMP? Observamos silencio total do dispositivo (nenhuma resposta). 3. **Existem pre-requisitos ou parametros de configuracao adicionais** (alem do `RSERVICE`) que devem ser definidos antes que o comando CAMERA funcione? Por exemplo, alguma configuracao `PARAM`, configuracao de codificacao de video, ou flag de habilitacao de recurso? 4. **Existe um comando de diagnostico** que possa ser enviado ao dispositivo para consultar o estado do modulo de streaming RTMP (por exemplo, habilitado/desabilitado, ultimo erro, log de tentativa de conexao)? 5. **Existe uma versao de firmware recomendada** para o JC400D que tenha streaming RTMP ao vivo totalmente funcional? Se sim, uma atualizacao OTA pode ser fornecida? 6. **O JC400D requer que a URL RTMP siga um formato especifico?** Testamos: - `camera.mine.nu:1936/live` (armazenado como `rtmp://camera.mine.nu:1936/live`) - `144.76.103.132:1936/live` (armazenado como `rtmp://144.76.103.132:1936/live`) - `camera.mine.nu:8080/live` (armazenado como `rtmp://camera.mine.nu:8080/live`) Nenhum destes resultou em uma tentativa de conexao RTMP. E necessario um formato de caminho ou chave de stream especifico (ex: `/live/{IMEI}`)? 7. **A resposta `_code:302` (Device Busy) do `CAMERA,2,0`** indica um erro interno do dispositivo que pode estar impedindo todas as tentativas de streaming subsequentes? O dispositivo requer um reboot para limpar este estado? --- ## 9. Acoes Solicitadas 1. Confirmar se este build de firmware suporta streaming RTMP ao vivo 2. Se suportado, fornecer a sintaxe correta do comando e quaisquer parametros de configuracao necessarios 3. Se nao suportado, fornecer um build de firmware que inclua capacidade de streaming RTMP para o JC400D 4. Fornecer quaisquer logs de diagnostico do lado do dispositivo ou comandos de debug disponiveis que possam ajudar a isolar se o problema esta no parsing do comando, inicializacao do cliente RTMP ou estabelecimento da conexao de rede --- ## 10. Diagrama do Ambiente ``` ┌──────────────────┐ Protocolo JIMI (TCP) ┌──────────────────────┐ │ JC400D │◄─────────────────────────────► │ Gateway IoTHub │ │ IMEI: ...391 │ Comandos entregues OK ✓ │ (proNo=128) │ │ FW: FOBA_CUST │ Cmd CAMERA entregue ✓ └──────────────────────┘ │ 4G Conectado │ Resposta dispositivo: NADA ✗ │ │ │ │── RTMP p/ camera.mine.nu:1936 ──► ┌──────────────────┐ │ │ CONEXAO NUNCA ESTABELECIDA ✗ │ Servidor Midia │ └──────────────────┘ │ 144.76.103.132 │ │ RTMP: 1936 │ ┌──────────────────┐ JT/T 808 (TCP) │ RTP: 10002 │ │ JC181 │◄──────────────────────────────────► │ Status: OK ✓ │ │ IMEI: ...687 │ Stream RTP CH1: 662KB ✓ └──────────────────┘ │ proNo=37121 │ Stream confirmado ✓ └──────────────────┘ ``` --- **Fim do Relatorio** *Para duvidas ou solicitacoes de dados de diagnostico adicionais, favor contatar a equipe de integracao da plataforma IoTHub. Estamos disponiveis para executar comandos adicionais no dispositivo ou capturar traces de rede se necessario.*