WebRTC P2P Görüntülü ve Sesli Arama

Geliştirici Teknik Klavuzu

1. Doğrudan Uçtan Uca İletişim

HüdHüdCell, gerçek zamanlı sesli ve görüntülü görüşmeler için WebRTC (Web Real-Time Communication) standardını kullanır. WebRTC, ses ve video verilerinin merkezi bir sunucu üzerinden aktarılması yerine, iki istemci arasında doğrudan peer-to-peer (P2P) tüneller kurulmasını sağlar.

2. Sinyalleşme ve Bağlantı Kurulumu

Geleneksel WebRTC sistemleri, bağlantı kurmak için merkezi sinyalleşme sunucularına ihtiyaç duyarken, HüdHüdCell bu adımı da tamamen merkeziyetsiz hale getirmiştir:

  • GossipSub Sinyalleşmesi: Eşler, SDP (Session Description Protocol) tekliflerini ve ICE adaylarını doğrudan libp2p'nin GossipSub kanalları üzerinden takas eder.
  • Bağlantı Şifreleme: WebRTC görüşmelerinin güvenliği, yerleşik DTLS (Datagram Transport Layer Security) ve SRTP (Secure Real-time Transport Protocol) standartları ile sağlanır.
  • Sıfır İz Politikası: Görüşmenin içeriği ve tarafları sunucu disklerine asla kaydedilmez; bağlantı kapandığında izler tamamen yok olur.

3. NAT Aşımı ve STUN/TURN Servisleri

Doğrudan bağlantının kurulamadığı durumlarda NAT aşımı için STUN servislerinden yararlanılır. Ağ kısıtlamalarının çok katı olduğu simetrik NAT arkasındaki düğümlerde ise, medya paketleri güvenli ve şifreli uçtan uca (E2EE) TURN röle sunucuları üzerinden aktarılır.

1. Direct Peer-to-Peer Media Channels

For real-time audio and video communications, HudHudCell implements the industry-standard WebRTC (Web Real-Time Communication) framework. Instead of routing latency-heavy media streams through centralized relay clusters, WebRTC establishes direct peer-to-peer tunnels between devices.

2. Decentralized WebRTC Signaling

Conventional WebRTC systems depend on central signaling servers to orchestrate handshakes. HudHudCell bypasses central infrastructure by decentralizing the signaling pipeline:

  • GossipSub Handshake: SDP (Session Description Protocol) offers, answers, and ICE candidates are exchanged securely using libp2p GossipSub topics.
  • Media Encryption: Audio and video packets are encrypted end-to-end utilizing mandatory DTLS (Datagram Transport Layer Security) and SRTP (Secure Real-time Transport Protocol).
  • Zero Logs: Call metadata is never logged to cloud servers. Once the channel is closed, all session variables are discarded from active RAM.

3. NAT Traversal & STUN/TURN Setup

To establish direct links across network firewalls, HudHudCell relies on STUN queries. In strict symmetric NAT configurations where direct punching fails, media is routed through secure, end-to-end encrypted (E2EE) TURN relays.

1. قنوات إعلامية مباشرة من نظير لنظير

بالنسبة للاتصالات الصوتية والمرئية في الوقت الفعلي، تطبق HudHudCell إطار عمل WebRTC القياسي. بدلاً من توجيه تدفقات الوسائط عبر خوادم مركزية، ينشئ WebRTC أنفاقاً مباشرة لنقل البيانات من نظير لنظير بين الأجهزة.

2. إشارات WebRTC اللامركزية

تعتمد أنظمة WebRTC التقليدية على خوادم إشارات مركزية لتنسيق المصافحة. تتجاوز HudHudCell هذه البنية التحتية المركزية من خلال جعل عملية تبادل الإشارات لا مركزية بالكامل:

  • مصافحة GossipSub: يتم تبادل عروض SDP (بروتوكول وصف الجلسة) والردود ومرشحي ICE بشكل آمن عبر قنوات GossipSub الخاصة بـ libp2p.
  • تشفير الوسائط: يتم تشفير حزم الفيديو والصوت بالكامل باستخدام بروتوكولات DTLS و SRTP الإلزامية.
  • سجلات صفرية: لا يتم تسجيل البيانات الوصفية للمكالمة على خوادم سحابية. بمجرد إغلاق القناة، تُحذف جميع متغيرات الجلسة من الذاكرة (RAM).

3. اجتياز NAT وتكوين STUN/TURN

لإنشاء اتصالات مباشرة عبر جدران الحماية للشبكات، تعتمد HudHudCell على استعلامات STUN. في حالات NAT المتماثلة الصارمة حيث تفشل المصافحة المباشرة، يتم توجيه الوسائط عبر خوادم TURN مشفرة بالكامل بين الطرفين (E2EE).

1. Canaux Médias Directs Pair-à-Pair

Pour les appels vocaux et vidéo en temps réel, HudHudCell intègre le framework standard WebRTC. Plutôt que de faire transiter les flux vidéo gourmands en bande passante par des serveurs intermédiaires, WebRTC établit des tunnels directs entre les terminaux.

2. Signalisation WebRTC Décentralisée

Les implémentations WebRTC classiques nécessitent des serveurs de signalisation centralisés pour orchestrer la connexion. HudHudCell contourne ce problème en décentralisant l'intégralité du processus :

  • Négociation GossipSub: Les offres, réponses SDP (Session Description Protocol) et candidats ICE sont échangés via les canaux de publication de libp2p.
  • Chiffrement des Flux: Les flux audio et vidéo sont chiffrés de bout en bout à l'aide des protocoles DTLS (Datagram Transport Layer Security) et SRTP (Secure Real-time Transport Protocol).
  • Zéro Trace: Les métadonnées de l'appel ne sont jamais archivées sur le cloud. Dès la fin de la communication, les données de la session sont effacées de la RAM.

3. Franchissement de NAT et Serveurs STUN/TURN

Les requêtes STUN permettent d'établir des connexions directes à travers les pare-feu. Dans les cas restrictifs de NAT symétrique où le raccordement direct échoue, les flux transitent par des relais TURN chiffrés de bout en bout (E2EE).

1. Direkte Peer-to-Peer Medientunnel

Für Sprach- und Videoverbindungen in Echtzeit implementiert HudHudCell das bewährte WebRTC-Framework. Anstatt bandbreitenintensive Ströme über Server umzuleiten, baut WebRTC einen direkten Peer-to-Peer-Medientunnel zwischen den Geräten auf.

2. Dezentrales WebRTC-Signaling

Klassische WebRTC-Systeme benötigen zentrale Signal-Server für den Verbindungsaufbau. HudHudCell dezentralisiert diese Pipeline vollständig:

  • GossipSub-Handshake: Der Austausch von SDP-Dokumenten (Session Description Protocol) und ICE-Kandidaten erfolgt sicher über libp2p GossipSub-Channels.
  • Medienverschlüsselung: Audio- und Videodaten werden mittels DTLS (Datagram Transport Layer Security) und SRTP (Secure Real-time Transport Protocol) durchgehend verschlüsselt.
  • Keine Protokolle: Verbindungsdaten werden nicht auf Servern gespeichert. Nach Beendigung des Gesprächs werden alle temporären Daten im RAM sicher überschrieben.

3. NAT-Overhead & STUN/TURN-Dienste

Um Verbindungen über Router und Firewalls hinweg aufzubauen, nutzt HudHudCell STUN-Server. Scheitert dieser direkte Weg bei symmetrischem NAT, werden die Medienpakete über Ende-zu-Ende verschlüsselte (E2EE) TURN-Relay-Server geleitet.