المفاهيم الأساسية
يوفر هذا القسم نظرة عامة على المفاهيم الأساسية لتطبيق 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 بهذا المحرك.
تحذير
تقتصر هذه الميزة حاليًا على الصوت ولا تدعم تحسين الفيديو.
تدعم هذه الميزة المنتجات والقنوات التالية من تطبيق Zoom Web:
Zoom Phone
مركز الاتصال Zoom
موصل CTI لمركز الاتصال Zoom
تدعم هذه الميزة حاليًا منصات سطح المكتب الافتراضي التالية:
Citrix
Omnissa Horizon
راجع مركز دعم Zoom لمزيد من المعلومات حول تكوين Zoom VDI لدعم إعادة توجيه WebRTC لتطبيق Zoom Web.
يقوم تطبيق Zoom Web بتفريغ صوت WebRTC الخاص بـ VDI إلى الجهاز المحلي
عندما يحاول تطبيق 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 إضافية على الجهاز المحلي أو متطلبات معالجة من خادم سطح المكتب الافتراضي.
آخر تحديث
هل كان هذا مفيدا؟