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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• لا يتجاوز العدد المتوقّع 10 هواتف مكتبية متصلة بنقطة الوصول نفسها. وقد يؤدي استخدام عدد أكبر إلى تقديم تجربة مستخدم غير متوقّعة.
• يجب ألّا تستخدم الفِرق التي تجري عددًا كبيرًا من المكالمات الصوتية، مثل وكلاء المبيعات أو فِرق الدعم، هواتف مكتبية متصلة لاسلكيًا. على سبيل المثال، مواقع GOVO أو مراكز الاتصال التي تعمل على مدار الساعة طوال أيام الأسبوع.
• من المتوقّع حدوث انقطاعات صوتية قصيرة، أقل من 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

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