إصلاح جودة مكالمات الفيديو في Nextcloud Talk واتصال خادم TURN

غالبًا ما تُوصف مشاكل مكالمات Nextcloud Talk بأنها "جودة فيديو رديئة"، لكن الأسباب الكامنة وراءها ليست متطابقة. فقد يمتلك المستخدم نطاقًا تردديًا كافيًا ومع ذلك يفشل في الاتصال لأن جدار الحماية يحظر حركة مرور WebRTC من نظير إلى نظير. وقد تنجح مكالمة أخرى عبر TURN ولكنها تبدو أبطأ لأن جميع الوسائط يتم نقلها. وقد يواجه اجتماع كبير صعوبة حتى مع وجود خادم TURN يعمل بكفاءة تامة لأن النظام لا يزال يستخدم بنية نظير إلى نظير المدمجة بدلًا من الواجهة الخلفية عالية الأداء.

لذا، فإنّ أنجع طريقة لحلّ المشكلات هي فصل الاتصال ، ومسار الوسائط ، وقابلية التوسع . اعتبارًا من 6 أكتوبر 2026، لا تزال وثائق Nextcloud Talk الأصلية تصف TURN كخيار احتياطي عند تعذّر الاتصال المباشر بـ WebRTC، وتوصي باستخدام المنفذ 443 لتحقيق أقصى قدر من التوافق. كما تشير إلى أنه قد يظلّ خادم TURN مطلوبًا عند استخدام الواجهة الخلفية عالية الأداء. راجع وثائق Nextcloud Talk TURN الرسمية ودليل إعداد coturn الرسمي لـ Talk .

ما الذي يجب عليك إصلاحه أولاً: عرض النطاق الترددي، أو TURN، أو الواجهة الخلفية عالية الأداء؟

استخدم نمط الأعراض لاختيار الإجراء التالي بدلاً من تغيير عدة إعدادات في وقت واحد.

الخطوة 1: تحديد ما إذا كان العطل ناتجًا عن الاتصال أو جودة الوسائط

ابدأ باختبارين قصيرين. أولًا، قم بإجراء مكالمة بين عميلين على شبكات بسيطة، مثل اتصالين عاديين بالإنترنت عريض النطاق. ثم كرر العملية من شبكة مقيدة، مثل شبكة Wi-Fi خاصة بالشركة، أو شبكة VPN، أو نقطة اتصال محمولة. إذا فشلت المكالمة على الشبكة المقيدة فقط، فمن المرجح أن يكون السبب هو TURN. أما إذا نجحت كلتا المكالمتين ولكن جودة الفيديو رديئة، فاجمع بيانات الشبكة والجهاز قبل تغيير بنية الترحيل.

تُحاول آلية الاتصال الموثقة في Nextcloud أولاً الاتصال المباشر بين الأجهزة، وتستخدم بروتوكول STUN لاكتشاف العناوين المتاحة، وتعتمد على بروتوكول TURN عندما يتعذر إنشاء مسار مباشر. هذا يعني أن TURN هو في الأساس خيار احتياطي للاتصال ، وليس مُحسِّنًا شاملاً لجودة الفيديو. قد يكون المسار المُرحَّل أكثر موثوقية، ولكنه أطول ويُحمِّل خادم TURN عرض النطاق الترددي للوسائط.

الخطوة الثانية: إعداد coturn لـ Nextcloud Talk

بالنسبة لعمليات النشر ذاتية الاستضافة، يُعدّ coturn أكثر تطبيقات TURN شيوعًا والموثّقة من قِبل Nextcloud. توصي Nextcloud باستخدام مصادقة المفتاح المشترك لهذا التكامل. أنشئ مفتاحًا عشوائيًا قويًا واستخدم القيمة نفسها في كلٍّ من coturn وإعدادات إدارة Talk.

openssl rand -hex 32

يتضمن التكوين الأدنى عادةً منفذ استماع، وبصمة رقمية، ومصادقة باستخدام مفتاح مشترك، ونطاق، وقيود على النظراء. يعتمد موقع الملف الدقيق على نظام التشغيل وحزمة البرامج المستخدمة. مثال على التكوين:

listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peers

قد تتطلب إصدارات coturn القديمة خيارات لم تعد الإصدارات الأحدث بحاجة إليها، لذا تجنب نسخ الإعدادات القديمة دون تدقيق. توضح وثيقة Nextcloud coturn المُحدّثة باستمرار التوجيهات التي تعتمد على الإصدار بشكلٍ صريح. تحقق من إصدار coturn المُثبّت لديك وقارنه بتعليمات Nextcloud coturn الحالية .

إذا كان برنامج Coturn خلف جدار حماية NAT، فقم بضبط ربط عناوين الشبكة العامة بالخاصة بشكل صحيح. يشرح مرجع تكوين Coturn هذا external-ipالربط، ويتطلب أن تعمل منافذ الترحيل بشكل متسق عبر جدار الحماية NAT. راجع مثال تكوين Coturn الخاص بالشبكة الرئيسية .

UDP أو TCP أو TLS: أيها يجب عليك تفعيله؟

بالنسبة للوسائط في الوقت الفعلي، يُعد بروتوكول UDP عادةً الخيار الأمثل لأنه يتجنب إعادة إرسال TCP وحظر رأس الطابور. مع ذلك، تحظر بعض شبكات المؤسسات والضيوف بروتوكول UDP تمامًا. يمكن لبروتوكول TCP أو TURN عبر TLS أن يوفرا حلاً بديلاً عمليًا عبر الشبكات التي تسمح فقط بحركة مرور شبيهة بحركة مرور الويب.

لتحقيق أقصى قدر من إمكانية الوصول، توصي Nextcloud بالاستماع على المنفذ 443 وتدعم بروتوكول TURN/TLS. استخدام كليهما turn:يُحسّن turns:التوافق، ولكنه يتطلب أيضًا إدارة الشهادات ومسارات نقل إضافية. إذا كان جميع المستخدمين على شبكات مُدارة حيث يعمل بروتوكول UDP بشكل صحيح، فقد يكون تصميم UDP أولًا أبسط وأسهل في التشغيل. أما إذا كان المستخدمون يتصلون بانتظام من الفنادق أو مواقع العملاء أو المكاتب المغلقة أو شبكات VPN، فإن استخدام TCP/TLS كخيار احتياطي يستحق عادةً التكوين الإضافي.

الخطوة 3: افتح منافذ الاستماع والترحيل بشكل صحيح

من الأخطاء الشائعة فتح منفذ الاستماع الخاص بـ TURN فقط. يتصل العميل أولاً بـ coturn عبر منفذ الاستماع الخاص به، ولكن coturn يخصص أيضًا نقاط نهاية ترحيل للوسائط. تستخدم الإعدادات الافتراضية لـ coturn منافذ UDP 49152-65535لتخصيص نقاط نهاية الترحيل. إذا تم حظر هذا النطاق بواسطة جدار حماية المضيف، أو مجموعة أمان السحابة، أو جهاز التوجيه الخاص بالخادم، أو جهاز NAT، فقد تنجح عملية المصادقة بينما تفشل عملية إرسال الوسائط.

يمكنك الاحتفاظ بنطاق الترحيل الافتراضي أو تقليصه عمدًا باستخدام خياري min-port`and` max-port. المفاضلة واضحة: النطاق الواسع سهل التشغيل ويوفر سعة تخصيص كبيرة؛ أما النطاق الضيق فيسهل وصفه في سياسة جدار الحماية، ولكنه قد يُصبح عنق زجاجة في السعة إذا احتاج عدد كبير جدًا من عمليات الترحيل المتزامنة إلى منافذ. حدد نطاقًا مُصغّرًا بناءً على التزامن المتوقع بدلًا من اختيار رقم صغير عشوائي.

إذا كان لدى مضيف TURN عنوان IP خاص خلف جهاز توجيه، فاحتفظ بربط المنافذ بشكل فردي لنطاق الترحيل المحدد، وقم بتعيين ربط العنوان العام في coturn. أما إذا كان لدى المضيف عنوان IP عام مباشرةً على واجهته، فإن خطوة ربط NAT غير ضرورية.

الخطوة 4: أضف خادم TURN في Nextcloud Talk

افتح لوحة تحكم Nextcloud وانتقل إلى إعدادات Talk. أضف خادم TURN باستخدام اسم المضيف والمنفذ فقط، وليس عنوان URL http://أو https://رابط URL. تشير وثائق Talk الحالية في Nextcloud إلى أن نظام TURN يُحدد بشكل منفصل، لذا يجب أن يكون حقل الخادم بالصيغة التالية turn.example.com:443: .

أدخل نفس السر المشترك المُهيأ في coturn، وفعّل البروتوكولات التي يقبلها خادمك فعليًا. إذا كنت تستخدم TLS، فاختر مخطط TURN المناسب، وتأكد من تطابق الشهادة مع اسم مضيف TURN. يمكنك أيضًا استخدام خدمة TURN الخاصة بك كخادم STUN، مما يُسهّل إدارة المضيف، مع العلم أن فصل STUN وTURN قد يكون مفيدًا عند الحاجة إلى نطاقات أعطال مستقلة أو مُرحِّلات موزعة جغرافيًا.

لا تكشف عن السر المشترك في لقطات الشاشة أو التذاكر أو أمثلة التكوين العامة. يستخدمه Nextcloud لاستخلاص بيانات اعتماد TURN مؤقتة للعملاء.

الخطوة 5: اختبار المرشحين لـ ICE، ثم الاختبار من شبكة مقيدة

بعد حفظ إعدادات Talk، استخدم فحص الإدارة للتحقق مما إذا كان خادم TURN يُعيد مرشحين صالحين لبروتوكول ICE. تُثبت النتيجة الناجحة أن المتصفح قد حصل على مرشحين صالحين من خدمة TURN المُكوّنة. لكن هذا لا يضمن الأداء الجيد لجميع شبكات المستخدمين، أو مسارات الترحيل، أو المكالمات الكبيرة.

أعد إجراء مكالمة حقيقية من شبكة واحدة على الأقل ذات قيود صارمة. هذا الأمر مهم لأن فحص الخادم قد ينجح بينما لا تزال شبكة المستخدم تحظر بروتوكول UDP أو تحليل DNS أو بروتوكول نقل معين. إذا فشل بروتوكول UDP ولكن نجح بروتوكول TCP/TLS على المنفذ 443، فاحتفظ بمسار النسخ الاحتياطي. إذا فشلت جميع المسارات، فافحص سجلات جدار الحماية، وسجلات coturn، ونظام أسماء النطاقات (DNS)، وصلاحية الشهادة، والمفتاح السري المشترك، وتعيين NAT.

متى يجب إضافة الواجهة الخلفية عالية الأداء؟

يُعالج كلٌّ من TURN والخادم الخلفي عالي الأداء مشكلاتٍ مختلفة. يقوم TURN بإعادة توجيه البيانات عندما يتعذر على العملاء إنشاء مسار WebRTC المطلوب. أما الخادم الخلفي عالي الأداء فيُغيّر طريقة معالجة الوسائط متعددة المشاركين، بحيث لا يضطر كل مشارك إلى تحميل بث منفصل لكل مشارك آخر.

تحذر واجهة Talk الخاصة بـ Nextcloud من أن التشغيل بدون الواجهة الخلفية عالية الأداء مُصمم فقط للمكالمات الصغيرة جدًا، والتي يُشار إليها عادةً في المشروع بأنها تضم ​​من اثنين إلى ثلاثة مشاركين. إذا ظهرت مشكلتك فقط مع ازدياد عدد المشاركين، فقد يؤدي إضافة TURN إلى زيادة عدد العملاء الذين يمكن الوصول إليهم، ولكنه لن يُزيل عبء التحميل من نظير إلى نظير واستهلاك وحدة المعالجة المركزية. راجع متطلبات نظام Nextcloud Talk وإرشادات الواجهة الخلفية عالية الأداء الخاصة بالمشروع قبل توسيع نطاق المكالمات الجماعية.

حتى مع وجود نظام خلفي عالي الأداء، يجب إبقاء بروتوكول TURN متاحًا عند اتصال المستخدمين من شبكات ذات قيود. توثق Nextcloud نطاق وسائط WebRTC الافتراضي 20000-40000للنظام الخلفي، وتشير تحديدًا إلى أن العميل المقيد بالمنفذ 443 قد يحتاج إلى بروتوكول TURN لإعادة توجيه الحزم إلى نطاق النظام الخلفي هذا.

TURN المُستضاف ذاتيًا مقابل TURN المُدار

قائمة التحقق العملية لضبط الآلات

• يفضل استخدام WebRTC المباشر كلما أمكن ذلك. فهو عادةً ما يقلل من تكلفة الترحيل وزمن الاستجابة.
• وفر بروتوكول TURN لضمان الموثوقية. اعتبره مسارًا احتياطيًا في حالات صعوبة ترجمة عناوين الشبكة (NAT) وجدران الحماية.
• استخدم بروتوكول UDP أولاً، ثم بروتوكول TCP/TLS لضمان التوافق. يُعد المنفذ 443 الخيار الأمثل للاستماع، وهو الأنسب لجدار الحماية، وفقًا لتوصيات Nextcloud.
• افتح نطاق الترحيل، وليس فقط نطاق الاستماع. طابق قواعد جدار الحماية وNAT مع التكوين min-portالفعلي max-port.
• راقب عرض النطاق الترددي لشبكة TURN. يمكن للمكالمات المُعاد توجيهها أن تنقل كمية كبيرة من بيانات الوسائط عبر مضيف TURN، لذا فإن سعة الشبكة غالباً ما تكون أهم من وحدة المعالجة المركزية.
• افصل بين مشاكل التوسع ومشاكل الاتصال. بالنسبة للاجتماعات الكبيرة، قيّم أداء الواجهة الخلفية العالية بدلاً من زيادة حركة البيانات عبر شبكة TURN.
• تحقق من صحة النتائج باستخدام شبكات المستخدمين الحقيقيين. اختبار ICE ضروري، ولكن قد تختلف سلوكيات شبكات الفنادق والشركات وشبكات VPN وشبكات الهاتف المحمول.

خلاصة القول

إذا كان Nextcloud Talk يعمل على بعض الشبكات دون غيرها، فقم بتهيئة خدمة TURN قابلة للوصول بشكل صحيح، وتحقق من المُستمع، والمفتاح السري المشترك، وتعيين NAT، ومنافذ الترحيل. إذا كانت المكالمات متصلة ولكن بجودة رديئة، فقم أولاً بقياس حمل شبكة العميل ونقطة النهاية، لأن TURN قد يزيد من زمن الاستجابة بدلاً من تقليله. إذا تفاقمت المشكلة مع ازدياد عدد المشاركين، فإن الحل المعماري الأنسب عادةً ما يكون استخدام نظام خلفي عالي الأداء، مع الإبقاء على TURN كخيار توافق للشبكات ذات القيود.