> 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 وحدة معالجة مركزية</p><p>16 غيغابايت RAM</p><p>80 غيغابايت HDD</p> | <p>16 وحدة معالجة مركزية</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>

A **موقع** هو مصطلح محدد يُستخدم داخل 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 متصلة عبر شبكة مشتركة، يمكن للمستخدمين الاتصال بمستخدمين في مواقع أخرى، طالما ظلت الشبكة المحلية قيد التشغيل. ومع ذلك، يكون هذا التصميم عرضة للخطر في حالة انقطاع شبكة الحرم الجامعي الذي يؤثر في الاتصال بين المباني. يوضح المثال التالي كيف يمكن لفشل شبكة الحرم الجامعي أن يؤثر في نشر عدة مواقع.

<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، وبما أن الموقع A هو موقعه الرئيسي، فسيحاول عميل المستخدم الاتصال بوحدة ZPLS المهيأة في موقعه الرئيسي داخل المبنى 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.