Bedrud التوثيق

كيف يؤسس العملاء اتصالات وسائط في الوقت الفعلي في بدرود. يغطي مسار الاتصال الكامل: الإشارات وICE وSTUN وTURN ومسار وسائط SFU.


نظرة عامة

يتطلب WebRTC سلسلة من الخطوات قبل أن يتدفق الصوت والفيديو بين العميل والخادم. يستخدم بدرود بنية SFU (وحدة الإرسال الانتقائي) من LiveKit - يتصل العملاء بالخادم، وليس ببعضهم. هذا يعني أن مسار الشبكة بين العميل والخادم فقط هو المهم، وليس الاتصال بين المشاركين فرديًا.

sequenceDiagram
    participant C as Client
    participant S as Bedrud Server
    participant LK as LiveKit SFU
 
    C->>S: POST /api/room/join
    S->>S: Validate permissions
    S->>C: LiveKit JWT token
 
    C->>LK: WebSocket connect (with token)
    LK->>C: Join response + SDP offer
 
    Note over C,LK: ICE Candidate Gathering
    C->>LK: Host candidates (local IPs)
    C->>LK: STUN candidates (public IPs)
    C->>LK: TURN candidates (relay addresses)
 
    alt Direct path available
        Note over C,LK: ICE/UDP - direct media
        C-->>LK: Media via UDP 50000-60000
    else UDP blocked, TURN available
        Note over C,LK: TURN - relayed media
        C-->>LK: Media via TURN relay (3478/5349)
    else Corporate firewall
        Note over C,LK: TURN/TLS - relayed via 443
        C-->>LK: Media via TLS tunnel
    end
 
    Note over C,LK: Audio/video tracks flow through SFU

مسار الاتصال

خمس طبقات تعمل معًا لتأسيس مسار الوسائط:

flowchart TB
    subgraph Layers["Connectivity Stack"]
        direction TB
        SIG["1. Signaling<br/>WebSocket - exchange SDP offers/answers"]
        ICE["2. ICE<br/>Orchestrate all candidate paths"]
        STUN["3. STUN<br/>Discover public IP/port"]
        TURN["4. TURN<br/>Relay when direct fails"]
        SFU["5. SFU<br/>Route media between participants"]
    end
 
    SIG --> ICE
    ICE --> STUN
    ICE --> TURN
    STUN --> SFU
    TURN --> SFU

تفاصيل الطبقات

١. الإشارات - يتبادل العميل والخادم بيانات الاتصال الوصفية باستخدام عروض وإجابات SDP (بروتوكول وصف الجلسة) عبر WebSocket. هذا ليس وسائط - إنه مرحلة الإعداد. يُوَجِّه بدرود الإشارات عبر خادم API إلى مثيل LiveKit المدمج.

٢. ICE (إنشاء الاتصال التفاعلي) - يجمع جميع مسارات الاتصال الممكنة، المسماة مرشحين، ويختبرها حسب الأولوية. ICE هو إطار عمل - ينسق محاولات الاتصال لكنه ليس بروتوكولًا بحد ذاته.

٣. STUN (أدوات عبور الجلسة لـ NAT) - بروتوكول خفيف. يرسل العميل طلب ربط إلى خادم STUN، الذي يرد بعنوان IP العام للعميل والمنفذ. يُختَبر هذا المرشح “الانعكاسي الخادمي” للاتصال المباشر. يعمل لحوالي 80% من الاتصالات.

٤. TURN (العبور باستخدام المرحلات حول NAT) - عندما يفشل الاتصال المباشر، يخصص TURN عنوان مرحل على الخادم. تُمرَّر جميع حزم الوسائط عبر هذا المرحل. أعلى تكلفة - عرض نطاق الخادم يزداد مع المستخدمين المُرحَّلين. راجع دليل خادم TURN للتغطية المعمقة.

٥. SFU (وحدة الإرسال الانتقائي) - بمجرد تأسيس مسار النقل، يُوجِّه SFU الخاص بـ LiveKit الوسائط بين المشاركين. يرسل كل مشارك تدفقًا واحدًا للأعلى؛ يُعيد SFU توجيه نسخ للمشاركين الآخرين. هذا ليس نظير-لنظير - الخادم دائمًا في المسار.


جمع مرشحي ICE

flowchart TD
    START[Start ICE Gathering] --> HOST
    START --> SRFLX
    START --> TURN_C
    HOST["Host candidates<br/>Local interface IPs<br/>e.g. 192.168.1.5:50001"]
    SRFLX["STUN candidates (srflx)<br/>Public IP discovered via STUN<br/>e.g. 203.0.113.5:50001"]
    TURN_C["TURN candidates (relay)<br/>Relay address on server<br/>e.g. 203.0.113.10:30001"]
    HOST --> TEST
    SRFLX --> TEST
    TURN_C --> TEST
    TEST{Test candidate<br/>connectivity}
    TEST -->|"Host works"| CONNECTED[Connected via host]
    TEST -->|"srflx works"| CONNECTED2[Connected via STUN<br/>direct P2P]
    TEST -->|"Only relay works"| CONNECTED3[Connected via TURN relay]
    TEST -->|"None work"| FAIL[Connection failed]

يجمع ICE ثلاثة أنواع من المرشحين في وقت واحد:

النوعالمصدرالأولويةطريقة العمل
hostواجهات الشبكة المحليةالأعلىIP مباشر من الجهاز. يعمل على الشبكة المحلية.
srflx (انعكاسي خادمي)استجابة خادم STUNمتوسطةعنوان IP العام المكتشف عبر STUN. يعلم لمعظم أنواع NAT.
relay (مرحل)تخصيص خادم TURNالأدنىعنوان على خادم TURN. يعمل دائمًا. أعلى تكلفة.

يختبر ICE جميع المرشحين ويختار الزوج الأعلى أولوية الذي ينجح. إذا نجح srflx، يتخطى relay.


أنواع NAT والاتصال

تؤثر أنواع NAT المختلفة على إمكانية الاتصال المباشر:

flowchart LR
    subgraph NAT1["Client A NAT"]
        direction TB
        F["Full Cone"]
        R["Restricted Cone"]
        PR["Port Restricted"]
        S["Symmetric"]
    end
 
    subgraph NAT2["Client B / Server NAT"]
        direction TB
        F2["Full Cone"]
        R2["Restricted Cone"]
        PR2["Port Restricted"]
        S2["Symmetric"]
    end
 
    F -->|"Direct"| F2
    R -->|"Direct"| R2
    PR -->|"Direct"| PR2
    S -->|"TURN required"| S2
    S -.->|"TURN required"| PR2
    PR -.->|"TURN required"| S2
 
 
نوع NATالوصفP2P مباشريحتاج TURN
مخروطي كاملجميع الطلبات من نفس IP/منفذ داخلي تُربَط بنفس IP/منفذ عام. أي مضيف خارجي يمكنه الإرسال.نعملا
مخروطي مقيدنفس الربط كالمخروطي الكامل، لكن فقط المضيفون الخارجيون الذين استلموا حزمة يمكنهم الرد.عادةًلا
مخروطي مقيد المنفذمشابه للمخروطي المقيد، لكن NAT يقيد رقم المنفذ الخارجي أيضًا. النوع الأكثر شيوعًا في موجهات المنازل.عادةًنادرًا
متماثلربط IP/منفذ عام مختلف لكل وجهة. العنوان المكتشف عبر STUN لا يمكن إعادة استخدامه.لا (عندما يكون كلاهما متماثلًا)نعم

نقطة رئيسية: بما أن الخادم يمتلك عنوان IP عام ونطاق منافذ قابل للتنبؤ، تعمل معظم أنواع NAT مباشرة. TURN مطلوب بشكل أساسي عندما يمنع جدار حماية العميل UDP الصادر بالكامل.


ملخص التهيئة

مفاتيح تهيئة بدرود/LiveKit التي تؤثر على اتصال WebRTC:

مفاتيح livekit.yaml:

rtc:
  port_range_start: 50000       # UDP media port range start
  port_range_end: 60000         # UDP media port range end
  tcp_port: 7881                # ICE/TCP fallback port
  stun_servers:                 # External STUN servers (optional)
    - stun:stun.l.google.com:19302
  use_external_ip: true         # Advertise public IP in ICE candidates
 
turn:
  enabled: true                 # Enable embedded TURN
  domain: "turn.example.com"    # TURN domain (DNS must resolve)
  udp_port: 3478                # TURN/UDP + STUN port
  tls_port: 5349                # TURN/TLS port (or 443)
  cert_file: /path/to/turn.crt  # TLS cert for TURN/TLS
  key_file: /path/to/turn.key   # TLS key for TURN/TLS
  relay_range_start: 30000      # Relay port range start
  relay_range_end: 40000        # Relay port range end
  external_tls: false           # L4 LB terminates TLS

مفاتيح config.yaml (خادم بدرود):

server:
  port: 8090                    # API port (signaling proxied through this)
  enableTLS: true               # HTTPS for signaling
  domain: "meet.example.com"    # Public domain

تصحيح مشاكل الاتصال

العَرَضالتحقق
لا يمكن الاتصال إطلاقًاهل rtc.use_external_ip: true؟ هل جدار الحماية مفتوح على 443 + نطاق UDP؟
يتصل لكن بدون صوت/فيديوهل UDP 50000-60000 محظور؟ تحقق من مرشحي ICE في المتصفح.
اتصال بطيءمرحل TURN نشط (تحقق من المرشحين). متوقع إذا كان العميل خلف NAT صارم.
يفشل خلف شبكة مؤسسيةTURN/TLS غير مُهيأ. اضبط turn.tls_port: 443 مع شهادة صالحة.
يعمل على الشبكة المحلية، يفشل عن بُعدعنوان IP العام غير مُعلَن. اضبط rtc.use_external_ip: true.

لاستكشاف مشاكل TURN بعمق، راجع دليل خادم TURN.


انظر أيضًا