المفاهيم الأساسية
يوفر هذا القسم نظرة عامة على المفاهيم الأساسية لتطبيق Zoom Workplace VDI.
أوضاع تحسين المكون الإضافي
يدعم تطبيق Zoom Workplace VDI ثلاثة أوضاع تشغيل لمعالجة الوسائط في الوقت الفعلي: التحسين المباشر، والتحسين عبر القناة، ووضع الرجوع
في سياق تطبيق Zoom Workplace VDI، تشير معالجة الوسائط في الوقت الفعلي إلى ترحيل وعرض الوسائط في الوقت الفعلي بين Zoom سحابة، وتطبيق Zoom Workplace VDI، و/أو المكون الإضافي. ولدعم مجموعة من حالات استخدام VDI، يدعم تطبيق Zoom Workplace VDI ثلاثة أوضاع تشغيل مميزة لمعالجة الوسائط وتحسينها: وضع التحسين المباشر، ووضع التحسين عبر قناة، ووضع الرجوع. وتتم مناقشة هذه الأوضاع في الأقسام التالية.
وضع التحسين المباشر: عندما يتلقى تطبيق Zoom Workplace VDI والمكون الإضافي تدفقات بيانات مستقلة من Zoom سحابة
يُعد وضع التحسين المباشر وضع التحسين افتراضي لتطبيق Zoom Workplace VDI والمكون الإضافي. في هذا الوضع، يحتفظ Zoom سحابة بتدفقَي بيانات منفصلين لمستخدم VDI محسّن: أحدهما لتطبيق Zoom Workplace VDI والآخر للمكون الإضافي. ويتيح هذا التكوين للعميل البعيد الخاص بالمستخدم (المجهز بمكون VDI إضافي) التواصل مباشرة مع Zoom سحابة لنقل بيانات الوسائط في الوقت الفعلي، مما يلغي الحاجة إلى توجيه معظم حركة مرور الوسائط في الوقت الفعلي عبر سطح المكتب الافتراضي أو عبر القناة الافتراضية.
عند التشغيل في وضع التحسين المباشر، يحدث ما يلي:
يتلقى المكون الإضافي تدفقات بيانات الفيديو و صوت مباشرة من السحابة.
يتولى تطبيق Zoom Workplace VDI بيانات الاجتماع العامة، مثل معلومات المشارك، أو رسالة دردشة، أو ميزات AI Companion، ويعرضها داخل العنصر النائب لتطبيق Workplace، مع إدارة مشاركة الشاشة الواردة أيضًا من خلال إعادة توجيهها إلى المكون الإضافي وتحميل محتوى مشاركة الشاشة المحلي من سطح المكتب الافتراضي عندما يكون نشط.
يستخدم المكون الإضافي وسطح مكتب VDI الاتصال الافتراضي الخاص بمورد VDI للتواصل وتحديد موضع الوسائط المعروضة على شاشة وعرضها بين الطبقتين.
وضع التحسين عبر القناة: عندما يتلقى المكون الإضافي بيانات معاد تمريرها عبر سطح المكتب الافتراضي
يشبه التحسين عبر القناة تجربة التحسين المباشر، حيث يستمر المكون الإضافي في عرض وسائط الاجتماع (كما يظهر في الصورة أعلاه)، ولكن عبر مسار شبكة مختلف. في هذا الوضع، يحدث ما يلي:
يتم أولاً تسليم جميع وسائط الاجتماع إلى خادم VDI من Zoom سحابة.
ينقل خادم VDI الوسائط إلى المكون الإضافي إما عبر اتصال UDP خارج النطاق أو من خلال القناة الافتراضية الحالية لـ VDI إذا تعذر إنشاء اتصال UDP.
قد تُفضّل المؤسسات هذه الطريقة التي لا تقوم بـ تمكين الوصول المباشر إلى الإنترنت للعملاء النحيفين (أو الأجهزة البعيدة الأخرى)، أو التي تفضّل توجيه البيانات عبر شبكتها، ولكن يمكن أن من المحتمل تؤدي إلى تجربة أسوأ من التحسين المباشر إذا كانت ظروف توجيه الشبكة غير مثالية. توضح الصورة أدناه تدفق بيانات تحسين UDP/القناة.
وضع الرجوع: عندما يتم توجيه جميع وسائط الاجتماع إلى سطح المكتب الافتراضي ومعالجتها مباشرة عليه
يمثل وضع الرجوع تجربة VDI غير محسّنة بالكامل. في هذا الوضع، لا يتم استخدام أي تحسين للوسائط أو مكون إضافي، وتحدث جميع الاتصالات مباشرة بين خادم VDI وZoom سحابة، مع تنفيذ جميع عمليات المعالجة حصريًا على خادم VDI.
تفرض هذه الطريقة عبئًا كبيرًا على موارد معالجة خادم VDI، مما يؤدي غالبًا إلى أداء ضعيف، بما في ذلك البطء، والفيديو المتقطع، و صوت المشوه. لذلك، يُعد وضع الرجوع الخيار الأقل تفضيلًا ويجب استخدامه فقط كحل أخير أو عندما تكون المكونات الإضافية غير متوفرة.
تحذير
يجب تجنب وضع الرجوع متى أمكن للحفاظ على أداء الخادم.
ملخص أوضاع الاتصال
يدعم تطبيق Zoom Workplace VDI ثلاثة أوضاع اتصال مميزة، صُمم كل منها لتلبية احتياجات تشغيلية وأمنية مختلفة. الوضع افتراضي والأكثر كفاءة هو وضع التحسين المباشر، حيث ينشئ تطبيق Zoom Workplace VDI والمكون الإضافي اتصالات منفصلة مع Zoom سحابة، ويتولى كل منهما بشكل مستقل الجزء الخاص به من اجتماع Zoom لتقديم تجربة سلسة ومحسّنة.
بالإضافة إلى وضع التحسين المباشر، يمكن لتطبيق Zoom Workplace VDI العمل في تكوينات بديلة، بما في ذلك وضع التحسين عبر القناة ووضع الرجوع. ويمكن أن تساعد هذه الأوضاع في معالجة قيود محددة في سير العمل أو الشبكة، مثل تقييد الوصول إلى الإنترنت للأجهزة البعيدة، أو توجيه البيانات بسبب مخاوف الخصوصية، أو غياب المكونات الإضافية.
يلخص الجدول التالي الفروق الرئيسية بين هذه الأوضاع.
إلغاء تحميل الوسائط
وصول مباشر إلى السحابة من المكون الإضافي
التحسين المباشر
✔
✔
التحسين عبر القناة
✔
وضع الرجوع
إلغاء تحميل وسائط WebRTC
نظرة عامة
يوفر Zoom عميل WebRTC قائمًا على المتصفح عبر تطبيق Zoom Web يمكنه إلغاء تحميل معالجة صوت إلى جهاز مستخدم المحلي عند التشغيل داخل بيئة سطح مكتب افتراضي. ويعمل هذا من دون الحاجة إلى أي مكونات إضافية خاصة بـ Zoom لأن منصة VDI توفر محرك WebRTC محليًا خاصًا بها وإطار عمل لإعادة التوجيه يربط تطبيق Zoom Web بذلك المحرك.
تحذير
يقتصر إلغاء تحميل وسائط WebRTC حاليًا على صوت ولا يدعم تحسين الفيديو.
تدعم هذه الميزة المنتجات و القنوات التالية من تطبيق Zoom Web:
Zoom Phone
Zoom مركز الاتصال
Zoom مركز الاتصال CTI الموصل
هذه الميزة مدعومة حاليًا من قبل منصات سطح المكتب الافتراضي التالية:
Citrix
Omnissa Horizon
ارجع إلى مركز الدعم الخاص بـ Zoom للحصول على مزيد من المعلومات حول تكوين Zoom VDI لدعم إعادة توجيه WebRTC لتطبيق Zoom Web.
يقوم تطبيق Zoom Web بإلغاء تحميل صوت VDI WebRTC إلى الجهاز المحلي
عندما يحاول تطبيق Zoom Web داخل سطح المكتب الافتراضي تهيئة صوت WebRTC، يتم اعتراض طلباته قبل أن يحاول سطح المكتب الافتراضي التقاط الصوت أو معالجته. وبدلاً من تنشيط مكدس وسائط WebRTC المدمج في المتصفح داخل الجلسة المستضافة، تقوم منصة VDI بترجمة الإشارات المتعلقة بالصوت إلى رسائل تحكم خفيفة. ويتم إرسال هذه الرسائل عبر القناة الافتراضية الخاصة بموفر VDI إلى الجهاز المحلي للمستخدم، مع إعادة توجيه حركة مرور صوت في الوقت الفعلي من Zoom السحابة مباشرة إلى الجهاز المحلي للمستخدم.
على الجهاز المحلي، يتلقى محرك WebRTC الأصلي المضمّن مع عميل VDI (على سبيل المثال، Citrix وOmnissa Horizon) هذه الرسائل ويصبح مسؤولًا عن جميع عمليات التقاط صوت وترميزه وفك ترميزه وتشغيله. ويستخدم المحرك ميكروفون النظام المحلي ومكبرات الصوت وموارد المعالجة، مما يساعد على ضمان عدم مرور صوت عبر خادم سطح المكتب الافتراضي.
يوضح المخطط التالي كيفية توجيه البيانات عند استخدام إلغاء تحميل وسائط WebRTC مع تطبيق Zoom Web ووكيل افتراضي مدعوم.

التفاعل بين تطبيق Zoom Web والجهاز المحلي
من منظور تطبيق Zoom Web، تظل التجربة مشابهة لجلسة WebRTC معياري. يتم ترحيل الإشارات بين تطبيق Zoom Web والواجهة الخلفية لـ Zoom عبر سطح المكتب الافتراضي، ويعكس محرك WebRTC المحلي معلمات الجلسة المتفاوض عليها. ويستمر تطبيق سطح المكتب الافتراضي في عرض واجهة Zoom — عناصر التحكم، وحالة الاجتماع، والمؤشرات — بينما يتم إنشاء صوت الفعلي في الوقت الفعلي واستهلاكه بواسطة الجهاز المحلي.
لأن رسائل الإشارة فقط هي التي تعبر القناة الافتراضية، فإن حمل النطاق الترددي منخفض وثابت، حتى في بيئات متعددة المستخدمين.
لماذا لا يلزم وجود مكوّن إضافي
العامل الرئيسي المُمكِّن هو أن عميل VDI (مثل Citrix وOmnissa Horizon) يتضمن بالفعل محرك وسائط WebRTC كاملًا قادرًا على التعامل مع صوت في الوقت الحقيقي. وبما أن طبقة إعادة التوجيه تجعل هذا المحرك يظهر أمام تطبيق Zoom Web كتنفيذ WebRTC الأساسي لديه، فلا يحتاج Zoom إلى توفير مكوّن إضافي منفصل أو صيانته. وتقوم منطقية إعادة التوجيه بربط استدعاءات واجهة برمجة التطبيقات WebRTC، والوصول إلى الجهاز، وتفاوض الجلسة من المتصفح داخل سطح المكتب الافتراضي إلى المحرك الأصلي على الجهاز المحلي.
النتيجة
يتيح هذا النهج لتجربة WebRTC القائمة على المتصفح من Zoom أن تعمل بكفاءة في بيئات VDI مع تحسين كامل للصوت. تعمل الواجهة داخل سطح المكتب الافتراضي، ولكن يتم التقاط الصوت في الوقت الحقيقي ومعالجته محليًا، مما يمنح المستخدمين تجربة مؤتمرات سريعة الاستجابة وقابلة للتوسع دون الحاجة إلى برنامج Zoom إضافي على الجهاز المحلي أو فرض متطلبات معالجة على خادم سطح المكتب الافتراضي.
Last updated
Was this helpful?

