> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/technical-library-ar/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md).

# اعتبارات نشر الأجهزة

توضح هذه الصفحة نشر وحدة Zoom Node ZPLS على جهاز افتراضي باستخدام برامج المراقبة الافتراضية المدعومة. وهي توفر خيارات تكوين مفصلة ومصممة لاستيعاب قدرات الأجهزة المختلفة، بما يضمن الأداء الأمثل لمختلف الاحتياجات التشغيلية.

### برامج المراقبة الافتراضية المدعومة

#### <mark style="color:أزرق;">يجب على العملاء تثبيت برنامج Zoom Node على جهاز افتراضي يعمل على برنامج مراقبة افتراضية مدعوم</mark>

باعتبارها حمل عمل Zoom Node، يجب تثبيت وحدة ZPLS على جهاز افتراضي يعمل على منصة Zoom Node، على [برنامج مراقبة افتراضية مدعوم](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server)‌. يمكن العثور على مزيد من المعلومات حول Zoom Node كمنتج [في الملحق](#_a2lvsihjp0ek).

#### <mark style="color:أزرق;">يمكن للعملاء اختر أحد خياري التكوين، اعتمادًا على قدرات الأجهزة</mark>

تدعم وحدة ZPLS تكوينين، اعتمادًا على قدرات الأجهزة الخاصة بالجهاز الافتراضي. هذه القدرات مدرجة أدناه:

|                                     | خيار التكوين 1                                                 | خيار التكوين 2                                                 |
| ----------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------- |
| **مواصفات الأجهزة**                 | <p>8 وحدات CPU</p><p>16 جيجابايت RAM</p><p>80 جيجابايت HDD</p> | <p>16 وحدة CPU</p><p>16 جيجابايت RAM</p><p>80 جيجابايت HDD</p> |
| **إجمالي عمليات التسجيل**           | 2000                                                           | 5000                                                           |
| **الحد الأقصى للمكالمات المتزامنة** | 240                                                            | 480                                                            |
| **المكالمات في الثانية**            | 2                                                              | 4                                                              |
| **عمليات التسجيل في الثانية**       | 60                                                             | 400                                                            |

{% hint style="info" %}
إذا تجاوز عدد نقاط النهاية ضمن موقع مُمكَّن للبقاء التشغيلي قدرات النشر الخاصة بالموقع، فستقوم وحدة ZPLS بمعالجة التسجيلات على أساس أسبقية الوصول. ويُنصح العملاء بـ إضافة وحدات إضافية، أو استخدام إعداد نهج Zoom Phone [**وضع البقاء المحلي**](#_ah8xua8wdq10) لتحديد أولوية المستخدمين الذين يدعمون التحويل إلى البقاء التشغيلي عند الفشل.
{% endhint %}

### توسيع الوحدة والمرونة

#### <mark style="color:أزرق;">تدعم وحدات ZPLS التجميع لتوفير توسيع إضافي و/أو مرونة</mark>

يمكن للعملاء تجميع وحدات ZPLS معًا بما يصل إلى 20 وحدة لكل موقع (أو 100 جهاز Node إجمالًا لكل الحساب) لتوفير تكرار إضافي أو توسيع.

{% hint style="info" %}
هذه الميزة متاحة حاليًا في النسخة التجريبية وتتطلب تذكرة دعم فني ليتم تمكينها.
{% endhint %}

#### <mark style="color:أزرق;">يؤدي التوسيع إلى زيادة قدرات الجهاز المدعومة في الموقع</mark>

إن زيادة عدد وحدات ZPLS تعزز قدرات كل موقع بشكل خطي مع كل وحدة إضافية. على سبيل المثال، إذا كانت وحدة واحدة تدعم إجمالي 5,000 عملية تسجيل، فإن نشر خمس وحدات سيرفع الدعم إلى 25,000 عملية تسجيل.

#### <mark style="color:أزرق;">يضيف التكرار وحدات إضافية لتحقيق المرونة، لكنه لا يوسع قدرات الجهاز في الموقع</mark>

عندما تُستخدم وحدة ZPLS لأغراض التكرار، فإن الوحدات الاحتياطية لا تسهم في العدد الإجمالي للامتدادات المدعومة. بدلًا من ذلك، تكون الوحدات في وضع «استعداد ساخن»، ولن تعمل إلا إذا فشلت الوحدات الأساسية. على سبيل المثال، تدعم وحدة أساسية واحدة ووحدة احتياطية واحدة إجمالي 5,000 عملية تسجيل، لذا إذا تعطلت وحدة أساسية، فلن تكون الوحدة الاحتياطية محملة بعدد أجهزة يتجاوز حدها المدعوم.

#### <mark style="color:أزرق;">مثال على نشر ZPLS مع التوسيع والتكرار</mark>

للتسهيل، يوضح المثال التالي النشر مع توسيع إضافي وتكرار.

{% hint style="success" %}
**مثال**:

يُطلب من مستشفى دعم ما يصل إلى 10,000 امتداد مسجل من أجل البقاء التشغيلي. ولتحقيق ذلك، يقوم المستشفى بنشر أربع وحدات ZPLS.

أول وحدتين قادرتان على دعم 5,000 عملية تسجيل لكل منهما، ما ينتج عنه سعة إجمالية تصل إلى 10,000 عملية تسجيل. ومع ذلك، وإدراكًا لأهمية المرونة، يقوم المستشفى أيضًا بنشر وحدتين إضافيتين كنسخ احتياطية للوحدات الأساسية.

في هذا السيناريو، أصبح لدى المستشفى الآن أجهزة بقاء تشغيلي أساسية وثانوية منشورة. والآن، إذا واجهت وحدة أساسية عطلًا، فستتولى الوحدة (أو الوحدات) الاحتياطية السيطرة على التشغيل للحفاظ على الخدمة دون انقطاع، مع الاستمرار في دعم ما يصل إلى 10,000 جهاز مسجل.
{% endhint %}

### اعتبارات تصميم الموقع

#### <mark style="color:أزرق;">تقوم المواقع بتجميع مستخدمي Zoom Phone معًا حسب الموقع من أجل إعدادات وسياسات الاتصال الهاتفي المشتركة</mark>

إن **موقع** هو مصطلح محدد يُستخدم داخل Zoom Phone ويجمع المستخدمين ذوي الخصائص المشتركة — مثل رمز وصول مشترك، أو عنوان، أو منطقة SIP، أو قسم، أو سياسات — في مجموعة واحدة قابلة للإدارة داخل بوابة Zoom الإلكترونية. بالنسبة لبعض العملاء، قد يمثل موقع واحد جميع المستخدمين داخل أعمالهم، ويمكن أن يمتد عبر عدة مبانٍ داخل حرم أو الموقع؛ وبالنسبة لآخرين، قد تكون عدة مواقع مطلوبة اعتمادًا على احتياجات أعمالك. لمزيد من المعلومات حول المواقع أو إدارة الموقع، [ارجع إلى مركز دعم Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:أزرق;">يدعم Zoom Phone تصميمات الموقع الواحد والمواقع المتعددة</mark>

هناك تصميمان أساسيان لتكوين مواقع Zoom Phone داخل الحساب:

1. **موقع واحد**: يمثل جميع المستخدمين داخل الحساب، وقد يمتد عبر عدة مبانٍ أو مواقع، ضمن موقع Zoom Phone واحد.
2. **متعدد المواقع**: يمثل شرائح من المستخدمين حسب الموقع أو المبنى أو القسم أو الوظيفة بشكل منفصل، بحيث يكون لكل منها موقعه الخاص.

<div data-with-frame="true"><img src="/files/8d126cf79305063ff06ab731d1d524e8b90b210f" alt=""></div>

{% hint style="info" %}
يمكن لمسؤولي الحساب لدى عملاء Zoom الحاليين التحقق من تصميم الموقع الحالي لديهم من خلال صفحة [**معلومات الشركة**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) ، المتاحة في قائمة **إدارة نظام الهاتف** على البوابة الإلكترونية.
{% endhint %}

#### <mark style="color:أزرق;">يمكن ربط كل وحدة ZPLS بموقع واحد فقط في كل مرة</mark>

كما ذُكر سابقًا، فإن وحدة ZPLS هي [المسجل ذو الأولوية الثالثة](#_7itj40mx1dut) للأجهزة المدعومة، بعد منطقتي SIP الأساسية والثانوية. ولأن الأجهزة تتلقى قوائم SRV الخاصة بها أثناء عملية الإقلاع، وهذه القوائم مرتبطة بإعداد الموقع الخاص بها، **يمكن ربط كل وحدة ZPLS بموقع واحد فقط في كل مرة**.

#### <mark style="color:أزرق;">يمكن لكل موقع دعم ما يصل إلى 20 وحدة ZPLS في وقت واحد</mark>

على الرغم من أن كل وحدة ZPLS يمكن ربطها بموقع واحد فقط في كل مرة، فإن الموقع يمكنه دعم ما يصل إلى 20 وحدة ZPLS في مجموعة واحدة، مما يوسع قدرات البقاء التشغيلي لكل موقع.

{% hint style="info" %}
هذه الميزة متاحة حاليًا في النسخة التجريبية وتتطلب تذكرة دعم فني ليتم تمكينها.
{% endhint %}

#### <mark style="color:أزرق;">تدعم وحدات ZPLS المكالمات بين المواقع إذا كانت الوحدات متصلة بشبكة مشتركة</mark>

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

{% hint style="info" %}
هذه الميزة متاحة حاليًا في النسخة التجريبية وتتطلب تذكرة دعم فني ليتم تمكينها.
{% endhint %}

#### <mark style="color:أزرق;">قبل نشر ZPLS، يجب أن تفهم الحسابات أي تكوين موقع هو الأنسب لاحتياجاتها</mark>

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

#### <mark style="color:أزرق;">يكون تصميم الموقع الواحد أسهل في الإدارة ويوفر البقاء التشغيلي باستخدام وحدة ZPLS واحدة، لكنه يوفر مرونة أقل لإعدادات المستخدم والسياسات</mark>

يساعد تصميم الموقع الواحد على تبسيط إدارة إعدادات وسياسات Zoom Phone من خلال دمج جميع المستخدمين داخل الحساب تحت مجموعة واحدة موحدة. وتوفر مجموعة المستخدمين الواحدة هذه للأعمال إدارة مباشرة وتقليلًا في التعقيد، مما يبسّط عملية الإدارة. بالإضافة إلى ذلك، يمكن أن يوفر تصميم الموقع الواحد بقاءً هاتفيًا محليًا باستخدام وحدة ZPLS واحدة، طالما أن مستخدمي الموقع لا يتجاوزون [قدرات الوحدة الواحدة](#_rx0i1j9xofnc).

ومع ذلك، فإن بساطة تصميم الموقع الواحد تتضمن بطبيعتها بعض القيود. وعلى وجه التحديد، توفر تصميمات الموقع الواحد مرونة أقل بسبب طبيعتها «مقاس واحد يناسب الجميع»، وهو ما قد لا يناسب جميع سيناريوهات النشر عبر أقسام متعددة ذات احتياجات متفاوتة. وعلاوة على ذلك، قد تكون عمليات النشر أحادية الموقع عرضة للخطر في بعض سيناريوهات البقاء إذا [فشلت الشبكة المحلية](#_gzpf5m70jl3i).

#### <mark style="color:أزرق;">يوفر تصميم المواقع المتعددة مرونة أكبر لإعدادات المستخدم والسياسات، لكنه يتطلب وحدة ZPLS واحدة لكل موقع مُمكَّن للبقاء التشغيلي ويكون أكثر تعقيدًا في الإدارة</mark>

يوفر تصميم المواقع المتعددة للأعمال مرونة إضافية في إعدادات المستخدم والسياسات من خلال فصل المستخدمين إلى مجموعات متنوعة مع ضوابط إعدادات دقيقة. ويمكّن هذا التصميم المؤسسات من ضبط تكوينات الاتصال بشكل تفصيلي لتلبية متطلبات محددة عبر مواقع متنوعة، مما يؤدي إلى تجربة مستخدم أكثر دقة وقابلية للتكيف لمختلف الأقسام أو السيناريوهات أو الاحتياجات. بالإضافة إلى ذلك، يمكن لعمليات النشر متعددة المواقع دعم [الاتصال بين المواقع](#_a42hwaw1pfmx) إذا كانت المواقع متصلة عبر شبكة مشتركة.

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

{% hint style="info" %}
في تصميم متعدد المواقع، يتمتع العملاء بالمرونة في اختر المواقع التي سيتم تكوينها للبقاء التشغيلي. المواقع *من دون* وحدة ZPLS ستظل غير قادرة على إجراء المكالمات أو تلقيها حتى تتم استعادة الاتصال المعياري.
{% endhint %}

### إخفاقات الشبكة

#### <mark style="color:أزرق;">قد يتأثر البقاء التشغيلي إذا فشلت الشبكة المحلية للموقع</mark>

على الرغم من أن وحدات ZPLS مصممة لتوفير بقاء هاتفي محلي أثناء الفعاليات التي تؤثر في الخدمة، فإن البقاء التشغيلي قد يتأثر إذا فشلت الشبكة المحلية للموقع. يتم توضيح هذه السيناريوهات في القسمين التاليين.

#### <mark style="color:أزرق;">فشل الشبكة المحلية في الموقع الواحد</mark>

في تصميم الموقع الواحد، يتم توصيل مبنى واحد أو أكثر عبر شبكة محلية أو شبكة منطقة حرم، ويتم تمثيلها بواسطة موقع واحد داخل Zoom Phone. يفترض هذا التكوين وجود شبكة مشتركة بين جميع المستخدمين والمباني داخل موقع واحد، من دون أي تبعيات شبكة خارجية (مثل الإنترنت) للاتصال بين المباني.

باستخدام تصميم الموقع هذا، يمكن للأعمال توفير بقاء تشغيلي محلي لجميع المستخدمين داخل موقع أو موقع واحد باستخدام أقل عدد ممكن وهو وحدة ZPLS واحدة؛ ومع ذلك، يكون هذا التصميم عرضة للخطر في حال حدوث انقطاع في الشبكة المحلية أو شبكة الحرم يؤثر في الاتصال بين المباني. يصف المثال التالي كيف يمكن أن يؤثر فشل الشبكة المحلية في نشر موقع واحد.

<div data-with-frame="true"><img src="/files/9a345f5742f56fa688c61f921700f4eac6578da2" alt=""></div>

{% hint style="success" %}
**مثال:**

تقوم شركة بنشر وحدة ZPLS لموقع Zoom Phone واحد، يتكون من المباني A وB وC، والتي ترتبط عبر شبكة منطقة حرم. تعمل وحدة ZPLS في المبنى A وهي **غير** متصلة بوحدة SBC لإجراء المكالمات الخارجية عبر شبكة الهاتف العامة المترابطة.

في حال حدوث فشل في خدمة الإنترنت الخارجية أو فعالية تؤثر في الخدمة، يمكن لأي مستخدم موجود داخل الموقع أن يجري مكالمة إلى مستخدم آخر داخل *نفس* الموقع، طالما حافظ كلا المستخدمين على الاتصال بوحدة ZPLS عبر شبكة منطقة الحرم.

ومع ذلك، في حال حدوث انقطاع في شبكة منطقة الحرم، لا يمكن للمستخدمين داخل المبنيين B وC إجراء المكالمات بينما تكون وحدة ZPLS داخل المبنى A غير قابلة للوصول. وبالتالي، يجب على المستخدمين داخل المبنيين B وC الانتظار حتى تتم استعادة شبكة منطقة الحرم لإجراء مكالمات البقاء التشغيلي.
{% endhint %}

يوضح الجدول التالي البقاء التشغيلي في Zoom Phone في تصميم موقع واحد متعدد المباني:

| المكالمات الصادرة من المبنى | يمكنها الوصول إلى هذه المواقع أثناء فشل الإنترنت الخارجي | يمكنها الوصول إلى هذه المواقع أثناء فشل شبكة الحرم |
| --------------------------- | -------------------------------------------------------- | -------------------------------------------------- |
| المبنى A (مضيف ZPLS)        | ☑️ المباني A وB وC                                       | ☑️ المبنى A *فقط*                                  |
| المبنى B                    | ☑️ المباني A وB وC                                       | ✖️                                                 |
| المبنى C                    | ☑️ المباني A وB وC                                       | ✖️                                                 |

#### <mark style="color:أزرق;">فشل الشبكة المحلية في تصميم متعدد المواقع من دون SBC</mark>

في تصميم متعدد المواقع، يتم تمثيل كل مبنى أو موقع (مثل الطابق أو المكتب الفرعي، إلخ) بشكل مستقل بواسطة موقع فريد داخل Zoom Phone. ويفترض هذا التكوين أن لكل موقع وحدة ZPLS، وأن المواقع متصلة عبر شبكة منطقة حرم مشتركة.

باستخدام تصميم الموقع هذا، يدعم كل موقع وحدة ZPLS الخاصة به، مما يسمح للمستخدمين داخل المبنى نفسه بالاتصال ببعضهم بعضًا عند تفعيل وضع البقاء التشغيلي. علاوة على ذلك، عندما تكون عدة مواقع تحتوي على وحدة ZPLS متصلة عبر شبكة مشتركة، يمكن للمستخدمين الاتصال بمستخدمين في \_other\_sites، طالما بقيت الشبكة المحلية قيد التشغيل. ومع ذلك، يكون هذا التصميم عرضة للخطر في حال حدوث انقطاع في شبكة منطقة الحرم يؤثر في الاتصال بين المباني. يصف المثال التالي كيف يمكن أن يؤثر فشل شبكة الحرم في نشر متعدد المواقع.

<div data-with-frame="true"><img src="/files/749367d41a1e21697d2fc8d7a726681f8d799fae" alt=""></div>

{% hint style="success" %}
**مثال:**

تقوم شركة بنشر وحدة ZPLS داخل حرمها متعدد المباني، والمكوَّن من المباني A وB وC. ويُعد كل مبنى موقعًا فريدًا داخل Zoom Phone، ويحتفظ بوحدة ZPLS خاصة بالموقع. جميع المباني داخل الحرم متصلة عبر شبكة منطقة حرم لا تعتمد على خدمة الإنترنت الخارجية للاتصالات بين المباني.

في هذا المثال، في حال حدوث فشل في خدمة الإنترنت الخارجية أو انقطاع في شبكة الحرم أو فعالية تؤثر في الخدمة، يمكن لأي مستخدم موجود داخل موقع ما أن يجري مكالمة إلى مستخدم آخر موجود داخل الموقع نفسه. ومع ذلك، نظرًا لأن كل مبنى هو موقع فريد ويسجل المستخدمون في الوحدات الخاصة بمواقعهم، فإذا تعطلت شبكة الحرم، فلن تتمكن وحدات ZPLS من نقل المكالمات بين المواقع. وبدلًا من ذلك، سيقتصر المستخدمون على إجراء المكالمات إلى مستخدمين آخرين داخل موقعهم المحلي.
{% endhint %}

يوضح الجدول التالي البقاء التشغيلي في Zoom Phone استنادًا إلى المثال أعلاه في تصميم متعدد المواقع مع شبكة حرم مترابطة:

| المكالمات الصادرة من المبنى | يمكنها الوصول إلى هذه المواقع أثناء فشل الإنترنت الخارجي | يمكنها الوصول إلى هذه المواقع أثناء فشل شبكة الحرم |
| --------------------------- | -------------------------------------------------------- | -------------------------------------------------- |
| المبنى A (مضيف ZPLS)        | ☑️ المباني A وB وC                                       | ☑️ المبنى A                                        |
| المبنى B (مضيف ZPLS)        | ☑️ المبنى A وB وC                                        | ☑️ المبنى B                                        |
| المبنى C (مضيف ZPLS)        | ☑️ المبنى A وB وC                                        | ☑️ المبنى C                                        |

#### <mark style="color:أزرق;">إذا فشلت شبكة محلية، فسيتم أيضًا دعم المكالمات بين المواقع عبر شبكة الهاتف العامة المترابطة، بشرط أن يكون كل موقع متصلًا بوحدة SBC وأن يكون تحويل المكالمات ممكّنًا</mark>

في حال حدوث فشل في الشبكة المحلية، يمكن للعملاء الذين لديهم تصميم متعدد المواقع يدمج وحدة ZPLS مع SBC واتصال شبكة الهاتف العامة المترابطة في كل موقع تمكين الاتصال من موقع إلى موقع إذا كان [تحويل المكالمات ممكّنًا](#_2v7qst7vxwaa)‌. عند تكوين ذلك، سيتم توجيه المكالمات الهاتفية التي يتم إجراؤها أثناء وضع البقاء التشغيلي من عميل المستخدم إلى شبكة الهاتف العامة المترابطة، ثم إلى وحدة SBC ووحدة ZPLS الخاصة بالموقع الثاني، لتصل أخيرًا إلى جهاز الطرف المتلقي. يوفر المخطط التالي نظرة عامة على هذا التكوين:

<div data-with-frame="true"><img src="/files/281bb6f5e2310af8b802dc8cf43cb39d408a753d" alt=""></div>

{% hint style="danger" %}
هذا التكوين **يتطلب** معالجة أرقام الهاتف E.164 على وحدات SBC التي تم تكوينها.
{% endhint %}

يوضح الجدول التالي أيضًا البقاء التشغيلي في Zoom Phone في تصميم متعدد المواقع مع وحدات SBC مستقلة:

| المكالمات الصادرة من المبنى | يمكنها الوصول إلى هذه المواقع أثناء فشل الإنترنت الخارجي | يمكنها الوصول إلى هذه المواقع أثناء فشل شبكة الحرم |
| --------------------------- | -------------------------------------------------------- | -------------------------------------------------- |
| المبنى A (مضيف ZPLS)        | ☑️ المباني A وB وC                                       | ☑️ المباني A وB وC                                 |
| المبنى B (مضيف ZPLS)        | ☑️ المباني A وB وC                                       | ☑️ المباني A وB وC                                 |
| المبنى C (مضيف ZPLS)        | ☑️ المباني A وB وC                                       | ☑️ المباني A وB وC                                 |

#### <mark style="color:أزرق;">يسجل المستخدمون المتنقلون دائمًا في وحدة ZPLS المرتبطة بموقعهم الأساسي</mark>

عند إضافة مستخدمين أو أجهزة إلى Zoom Phone، يتم ربط موقع «أساسي» بشكل ثابت بالمستخدم أو الجهاز حتى يتم تحديثه بخلاف ذلك بواسطة مسؤول الحساب. وهذا يعني أنه إذا انتقل مستخدم إلى موقع فعلي خارج موقعه الأساسي المرتبط، مثل مبنى مكاتب مرتبط بموقع مختلف، فلن يقوم Zoom بضبط الموقع المرتبط بالمستخدم بشكل ديناميكي. ونتيجة لذلك، إذا فقد المستخدم الاتصال بمراكز بيانات Zoom Phone، فسيحاول المستخدم التسجيل في وحدة ZPLS المرتبطة بموقعه الأساسي، حتى إذا كان في موقع مختلف.

{% hint style="success" %}
**مثال:**

يوجد مستخدم في حرم متعدد المواقع مقره في المبنى A (الموقع A)، وينتقل مؤقتًا إلى المبنى B (الموقع B) من أجل اجتماع. وأثناء وجوده في المبنى B، تحدث فعالية تؤثر في الخدمة، ويتم تفعيل وضع البقاء التشغيلي. وعلى الرغم من أن المستخدم موجود داخل المبنى B، فإن عميل المستخدم سيحاول الاتصال بوحدة ZPLS المجهزة في موقعه الأساسي داخل المبنى A، لأن الموقع A هو موقعه الأساسي.

في هذا السيناريو، يتم تحديد حالة البقاء التشغيلي للمستخدم من خلال قدرة جهاز المستخدم على التسجيل في وحدة ZPLS داخل موقعه الأساسي عبر شبكة منطقة الحرم. وإذا كانت شبكة منطقة الحرم متوقفة بينما يكون المستخدم بعيدًا عن موقعه الأساسي، فلن يتمكن المستخدم من الاستفادة من وحدة البقاء التشغيلي.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://library.zoom.com/technical-library/technical-library-ar/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.