Guia LivSmart
Protocolo

SIP

Originado da sinalização multimídia da Internet dos anos 1990, SIP foi padronizado na RFC 3261 em 2002 e substituiu a RFC 2543. Ele localiza usuários e negocia sessões por métodos como REGISTER, INVITE, ACK, BYE e CANCEL; a mídia normalmente segue por RTP. A implantação exige proxy ou registrar, identidade, DNS e proteção TLS/SRTP. Certificação de interoperabilidade e perfis importam, pois dois dispositivos SIP podem divergir em codecs, DTMF, NAT e recursos.

📖Definição aprofundada

SIP é um protocolo de sinalização de camada de aplicação usado para estabelecer, modificar e encerrar sessões multimídia. A sessão pode transportar voz, vídeo, mensagens ou outros fluxos. SIP não carrega normalmente a mídia. Ele negocia por SDP, e RTP/RTCP transporta. Essa separação permite que o mesmo protocolo sinalize uma chamada de áudio G.711, uma videochamada H.264 ou um intercomunicador. A especificação principal é RFC 3261, publicada em junho de 2002, que substituiu RFC 2543. O protocolo adota sintaxe textual inspirada em HTTP e e-mail, com start-line, cabeçalhos e corpo. Métodos incluem REGISTER para registrar contato, INVITE para iniciar ou modificar diálogo, ACK para confirmar resposta final a INVITE, BYE para encerrar, CANCEL para cancelar tentativa pendente, OPTIONS para capacidades. Extensões adicionam PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH e INFO. Uma identidade SIP é uma URI como `sip:porta@casa.exemplo`. User Agent Client envia; User Agent Server responde. Um endpoint costuma exercer ambos. Proxy encaminha e aplica política. Registrar associa Address-of-Record a Contacts. Redirect server informa destino. Location service guarda. Um fluxo básico: o videoporteiro registra no PBX. Ao apertar, envia INVITE para um ramal. O PBX autentica e roteia. O telefone responde 180 Ringing e 200 OK com SDP. O originador envia ACK. RTP passa. Ao terminar, BYE. Respostas 1xx são provisórias; 2xx sucesso; 3xx redirecionamento; 4xx erro do pedido; 5xx servidor; 6xx global. 401 e 407 acionam Digest Authentication. O cliente reenvia com resposta calculada. Senhas precisam ser fortes. Digest não cifra mensagem. TLS protege sinalização. SIPS URI indica transporte seguro ao próximo salto, mas segurança fim a fim depende da cadeia. SRTP protege mídia. SIP sobre UDP 5060 é comum; TCP 5060 e TLS 5061 também. Portas são convenções. Mensagens grandes podem exigir TCP. UDP precisa de retransmissões e timers definidos. TCP/TLS mantém conexão. WebSocket permite SIP em navegadores, com WebRTC para mídia. A RFC 7118 define SIP over WebSocket. SIP possui transações e diálogos. Call-ID, tags From/To e CSeq identificam. Via rastreia caminho e branch. Route/Record-Route mantém proxies. Contact indica destino. Max-Forwards evita loops. O protocolo é distribuído e extensível. Essa flexibilidade gera interoperabilidade difícil. Codecs precisam de interseção. G.711 PCMU/PCMA são comuns. Opus é melhor em redes variáveis, mas telefones antigos podem não suportar. Vídeo H.264 precisa de perfil. DTMF pode usar RFC 4733, SIP INFO ou áudio in-band. O PBX e o interfone precisam concordar. Abertura de porta por DTMF é comum, mas um código audível ou sem autenticação pode ser arriscado. Preferir evento protegido e autorização. NAT é um desafio. SIP carrega endereços dentro de cabeçalhos e SDP, então NAT simples não basta. STUN, TURN, ICE, outbound RFC 5626, rport, symmetric RTP e SBC ajudam. SIP ALG em roteadores tenta reescrever e frequentemente quebra TLS, SDP e múltiplos dispositivos. Desabilitar quando existe SBC ou PBX competente. Um Session Border Controller termina e normaliza, protege e atravessa. Em casa, um PBX local como Asterisk, FreePBX ou 3CX pode registrar interfones e ramais. Para acesso remoto, VPN ou SBC. Expor 5060 recebe scanners e tentativas de fraude. Firewalls, fail2ban, ACL, TLS, autenticação e limites são essenciais. Usuários não devem usar ramal 100/senha 100. O protocolo suporta presença e eventos por SUBSCRIBE/NOTIFY. Interfones podem informar estado. REFER transfere chamada. Recursos dependem. A conformidade com RFC 3261 não garante todos. Perfis de fabricantes, SIP Forum e testes de interoperabilidade ajudam. SIPconnect é perfil de trunking. ONVIF possui recursos de vídeo separados; um videoporteiro pode usar SIP para chamada e ONVIF/RTSP para câmera. Matter não substitui telefonia. A automação pode receber eventos do PBX por AMI/ARI, webhook ou MQTT. O caminho de abertura precisa permanecer seguro e local. Qualidade de voz depende de RTP, jitter, QoS e rede, não do SIP. O SIP pode completar enquanto mídia falha por NAT. Diagnóstico separa sinalização e RTP. Capturas com sngrep e Wireshark mostram. TLS dificulta, mas logs ajudam. O relógio NTP é necessário para certificados e logs. O protocolo amadureceu por décadas e é amplamente suportado. A limitação é a combinação de extensões, NAT, codecs e segurança legada.

Arquitetura e Funcionamento
Transações, diálogos e roteamento
Uma transação SIP combina pedido e respostas. INVITE possui regras especiais. Um diálogo nasce de uma resposta e é identificado por Call-ID e tags. CSeq ordena. Via recebe branches para encaminhamento e respostas. Record-Route mantém proxies no caminho. Contact aponta o endpoint. Registrar mapeia `sip:usuario@dominio` para `sip:usuario@ip:porta`. O registro expira e precisa renovar. Um dispositivo atrás de NAT deve manter conexão ou usar outbound. Expiração de 3600 s é comum, mas PBX pode exigir 300 s. Não registrar a cada 10 s. O proxy autentica. O PBX pode ter múltiplos contatos por usuário. Forking toca telefone e app. A primeira resposta 200 vence; outras recebem CANCEL ou BYE. Sistemas precisam tratar. Em interfone, chamar grupo pode ter atraso. O comando de abertura não deve ser aceito por qualquer ramal. Políticas no PBX e no dispositivo limitam.
SDP, codecs e mídia RTP
INVITE e 200 OK carregam SDP com endereços, portas, codecs e direção. Offer/answer escolhe interseção. `m=audio 40000 RTP/AVP 0 8 101` e `a=rtpmap` definem. Payload 0 é PCMU estático; 8 PCMA; 101 pode ser telephone-event naquela sessão. Opus usa payload dinâmico. Vídeo descreve H.264 e fmtp. O PBX pode transcodificar, consumindo CPU. Se os endpoints compartilham codec, direct media reduz. NAT pode exigir que RTP passe pelo PBX/SBC. A chamada pode sinalizar e ficar sem áudio por SDP com IP privado ou firewall. Isso é “one-way audio”. Diagnóstico verifica pacotes. DTMF via RFC 4733 é preferido a in-band em codecs comprimidos. A abertura de porta por DTMF precisa de controle. SRTP pode ser negociado por SDES ou DTLS. TLS na sinalização não cifra RTP aberto. O status do cadeado no app não basta; verificar mídia.
NAT, SBC e segurança de borda
SIP inclui IPs em Contact, Via e SDP. NAT altera cabeçalho IP externo, mas não o conteúdo. STUN descobre; ICE testa; TURN relaya; SBC reescreve e ancora mídia. SIP ALG tenta ajudar e frequentemente causa cabeçalhos incorretos, especialmente com TLS. Em implantação com PBX/SBC, desativar ALG. O PBX deve conhecer redes locais e endereço externo. Firewall permite sinalização apenas de provedores e VPN quando possível. Expor UDP 5060 a toda Internet gera scans. Use TLS, certificados, senhas aleatórias, rate limit, fail2ban e bloqueio geográfico quando apropriado. Trunks autenticam por IP ou credencial. Não confiar apenas no From. Authorization e P-Asserted-Identity têm contextos. Fraude telefônica pode gerar custo. Limitar destinos e horário. Para casa, VPN é mais simples que publicar PBX. Apps móveis podem usar push e conexão segura do fornecedor. Logs registram tentativas. Senhas não aparecem. Firmware de interfones precisa de atualização.
Interoperabilidade com interfone e automação
Um videoporteiro SIP pode ligar para tablet, telefone IP ou PBX. A câmera pode ser enviada no SIP/RTP ou acessada por RTSP. O relé de porta pode ser acionado por DTMF, SIP INFO, HTTP API ou comando do fabricante. Cada método tem risco. DTMF in-band pode ser gravado ou reproduzido; RFC 4733 é evento, mas ainda precisa autorização do diálogo. SIP INFO pode transportar. Uma API autenticada é mais expressiva. O PBX pode publicar evento no MQTT quando recebe chamada. Home Assistant abre painel e mostra stream. A automação não deve atender e destravar automaticamente por reconhecimento não verificado. O controle de acesso mantém regras. O SIP pode integrar WebRTC: um gateway converte sinalização e mídia para navegador. Asterisk, FreeSWITCH e Kamailio oferecem. O WebRTC exige DTLS-SRTP, ICE e codecs; SIP legado pode usar RTP aberto. O gateway traduz. A interoperabilidade deve ser testada com firmware exato, porque “SIP” não garante vídeo, presença, transferência ou abertura.
Análise Técnica
✓ Vantagens
  • Protocolo aberto e maduro com ampla oferta de PBXs, telefones, intercomunicadores, gateways, SBCs e ferramentas.
  • Separa sinalização da mídia, permitindo negociar codecs e usar RTP/SRTP, áudio, vídeo e múltiplos fluxos.
  • Suporta registro, roteamento, forking, transferência, presença, eventos e integração com sistemas empresariais e residenciais.
  • Pode operar sobre UDP, TCP, TLS e WebSocket, conectando equipamentos legados a aplicativos WebRTC modernos.
  • Permite arquitetura local com Asterisk ou FreeSWITCH, reduzindo dependência de nuvem para interfone e comunicação interna.
✗ Desvantagens
  • A flexibilidade de extensões, codecs, DTMF e perfis causa incompatibilidades mesmo entre produtos rotulados como SIP.
  • NAT é complexo porque endereços aparecem na sinalização e no SDP; SBC, ICE ou configuração cuidadosa são frequentemente necessários.
  • Sinalização e mídia podem ficar sem criptografia em equipamentos legados; TLS não protege RTP automaticamente.
  • Portas SIP expostas são alvo constante de varredura, brute force e fraude, exigindo hardening e monitoramento.
  • Uma chamada pode estabelecer sem áudio ou vídeo por problemas de RTP, firewall ou codec; diagnóstico precisa separar camadas.
💡 Cenário Prático: SIP local para videoporteiro e telefones da residência
Um PBX Asterisk ou FreePBX roda na VLAN de serviços. O videoporteiro e os telefones estão em VLAN de voz/IoT e registram por TLS quando suportado, com senhas aleatórias. A mídia usa SRTP; se o interfone não suporta, permanece restrita à LAN. O roteador não expõe 5060/5061. Acesso móvel usa VPN ou SBC gerenciado. SIP ALG fica desativado. NTP é comum. O interfone chama um ring group com tablet e telefone. O Home Assistant recebe um webhook do PBX e abre o painel com vídeo, mas não controla a sessão SIP diretamente. A abertura usa uma entrada autenticada do controlador de acesso, não um DTMF universal. Se DTMF é necessário, limita-se aos ramais autorizados e ao diálogo ativo. O PBX registra Call-ID, origem, destino e resultado. Fail2ban bloqueia tentativas. Codecs são PCMA/PCMU e Opus quando possível. O vídeo usa H.264 Baseline compatível. O RTP é ancorado no PBX quando atravessa VPN; na LAN pode ser direto. Backup da configuração é testado. Após atualização, são verificados chamada, áudio bidirecional, vídeo, DTMF, transferência e comportamento sem Internet.