Relatório SIP Descentralizado_ Web3, DePIN

Prévia do material em texto

Relatório Técnico: A Convergência da 
Telefonia SIP com Arquiteturas 
Descentralizadas da Web3 
 
 
Seção 1: Introdução – Duas Eras da Comunicação 
Digital 
 
 
1.1 O Legado e a Centralização do SIP: O Padrão Ouro para VoIP 
 
O Session Initiation Protocol (SIP), padronizado pela Internet Engineering Task Force (IETF) na 
RFC 3261, representa a pedra angular da comunicação de Voz sobre IP (VoIP) moderna.1 
Concebido no final da década de 1990, o SIP foi projetado para ser um protocolo de 
sinalização extensível e modular para iniciar, modificar e terminar sessões de comunicação 
em tempo real, incluindo voz, vídeo e mensagens instantâneas.2 Sua sintaxe baseada em 
texto, que empresta elementos do Hypertext Transfer Protocol (HTTP) e do Simple Mail 
Transfer Protocol (SMTP), facilitou sua adoção e depuração, tornando-o o padrão de fato 
para a telefonia na Internet.2 
A arquitetura do SIP foi fundamentalmente concebida para operar dentro do paradigma 
cliente-servidor, predominante na era em que foi criado.3 Em sua essência, o SIP foi projetado 
para replicar e aprimorar as funcionalidades da Rede Telefônica Pública Comutada (PSTN) em 
redes baseadas em IP, oferecendo uma estrutura familiar de sinalização e configuração de 
chamadas.2 Essa abordagem levou à definição de componentes de rede centralizados, como 
Servidores Proxy, Servidores de Registro (Registrars) e Servidores de Localização, que juntos 
formam a espinha dorsal de uma rede SIP tradicional. Esses servidores atuam como 
autoridades centrais que gerenciam a localização do usuário, aplicam políticas de roteamento 
e autenticam os participantes.5 Embora essa arquitetura centralizada tenha proporcionado a 
estabilidade e a interoperabilidade necessárias para o crescimento explosivo do VoIP, ela 
também incorporou as vulnerabilidades inerentes a qualquer sistema centralizado: pontos 
únicos de falha, gargalos de escalabilidade e a concentração de controle e dados nas mãos 
de um único provedor de serviços.7 
 
1.2 A Ascensão da Web3: Um Imperativo para a Descentralização 
 
Em contraste direto com a arquitetura centralizada da Web 2.0, da qual a telefonia SIP 
tradicional é um produto, a Web3 emerge como a próxima evolução da internet, construída 
sobre os princípios de descentralização, ausência de confiança (trustlessness) e soberania do 
usuário.8 A Web3 não é apenas uma atualização tecnológica; é uma mudança ideológica que 
visa transferir o controle das corporações centralizadas de volta para os indivíduos.11 
Utilizando tecnologias como blockchain, redes peer-to-peer (P2P) e criptografia avançada, a 
Web3 permite a criação de aplicações descentralizadas (dApps) que operam sem a 
necessidade de intermediários.13 
Os pilares da Web3 — descentralização, segurança, interoperabilidade e transparência — 
oferecem uma nova lente através da qual podemos reexaminar os protocolos de comunicação 
legados.8 Em um ecossistema Web3, os usuários controlam seus próprios dados e identidade 
digital por meio de chaves criptográficas, em vez de dependerem de contas gerenciadas por 
provedores de serviços.10 A infraestrutura é distribuída entre os participantes da rede, 
eliminando pontos únicos de falha e tornando os sistemas inerentemente mais resilientes e 
resistentes à censura.8 Essa mudança fundamental de paradigma cria um imperativo para 
reimaginar como as comunicações em tempo real podem ser projetadas para se alinharem 
com esses novos valores, movendo-se de modelos de confiança baseados em autoridade 
para modelos de confiança baseados em protocolo. 
 
1.3 Tese: Rumo a um Modelo de Comunicação Soberano e Resiliente 
via P2P-SIP 
 
Este relatório apresenta a tese de que a convergência do Session Initiation Protocol com as 
arquiteturas descentralizadas da Web3 é uma evolução necessária para o futuro das 
comunicações digitais. A aplicação de tecnologias peer-to-peer para implementar a 
funcionalidade SIP, um conceito conhecido como P2P-SIP, oferece um caminho para superar 
as limitações intrínsecas do modelo centralizado tradicional.16 O objetivo não é simplesmente 
substituir componentes de servidor por alternativas distribuídas, mas reconciliar duas 
filosofias de design de rede fundamentalmente opostas. O SIP foi concebido para espelhar a 
confiança hierárquica da PSTN, enquanto a Web3 foi projetada para subverter essa mesma 
hierarquia. 
A fusão dessas duas eras da comunicação digital visa criar um novo modelo de telefonia: um 
que seja soberano, onde os usuários tenham controle criptográfico sobre sua identidade e 
comunicações; resiliente, operando sem pontos únicos de falha; e aberto, permitindo a 
inovação sem a permissão de guardiões centralizados. Ao analisar a desconstrução da 
arquitetura SIP tradicional e a aplicação de tecnologias como Tabelas de Hash Distribuídas 
(DHTs), stacks de rede P2P modulares como o libp2p e conceitos de identidade soberana 
como Identificadores Descentralizados (DIDs), este relatório delineará uma arquitetura viável 
para um sistema de comunicação que não apenas preserva a rica funcionalidade do SIP, mas 
a eleva para atender às demandas de uma internet mais aberta, justa e descentralizada. 
 
Seção 2: Análise da Arquitetura SIP Tradicional (RFC 
3261) 
 
 
2.1 Componentes Centrais: O Papel do Proxy, Registrar e Servidor de 
Localização 
 
A arquitetura SIP, conforme especificada na RFC 3261, é definida por um conjunto de 
entidades lógicas que colaboram para facilitar as sessões de comunicação. Embora um User 
Agent (UA) possa, em teoria, se comunicar diretamente com outro, a funcionalidade prática 
em redes de grande escala depende de três componentes de servidor centrais.6 É importante 
notar que essa distinção é lógica; uma única implementação de software pode incorporar 
todas essas funções.6 
● Servidor Proxy (Proxy Server): O proxy SIP é a entidade intermediária fundamental, 
atuando tanto como servidor quanto como cliente para fazer solicitações em nome de 
outros clientes.6 Sua principal função é o roteamento de mensagens SIP. Ele recebe 
solicitações (como um 
INVITE para iniciar uma chamada) e as encaminha para a próxima entidade na rede, que 
pode ser outro proxy ou o User Agent de destino.5 Além do roteamento, os proxies 
podem aplicar políticas de negócios, como autenticação, autorização, balanceamento de 
carga e gerenciamento de sessões, tornando-os um componente crítico para a operação 
e o controle de um provedor de serviços VoIP.5 
● Servidor de Registro (Registrar Server): O Registrar é o servidor responsável por 
gerenciar o registro de localização dos usuários. Ele processa as solicitações REGISTER 
enviadas pelos User Agents.6 Quando um usuário se conecta à rede (por exemplo, ao 
ligar um telefone SIP ou iniciar um softphone), seu UA envia uma mensagem 
REGISTER para o Registrar do seu domínio. Esta mensagem contém o Endereço de 
Registro (Address of Record - AOR), que é o identificador público do usuário (ex: 
sip:alice@example.com), e o endereço de contato atual (ex: sip:alice@192.0.2.4:5060), 
que é o endereço IP e a porta onde o UA pode ser alcançado.19 O Registrar autentica o 
usuário e armazena essa associação (AOR para contato) no Servidor de Localização. 
● Servidor de Localização (Location Server): O Servidor de Localização é, 
essencialmente, um banco de dados que armazena os mapeamentos de AOR para 
endereços de contato mantidos pelo Registrar.5 Ele não é um servidor SIP no sentido de 
que não processa diretamente as solicitações SIP (exceto as do Registrar). Em vez disso, 
ele fornece um serviço de consulta para outras entidades, principalmente o Servidor 
Proxy. Quando um proxy recebe uma solicitação para um AOR (por exemplo, um 
INVITE para sip:bob@example.com), ele consulta o Servidor de Localização para obter 
o(s) endereço(s) de contato atual(is) de Bob, permitindo que o proxy encaminhe a 
solicitação para o local correto na rede.19 
 
2.2 Fluxos de Sinalização: Registro, Descoberta de Pares e 
Estabelecimento de Sessão 
 
O funcionamentohttps://medium.com/@hackerhub/building-a-decentralized-network-using-go-libp2p-ccb54bc86f43
https://medium.com/@hackerhub/building-a-decentralized-network-using-go-libp2p-ccb54bc86f43
https://www.bnbchain.org/en/blog/the-rise-of-depin-and-its-impact-on-web3
https://medium.com/@chaincom/understanding-the-power-of-depins-and-their-real-world-applications-61c61e9c5eae
https://medium.com/@chaincom/understanding-the-power-of-depins-and-their-real-world-applications-61c61e9c5eae
https://news.lever.io/depin-crypto-web3/
https://www.ietf.org/proceedings/94/p2psip.html
https://www.rfc-editor.org/rfc/rfc6940.html
https://www.potaroo.net/ietf/all-ids/draft-ietf-p2psip-sip-12.html
https://datatracker.ietf.org/doc/rfc7904/
em setembro 26, 2025, https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/19/ 
56. Using an External DHT as a SIP Location Service - Semantic Scholar, acessado em 
setembro 26, 2025, 
https://www.semanticscholar.org/paper/Using-an-External-DHT-as-a-SIP-Locatio
n-Service-Singh-Schulzrinne/ce1741b39a6622f6dffa0cedf6c704dfd8a4bae6 
57. STUN, TURN, and ICE NAT Traversal Protocols - AnyConnect, acessado em 
setembro 26, 2025, https://anyconnect.com/stun-turn-ice/ 
58. VoIP NAT Traversal – Getting Through the Maze - DEV Community, acessado em 
setembro 26, 2025, 
https://dev.to/sip_games/voip-nat-traversal-getting-through-the-maze-2d0m 
59. What are NATs - libp2p, acessado em setembro 26, 2025, 
https://docs.libp2p.io/concepts/nat/overview/ 
60. Peer-to-Peer Communication Across Network Address Translators - PDOS-MIT, 
acessado em setembro 26, 2025, https://pdos.csail.mit.edu/papers/p2pnat.pdf 
61. VoIP and NAT/Firewalls: Issues, Traversal Techniques, and a Real-World Solution - 
UiO, acessado em setembro 26, 2025, 
https://www.uio.no/studier/emner/matnat/ifi/IN5070/h24/timeplan/01668388.pdf 
62. STUN VoIP: The 2025 Guide to NAT Traversal, Call Quality & Configuration - 
VideoSDK, acessado em setembro 26, 2025, 
https://www.videosdk.live/developer-hub/voip/stun-voip 
63. What Are STUN, TURN, and ICE? | LiveSwitch Server Documentation, acessado em 
setembro 26, 2025, 
https://developer.liveswitch.io/liveswitch-server/guides/what-are-stun-turn-and-i
ce.html 
64. STUN - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/STUN 
65. NAT, STUN, TURN, and ICE | Thirdlane.com, acessado em setembro 26, 2025, 
https://www.thirdlane.com/blog/nat-stun-turn-and-ice 
66. Demystifying NAT Traversal with STUN TURN and ICE - Cisco Community, 
acessado em setembro 26, 2025, 
https://community.cisco.com/t5/collaboration-knowledge-base/demystifying-nat
-traversal-with-stun-turn-and-ice/ta-p/4766853 
67. NAT, STUN, TURN and ICE. In networking while building a p2p… - Dikshant Rajput, 
acessado em setembro 26, 2025, 
https://dikshantraj2001.medium.com/nat-stun-turn-and-ice-466dabbc2fdb 
68. Hole Punching - libp2p, acessado em setembro 26, 2025, 
https://docs.libp2p.io/concepts/nat/hole-punching/ 
69. How NAT traversal and hole-punching work in IPFS - Users and Developers - 
libp2p, acessado em setembro 26, 2025, 
https://discuss.libp2p.io/t/how-nat-traversal-and-hole-punching-work-in-ipfs/142
2 
70. Show HN: connet – A P2P reverse proxy with NAT traversal - Hacker News, 
acessado em setembro 26, 2025, 
https://news.ycombinator.com/item?id=42575841 
71. Self-sovereign identity - Wikipedia, acessado em setembro 26, 2025, 
https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/19/
https://www.semanticscholar.org/paper/Using-an-External-DHT-as-a-SIP-Location-Service-Singh-Schulzrinne/ce1741b39a6622f6dffa0cedf6c704dfd8a4bae6
https://www.semanticscholar.org/paper/Using-an-External-DHT-as-a-SIP-Location-Service-Singh-Schulzrinne/ce1741b39a6622f6dffa0cedf6c704dfd8a4bae6
https://anyconnect.com/stun-turn-ice/
https://dev.to/sip_games/voip-nat-traversal-getting-through-the-maze-2d0m
https://docs.libp2p.io/concepts/nat/overview/
https://pdos.csail.mit.edu/papers/p2pnat.pdf
https://www.uio.no/studier/emner/matnat/ifi/IN5070/h24/timeplan/01668388.pdf
https://www.videosdk.live/developer-hub/voip/stun-voip
https://developer.liveswitch.io/liveswitch-server/guides/what-are-stun-turn-and-ice.html
https://developer.liveswitch.io/liveswitch-server/guides/what-are-stun-turn-and-ice.html
https://en.wikipedia.org/wiki/STUN
https://www.thirdlane.com/blog/nat-stun-turn-and-ice
https://community.cisco.com/t5/collaboration-knowledge-base/demystifying-nat-traversal-with-stun-turn-and-ice/ta-p/4766853
https://community.cisco.com/t5/collaboration-knowledge-base/demystifying-nat-traversal-with-stun-turn-and-ice/ta-p/4766853
https://dikshantraj2001.medium.com/nat-stun-turn-and-ice-466dabbc2fdb
https://docs.libp2p.io/concepts/nat/hole-punching/
https://discuss.libp2p.io/t/how-nat-traversal-and-hole-punching-work-in-ipfs/1422
https://discuss.libp2p.io/t/how-nat-traversal-and-hole-punching-work-in-ipfs/1422
https://news.ycombinator.com/item?id=42575841
https://en.wikipedia.org/wiki/Self-sovereign_identity 
72. Your Guide to Self-Sovereign Identity (SSI), acessado em setembro 26, 2025, 
https://www.identity.com/self-sovereign-identity/ 
73. Decentralized identifier - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Decentralized_identifier 
74. Decentralized Identifiers (DIDs) v1.0 - W3C, acessado em setembro 26, 2025, 
https://www.w3.org/TR/did-1.0/ 
75. Decentralized Identifiers (DIDs) v1.1 - W3C, acessado em setembro 26, 2025, 
https://www.w3.org/TR/did-1.1/ 
76. Decentralized Identity (DID): The Complete Guide to Self-Sovereign Identity in 
Web3 | by Ancilar Technologies | Jul, 2025 | Medium, acessado em setembro 26, 
2025, 
https://medium.com/@ancilartech/decentralized-identity-did-the-complete-guid
e-to-self-sovereign-identity-in-web3-871bfcdc3335 
77. What Are Decentralized Identifiers (DIDs)? - Identity.com, acessado em setembro 
26, 2025, https://www.identity.com/what-are-decentralized-identifiers-dids/ 
78. Verifiable Credentials and Decentralised Identifiers: Technical Landscape - GS1 
Reference, acessado em setembro 26, 2025, 
https://ref.gs1.org/docs/2025/VCs-and-DIDs-tech-landscape 
79. Verifiable credentials - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Verifiable_credentials 
80. Verifiable Credentials: The Key to Decentralized Identity Models Explained - 
Truvity, acessado em setembro 26, 2025, 
https://www.truvity.com/ssi-essentials/verifiable-credentials-in-decentralized-ide
ntity-models 
81. What Are Verifiable Credentials? Complete Overview - Identity.com, acessado 
em setembro 26, 2025, https://www.identity.com/what-are-verifiable-credentials/ 
82. Verifiable Credentials: A Simple Guide to How They Work - walt.id Docs, 
acessado em setembro 26, 2025, 
https://docs.walt.id/community-stack/concepts/digital-credentials/verifiable-cred
entials-w3c 
83. Verifiable Credentials: The Ultimate Guide 2025 - Dock Labs, acessado em 
setembro 26, 2025, https://www.dock.io/post/verifiable-credentials 
84. Introduction to Verifiable Credentials - Self Sovereign Identity, acessado em 
setembro 26, 2025, 
https://www.selfsovereignidentity.it/what-are-verifiable-credentials/ 
85. Introduction to Microsoft Entra Verified ID, acessado em setembro 26, 2025, 
https://learn.microsoft.com/en-us/entra/verified-id/decentralized-identifier-overvi
ew 
86. Self-sovereign identities | Bosch Global, acessado em setembro 26, 2025, 
https://www.bosch.com/stories/self-sovereign-identities/ 
87. Self-Sovereign Identity: The Ultimate Guide 2025 - Dock Labs, acessado em 
setembro 26, 2025, https://www.dock.io/post/self-sovereign-identity 
88. Decentralized Identifiers (DIDs): The Ultimate Beginner's Guide 2025 - Dock Labs, 
acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Self-sovereign_identity
https://www.identity.com/self-sovereign-identity/
https://en.wikipedia.org/wiki/Decentralized_identifier
https://www.w3.org/TR/did-1.0/
https://www.w3.org/TR/did-1.1/
https://medium.com/@ancilartech/decentralized-identity-did-the-complete-guide-to-self-sovereign-identity-in-web3-871bfcdc3335https://medium.com/@ancilartech/decentralized-identity-did-the-complete-guide-to-self-sovereign-identity-in-web3-871bfcdc3335
https://www.identity.com/what-are-decentralized-identifiers-dids/
https://ref.gs1.org/docs/2025/VCs-and-DIDs-tech-landscape
https://en.wikipedia.org/wiki/Verifiable_credentials
https://www.truvity.com/ssi-essentials/verifiable-credentials-in-decentralized-identity-models
https://www.truvity.com/ssi-essentials/verifiable-credentials-in-decentralized-identity-models
https://www.identity.com/what-are-verifiable-credentials/
https://docs.walt.id/community-stack/concepts/digital-credentials/verifiable-credentials-w3c
https://docs.walt.id/community-stack/concepts/digital-credentials/verifiable-credentials-w3c
https://www.dock.io/post/verifiable-credentials
https://www.selfsovereignidentity.it/what-are-verifiable-credentials/
https://learn.microsoft.com/en-us/entra/verified-id/decentralized-identifier-overview
https://learn.microsoft.com/en-us/entra/verified-id/decentralized-identifier-overview
https://www.bosch.com/stories/self-sovereign-identities/
https://www.dock.io/post/self-sovereign-identity
https://www.dock.io/post/decentralized-identifiers 
89. Self-Sovereign Identity (SSI): Autonomous Identity Management | Okta, acessado 
em setembro 26, 2025, 
https://www.okta.com/identity-101/self-sovereign-identity/ 
90. Jami, acessado em setembro 26, 2025, https://jami.net/ 
91. Jami (software) - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Jami_(software) 
92. The Jami messenger - Linux Kamarada, acessado em setembro 26, 2025, 
https://linuxkamarada.com/en/2021/05/25/the-jami-messenger/ 
93. en.wikipedia.org, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Jami_(software)#:~:text=Operates%20on%20a%20p
eer%2Dto,SIP%2Dcompatible%20with%20OpenDHT%20support. 
94. Introduction - Jami documentation, acessado em setembro 26, 2025, 
https://docs.jami.net/en_US/user/introduction.html 
95. Jami Concepts — Jami documentation, acessado em setembro 26, 2025, 
https://docs.jami.net/en_US/developer/jami-concepts/index.html 
96. Jami - VoIP.ms Wiki, acessado em setembro 26, 2025, 
https://wiki.voip.ms/article/Jami 
97. Jami: Share, Message, Call freely and privately | Hacker News, acessado em 
setembro 26, 2025, https://news.ycombinator.com/item?id=34082718 
98. The Kamailio SIP Server Project – The Open Source SIP Server, acessado em 
setembro 26, 2025, https://www.kamailio.org/w/ 
99. openSIPS | Main / HomePage, acessado em setembro 26, 2025, 
https://opensips.org/ 
100. A P2P Approach to SIP Registration and Resource Location - Softarmor 
Systems LLC, acessado em setembro 26, 2025, 
https://www.softarmor.com/wgdb/docs/draft-bryan-sipping-p2p-01.html 
101. Revolutionizing Communication with Unparalleled Decentralized SIP VoIP — 
Marina.Rodeo. | by Dmitry Sorokin | CodeX | Medium, acessado em setembro 26, 
2025, 
https://medium.com/codex/revolutionizing-communication-with-unparalleled-de
centralized-sip-voip-marina-rodeo-6457283700a8 
102. voip-security · GitHub Topics, acessado em setembro 26, 2025, 
https://github.com/topics/voip-security 
103. voip-communications · GitHub Topics, acessado em setembro 26, 2025, 
https://github.com/topics/voip-communications 
104. P2PSIP, ICE, WebRTC, and SIP extensions, acessado em setembro 26, 2025, 
https://www.cse.tkk.fi/fi/opinnot/T-110.5150/2013/luennot-files/Lecture%206-Web
RTC.pdf 
105. Web3 Use Cases and Applications - Medium, acessado em setembro 26, 
2025, 
https://medium.com/@iamamellstephen/web3-use-cases-and-applications-3075
40916ede 
106. Top Web3 Use Cases: How It's Transforming Industries - Debut Infotech, 
acessado em setembro 26, 2025, 
https://www.dock.io/post/decentralized-identifiers
https://www.okta.com/identity-101/self-sovereign-identity/
https://jami.net/
https://en.wikipedia.org/wiki/Jami_(software)
https://linuxkamarada.com/en/2021/05/25/the-jami-messenger/
https://en.wikipedia.org/wiki/Jami_(software)#:~:text=Operates%20on%20a%20peer%2Dto,SIP%2Dcompatible%20with%20OpenDHT%20support.
https://en.wikipedia.org/wiki/Jami_(software)#:~:text=Operates%20on%20a%20peer%2Dto,SIP%2Dcompatible%20with%20OpenDHT%20support.
https://docs.jami.net/en_US/user/introduction.html
https://docs.jami.net/en_US/developer/jami-concepts/index.html
https://wiki.voip.ms/article/Jami
https://news.ycombinator.com/item?id=34082718
https://www.kamailio.org/w/
https://opensips.org/
https://www.softarmor.com/wgdb/docs/draft-bryan-sipping-p2p-01.html
https://medium.com/codex/revolutionizing-communication-with-unparalleled-decentralized-sip-voip-marina-rodeo-6457283700a8
https://medium.com/codex/revolutionizing-communication-with-unparalleled-decentralized-sip-voip-marina-rodeo-6457283700a8
https://github.com/topics/voip-security
https://github.com/topics/voip-communications
https://www.cse.tkk.fi/fi/opinnot/T-110.5150/2013/luennot-files/Lecture%206-WebRTC.pdf
https://www.cse.tkk.fi/fi/opinnot/T-110.5150/2013/luennot-files/Lecture%206-WebRTC.pdf
https://medium.com/@iamamellstephen/web3-use-cases-and-applications-307540916ede
https://medium.com/@iamamellstephen/web3-use-cases-and-applications-307540916ede
https://www.debutinfotech.com/blog/top-web3-use-cases 
107. 14 Web3 Use Cases Your Business Can't Ignore in 2025 - Changelly, acessado 
em setembro 26, 2025, https://changelly.com/blog/web3-use-cases/ 
https://www.debutinfotech.com/blog/top-web3-use-cases
https://changelly.com/blog/web3-use-cases/
	Relatório Técnico: A Convergência da Telefonia SIP com Arquiteturas Descentralizadas da Web3 
	Seção 1: Introdução – Duas Eras da Comunicação Digital 
	1.1 O Legado e a Centralização do SIP: O Padrão Ouro para VoIP 
	1.2 A Ascensão da Web3: Um Imperativo para a Descentralização 
	1.3 Tese: Rumo a um Modelo de Comunicação Soberano e Resiliente via P2P-SIP 
	Seção 2: Análise da Arquitetura SIP Tradicional (RFC 3261) 
	2.1 Componentes Centrais: O Papel do Proxy, Registrar e Servidor de Localização 
	2.2 Fluxos de Sinalização: Registro, Descoberta de Pares e Estabelecimento de Sessão 
	2.3 Mecanismos de Autenticação: Limitações da Autenticação Digest em um Mundo Descentralizado 
	2.4 Identificando os Pontos Únicos de Falha e Controle 
	Seção 3: Fundamentos da Descentralização para Comunicações em Tempo Real 
	3.1 O Protocolo de Rede P2P: Substituindo a Infraestrutura de Servidores 
	3.2 Tabelas de Hash Distribuídas (DHTs): O Novo Registro Descentralizado 
	3.2.1 Análise Comparativa: Chord vs. Kademlia 
	3.3 Stacks de Rede Modulares: O Caso do libp2p como Camada de Base 
	3.4 Modelos de Incentivo: Aplicando os Princípios DePIN para a Participação de Nós 
	Seção 4: Arquitetura de Referência para SIP sobre uma Overlay P2P (P2P-SIP) 
	4.1 O Padrão RELOAD da IETF: Uma Base para a Interoperabilidade 
	4.2 Mapeamento de Funções: Como a DHT Substitui o Servidor de Registro e Localização 
	4.3 Roteamento de Sinalização em uma Rede P2P: Do INVITE ao 200 OK sem um Proxy Central 
	4.4 Considerações sobre Latência e Desempenho em Lookups de DHT 
	Seção 5: O Desafio Crítico da Travessia de NAT em Redes P2P 
	5.1 Por que o NAT Inviabiliza a Comunicação P2P Direta 
	5.2 A Abordagem Clássica: STUN, TURN e ICE 
	5.3 Uma Solução Descentralizada: "Hole Punching" e Retransmissão de Circuito no libp2p 
	5.4 Recomendações para Máxima Conectividade em Ambientes de Rede Hostis 
	Seção 6: Identidade Soberana: Autenticação SIP na Era Web3 
	6.1 Identificadores Descentralizados (DIDs): Desacoplando a Identidade dos Servidores 
	6.2 Credenciais Verificáveis (VCs): Provas Criptográficas para Autorização de Chamadas 
	6.3 Fluxo de Autenticação Baseado em DID/VC: Um Novo Paradigma de Segurança 
	6.4 Implicações para a Privacidade e Controle do Usuário 
	Seção 7: Implementações, Projetos e Estudos de Caso 
	7.1 Jami: Um Exemplo Prático de Comunicação Distribuída baseada em DHT e SIP 
	7.2 Servidores SIP Open Source (Kamailio, OpenSIPS): Potencial de Adaptação para Arquiteturas Híbridas 
	7.3 Projetos Conceituais: A Visão do Marina.Rodeopara SIP sobre Blockchain 
	7.4 Análise de Viabilidade e Barreiras à Adoção em Massa 
	Seção 8: Conclusão – Desafios, Oportunidades e o Futuro da Telefonia Descentralizada 
	8.1 Síntese dos Desafios Técnicos Remanescentes 
	8.2 Oportunidades Emergentes: Comunicações Resistentes à Censura, Redução de Custos e Novos Modelos de Negócio 
	8.3 Recomendações para Desenvolvedores e Arquitetos de Rede 
	8.4 Perspectivas Futuras: A Integração Total de Comunicações em Tempo Real no Ecossistema Web3 
	Referências citadasde uma rede SIP centralizada pode ser melhor compreendido através de 
seus fluxos de sinalização primários. 
1. Registro: Antes que um usuário possa receber chamadas, seu UA deve se registrar. O UA 
envia uma mensagem REGISTER para o servidor Registrar do seu domínio. O Registrar 
autentica a solicitação e, se bem-sucedido, armazena a associação entre o AOR do 
usuário e seu endereço de contato no Servidor de Localização.19 Esse registro tem um 
tempo de vida limitado e deve ser atualizado periodicamente para que o sistema saiba 
que o usuário ainda está online. 
2. Estabelecimento de Chamada (INVITE): Quando Alice (sip:alice@domainA.com) 
deseja ligar para Bob (sip:bob@domainB.com), o processo geralmente segue o modelo 
conhecido como "trapézio SIP": 
○ O UA de Alice envia uma mensagem INVITE para o proxy de seu domínio (proxy A). 
○ O Proxy A determina que a chamada é para um domínio externo e encaminha o 
INVITE para o proxy do domínio de Bob (proxy B). 
○ O Proxy B recebe o INVITE e consulta seu Servidor de Localização para encontrar o 
endereço de contato atual de Bob. 
○ O Proxy B encaminha o INVITE para o endereço IP e porta do UA de Bob. 
○ O UA de Bob responde com uma resposta provisória (ex: 180 Ringing) e, finalmente, 
uma resposta final (200 OK), que percorrem o caminho inverso através dos proxies. 
○ Alice envia um ACK para confirmar o recebimento do 200 OK, estabelecendo a 
sessão de sinalização. A partir deste ponto, a mídia (fluxos RTP) pode fluir 
diretamente entre os UAs, embora em algumas configurações ela também possa ser 
roteada através de servidores de mídia.19 
Este fluxo demonstra a dependência crítica dos proxies e servidores de localização para o 
funcionamento da rede. Sem eles, Alice não teria como descobrir onde Bob está na rede. 
 
2.3 Mecanismos de Autenticação: Limitações da Autenticação Digest 
em um Mundo Descentralizado 
 
A segurança no SIP tradicional depende fortemente de mecanismos que pressupõem uma 
autoridade central confiável. O método de autenticação mais comum é a Autenticação Digest 
(Digest Authentication), especificada originalmente na RFC 2617 para HTTP e adaptada para o 
SIP.22 O processo funciona da seguinte forma: 
1. Um UA envia uma solicitação (por exemplo, REGISTER ou INVITE) para um servidor (Proxy 
ou Registrar). 
2. O servidor, em vez de aceitar a solicitação, a desafia enviando uma resposta 401 
Unauthorized ou 407 Proxy Authentication Required. Esta resposta contém um "nonce", 
um número aleatório usado apenas uma vez.22 
3. O UA recebe o desafio e calcula uma resposta. Ele cria um hash MD5 combinando o 
nome de usuário, a senha, o nonce fornecido pelo servidor e outros detalhes da 
solicitação.23 
4. O UA reenvia a solicitação original, desta vez incluindo a resposta calculada em um 
cabeçalho de autorização. 
5. O servidor realiza o mesmo cálculo de hash usando a senha do usuário (que ele tem 
armazenada) e compara o resultado com a resposta do UA. Se corresponderem, a 
solicitação é autenticada. 
A principal vantagem da Autenticação Digest é que a senha nunca é transmitida em texto 
claro pela rede.24 No entanto, seu design é fundamentalmente centralizado. Todo o modelo de 
confiança repousa na capacidade do servidor de armazenar com segurança as credenciais 
(ou seus hashes) e atuar como o árbitro final da identidade. Em um sistema P2P, onde não 
existe um servidor central para armazenar senhas ou emitir desafios, este mecanismo se 
torna completamente inviável. Ele representa um anacronismo em um paradigma que busca 
eliminar a necessidade de confiar em uma única entidade. 
 
2.4 Identificando os Pontos Únicos de Falha e Controle 
 
A análise da arquitetura SIP tradicional revela claramente suas dependências centralizadas. O 
conjunto de servidores Proxy, Registrar e de Localização constitui o cérebro da rede. Se esses 
servidores falharem, todo o serviço de comunicação para aquele domínio é interrompido, 
criando um ponto único de falha (Single Point of Failure - SPOF).7 Embora a redundância e o 
failover possam mitigar esse risco, eles aumentam a complexidade e o custo da 
infraestrutura. 
Além da resiliência, essa centralização levanta questões de controle e soberania. A identidade 
de um usuário, representada por seu AOR (sip:user@provider.com), está intrinsecamente 
ligada e controlada pelo provedor de serviços que opera o domínio. Se um usuário desejar 
mudar de provedor, ele perde sua identidade SIP e deve estabelecer uma nova, um processo 
análogo a perder seu endereço de e-mail ao trocar de provedor. Isso cria "silos de 
identidade", onde a portabilidade é inexistente e o controle final reside com o provedor, não 
com o usuário. Essa dependência de um intermediário para identidade, registro e roteamento 
é o problema fundamental que as arquiteturas descentralizadas buscam resolver, movendo o 
controle da infraestrutura para o protocolo e a identidade para o próprio usuário. 
 
Seção 3: Fundamentos da Descentralização para 
Comunicações em Tempo Real 
 
A transição de uma arquitetura SIP centralizada para um modelo descentralizado requer a 
substituição dos componentes de servidor tradicionais por primitivas de rede distribuídas. 
Esta seção explora os blocos de construção fundamentais que tornam essa transição 
possível, desde a camada de rede P2P até os modelos econômicos que a sustentam. 
 
3.1 O Protocolo de Rede P2P: Substituindo a Infraestrutura de 
Servidores 
 
A base de qualquer sistema de comunicação descentralizado é a rede peer-to-peer (P2P). 
Diferente do modelo cliente-servidor, onde clientes se comunicam através de um servidor 
central, em uma rede P2P, cada participante, ou "nó", atua simultaneamente como cliente e 
servidor.26 Os nós se comunicam diretamente uns com os outros, compartilhando recursos e 
informações sem a necessidade de um intermediário.27 
As vantagens inerentes a essa arquitetura são cruciais para a telefonia descentralizada. A 
eliminação de um servidor central remove o ponto único de falha; a rede pode continuar a 
operar mesmo que alguns nós fiquem offline, conferindo alta resiliência e tolerância a 
falhas.29 A escalabilidade é orgânica: à medida que mais nós se juntam à rede, a capacidade 
total do sistema (para roteamento, armazenamento, etc.) aumenta.27 Mais importante, uma 
arquitetura P2P distribui o controle entre todos os participantes, tornando o sistema 
resistente à censura e ao controle por uma única entidade.8 
 
3.2 Tabelas de Hash Distribuídas (DHTs): O Novo Registro 
Descentralizado 
 
Se a rede P2P substitui a infraestrutura física dos servidores, a Tabela de Hash Distribuída 
(DHT) substitui sua função lógica de registro e localização. Uma DHT é um sistema de 
armazenamento de chave-valor distribuído em grande escala, onde a responsabilidade por 
armazenar os dados é repartida entre os nós participantes da rede.31 No contexto do P2P-SIP, 
a DHT é a substituição direta e elegante para a combinação centralizada dos servidores 
Registrar e de Localização.33 
A operação é conceitualmente simples: para registrar sua localização, um usuário calcula um 
hash de seu identificador (como seu AOR SIP) para gerar uma "chave". Em seguida, ele 
armazena seu endereço de contato (o "valor") no(s) nó(s) da rede P2P que são responsáveis 
por essa chave específica. Para encontrar esse usuário, outro participante calcula o mesmo 
hash e consulta a DHT para recuperar o endereço de contato associado.33 
 
3.2.1 Análise Comparativa: Chord vs. Kademlia 
 
Existem vários algoritmos de DHT, cada um com diferentes topologias e mecanismos de 
roteamento. Dois dos mais influentes são Chord e Kademlia. 
● Chord: Este protocolo organiza os nós em um anel lógico com base em seus 
identificadores de nó de 160 bits (geralmente um hash de seu endereço IP).36 Cada nó é 
responsável por armazenar os pares chave-valor para os quais a chave tem um hash que 
cai entre seu próprio identificador e o de seu predecessor no anel. As buscas são 
roteadas ao redor doanel, com cada nó encaminhando a consulta para o nó em sua 
tabela de roteamento ("finger table") que está mais próximo do destino, resultando em 
uma latência de busca de 
O(logN), onde N é o número de nós na rede.37 
● Kademlia: Este protocolo, usado em sistemas massivos como a rede DHT do BitTorrent e 
o IPFS, também atribui um identificador de 160 bits a cada nó, mas define a "distância" 
entre os nós usando a operação XOR (ou exclusivo).39 Cada nó mantém tabelas de 
roteamento (chamadas k-buckets) que contêm informações sobre outros nós em 
diferentes faixas de distância XOR. As buscas são realizadas consultando iterativamente 
os nós que estão cada vez mais "próximos" (em termos de distância XOR) da chave 
alvo.41 Kademlia é conhecido por sua eficiência e resiliência em ambientes com alta 
rotatividade de nós (churn), tornando-o uma escolha robusta para redes P2P do mundo 
real.41 
 
3.3 Stacks de Rede Modulares: O Caso do libp2p como Camada de 
Base 
 
Construir uma aplicação P2P do zero é uma tarefa complexa, envolvendo a resolução de 
problemas como descoberta de pares, múltiplos transportes de rede, segurança e travessia 
de NAT. O libp2p é um framework de rede P2P que aborda esses desafios de forma modular.43 
Originalmente desenvolvido para o IPFS, o libp2p evoluiu para uma stack de rede agnóstica a 
aplicações, usada por projetos como Ethereum 2.0 e Filecoin.45 
O libp2p não é uma rede monolítica, mas sim uma coleção de protocolos e bibliotecas que 
permitem aos desenvolvedores montar uma stack de rede P2P personalizada. Suas principais 
características incluem 43: 
● Agnóstico a Transporte: Suporta múltiplos protocolos de transporte como TCP, QUIC e 
WebRTC, escolhendo o melhor disponível. 
● Multiplexação de Streams: Permite que múltiplos fluxos de comunicação 
independentes ocorram sobre uma única conexão. 
● Descoberta de Pares: Oferece vários mecanismos para encontrar outros nós na rede, 
incluindo o uso de uma DHT Kademlia. 
● Segurança: Fornece canais de comunicação criptografados e autenticados por padrão, 
usando a identidade criptográfica de cada nó (PeerID). 
● Travessia de NAT: Implementa soluções avançadas para conectividade P2P, como "hole 
punching", que serão detalhadas na Seção 5. 
Para uma aplicação P2P-SIP, o libp2p pode servir como a camada de base para toda a 
conectividade de rede, lidando com as complexidades da comunicação P2P e permitindo que 
os desenvolvedores se concentrem na lógica de sinalização SIP.47 
 
3.4 Modelos de Incentivo: Aplicando os Princípios DePIN para a 
Participação de Nós 
 
Uma questão fundamental em qualquer rede P2P em larga escala é: o que incentiva os 
participantes a contribuir com seus recursos (largura de banda, poder de computação, tempo 
de atividade) para o bem da rede? A participação puramente voluntária pode levar a uma alta 
rotatividade de nós e a uma infraestrutura instável. As Redes de Infraestrutura Física 
Descentralizada (DePIN) oferecem uma solução para este problema.9 
DePIN é um modelo que utiliza incentivos criptoeconômicos (tokens) para motivar indivíduos e 
organizações a construir e operar infraestrutura física ou digital de forma descentralizada.9 
Projetos como o Helium, que recompensa os usuários com tokens por operarem hotspots de 
rede sem fio, demonstraram a eficácia desse modelo para escalar infraestrutura 
globalmente.49 
No contexto de uma rede P2P-SIP, um modelo DePIN poderia ser aplicado para recompensar 
os nós que fornecem serviços essenciais, como armazenamento de registros na DHT e 
retransmissão de tráfego para travessia de NAT. Isso cria um "flywheel" (volante de inércia) 
auto-sustentável: 
1. Os usuários são incentivados a operar nós para ganhar tokens de recompensa. 
2. O aumento do número de nós torna a rede mais densa, confiável e com melhor 
desempenho. 
3. A melhoria do serviço atrai mais usuários para a plataforma de comunicação. 
4. O aumento do uso e da demanda pelo serviço pode aumentar o valor do token, 
fortalecendo ainda mais o incentivo para operar nós. 
Ao resolver o problema fundamental de "quem paga e mantém a infraestrutura" em um 
mundo sem servidores centrais, o modelo DePIN tem o potencial de transformar a telefonia 
P2P de uma solução de nicho para uma infraestrutura econômica viável, capaz de competir 
com os provedores de serviços tradicionais. 
 
Seção 4: Arquitetura de Referência para SIP sobre uma 
Overlay P2P (P2P-SIP) 
 
A transição da teoria para a prática requer uma arquitetura de referência bem definida que 
mapeie as funcionalidades do SIP em um paradigma P2P. O trabalho do grupo P2PSIP da IETF, 
culminando no protocolo RELOAD, fornece uma base sólida para essa arquitetura, garantindo 
um caminho em direção à interoperabilidade e padronização. 
 
4.1 O Padrão RELOAD da IETF: Uma Base para a Interoperabilidade 
 
O grupo de trabalho P2PSIP da IETF foi formado para desenvolver protocolos que 
permitissem o uso do SIP em ambientes com servidores centralizados mínimos ou 
inexistentes.16 O resultado principal desse esforço é o protocolo REsource LOcation And 
Discovery (RELOAD), especificado na RFC 6940.52 
RELOAD não é uma nova versão do SIP, mas sim um protocolo de sinalização P2P de 
propósito geral que opera como uma camada de overlay. Ele fornece aos seus clientes 
(chamados de "Usages") um serviço abstrato de armazenamento de dados e roteamento de 
mensagens entre os pares da rede.52 A especificação define um "SIP Usage for RELOAD" 
(RFC 7904), que detalha como as funcionalidades de um proxy e registrar SIP podem ser 
implementadas sobre uma overlay RELOAD, criando um serviço de telefonia totalmente 
distribuído.53 
Um aspecto crucial do RELOAD é a sua abordagem à interoperabilidade de DHT. Embora 
permita algoritmos opcionais, ele exige a implementação de um algoritmo DHT específico 
baseado em Chord, conhecido como "chord-reload", como linha de base obrigatória.33 Isso 
garante que diferentes implementações de P2P-SIP que seguem o padrão possam se 
comunicar e formar uma única overlay coesa. 
 
4.2 Mapeamento de Funções: Como a DHT Substitui o Servidor de 
Registro e Localização 
 
A função central da arquitetura P2P-SIP é a substituição da dupla Registrar/Location Server 
por uma DHT. O RELOAD formaliza as operações necessárias para realizar essa tarefa: 
● Registro (Operação Store): Quando um cliente P2P-SIP fica online, ele se registra na 
rede. Em vez de enviar uma mensagem REGISTER a um servidor, ele executa uma 
operação Store na DHT. O processo é o seguinte: 
1. O cliente usa seu AOR (por exemplo, sip:bob@dht.example.com) como a chave do 
recurso. 
2. Ele calcula um Resource-ID a partir dessa chave usando uma função de hash 
definida pelo protocolo. 
3. Ele armazena um valor, o SipRegistration Resource Record, sob esse Resource-ID. 
Esse registro contém o Node-ID do cliente na overlay e outras informações de 
contato.34 
 
A política de controle de acesso USER-NODE-MATCH do RELOAD garante que 
apenas o proprietário legítimo de um AOR (aquele que pode provar o controle sobre 
as credenciais associadas) pode armazenar um registro para ele.53 
● Resolução de Localização (Operação Fetch): Quando Alice quer ligar para Bob, seu 
cliente precisa descobrir a localização atual de Bob. Em vez de consultar um proxy, ele 
executa uma operação Fetch na DHT: 
1. O cliente de Alice calcula o mesmo Resource-ID a partir do AOR de Bob. 
2. Ele envia uma solicitação Fetch para a overlay, que é roteada através dos nós da DHT 
até chegar ao nó responsável por armazenar os dados daquele Resource-ID. 
3. O nó de armazenamento retorna o SipRegistration Resource Record de Bob, 
fornecendo a Alice o Node-ID e os endereços de contato necessários para iniciar a 
comunicação direta.33 
A tabela a seguir resume o mapeamento direto entre os componentes da arquitetura SIP 
centralizada e seus equivalentes descentralizados. 
Componente SIP 
Centralizado 
Função Equivalente 
Descentralizado 
Tecnologia 
Subjacente 
Servidor RegistrarAutentica e aceita 
solicitações 
REGISTER. 
Operação Store na 
DHT 
Protocolo DHT 
(e.g., Kademlia, 
Chord via RELOAD) 
Servidor de 
Localização 
Armazena e 
fornece 
mapeamentos AOR 
-> Contato. 
Nós da DHT 
responsáveis pela 
chave do AOR. 
Protocolo DHT 
Servidor Proxy Roteia a sinalização 
SIP (e.g., INVITE). 
Roteamento P2P 
Overlay 
Protocolo DHT 
(para lookup) + 
Roteamento direto 
de mensagens 
(e.g., libp2p) 
Domínio SIP (e.g., 
example.com) 
Namespace 
controlado por um 
provedor. 
Namespace 
gerenciado pela 
rede P2P ou DIDs. 
DHT / Blockchain 
Autenticação 
(usuário/senha) 
Prova a identidade 
para o Registrar. 
Assinatura 
Criptográfica 
Criptografia de 
Chave Pública 
(DIDs/VCs) 
 
4.3 Roteamento de Sinalização em uma Rede P2P: Do INVITE ao 200 
OK sem um Proxy Central 
 
Com o mecanismo de descoberta baseado em DHT estabelecido, o fluxo de uma chamada 
em uma rede P2P-SIP se torna totalmente descentralizado: 
1. Descoberta: O UA de Alice executa uma operação Fetch na DHT para resolver o AOR de 
Bob, obtendo seu Node-ID e endereços de contato. 
2. Conexão Direta: Alice usa o mecanismo de roteamento de mensagens da overlay para 
estabelecer uma conexão direta com o Node-ID de Bob. O RELOAD especifica um 
método AppAttach para este fim, que estabelece um canal de comunicação direto entre 
os dois pares.54 
3. Sinalização SIP: Uma vez que o canal direto é estabelecido, os UAs de Alice e Bob 
trocam mensagens SIP padrão (INVITE, 180 Ringing, 200 OK, ACK) diretamente através 
deste canal.16 A overlay P2P e a DHT já cumpriram sua função e não estão mais 
envolvidas na sinalização da sessão. 
4. Estabelecimento de Mídia: A negociação de mídia ocorre dentro das mensagens SIP 
via SDP, como de costume. Os fluxos de mídia (RTP) são então trocados diretamente 
entre os pares, nunca atravessando a overlay.54 
Uma capacidade notável desta arquitetura é o suporte nativo para funcionalidades avançadas 
como o encaminhamento de chamadas. A especificação do SIP Usage para RELOAD permite 
que um registro na DHT mapeie um AOR para outro AOR.53 Se Bob quiser que suas chamadas 
sejam encaminhadas para Charlie, ele simplesmente armazena um registro na DHT que 
mapeia 
sip:bob@dht.example.com para sip:charlie@dht.example.com. Quando Alice tenta ligar para 
Bob, seu cliente primeiro resolve o AOR de Bob e recebe o AOR de Charlie como resposta. O 
cliente de Alice então inicia uma nova busca na DHT pelo AOR de Charlie para encontrar sua 
localização real. Essa lógica, que em sistemas tradicionais reside em um servidor PBX 
centralizado, é aqui resolvida inteiramente no lado do cliente durante a fase de descoberta, 
descentralizando a própria funcionalidade e dando ao usuário controle total sobre seu 
roteamento de chamadas. 
 
4.4 Considerações sobre Latência e Desempenho em Lookups de DHT 
 
Uma preocupação válida em arquiteturas P2P-SIP é o potencial aumento da latência no 
estabelecimento da chamada (Post-Dial Delay - PDD) devido à necessidade de realizar uma 
busca na DHT. Em uma DHT estruturada, a latência de busca é tipicamente da ordem de 
O(logN), onde N é o número de nós na rede.35 Isso significa que a busca não é instantânea 
como uma consulta a um banco de dados local em um servidor centralizado. 
No entanto, pesquisas e implementações práticas demonstraram que essa latência é 
gerenciável. Para redes com milhões de nós, uma busca Kademlia ou Chord normalmente 
requer um pequeno número de saltos (hops) entre os nós. Estudos de desempenho indicaram 
que o atraso adicional introduzido pela busca na DHT é moderado e geralmente permanece 
bem abaixo dos valores recomendados pela ITU-T para a telefonia tradicional.56 Além disso, o 
uso de caches locais nos clientes para armazenar os resultados de buscas recentes pode 
reduzir significativamente a latência para chamadas repetidas para os mesmos contatos. 
Portanto, embora a latência de lookup seja uma consideração de design importante, ela não 
representa uma barreira intransponível para a viabilidade do P2P-SIP. 
 
Seção 5: O Desafio Crítico da Travessia de NAT em 
Redes P2P 
 
A viabilidade de qualquer sistema de comunicação peer-to-peer, incluindo o P2P-SIP, 
depende da capacidade dos nós de se conectarem diretamente uns aos outros. No entanto, a 
arquitetura predominante da internet moderna apresenta um obstáculo fundamental: a 
Tradução de Endereços de Rede (Network Address Translation - NAT). Superar as barreiras 
impostas pelo NAT é, talvez, o desafio técnico mais crítico para a implementação 
bem-sucedida de comunicações P2P em tempo real. 
 
5.1 Por que o NAT Inviabiliza a Comunicação P2P Direta 
 
O NAT é uma técnica usada em roteadores para permitir que múltiplos dispositivos em uma 
rede local privada (usando endereços IP privados, como 192.168.x.x) compartilhem um único 
endereço IP público.57 Quando um dispositivo na rede privada envia um pacote para um 
destino na internet pública, o roteador NAT substitui o endereço IP de origem privado pelo 
seu próprio endereço IP público. Ele mantém uma tabela de estado para rastrear essa 
tradução, de modo que, quando uma resposta chega, ele sabe para qual dispositivo interno 
encaminhar o pacote.59 
O problema para as comunicações P2P surge porque os NATs, por padrão, bloqueiam 
pacotes de entrada não solicitados.60 Se o Nó A, atrás de um NAT, tentar iniciar uma conexão 
com o Nó B, que está atrás de outro NAT, o roteador do Nó B receberá um pacote de uma 
fonte desconhecida e o descartará, pois não corresponde a nenhuma sessão de saída 
existente em sua tabela de estado. Como ambos os nós não podem iniciar uma conexão com 
o outro, a comunicação direta se torna impossível. Os protocolos SIP e RTP, que dependem 
do envio de endereços IP e portas nos seus pacotes de sinalização e mídia, são 
particularmente afetados, pois os endereços privados que eles anunciam são inúteis fora de 
sua rede local.58 
 
5.2 A Abordagem Clássica: STUN, TURN e ICE 
 
Para contornar o problema do NAT, a IETF desenvolveu um conjunto de protocolos que se 
tornaram o padrão da indústria para travessia de NAT em VoIP e outras aplicações em tempo 
real. 
● STUN (Session Traversal Utilities for NAT): O STUN é um protocolo simples que 
permite que um dispositivo atrás de um NAT descubra seu endereço IP público e a porta 
que o NAT abriu para sua conexão de saída.63 O dispositivo envia uma solicitação para 
um servidor STUN localizado na internet pública. O servidor STUN examina o endereço IP 
e a porta de origem do pacote recebido e os envia de volta para o dispositivo em sua 
resposta.65 Com essa informação, o dispositivo pode anunciar seu endereço público para 
outros pares, na esperança de que eles possam usá-lo para estabelecer uma conexão 
direta. O STUN funciona bem para certos tipos de NAT (Full Cone, Restricted Cone), mas 
falha em cenários mais restritivos, notadamente o NAT Simétrico, onde o NAT cria um 
mapeamento de porta diferente para cada destino externo.58 
● TURN (Traversal Using Relays around NAT): Quando a conexão direta falha, 
especialmente em casos de NAT Simétrico ou firewalls restritivos, o TURN atua como um 
último recurso.65 O TURN permite que a comunicação seja retransmitida através de um 
servidor público. Cada par envia seus pacotes de mídia para o servidor TURN, que então 
os encaminha para o outro par.63 Embora o TURN garanta a conectividade em quase 
todos os cenários, ele o faz ao custo de introduzir latência adicional e consumir largura 
de banda e recursos do servidor, o que vai contra o princípio de uma comunicação P2P 
pura.60 
● ICE (Interactive Connectivity Establishment): O ICE não é um protocolo, mas um 
framework (RFC 8445) que utiliza STUN e TURN de forma inteligente para encontrar o 
caminho de comunicação mais eficiente entre dois pares.57 Um agente ICE em cada 
dispositivo coleta uma lista de todos os endereços "candidatos" possíveis para a 
comunicação: 
1. Candidatos Host: Endereços IP e portas locais do dispositivo. 
2. CandidatosServer Reflexive (srflx): Endereços IP e portas públicos descobertos 
via STUN. 
3. Candidatos Relayed (relay): Endereços no servidor TURN alocados para 
retransmissão. 
Os pares trocam essas listas de candidatos e, em seguida, realizam verificações de 
conectividade sistemáticas, testando os pares de candidatos em uma ordem de 
preferência (Host > srflx > relay) para encontrar o caminho de maior qualidade que 
funcione. O ICE otimiza a probabilidade de estabelecer uma conexão direta P2P, 
recorrendo à retransmissão via TURN apenas quando absolutamente necessário.65 
 
5.3 Uma Solução Descentralizada: "Hole Punching" e Retransmissão 
de Circuito no libp2p 
 
Inspirado pelo ICE, o libp2p implementa uma abordagem de travessia de NAT que visa 
alcançar os mesmos objetivos, mas de uma maneira mais descentralizada, minimizando a 
dependência de servidores dedicados como STUN e TURN.68 
● AutoNAT: Este protocolo permite que um nó determine sua própria "dialability" 
(capacidade de ser alcançado) usando outros pares na rede como ajudantes. O nó pede 
a vários pares que tentem se conectar a ele em seus endereços conhecidos. O resultado 
desses testes informa ao nó se ele está publicamente acessível ou atrás de um NAT. Isso 
cumpre a mesma função do STUN, mas utiliza a própria rede P2P em vez de um servidor 
centralizado.68 
● Hole Punching: Esta técnica é usada para estabelecer conexões diretas entre dois nós 
que estão ambos atrás de NATs. O processo é coordenado por um terceiro nó, que atua 
como um ponto de encontro (geralmente um nó de retransmissão ao qual ambos estão 
conectados). O processo funciona da seguinte forma: 
1. O Nó A informa ao Nó B (através do nó de retransmissão) que deseja iniciar o "hole 
punching". 
2. Ambos os nós, de forma sincronizada, enviam pacotes um para o outro em seus 
endereços públicos (descobertos via AutoNAT ou protocolos semelhantes). 
3. O pacote de saída de cada nó "perfura um buraco" em seu próprio NAT, criando uma 
entrada temporária na tabela de estado que permite o tráfego de entrada do 
endereço IP e porta do outro nó. 
4. Quando o pacote do outro nó chega, ele corresponde à entrada recém-criada e é 
permitido passar, estabelecendo a conexão P2P.68 
● Circuit Relay: Se o "hole punching" falhar, o libp2p pode usar outros nós da rede P2P 
como retransmissores. Isso é análogo ao TURN, mas em vez de depender de servidores 
de retransmissão dedicados e pré-configurados, qualquer nó da rede pode, 
opcionalmente, atuar como um retransmissor. Isso mantém a arquitetura descentralizada, 
embora a qualidade da conexão retransmitida dependa do desempenho e da localização 
do nó de retransmissão escolhido.68 
A tabela a seguir compara as duas abordagens principais para a travessia de NAT. 
Característica Framework ICE 
(STUN/TURN) 
Framework libp2p 
(AutoNAT/Hole Punching) 
Filosofia Híbrida (usa servidores 
centralizados para facilitar 
P2P). 
Pura P2P (usa a própria 
rede para facilitar P2P). 
Descoberta de IP Público Servidor STUN dedicado. Protocolo AutoNAT (outros 
pares atuam como STUN). 
Fallback de 
Conectividade 
Servidor TURN dedicado 
(retransmissão de mídia). 
Circuit Relay (outros pares 
atuam como TURN). 
Dependências Servidores STUN/TURN 
publicamente acessíveis. 
Nós de bootstrap e relés 
P2P disponíveis na rede. 
Prós Altamente padronizado 
(RFCs), amplamente 
implementado. 
Maior descentralização, 
alinhado com a filosofia 
Web3. 
Contras Reintroduz pontos de 
falha/controle 
centralizados, custos de 
servidor. 
Menos padronizado, o 
desempenho do relé 
depende da topologia da 
rede. 
 
5.4 Recomendações para Máxima Conectividade em Ambientes de 
Rede Hostis 
 
A experiência prática demonstra que nenhuma técnica de travessia de NAT é infalível. 
Portanto, uma implementação robusta de P2P-SIP deve adotar uma abordagem em camadas 
e oportunista. A estratégia ideal é tentar o método mais eficiente primeiro e recorrer a 
métodos menos eficientes apenas quando necessário. A flexibilidade do libp2p, que integra 
nativamente a descoberta de alcançabilidade, o "hole punching" e a retransmissão por 
circuito, o torna uma base tecnológica particularmente adequada para implementar essa 
lógica complexa. A sequência recomendada é: 
1. Tentar a conexão direta usando endereços de host locais e públicos conhecidos. 
2. Se falhar, iniciar o "hole punching" coordenado através de um relé. 
3. Se o "hole punching" falhar, usar a conexão de retransmissão estabelecida como o canal 
de comunicação. 
Esta abordagem em cascata maximiza a probabilidade de estabelecer uma conexão P2P de 
baixa latência, ao mesmo tempo que garante a conectividade como um fallback confiável, 
mesmo nas condições de rede mais desafiadoras. 
 
Seção 6: Identidade Soberana: Autenticação SIP na Era 
Web3 
 
O modelo de autenticação centralizado do SIP tradicional, baseado em nome de usuário e 
senha, é fundamentalmente incompatível com os princípios de soberania e controle do 
usuário da Web3. A evolução para um sistema de comunicação verdadeiramente 
descentralizado exige um novo paradigma de identidade, um que desacople a identidade do 
usuário de qualquer provedor de serviços e a coloque firmemente sob o controle do próprio 
indivíduo. A Identidade Auto-Soberana (Self-Sovereign Identity - SSI), habilitada por 
tecnologias como Identificadores Descentralizados (DIDs) e Credenciais Verificáveis (VCs), 
fornece essa base.71 
 
6.1 Identificadores Descentralizados (DIDs): Desacoplando a 
Identidade dos Servidores 
 
Os Identificadores Descentralizados (DIDs) são um novo tipo de identificador globalmente 
único, padronizado pelo W3C, projetado para identidade digital verificável e 
descentralizada.73 Ao contrário dos identificadores tradicionais (como endereços de e-mail ou 
AORs SIP), os DIDs não dependem de um registro centralizado. Um DID é controlado pelo seu 
"sujeito" (uma pessoa, organização ou coisa) e sua propriedade pode ser provada 
criptograficamente.73 
A sintaxe de um DID é did:method:identifier-specific-string.76 
● did: O esquema de URI. 
● method: Especifica o método DID, que define como o DID é registrado e resolvido (ex: 
ethr para Ethereum, web para domínios da web, key para DIDs baseados apenas em 
chaves). 
● identifier-specific-string: Uma string única dentro do método especificado. 
Um DID resolve para um documento JSON-LD chamado "Documento DID".73 Este documento 
contém informações públicas essenciais associadas ao DID, incluindo: 
● Chaves Públicas Criptográficas: Usadas para autenticação (assinaturas digitais) e 
criptografia. 
● Métodos de Verificação: Descrevem como provar o controle sobre o DID. 
● Endpoints de Serviço (Service Endpoints): Especificam como interagir com o sujeito 
do DID, como um endpoint para mensagens seguras ou, no nosso caso, um endereço de 
contato para comunicação em tempo real.74 
Ao usar DIDs como o identificador principal em um sistema P2P-SIP, a identidade do usuário é 
desvinculada de qualquer provedor de serviços. O DID de um usuário é portátil e persistente, 
permitindo que ele se mova entre diferentes redes ou clientes sem perder sua identidade ou 
contatos. 
 
6.2 Credenciais Verificáveis (VCs): Provas Criptográficas para 
Autorização de Chamadas 
 
Enquanto os DIDs fornecem a base para a identidade, as Credenciais Verificáveis (VCs) 
fornecem um mecanismo para fazer afirmações sobre essa identidade de uma maneira 
criptograficamente segura e à prova de violação.78 Uma VC é um conjunto de declarações 
(claims) feitas por um "Emissor" sobre um "Sujeito" (o portador da credencial), que é então 
assinado digitalmente pelo Emissor.80 
O ecossistema de VCs opera em um "triângulo de confiança" 79: 
1. Emissor (Issuer): Uma entidade confiável (ex: uma empresa, uma universidade, um 
governo) emite uma VC para um Portador. 
2. Portador (Holder): O indivíduo armazena a VC em sua carteira digital (digital wallet) e 
tem controle total sobre quando e como ela é compartilhada. 
3. Verificador(Verifier): Uma entidade que solicita e verifica a VC para confirmar uma 
afirmação. 
No contexto do SIP, as VCs podem ser usadas para autorização granular. Por exemplo, em vez 
de uma simples autenticação de "tudo ou nada", um sistema poderia exigir que um chamador 
apresente uma VC que prove que ele é "um funcionário da empresa X" ou "um membro do 
grupo familiar Y" para que a chamada seja completada. Uma característica poderosa das VCs 
é a "divulgação seletiva" (selective disclosure), que permite ao portador provar uma 
afirmação sem revelar todos os dados da credencial (por exemplo, provar que tem mais de 18 
anos sem revelar a data de nascimento exata).83 
 
6.3 Fluxo de Autenticação Baseado em DID/VC: Um Novo Paradigma 
de Segurança 
 
A combinação de DIDs e VCs permite um fluxo de autenticação e autorização muito mais 
seguro e centrado no usuário do que a Autenticação Digest. Um fluxo de chamada P2P-SIP 
poderia ser assim: 
1. Iniciação: O UA de Alice, usando seu DID, inicia uma chamada para o DID de Bob. O 
INVITE inicial pode ser não autenticado. 
2. Desafio: O UA de Bob, ao receber o INVITE, responde com um desafio 401 Unauthorized. 
Este desafio não é baseado em senha, mas é um nonce criptográfico, uma string 
aleatória. 
3. Resposta de Autenticação: O UA de Alice usa a chave privada associada ao seu DID 
para assinar digitalmente o nonce (e possivelmente outros dados da transação). Ele 
envia um novo INVITE contendo a assinatura. 
4. Verificação: O UA de Bob recupera o Documento DID de Alice (por exemplo, de uma 
DHT ou blockchain). Ele usa a chave pública do documento para verificar a assinatura de 
Alice. Se a verificação for bem-sucedida, a identidade de Alice é confirmada. 
5. Autorização (Opcional): Se a política de Bob exigir autorização adicional, seu UA pode 
solicitar uma VC específica na resposta de desafio. Alice então apresentaria a VC 
solicitada em seu próximo INVITE. O UA de Bob verificaria a assinatura do emissor da VC 
para validar as afirmações.83 
A tabela a seguir destaca as diferenças fundamentais entre o modelo de autenticação legado 
e o novo paradigma baseado em identidade soberana. 
Atributo Autenticação SIP Digest 
(RFC 2617) 
Autenticação Baseada em 
DID/VC (W3C) 
Base da Identidade username:password 
armazenado no servidor. 
Chave criptográfica 
controlada pelo usuário 
(DID). 
Controle do Usuário Nulo. O provedor controla a 
identidade. 
Total. O usuário controla 
suas chaves e DIDs. 
Portabilidade Nenhuma. A identidade 
está presa ao domínio do 
provedor. 
Total. O DID é 
independente de qualquer 
serviço. 
Privacidade O provedor conhece todas 
as interações de 
autenticação. 
Interações P2P podem ser 
anônimas ou pseudônimas. 
Segurança Vulnerável a ataques de 
força bruta no servidor. 
Baseado em criptografia de 
chave pública, muito mais 
forte. 
Autorização Binária (autenticado ou 
não). 
Granular (pode provar 
atributos específicos via 
VCs). 
 
6.4 Implicações para a Privacidade e Controle do Usuário 
 
A adoção do modelo de Identidade Auto-Soberana (SSI) para a telefonia SIP representa uma 
mudança transformadora no poder do usuário.86 Ao controlar suas próprias chaves, os 
usuários podem gerar quantos DIDs forem necessários para diferentes contextos, separando 
sua identidade profissional, pessoal e anônima, o que impede o rastreamento e a correlação 
de dados por terceiros.74 As comunicações P2P seguras podem ser estabelecidas sem que 
nenhuma entidade central tenha conhecimento da interação.89 A capacidade de divulgar 
seletivamente os atributos por meio de VCs garante que apenas as informações estritamente 
necessárias sejam compartilhadas para qualquer transação, aderindo ao princípio da 
minimização de dados. Em suma, a integração de DIDs e VCs na arquitetura SIP não é apenas 
uma melhoria de segurança, mas a realização da promessa da Web3 de uma internet onde os 
usuários são os verdadeiros soberanos de suas vidas digitais. 
 
Seção 7: Implementações, Projetos e Estudos de Caso 
 
A transição de arquiteturas teóricas para sistemas funcionais é o teste final de qualquer 
paradigma tecnológico. No domínio da telefonia descentralizada, vários projetos, desde 
aplicações maduras de código aberto até conceitos emergentes, demonstram a viabilidade e 
o potencial da fusão do SIP com os princípios da Web3. Esta seção analisa implementações 
notáveis, avalia o potencial de adaptação de ferramentas existentes e examina a viabilidade 
geral e as barreiras à adoção. 
 
7.1 Jami: Um Exemplo Prático de Comunicação Distribuída baseada 
em DHT e SIP 
 
Jami (anteriormente conhecido como SFLphone e Ring) é um software de comunicação livre e 
de código aberto, oficialmente parte do Projeto GNU, que opera como uma plataforma de 
comunicação totalmente peer-to-peer.90 Ele se destaca como uma das implementações mais 
maduras dos conceitos de P2P-SIP no mundo real. 
A arquitetura do Jami é um estudo de caso prático dos fundamentos discutidos 
anteriormente: 
● Operação sem Servidor: A principal característica do Jami é a ausência de servidores 
centrais para retransmitir dados entre os usuários. As comunicações ocorrem 
diretamente entre os pares.90 
● Descoberta via DHT: Para a descoberta de pares e resolução de nomes, o Jami utiliza 
uma Tabela de Hash Distribuída (especificamente, OpenDHT).91 Quando um usuário se 
conecta, ele se junta à rede DHT, permitindo que outros o encontrem sem um servidor de 
registro central. 
● Identidade Baseada em Criptografia: As contas Jami não são baseadas em nome de 
usuário/senha, mas em certificados assimétricos X.509. O identificador único de um 
usuário (JamiID) é o fingerprint de sua chave pública, garantindo uma identidade 
criptográfica forte e controlada pelo usuário.92 
● Compatibilidade com SIP: O Jami mantém sua herança como um softphone SIP e pode 
funcionar como um cliente SIP padrão, permitindo que os usuários se conectem a 
servidores SIP tradicionais e façam chamadas para a PSTN.90 Isso o torna uma ponte 
entre o mundo centralizado e o descentralizado. 
● Sincronização Multi-dispositivo via "Swarm": Para conversas em grupo e 
sincronização de histórico entre múltiplos dispositivos de um mesmo usuário, o Jami 
implementa um conceito chamado "Swarm". Tecnicamente, cada conversa é um 
repositório Git distribuído, e as mensagens são commits que são sincronizados entre os 
dispositivos dos participantes, criando um histórico de conversas resiliente e 
descentralizado.95 
A implementação do Jami demonstra que é tecnicamente viável construir uma plataforma de 
comunicação rica em recursos (chamadas de áudio/vídeo, conferências, compartilhamento 
de arquivos) sobre uma arquitetura puramente P2P, utilizando uma DHT para descoberta e 
mantendo a compatibilidade com o SIP. 
 
7.2 Servidores SIP Open Source (Kamailio, OpenSIPS): Potencial de 
Adaptação para Arquiteturas Híbridas 
 
Servidores SIP de alto desempenho e de código aberto como Kamailio e OpenSIPS são a 
espinha dorsal de muitos dos maiores provedores de VoIP do mundo.98 Embora sejam 
projetados para operar em um modelo centralizado, sua extrema flexibilidade e 
extensibilidade os tornam candidatos ideais para a construção de componentes de ponte em 
um ecossistema P2P-SIP híbrido. 
Em vez de desaparecerem, esses servidores poderiam evoluir para desempenhar novos 
papéis cruciais: 
● Gateways P2P-PSTN: A interconexão com a rede telefônica tradicional continua sendo 
uma necessidade. Um servidor Kamailio ou OpenSIPS poderia atuar como um gateway, 
recebendo uma chamada de um nó P2P-SIP e encaminhando-a para a PSTN, e 
vice-versa. 
● Super-nós de DHT: Em algumas arquiteturas P2P, certos nós com alta disponibilidade e 
largura de banda (super-nós) assumem mais responsabilidades de roteamento.100 Um 
servidor SIP robusto poderia ser configurado para atuar como um super-nó confiável na 
DHT. 
● Proxy de Borda para Clientes Legados: Uma rede P2P-SIP poderia interagir com 
clientes SIP padrão que não suportama stack P2P. Um servidor OpenSIPS poderia atuar 
como um proxy de borda, registrando clientes legados da maneira tradicional, mas 
usando a overlay P2P para localizar usuários e rotear chamadas para o mundo 
descentralizado.37 
Essa abordagem híbrida oferece um caminho de migração gradual, permitindo que os 
benefícios da descentralização sejam introduzidos sem abandonar a compatibilidade com o 
vasto ecossistema de dispositivos e serviços SIP existentes. 
 
7.3 Projetos Conceituais: A Visão do Marina.Rodeo para SIP sobre 
Blockchain 
 
O projeto Marina.Rodeo se apresenta como um "serviço SIP VoIP descentralizado 
incomparável que integra a tecnologia blockchain para chamadas de voz seguras e de alta 
qualidade".101 Embora a documentação técnica detalhada, como um whitepaper, não esteja 
publicamente disponível, a descrição do projeto aponta para uma visão de utilizar blockchain 
como um pilar fundamental para a descentralização do SIP. 
É crucial fazer uma distinção arquitetônica importante aqui. A utilização de uma blockchain 
para a camada de identidade ou registro é uma abordagem viável e alinhada com os 
princípios da Web3. Por exemplo, os DIDs podem ser ancorados em uma blockchain para 
garantir persistência e resistência à censura. No entanto, o uso de uma blockchain para a 
sinalização em tempo real (a troca de mensagens INVITE, 200 OK, etc.) é tecnicamente 
problemático. As blockchains são otimizadas para consenso e imutabilidade, não para baixa 
latência. Os tempos de finalização de bloco, que podem variar de segundos a minutos, são 
ordens de magnitude muito lentos para a sinalização de chamadas em tempo real, que exige 
respostas em milissegundos. 
Portanto, a interpretação mais caridosa e tecnicamente sólida da visão de um projeto como o 
Marina.Rodeo é um sistema híbrido: 
1. Camada de Identidade/Registro (Blockchain): A blockchain é usada para registrar 
DIDs ou mapeamentos AOR, fornecendo uma fonte de verdade imutável e 
descentralizada. 
2. Camada de Descoberta/Sinalização (DHT/P2P): Uma DHT, que é otimizada para 
buscas rápidas, é usada para a descoberta de localização em tempo real, e a sinalização 
SIP flui diretamente entre os pares sobre uma rede P2P. 
Confundir essas duas camadas e tentar usar uma blockchain para sinalização em tempo real 
representaria uma falha de design fundamental, resultando em um sistema impraticável. 
 
7.4 Análise de Viabilidade e Barreiras à Adoção em Massa 
 
Apesar da promessa tecnológica, a adoção em massa da telefonia P2P-SIP enfrenta barreiras 
significativas: 
● Complexidade para o Usuário: Sistemas como o Jami, embora poderosos, ainda 
podem apresentar uma curva de aprendizado mais acentuada para usuários não 
técnicos em comparação com aplicativos centralizados e polidos. A gestão de chaves e 
backups de contas é uma responsabilidade que muitos usuários não estão acostumados 
a ter.92 
● Efeito de Rede: As plataformas de comunicação prosperam com o efeito de rede. 
Desafiar gigantes estabelecidos como WhatsApp, Telegram ou Zoom requer não apenas 
uma tecnologia superior, mas também a capacidade de atrair uma massa crítica de 
usuários. 
● Interoperabilidade e Legado: A falta de gateways padronizados e fáceis de usar para a 
PSTN e para o ecossistema SIP tradicional limita a utilidade das plataformas puramente 
P2P para muitos casos de uso de negócios. 
● Incerteza Regulatória: As comunicações P2P e criptografadas podem enfrentar 
escrutínio regulatório em várias jurisdições, especialmente em relação a questões como 
interceptação legal e chamadas de emergência.50 
Superar essas barreiras exigirá não apenas inovação tecnológica contínua, mas também um 
foco intenso na experiência do usuário, no desenvolvimento de ecossistemas e na navegação 
do complexo cenário regulatório. 
 
Seção 8: Conclusão – Desafios, Oportunidades e o 
Futuro da Telefonia Descentralizada 
 
A jornada para descentralizar a telefonia SIP, um protocolo profundamente enraizado no 
paradigma cliente-servidor, é tanto um desafio técnico formidável quanto uma oportunidade 
transformadora. A convergência com as arquiteturas da Web3 representa uma reimaginação 
fundamental de como concebemos a comunicação, a identidade e a confiança no mundo 
digital. Este relatório demonstrou que, embora o caminho seja complexo, os blocos de 
construção tecnológicos e os modelos arquitetônicos para realizar essa visão já existem e 
estão amadurecendo rapidamente. 
 
8.1 Síntese dos Desafios Técnicos Remanescentes 
 
Apesar dos avanços significativos, vários desafios técnicos persistem e exigem atenção 
contínua da comunidade de desenvolvimento e pesquisa para que a telefonia descentralizada 
alcance a robustez e a escala dos sistemas centralizados. 
● Segurança da Rede P2P: As redes P2P abertas são vulneráveis a uma classe específica 
de ataques que não afetam os sistemas centralizados da mesma forma. Ataques Sybil, 
onde um adversário cria um grande número de identidades falsas para ganhar influência 
desproporcional na rede, podem ser usados para subverter a DHT. O envenenamento da 
DHT, onde nós maliciosos inserem dados de roteamento incorretos, pode interromper a 
descoberta de pares. Ataques de negação de serviço distribuídos (DDoS) também 
representam uma ameaça, embora a natureza distribuída da rede ofereça alguma 
resiliência inerente.51 O desenvolvimento de mecanismos de reputação de nós e políticas 
de acesso mais sofisticadas é uma área de pesquisa ativa. 
● Escalabilidade e Gerenciamento de Churn: Embora as DHTs sejam teoricamente 
escaláveis para milhões de nós, o desempenho no mundo real pode ser degradado pela 
alta rotatividade de nós (churn), ou seja, nós entrando e saindo da rede frequentemente. 
O churn constante força a rede a gastar uma quantidade significativa de largura de 
banda em mensagens de manutenção para atualizar as tabelas de roteamento e 
redistribuir os dados armazenados, o que pode aumentar a latência de busca e a taxa de 
falha.17 Modelos econômicos como o DePIN podem ajudar a mitigar o churn, 
incentivando a operação de nós estáveis e de longo prazo. 
● Interoperabilidade com a PSTN: Para a maioria dos usuários e empresas, a capacidade 
de fazer e receber chamadas da Rede Telefônica Pública Comutada é um requisito não 
negociável. A integração de uma rede P2P-SIP com a PSTN requer gateways que possam 
traduzir a sinalização e a mídia entre os dois mundos. O desenvolvimento de gateways 
descentralizados ou de um mercado competitivo para serviços de gateway é essencial 
para evitar a reintrodução de novos pontos de centralização e controle. 
 
8.2 Oportunidades Emergentes: Comunicações Resistentes à 
Censura, Redução de Custos e Novos Modelos de Negócio 
 
Superar esses desafios desbloqueia um conjunto de oportunidades que têm o potencial de 
remodelar o cenário das comunicações. 
● Comunicações Resistentes à Censura e Vigilância: A aplicação mais profunda da 
telefonia descentralizada reside na sua capacidade de fornecer um meio de 
comunicação que não pode ser facilmente controlado, monitorado ou desligado por uma 
autoridade central. Em um mundo onde a liberdade de expressão está sob ameaça, as 
plataformas P2P-SIP podem se tornar ferramentas vitais para jornalistas, ativistas e 
cidadãos que vivem sob regimes repressivos.8 
● Redução Radical de Custos de Infraestrutura: Ao eliminar a necessidade de manter e 
operar uma vasta infraestrutura de servidores centrais (proxies, registrars, TURN 
servers), o modelo P2P transfere o custo da infraestrutura para as bordas da rede.7 Isso 
pode levar a uma redução dramática nos custos operacionais, permitindo a oferta de 
serviços de comunicação a preços mais baixos ou até mesmo gratuitos, sustentados por 
modelos de incentivo DePIN. 
● Novos Modelos de Negócio e Casos de Uso Nativos da Web3: A telefonia 
descentralizada pode se tornar a camada de comunicação nativa para o ecossistema 
Web3. Organizações Autônomas Descentralizadas (DAOs) podem usar sistemas P2P-SIP 
para governançae comunicação segura entre membros.105 Aplicações de metaverso 
podem integrar comunicação de voz e vídeo espacial P2P diretamente em seus mundos 
virtuais.106 Mercados descentralizados podem usar a comunicação segura para 
negociações entre compradores e vendedores.107 
 
8.3 Recomendações para Desenvolvedores e Arquitetos de Rede 
 
Para aqueles que buscam construir a próxima geração de aplicações de comunicação, as 
seguintes recomendações estratégicas podem servir como um guia: 
1. Adotar Stacks Modulares: Em vez de reinventar a roda, utilize frameworks P2P robustos 
e modulares como o libp2p. Isso permite que as equipes de desenvolvimento se 
concentrem na experiência do usuário e na lógica da aplicação, enquanto aproveitam 
uma base de rede testada em batalha que já resolve problemas complexos como 
travessia de NAT e segurança de transporte. 
2. Construir sobre Padrões Abertos: Sempre que possível, alinhe-se com padrões 
abertos como o SIP e o framework RELOAD da IETF. Isso não apenas promove a 
interoperabilidade, mas também garante que a solução possa se beneficiar da evolução 
futura desses padrões. 
3. Priorizar a Identidade Soberana: Integre DIDs e VCs desde o início do projeto. 
Construir um sistema de comunicação sobre uma base de identidade soberana não é 
uma reflexão tardia, mas uma decisão arquitetônica fundamental que define a proposta 
de valor do produto em termos de privacidade e controle do usuário. 
4. Considerar a Criptoeconomia: Avalie a implementação de um modelo de incentivo 
DePIN para garantir a saúde e a sustentabilidade da rede a longo prazo. Um token bem 
projetado pode alinhar os incentivos de operadores de nós e usuários, criando um 
ecossistema virtuoso de crescimento e confiabilidade. 
 
8.4 Perspectivas Futuras: A Integração Total de Comunicações em 
Tempo Real no Ecossistema Web3 
 
O futuro da telefonia descentralizada não reside na criação de aplicações isoladas que 
simplesmente replicam as funcionalidades do Skype ou do WhatsApp em uma arquitetura 
P2P. A verdadeira visão de longo prazo é a integração da comunicação em tempo real como 
uma camada de protocolo fundamental e nativa do ecossistema Web3, tão onipresente e 
interoperável quanto a transferência de valor via criptomoedas. 
Nesse futuro, iniciar uma chamada de voz ou vídeo segura e P2P a partir de uma carteira 
digital será tão simples quanto assinar uma transação. A identidade será gerenciada por DIDs, 
a autorização por VCs, e a conectividade garantida por redes P2P incentivadas. O SIP, com 
sua rica herança de funcionalidades de telefonia, não será descartado, mas sim 
transformado, seu motor de sinalização adaptado para operar sobre uma nova base de 
confiança distribuída. O resultado final será a realização da promessa original da internet: 
uma rede de pares, verdadeiramente aberta, onde a comunicação é um direito fundamental e 
não um serviço controlado por intermediários. 
Referências citadas 
1. Session Initiation Protocol - RFC 3261 - Mobius Software, acessado em setembro 
26, 2025, 
https://www.mobius-software.com/documentation/Mobius+SIP/Core+SIP+Protoc
ol 
2. Session Initiation Protocol - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Session_Initiation_Protocol 
3. SIP Architecture, acessado em setembro 26, 2025, 
https://cdn.ttgtmedia.com/searchVoIP/downloads/Building_a_VoIP_Network_Ch[1].
_8.pdf 
4. RFC 3261: 3 of 13, p. 34 to 55 - Tech-invite, acessado em setembro 26, 2025, 
https://www.tech-invite.com/y30/tinv-ietf-rfc-3261-3.html 
https://www.mobius-software.com/documentation/Mobius+SIP/Core+SIP+Protocol
https://www.mobius-software.com/documentation/Mobius+SIP/Core+SIP+Protocol
https://en.wikipedia.org/wiki/Session_Initiation_Protocol
https://cdn.ttgtmedia.com/searchVoIP/downloads/Building_a_VoIP_Network_Ch[1]._8.pdf
https://cdn.ttgtmedia.com/searchVoIP/downloads/Building_a_VoIP_Network_Ch[1]._8.pdf
https://www.tech-invite.com/y30/tinv-ietf-rfc-3261-3.html
5. SIP proxy server - 8x8, acessado em setembro 26, 2025, 
https://www.8x8.com/s/sip-proxy-server 
6. SIP Proxy Server - OnSIP, acessado em setembro 26, 2025, 
https://www.onsip.com/voip-resources/voip-fundamentals/sip-proxy-server 
7. Centralized vs. Distributed SIP Trunking: Making an Informed Decision - White 
Paper | Oracle - Webtorials, acessado em setembro 26, 2025, 
http://www.webtorials.com/main/resource/papers/Oracle/paper10/sip-trunking-to
pologies.pdf 
8. What is The Web3 Communication Protocol? - Metana, acessado em setembro 
26, 2025, https://metana.io/blog/what-is-the-web3-communication-protocol/ 
9. The Potential of Decentralized Physical Infrastructure Networks (DePIN), 
acessado em setembro 26, 2025, 
https://www.natix.network/blog/potential-of-decentralized-physical-infrastructur
e-networks-depin 
10. What Is Web3? The Decentralized Internet Explained - Core blockchain, acessado 
em setembro 26, 2025, https://coredao.org/core-academy/what-is-web3 
11. What Is Web3? Understanding the Decentralized Internet - USDC, acessado em 
setembro 26, 2025, https://www.usdc.com/learn/what-is-web3 
12. O que é Web3? - AWS, acessado em setembro 26, 2025, 
https://aws.amazon.com/pt/what-is/web3/ 
13. Web3 Protocols: A Beginner's Guide 2025 - Metana, acessado em setembro 26, 
2025, https://metana.io/blog/web3-protocols-a-beginners-guide/ 
14. Web3 é o futuro da Internet? - EdgeUno, acessado em setembro 26, 2025, 
https://edgeuno.com/pt-br/is-web3-the-future-of-the-internet/ 
15. What is Web 3? The future of a decentralized internet - CoinTracker, acessado em 
setembro 26, 2025, https://www.cointracker.io/learn/web-3 
16. Peer-to-peer SIP - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Peer-to-peer_SIP 
17. Peer-to-Peer Internet Telephony using SIP - Academic Commons, acessado em 
setembro 26, 2025, 
https://academiccommons.columbia.edu/doi/10.7916/D8WM1RKD/download 
18. What Is a SIP Proxy? How Does a SIP Server Work? - Nextiva, acessado em 
setembro 26, 2025, https://www.nextiva.com/blog/sip-proxy-server.html 
19. Proxy Registrar, acessado em setembro 26, 2025, 
https://docs.oracle.com/en/industries/communications/converged-application-ser
ver/8.0/concepts/proxy-registrar.html 
20. What Is a SIP Proxy Server? [Complete Guide] - Momentum, acessado em 
setembro 26, 2025, https://gomomentum.com/sip-proxy-server/ 
21. What is a SIP Proxy Server? How it Works & Top Benefits - GetVoIP, acessado em 
setembro 26, 2025, https://getvoip.com/library/what-is-a-sip-proxy-server/ 
22. Understanding SIP Authentication | Tao, Zen, and Tomorrow - WordPress.com, 
acessado em setembro 26, 2025, 
https://andrewjprokop.wordpress.com/2015/01/27/understanding-sip-authenticati
on/ 
23. SIP User Authentication - VOCAL Technologies, acessado em setembro 26, 2025, 
https://www.8x8.com/s/sip-proxy-server
https://www.onsip.com/voip-resources/voip-fundamentals/sip-proxy-server
http://www.webtorials.com/main/resource/papers/Oracle/paper10/sip-trunking-topologies.pdf
http://www.webtorials.com/main/resource/papers/Oracle/paper10/sip-trunking-topologies.pdf
https://metana.io/blog/what-is-the-web3-communication-protocol/
https://www.natix.network/blog/potential-of-decentralized-physical-infrastructure-networks-depin
https://www.natix.network/blog/potential-of-decentralized-physical-infrastructure-networks-depin
https://coredao.org/core-academy/what-is-web3
https://www.usdc.com/learn/what-is-web3
https://aws.amazon.com/pt/what-is/web3/
https://metana.io/blog/web3-protocols-a-beginners-guide/
https://edgeuno.com/pt-br/is-web3-the-future-of-the-internet/
https://www.cointracker.io/learn/web-3
https://en.wikipedia.org/wiki/Peer-to-peer_SIP
https://academiccommons.columbia.edu/doi/10.7916/D8WM1RKD/download
https://www.nextiva.com/blog/sip-proxy-server.html
https://docs.oracle.com/en/industries/communications/converged-application-server/8.0/concepts/proxy-registrar.html
https://docs.oracle.com/en/industries/communications/converged-application-server/8.0/concepts/proxy-registrar.htmlhttps://gomomentum.com/sip-proxy-server/
https://getvoip.com/library/what-is-a-sip-proxy-server/
https://andrewjprokop.wordpress.com/2015/01/27/understanding-sip-authentication/
https://andrewjprokop.wordpress.com/2015/01/27/understanding-sip-authentication/
https://vocal.com/sip/sip-user-authentication/ 
24. Digest Authentication with SIP - Oracle Help Center, acessado em setembro 26, 
2025, 
https://docs.oracle.com/en/industries/communications/session-border-controller/
9.0.0/configuration/digest-authentication-sip1.html 
25. Digest Authentication with SIP - ACLI Configuration Guide, acessado em 
setembro 26, 2025, 
https://docs.oracle.com/en/industries/communications/enterprise-session-border
-controller/8.2.0/configuration/digest-authentication-sip.html 
26. What is P2P (Peer-to-Peer Process)? - GeeksforGeeks, acessado em setembro 
26, 2025, 
https://www.geeksforgeeks.org/computer-networks/what-is-p2p-peer-to-peer-
process/ 
27. Peer to Peer (p2p) Network - Blockchain Council, acessado em setembro 26, 
2025, https://www.blockchain-council.org/blockchain/peer-to-peer/ 
28. What is a Peer to Peer Network? Blockchain P2P Networks Explained - YouTube, 
acessado em setembro 26, 2025, 
https://www.youtube.com/watch?v=ie-qRQIQT4I 
29. p2p-sip - Google Code, acessado em setembro 26, 2025, 
https://code.google.com/archive/p/p2p-sip 
30. Enhancing Crypto Exchange Security Through P2P Blockchain Architecture - 
Debut Infotech, acessado em setembro 26, 2025, 
https://www.debutinfotech.com/blog/crypto-exchange-security-p2p-blockchain 
31. What is a distributed hash table (DHT)? - Milvus, acessado em setembro 26, 2025, 
https://milvus.io/ai-quick-reference/what-is-a-distributed-hash-table-dht 
32. Distributed hash table - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Distributed_hash_table 
33. Distributed Hash Table (DHT) In Structured Peer-to-Peer SIP Overlay | Real Time 
Magazine, acessado em setembro 26, 2025, 
https://voipmagazine.wordpress.com/2015/07/19/distributed-hash-table-dht-in-p
eer-to-peer-sip-overlay/ 
34. Peer-to-peer SIP user registration. | Download Scientific Diagram - 
ResearchGate, acessado em setembro 26, 2025, 
https://www.researchgate.net/figure/Peer-to-peer-SIP-user-registration_fig4_22
4347638 
35. P2P-SIP Using an External P2P network (DHT) - PPT - SlideServe, acessado em 
setembro 26, 2025, 
https://www.slideserve.com/espillman/p2p-sip-using-an-external-p2p-network-d
ht-powerpoint-ppt-presentation 
36. Simple basic explanation of a Distributed Hash Table (DHT) - Stack Overflow, 
acessado em setembro 26, 2025, 
https://stackoverflow.com/questions/144360/simple-basic-explanation-of-a-distri
buted-hash-table-dht 
37. Inter-working of P2P-SIP and Traditional SIP Network - Communication Systems 
Group | UZH, acessado em setembro 26, 2025, 
https://vocal.com/sip/sip-user-authentication/
https://docs.oracle.com/en/industries/communications/session-border-controller/9.0.0/configuration/digest-authentication-sip1.html
https://docs.oracle.com/en/industries/communications/session-border-controller/9.0.0/configuration/digest-authentication-sip1.html
https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/8.2.0/configuration/digest-authentication-sip.html
https://docs.oracle.com/en/industries/communications/enterprise-session-border-controller/8.2.0/configuration/digest-authentication-sip.html
https://www.geeksforgeeks.org/computer-networks/what-is-p2p-peer-to-peer-process/
https://www.geeksforgeeks.org/computer-networks/what-is-p2p-peer-to-peer-process/
https://www.blockchain-council.org/blockchain/peer-to-peer/
https://www.youtube.com/watch?v=ie-qRQIQT4I
https://code.google.com/archive/p/p2p-sip
https://www.debutinfotech.com/blog/crypto-exchange-security-p2p-blockchain
https://milvus.io/ai-quick-reference/what-is-a-distributed-hash-table-dht
https://en.wikipedia.org/wiki/Distributed_hash_table
https://voipmagazine.wordpress.com/2015/07/19/distributed-hash-table-dht-in-peer-to-peer-sip-overlay/
https://voipmagazine.wordpress.com/2015/07/19/distributed-hash-table-dht-in-peer-to-peer-sip-overlay/
https://www.researchgate.net/figure/Peer-to-peer-SIP-user-registration_fig4_224347638
https://www.researchgate.net/figure/Peer-to-peer-SIP-user-registration_fig4_224347638
https://www.slideserve.com/espillman/p2p-sip-using-an-external-p2p-network-dht-powerpoint-ppt-presentation
https://www.slideserve.com/espillman/p2p-sip-using-an-external-p2p-network-dht-powerpoint-ppt-presentation
https://stackoverflow.com/questions/144360/simple-basic-explanation-of-a-distributed-hash-table-dht
https://stackoverflow.com/questions/144360/simple-basic-explanation-of-a-distributed-hash-table-dht
https://www.csg.uzh.ch/csg/dam/jcr:ffffffff-e8de-0d6a-0000-0000276359e7/bal
astefan.pdf 
38. Distributed Hash Tables with Kademlia - Code the Change - Stanford, acessado 
em setembro 26, 2025, 
https://codethechange.stanford.edu/guides/guide_kademlia.html 
39. Kademlia - Wikipedia, acessado em setembro 26, 2025, 
https://en.wikipedia.org/wiki/Kademlia 
40. A formal specification of the Kademlia distributed hash table - Universidad 
Complutense de Madrid, acessado em setembro 26, 2025, 
http://maude.sip.ucm.es/kademlia/files/pita_kademlia.pdf 
41. Distributed Hash Tables with Kademlia - GeeksforGeeks, acessado em setembro 
26, 2025, 
https://www.geeksforgeeks.org/system-design/distributed-hash-tables-with-kad
emlia/ 
42. Distributed Hash Tables (DHT) - IPFS Docs, acessado em setembro 26, 2025, 
https://docs.ipfs.tech/concepts/dht/ 
43. What is libp2p, acessado em setembro 26, 2025, 
https://docs.libp2p.io/concepts/introduction/overview/ 
44. libp2p - IPFS Docs, acessado em setembro 26, 2025, 
https://docs.ipfs.tech/concepts/libp2p/ 
45. libp2p, acessado em setembro 26, 2025, https://libp2p.io/ 
46. Who uses libp2p, acessado em setembro 26, 2025, 
https://docs.libp2p.io/concepts/introduction/users/ 
47. How to Build a Decentralized Network with Go-libp2p | by HackerHub - Medium, 
acessado em setembro 26, 2025, 
https://medium.com/@hackerhub/building-a-decentralized-network-using-go-lib
p2p-ccb54bc86f43 
48. The Rise of DePIN and its Impact on Web3 - BNB Chain Blog, acessado em 
setembro 26, 2025, 
https://www.bnbchain.org/en/blog/the-rise-of-depin-and-its-impact-on-web3 
49. Understanding the Power of DePINs and Their Real World Applications | by Chain 
- Medium, acessado em setembro 26, 2025, 
https://medium.com/@chaincom/understanding-the-power-of-depins-and-their
-real-world-applications-61c61e9c5eae 
50. The Future of Web3's DePIN Protocols Could Change Everything, acessado em 
setembro 26, 2025, https://news.lever.io/depin-crypto-web3/ 
51. Peer-to-Peer Session Initiation Protocol (p2psip) (WG) - IETF, acessado em 
setembro 26, 2025, https://www.ietf.org/proceedings/94/p2psip.html 
52. RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol, acessado 
em setembro 26, 2025, https://www.rfc-editor.org/rfc/rfc6940.html 
53. A SIP Usage for RELOAD, acessado em setembro 26, 2025, 
https://www.potaroo.net/ietf/all-ids/draft-ietf-p2psip-sip-12.html 
54. RFC 7904 - A SIP Usage for REsource LOcation And Discovery (RELOAD), 
acessado em setembro 26, 2025, https://datatracker.ietf.org/doc/rfc7904/ 
55. draft-ietf-p2psip-sip-19 - A SIP Usage for RELOAD - IETF Datatracker, acessado 
https://www.csg.uzh.ch/csg/dam/jcr:ffffffff-e8de-0d6a-0000-0000276359e7/balastefan.pdf
https://www.csg.uzh.ch/csg/dam/jcr:ffffffff-e8de-0d6a-0000-0000276359e7/balastefan.pdf
https://codethechange.stanford.edu/guides/guide_kademlia.html
https://en.wikipedia.org/wiki/Kademlia
http://maude.sip.ucm.es/kademlia/files/pita_kademlia.pdf
https://www.geeksforgeeks.org/system-design/distributed-hash-tables-with-kademlia/
https://www.geeksforgeeks.org/system-design/distributed-hash-tables-with-kademlia/
https://docs.ipfs.tech/concepts/dht/
https://docs.libp2p.io/concepts/introduction/overview/
https://docs.ipfs.tech/concepts/libp2p/
https://libp2p.io/
https://docs.libp2p.io/concepts/introduction/users/