تحسين الشبكة لخدمة Google Voice

تسمح البنية الأساسية للشبكة المتوافقة مع السحابة الإلكترونية لعدد زيارات Voice بالتواصل بكفاءة مع بنية Google الأساسية. لإنشاء هذا:

• يُرجى التأكُّد من أن زيارات Google Voice لها مسار مختصر للإنترنت. وعليك تجنُّب:
  • الخوادم الوكيلة
  • فحص الحزم أو أدوات تحليل البروتوكول
• يُرجى قياس وتحسين:
  • وقت الاستجابة: تأخير بحد أقصى 150 ملي ثانية في اتجاه واحد (ITU G114)
  • معدل نقل البيانات: الإعداد المُقترح هو 50 كيلو بت في الثانية.
  • شبكة Wi-Fi: يُرجى الاطِّلاع على أفضل ممارسات شبكة WiFi

ننصح بشدة بعدم استخدام شبكتك لخوادم وكيلة لعدد زيارات Voice:

• في إعدادات الخادم الوكيل، أضِف عدد زيارات Voice إلى قائمة مسموح بها.
• لا يعود Voice إلى بروتوكول TCP كما يفعل Google Meet. ولا يستخدم تطبيق Voice بروتوكول حزم بيانات المستخدم (UDP) إلا لعدد زيارات Voice.
• يؤدي إنشاء خوادم وكيلة لعدد الزيارات إلى إطالة وقت الاستجابة وقد يتسبب في تخفيض جودة الصوت تلقائيًا في Voice. يكون أداء Voice مثاليًا عندما يكون وقت الاستجابة بين العميل وطبقة الوصول إلى البيانات في البنية البرمجية من Google أقل من 100 ملي ثانية.
• بروتوكول الإنترنت للمنافذ الآمنة (SOCKS5) غير مدعوم.

في حال كان ذلك ممكنًا، لا تستخدم فحص الحزم أو أدوات تحليل البروتوكول لتطبيق Voice. فهي تزيد من وقت الاستجابة الذي قد يتسبب في تقليل جودة الصوت تلقائيًا في البنية الأساسية لخدمة Voice.

لا يفيد فحص حِزم البيانات الصوتية كثيرًا لأنّ أدوات الفحص الآلي لا يمكنها إعادة إنشاء بيانات البث الصوتي.

في حال استخدام هذه الأدوات، أضِف جميع أرقام منافذ حركة بيانات Voice إلى قائمة مسموح بها لتجاوز الأدوات.

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

قد يصعُب تشغيل تطبيقات الوقت الفعلي على شبكة لاسلكية ويرجع ذلك إلى مشاركة معدل نقل البيانات وطيف ترددات اللاسلكي الأساسي بين جميع الأجهزة التي تستخدمهما.

يُرجى مراجعة الاعتبارات التالية بتأنٍ أثناء تصميم الشبكات اللاسلكية المستخدمة مع تطبيق Voice ونشرها وتشغيلها.

نطاقات تردد لاسلكي بقوة 2.4 غيغاهرتز مقابل 5 غيغاهرتز

ننصح بشكل عام بعدم نشر تطبيقات الوقت الفعلي على نطاق بقوة 2.4 غيغاهرتز (المستخدم بكثرة عادةً) لشبكة لاسلكية أو تشغيلها عليه. يتضمّن هذا الاقتراح التطبيقات التي توفّر إمكانية الاتصال في بيئة مكتبية عادية.

ينطوي النطاق الذي يعمل بقوة 2.4 غيغاهرتز على مشاكل بسبب عدم احتوائه إلا على 3 قنوات غير متراكبة، وتعرضه عادةً لمستويات تشويش عالية من الشبكات المتداخلة القريبة، والتداخل الإضافي من الأجهزة الأخرى (مثل الميكروويف)، مما يؤدي إلى إنشاء بيئة ترددات لاسلكية (RF) معقدة ومشوشة.

يعتمد التشغيل الموثوق للتطبيقات في الوقت الفعلي، مثل Voice، على مستويات كافية من السعة والتأخير والارتعاش وفقدان الحِزم، وهو أمر يكاد يكون من المستحيل تحقيقه عبر النطاق الترددي 2.4 غيغاهرتز.

اعتبارات التصميم والنشر

في حال صمّمت شبكة لاسلكية لتدعيم تطبيقات الوقت الفعلي، ننصحك بالتفكير في السعة بدلاً من التغطية.

• يمكنك معالجة حجم الخلية التي تتحكَّم بها قوة إرسال نقطة الوصول (AP). انشر خلايا أصغر حيث يحتمل وجود مزيد من الأجهزة، مثل غرف الاجتماعات وقاعات المؤتمرات لزيادة السعة. يمكن للخلايا الأكبر تقديم تغطية عامة في طابق المكتب.
• أوقف المعدلات المنخفضة لتحسين كفاءة استخدام التردد اللاسلكي. يؤدي ذلك إلى فرض نقل البرنامج إلى أقرب نقطة وصول أثناء التجوال بين نقاط الوصول.

في حال توفر SSID لشبكة لاسلكية على كلا النطاقين (2.4 غيغاهرتز و5 غيغاهرتز)، يجب أن تفرض الشبكة على البرامج استخدام نطاق 5 غيغاهرتز.

• من المتوقع ألا يزيد عدد الهواتف المكتبية المتصلة بنقطة الوصول نفسها عن 10 هواتف. وقد يؤدي استخدام عدد أكبر إلى تقديم تجربة مستخدم غير متوقعة.
• يجب عدم استخدام الهواتف المكتبية المتصلة لاسلكيًا من قِبل الفِرق التي تستخدم المكالمات الصوتية بكثافة عالية، مثل الوكلاء أو فِرق الدعم. على سبيل المثال، المواقع الإلكترونية الحكومية أو مراكز الاتصال التي تعمل على مدار الساعة.
• من المتوقّع حدوث انقطاعات قصيرة في الصوت، أقل من 10 ثوانٍ، ولا يمكن التخلص منها على مستوى الشبكة للهواتف المكتبية المتصلة لاسلكيًا. لا ننصح باستخدام الشبكات اللاسلكية لإجراء مكالمات هاتفية مهمة، مثل المؤتمرات أو الاجتماعات الصحفية أو المكالمات التنفيذية.
• على الرغم من اختلاف اللوائح التنظيمية حسب البلدان أو المناطق، فإنّ أحد المتطلبات الشائعة هو أن تتأكّد أجهزة Wi-Fi التي تستخدم قنوات DFS من أنّها لن تتداخل مع نظام رادار الطقس المحلي، على سبيل المثال. ونتيجة لذلك، ستُفرِغ نقطة الوصول المُعرَّضة لتداخل الرادار القناة. على جميع العملاء إعادة الاتصال بنقطة وصول أخرى تعمل على قناة أخرى.

من أجل السماح بالميزات المتقدمة، مثل التجوال المستمر بين نقاط الوصول وإدارة صحيحة للتردد اللاسلكي، يجب إدارة شبكة لاسلكية مركزيًا وتشغيلها - وليس مجموعة نقاط وصول منعزلة ومستقلة.

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

يتم تأمين عدد الزيارات في Voice وتشفيرها، لذلك ليس هناك حاجة إلى تقييد عدد الزيارات إلى عناوين IP التي يستخدمها Google.

في حال كانت هناك قيود على الشبكة تتطلب تقييد عدد الزيارات، يمكنك وضع المجموعة التالية من نطاقات عناوين IP في القائمة المسموح بها للسماح بخوادم وسائط Voice. تُستخدم عناوين IP حصريًا في خدمة Voice لمستخدمي Google Workspace حتى تتمكّن من تحديد البيانات الصوتية المنقولة في Google Workspace وتخفيض أولوية زيارات Voice من حسابات المستهلكين. وقد يساعد ذلك في إعداد الوصول إلى جدار الحماية والشبكة وتحسينهما بشكل أفضل.

• IPv4: 74.125.39.0/24
• IPv6: 2001:4860:4864:2::0/64

يُرجى إعداد شبكتك بحيث تسمح المنافذ التالية بتدفق البيانات الصوتية المنقولة من مؤسستك وإليها:

• منافذ UDP الصادرة من 19302 حتى 19309
• منفذ TCP الصادر 443

ملاحظة: يستخدم نطاق منافذ Voice من 19302 إلى 19309 إعداد منافذ Chrome WebRTC UDP. لمزيد من المعلومات، يُرجى الاطّلاع على مقالة ضبط سياسات Chrome للمستخدمين أو المتصفِّحات.