> 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/vi/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md).

# Những điều cần cân nhắc khi triển khai phần cứng

Trang này trình bày việc triển khai mô-đun Zoom Node ZPLS trên một máy ảo bằng cách sử dụng các hypervisor được hỗ trợ. Trang này cung cấp các tùy chọn cấu hình chi tiết được điều chỉnh để phù hợp với các khả năng phần cứng khác nhau, bảo đảm hiệu suất tối ưu cho nhiều nhu cầu vận hành.

### Các hypervisor được hỗ trợ

#### <mark style="color:xanh dương;">Khách hàng phải cài đặt phần mềm Zoom Node trên một máy ảo đang chạy trên hypervisor được hỗ trợ</mark>

Là một khối lượng công việc của Zoom Node, mô-đun ZPLS phải được cài đặt trên một máy ảo đang chạy nền tảng Zoom Node, trên một [hypervisor được hỗ trợ](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Có thể tìm thấy thêm thông tin về Zoom Node với tư cách là một sản phẩm [trong Phụ lục](#_a2lvsihjp0ek).

#### <mark style="color:xanh dương;">Khách hàng có thể Chọn một trong hai tùy chọn cấu hình, tùy thuộc vào khả năng phần cứng</mark>

Mô-đun ZPLS hỗ trợ hai cấu hình, tùy thuộc vào khả năng phần cứng của máy ảo. Các khả năng này được liệt kê bên dưới:

|                                   | Tùy chọn cấu hình 1                          | Tùy chọn cấu hình 2                           |
| --------------------------------- | -------------------------------------------- | --------------------------------------------- |
| **Thông số phần cứng**            | <p>8 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> | <p>16 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> |
| **Tổng số đăng ký**               | 2000                                         | 5000                                          |
| **Số cuộc gọi đồng thời tối đa** | 240                                          | 480                                           |
| **Số cuộc gọi mỗi giây**         | 2                                            | 4                                             |
| **Số đăng ký mỗi giây**           | 60                                           | 400                                           |

{% hint style="info" %}
Nếu số lượng thiết bị đầu cuối trong một cơ sở đã Bật khả năng sống sót vượt quá khả năng triển khai của cơ sở đó, mô-đun ZPLS sẽ xử lý đăng ký theo nguyên tắc ai đến trước được phục vụ trước. Khách hàng được khuyên nên Thêm các mô-đun bổ sung hoặc sử dụng cài đặt Chính sách Zoom Phone [**Chế độ sống sót cục bộ**](#_ah8xua8wdq10) để ưu tiên những người dùng nào hỗ trợ chuyển đổi dự phòng sống sót.
{% endhint %}

### Mở rộng mô-đun và khả năng phục hồi

#### <mark style="color:xanh dương;">Các mô-đun ZPLS hỗ trợ phân cụm để mở rộng và/hoặc tăng khả năng phục hồi</mark>

Khách hàng có thể nhóm các mô-đun ZPLS lại với nhau với tối đa 20 mô-đun cho mỗi cơ sở (hoặc tổng cộng 100 Thiết bị Node cho mỗi tài khoản) để tăng thêm dự phòng hoặc khả năng mở rộng.

{% hint style="info" %}
Tính năng này hiện đang ở bản beta và yêu cầu một phiếu yêu cầu hỗ trợ kỹ thuật để được Bật.
{% endhint %}

#### <mark style="color:xanh dương;">Khả năng mở rộng làm tăng khả năng hỗ trợ Thiết bị của một cơ sở</mark>

Việc mở rộng số lượng mô-đun ZPLS nâng cao khả năng của từng cơ sở theo tuyến tính với mỗi mô-đun bổ sung. Ví dụ: nếu một mô-đun hỗ trợ tổng cộng 5.000 đăng ký, việc triển khai năm mô-đun sẽ nâng mức hỗ trợ lên 25.000 đăng ký.

#### <mark style="color:xanh dương;">Dự phòng bổ sung thêm mô-đun để tăng khả năng phục hồi, nhưng không mở rộng khả năng Thiết bị của một cơ sở</mark>

Khi một mô-đun ZPLS được օգտագործված cho mục đích dự phòng, các mô-đun dự phòng sẽ không đóng góp vào tổng số máy nhánh được hỗ trợ. Thay vào đó, các mô-đun ở trạng thái “dự phòng nóng”, và sẽ chỉ tham gia nếu các mô-đun chính gặp sự cố. Ví dụ: một mô-đun chính và một mô-đun dự phòng hỗ trợ tổng cộng 5.000 đăng ký, do đó nếu mô-đun chính gặp lỗi, mô-đun dự phòng sẽ không bị quá tải bởi số lượng Thiết bị vượt quá giới hạn được hỗ trợ của nó.

#### <mark style="color:xanh dương;">Ví dụ về triển khai ZPLS với khả năng mở rộng và dự phòng</mark>

Để thuận tiện, ví dụ sau minh họa việc triển khai với khả năng mở rộng và dự phòng bổ sung.

{% hint style="success" %}
**Ví dụ**:

Một bệnh viện cần hỗ trợ tối đa 10.000 máy nhánh đã đăng ký để bảo đảm khả năng sống sót. Để đạt được điều này, bệnh viện đang triển khai bốn mô-đun ZPLS.

Hai mô-đun đầu tiên có khả năng hỗ trợ mỗi mô-đun 5.000 đăng ký, tạo ra tổng dung lượng lên đến 10.000 đăng ký. Tuy nhiên, nhận thấy tầm quan trọng của khả năng phục hồi, bệnh viện cũng đang triển khai thêm hai mô-đun làm bản sao lưu dự phòng cho các mô-đun chính.

Trong tình huống này, bệnh viện hiện có phần cứng sống sót chính và phụ đã được triển khai. Bây giờ, nếu một mô-đun chính gặp sự cố, (các) mô-đun dự phòng sẽ Tiếp nhận để duy trì dịch vụ không bị gián đoạn, đồng thời tiếp tục hỗ trợ tối đa 10.000 Thiết bị đã đăng ký.
{% endhint %}

### Các cân nhắc về thiết kế cơ sở

#### <mark style="color:xanh dương;">Các cơ sở nhóm người dùng Zoom Phone lại với nhau theo Vị trí để áp dụng Cài đặt và chính sách điện thoại chung</mark>

A **cơ sở** là một thuật ngữ cụ thể được sử dụng trong Zoom Phone để nhóm những người dùng có đặc điểm chung — như mã Truy cập chung, địa chỉ, Vùng SIP, phòng ban hoặc chính sách — vào một nhóm duy nhất, dễ quản lý trong Cổng thông tin web của Zoom. Đối với một số Khách hàng, một cơ sở duy nhất có thể đại diện cho tất cả người dùng trong doanh nghiệp của họ và có thể trải rộng trên nhiều tòa nhà trong một khuôn viên hoặc Vị trí; đối với những người khác, Nhiều địa điểm có thể được yêu cầu tùy thuộc vào nhu cầu Kinh doanh của bạn. Để biết thêm thông tin về các cơ sở hoặc quản lý cơ sở, [tham khảo Trung tâm hỗ trợ của Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:xanh dương;">Zoom Phone hỗ trợ thiết kế một cơ sở và nhiều cơ sở</mark>

Có hai thiết kế chính để cấu hình các cơ sở Zoom Phone trong một tài khoản:

1. **Một cơ sở**: Đại diện cho tất cả người dùng trong một tài khoản, có khả năng trải rộng trên nhiều tòa nhà hoặc Vị trí, trong một cơ sở Zoom Phone duy nhất.
2. **Nhiều cơ sở**: Đại diện cho các phân đoạn người dùng theo Vị trí, tòa nhà, phòng ban hoặc chức năng một cách riêng biệt, mỗi phân đoạn có cơ sở riêng.

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

{% hint style="info" %}
quản trị viên tài khoản của các Khách hàng Zoom hiện tại có thể kiểm tra thiết kế cơ sở hiện tại của họ thông qua trang [**Thông tin công ty**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) trang, có sẵn trong menu **menu con Quản lý hệ thống điện thoại** trên cổng thông tin web.
{% endhint %}

#### <mark style="color:xanh dương;">Mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm</mark>

Như đã đề cập trước đó, một mô-đun ZPLS là [bộ đăng ký ưu tiên thứ ba](#_7itj40mx1dut) đối với các Thiết bị được hỗ trợ, sau các vùng SIP chính và phụ. Bởi vì các Thiết bị nhận danh sách SRV của chúng trong quá trình khởi động và các danh sách này gắn với cài đặt của cơ sở, **mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm**.

#### <mark style="color:xanh dương;">Mỗi cơ sở có thể hỗ trợ tối đa 20 mô-đun ZPLS đồng thời</mark>

Mặc dù mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm, một cơ sở có thể hỗ trợ tối đa 20 mô-đun ZPLS trong một nhóm, mở rộng khả năng sống sót của từng cơ sở.

{% hint style="info" %}
Tính năng này hiện đang ở bản beta và yêu cầu một phiếu yêu cầu hỗ trợ kỹ thuật để được Bật.
{% endhint %}

#### <mark style="color:xanh dương;">Các mô-đun ZPLS hỗ trợ cuộc gọi liên cơ sở nếu các mô-đun được kết nối với một mạng chung</mark>

Các mô-đun ZPLS từ các cơ sở khác nhau hỗ trợ cuộc gọi liên cơ sở trong một Sự kiện sống sót miễn là các Thiết bị có thể được phát hiện trong mạng cục bộ. Ví dụ: nếu một khuôn viên Kinh doanh có ba tòa nhà, mỗi tòa nhà có cơ sở điện thoại riêng, các mô-đun ZPLS từ mỗi cơ sở có thể kết nối các cuộc gọi từ cơ sở này sang cơ sở khác trên mạng khu vực khuôn viên.

{% hint style="info" %}
Tính năng này hiện đang ở bản beta và yêu cầu một phiếu yêu cầu hỗ trợ kỹ thuật để được Bật.
{% endhint %}

#### <mark style="color:xanh dương;">Trước khi triển khai ZPLS, các tài khoản nên hiểu cấu hình cơ sở nào phù hợp nhất với nhu cầu của họ</mark>

Vì mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm, thiết kế cơ sở là một trong những yếu tố quan trọng nhất khi triển khai dịch vụ ZPLS trong một tài khoản. Vì lý do này, Khách hàng nên hiểu cấu hình cơ sở nào là tốt nhất để đáp ứng nhu cầu thực tế về Kinh doanh và khả năng sống sót của họ, vì mỗi cơ sở bổ sung được Bật khả năng sống sót sẽ yêu cầu ít nhất một mô-đun ZPLS bổ sung.

#### <mark style="color:xanh dương;">Thiết kế một cơ sở dễ quản lý hơn và cung cấp khả năng sống sót với một mô-đun ZPLS duy nhất, nhưng ít linh hoạt hơn đối với Cài đặt và chính sách của người dùng</mark>

Thiết kế một cơ sở giúp tinh giản việc quản lý Cài đặt và chính sách Zoom Phone bằng cách hợp nhất tất cả người dùng trong một tài khoản vào một nhóm thống nhất duy nhất. Nhóm người dùng duy nhất này mang lại cho doanh nghiệp khả năng quản trị đơn giản và giảm độ phức tạp, giúp đơn giản hóa quy trình quản lý. Ngoài ra, thiết kế một cơ sở có thể cung cấp khả năng sống sót điện thoại cục bộ với một mô-đun ZPLS duy nhất, miễn là người dùng của cơ sở không vượt quá [khả năng của một mô-đun đơn](#_rx0i1j9xofnc).

Tuy nhiên, sự đơn giản của thiết kế một cơ sở tự nhiên cũng đi kèm với các hạn chế. Cụ thể, thiết kế một cơ sở mang lại ít linh hoạt hơn do tính chất “một cỡ cho tất cả”, điều này có thể không phù hợp với mọi kịch bản triển khai trên nhiều phòng ban có nhu cầu khác nhau. Hơn nữa, các triển khai một cơ sở có thể dễ bị ảnh hưởng trong một số kịch bản sống sót nhất định nếu [mạng cục bộ bị lỗi](#_gzpf5m70jl3i).

#### <mark style="color:xanh dương;">Thiết kế nhiều cơ sở mang lại nhiều linh hoạt hơn cho Cài đặt và chính sách người dùng, nhưng yêu cầu một mô-đun ZPLS cho mỗi cơ sở được Bật khả năng sống sót và phức tạp hơn để quản lý</mark>

Thiết kế nhiều cơ sở mang lại cho doanh nghiệp thêm tính linh hoạt trong Cài đặt và chính sách người dùng bằng cách tách người dùng thành nhiều nhóm khác nhau với khả năng kiểm soát cài đặt chi tiết. Thiết kế này giúp các tổ chức tinh chỉnh cấu hình liên lạc để đáp ứng các yêu cầu cụ thể trên nhiều cơ sở khác nhau, từ đó mang lại trải nghiệm người dùng tinh tế và thích ứng hơn cho nhiều phòng ban, tình huống hoặc nhu cầu. Ngoài ra, các triển khai nhiều cơ sở có thể hỗ trợ [liên lạc liên cơ sở](#_a42hwaw1pfmx) nếu các cơ sở được kết nối qua một mạng chung.

Tuy nhiên, việc quản lý thiết kế nhiều cơ sở đòi hỏi sự chú ý cẩn thận đến những chi tiết phức tạp trong yêu cầu riêng của từng cơ sở, điều này có thể đòi hỏi mức độ nỗ lực quản trị cao hơn. Hơn nữa, vì mỗi mô-đun ZPLS chỉ có thể được chỉ định cho một cơ sở tại một thời điểm, mỗi cơ sở được Bật khả năng sống sót sẽ yêu cầu một mô-đun ZPLS và giấy phép, điều này có thể góp phần làm cho việc thiết lập tiêu tốn nhiều tài nguyên hơn.

{% hint style="info" %}
Trong thiết kế nhiều cơ sở, Khách hàng có thể linh hoạt Chọn cơ sở nào sẽ được cấu hình cho khả năng sống sót. Các cơ sở *không có* mô-đun ZPLS sẽ vẫn không thể thực hiện hoặc nhận cuộc gọi cho đến khi kết nối Tiêu chuẩn được khôi phục.
{% endhint %}

### Sự cố mạng

#### <mark style="color:xanh dương;">Khả năng sống sót có thể bị ảnh hưởng nếu mạng cục bộ của một cơ sở bị lỗi</mark>

Mặc dù các mô-đun ZPLS được thiết kế để cung cấp khả năng sống sót điện thoại cục bộ trong các Sự kiện ảnh hưởng đến dịch vụ, khả năng sống sót có thể bị ảnh hưởng nếu mạng cục bộ của một cơ sở bị lỗi. Các tình huống này được trình bày trong hai phần sau.

#### <mark style="color:xanh dương;">Sự cố mạng cục bộ của một cơ sở đơn</mark>

Trong thiết kế một cơ sở, một hoặc nhiều tòa nhà được kết nối qua mạng cục bộ hoặc mạng khu vực khuôn viên và được đại diện bởi một cơ sở duy nhất trong Zoom Phone. Cấu hình này giả định có một mạng chung giữa tất cả người dùng và tòa nhà trong một Vị trí, không có bất kỳ phụ thuộc mạng bên ngoài nào (ví dụ: Internet) cho liên lạc giữa các tòa nhà.

Với thiết kế cơ sở này, một doanh nghiệp có thể cung cấp khả năng sống sót cục bộ cho tất cả người dùng trong một cơ sở hoặc Vị trí duy nhất chỉ với một mô-đun ZPLS; tuy nhiên, thiết kế này dễ bị ảnh hưởng trong trường hợp mất mạng cục bộ hoặc mạng khuôn viên làm tác động đến liên lạc giữa các tòa nhà. Ví dụ sau mô tả cách sự cố mạng cục bộ có thể ảnh hưởng đến triển khai một cơ sở.

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

{% hint style="success" %}
**Ví dụ:**

Một công ty đang triển khai mô-đun ZPLS cho một cơ sở Zoom Phone duy nhất, bao gồm các tòa nhà A, B và C, được kết nối qua mạng khu vực khuôn viên. Mô-đun ZPLS đang hoạt động trong Tòa nhà A và **không** được kết nối với một SBC để thực hiện cuộc gọi bên ngoài qua Mạng điện thoại chuyển tiếp công cộng.

Trong trường hợp sự cố dịch vụ internet bên ngoài hoặc Sự kiện ảnh hưởng đến dịch vụ, bất kỳ người dùng nào thuộc cơ sở đều có thể gọi cho người dùng khác trong *cùng* cơ sở, miễn là cả hai người dùng vẫn duy trì kết nối đến mô-đun ZPLS qua mạng khu vực khuôn viên.

Tuy nhiên, trong trường hợp mạng khu vực khuôn viên bị gián đoạn, người dùng trong các tòa nhà B và C không thể thực hiện cuộc gọi khi mô-đun ZPLS trong Tòa nhà A không thể truy cập. Do đó, người dùng trong các tòa nhà B và C phải đợi đến khi mạng khu vực khuôn viên được khôi phục để thực hiện cuộc gọi trong chế độ sống sót.
{% endhint %}

Bảng sau minh họa khả năng sống sót của Zoom Phone trong thiết kế một cơ sở nhiều tòa nhà:

| Các cuộc gọi bắt nguồn từ tòa nhà | Có thể đến các Vị trí này khi xảy ra sự cố Internet bên ngoài | Có thể đến các Vị trí này khi xảy ra sự cố mạng khuôn viên |
| ---------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- |
| Tòa nhà A (người chủ trì ZPLS)     | ☑️Tòa nhà A, B và C                                           | ☑️ Chỉ Tòa nhà A *chỉ*                                     |
| Tòa nhà B                          | ☑️Tòa nhà A, B và C                                           | ✖️                                                         |
| Tòa nhà C                          | ☑️Tòa nhà A, B và C                                           | ✖️                                                         |

#### <mark style="color:xanh dương;">Sự cố mạng cục bộ nhiều cơ sở không có SBC</mark>

Trong thiết kế nhiều cơ sở, mỗi tòa nhà hoặc Vị trí (ví dụ: tầng, văn phòng vệ tinh, v.v.) được đại diện độc lập bởi một cơ sở riêng biệt trong Zoom Phone. Cấu hình này giả định rằng mỗi cơ sở có một mô-đun ZPLS và các cơ sở được kết nối qua một mạng khu vực khuôn viên chung.

Với thiết kế cơ sở này, mỗi cơ sở hỗ trợ mô-đun ZPLS riêng của mình, cho phép người dùng trong cùng một tòa nhà gọi cho nhau khi chế độ sống sót được kích hoạt. Hơn nữa, khi nhiều cơ sở có mô-đun ZPLS được kết nối qua một mạng chung, người dùng có thể gọi cho người dùng tại \_other\_sites, miễn là mạng cục bộ vẫn hoạt động. Tuy nhiên, thiết kế này dễ bị ảnh hưởng trong trường hợp mất mạng khu vực khuôn viên làm tác động đến liên lạc giữa các tòa nhà. Ví dụ sau mô tả cách sự cố mạng khuôn viên có thể ảnh hưởng đến triển khai nhiều cơ sở.

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

{% hint style="success" %}
**Ví dụ:**

Một công ty đang triển khai mô-đun ZPLS trong khuôn viên nhiều tòa nhà của họ, bao gồm các tòa nhà A, B và C. Mỗi tòa nhà là một cơ sở riêng biệt trong Zoom Phone và duy trì một mô-đun ZPLS dành riêng cho cơ sở đó. Tất cả các tòa nhà trong khuôn viên được kết nối qua một mạng khu vực khuôn viên không phụ thuộc vào dịch vụ internet bên ngoài cho liên lạc giữa các tòa nhà.

Trong ví dụ này, trong trường hợp sự cố dịch vụ internet bên ngoài, mất mạng khuôn viên hoặc Sự kiện ảnh hưởng đến dịch vụ, bất kỳ người dùng nào nằm trong một cơ sở đều có thể gọi cho người dùng khác nằm trong cùng cơ sở đó. Tuy nhiên, vì mỗi tòa nhà là một cơ sở riêng biệt và người dùng đăng ký với các mô-đun dành riêng cho cơ sở của họ, nếu mạng khuôn viên bị lỗi, các mô-đun ZPLS không thể truyền tải các cuộc gọi liên cơ sở. Thay vào đó, người dùng sẽ bị giới hạn chỉ có thể thực hiện cuộc gọi tới những người dùng khác trong cơ sở cục bộ của họ.
{% endhint %}

Bảng sau cũng minh họa khả năng sống sót của Zoom Phone từ ví dụ trên trong thiết kế nhiều cơ sở với mạng khuôn viên được kết nối liên thông:

| Các cuộc gọi bắt nguồn từ tòa nhà | Có thể đến các Vị trí này khi xảy ra sự cố Internet bên ngoài | Có thể đến các Vị trí này khi xảy ra sự cố mạng khuôn viên |
| ---------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- |
| Tòa nhà A (người chủ trì ZPLS)     | ☑️ Tòa nhà A, B và C                                          | ☑️ Chỉ Tòa nhà A                                           |
| Tòa nhà B (người chủ trì ZPLS)     | ☑️ Tòa nhà A, B và C                                          | ☑️ Tòa nhà B                                               |
| Tòa nhà C (người chủ trì ZPLS)     | ☑️ Tòa nhà A, B và C                                          | ☑️ Tòa nhà C                                               |

#### <mark style="color:xanh dương;">Nếu một mạng cục bộ bị lỗi, cuộc gọi liên cơ sở cũng được hỗ trợ qua Mạng điện thoại chuyển tiếp công cộng, với điều kiện mỗi cơ sở được kết nối với một SBC và đã Bật chuyển tiếp cuộc gọi</mark>

Trong trường hợp sự cố mạng cục bộ, Khách hàng có thiết kế nhiều cơ sở tích hợp mô-đun ZPLS với SBC và kết nối Mạng điện thoại chuyển tiếp công cộng tại mỗi cơ sở có thể Bật cuộc gọi từ cơ sở này sang cơ sở khác nếu [đã Bật chuyển tiếp cuộc gọi](#_2v7qst7vxwaa). Khi được cấu hình, các cuộc gọi điện thoại được thực hiện trong chế độ sống sót sẽ được định tuyến từ ứng dụng khách của người dùng tới Mạng điện thoại chuyển tiếp công cộng, tới SBC và mô-đun ZPLS của cơ sở thứ hai, và cuối cùng đến Thiết bị của người nhận cuộc gọi. Sơ đồ sau cung cấp tổng quan về cấu hình này:

<div data-with-frame="true"><img src="/files/42542df0158bf7025fe5789b6a92b1d0a79a6f2f" alt=""></div>

{% hint style="danger" %}
Cấu hình này **yêu cầu** xử lý số điện thoại E.164 trên các SBC đã được cấu hình.
{% endhint %}

Bảng sau cũng minh họa khả năng sống sót của Zoom Phone trong thiết kế nhiều cơ sở với các SBC độc lập:

| Các cuộc gọi bắt nguồn từ tòa nhà | Có thể đến các Vị trí này khi xảy ra sự cố Internet bên ngoài | Có thể đến các Vị trí này khi xảy ra sự cố mạng khuôn viên |
| ---------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- |
| Tòa nhà A (người chủ trì ZPLS)     | ☑️Tòa nhà A, B và C                                           | ☑️Tòa nhà A, B và C                                        |
| Tòa nhà B (người chủ trì ZPLS)     | ☑️Tòa nhà A, B và C                                           | ☑️Tòa nhà A, B và C                                        |
| Tòa nhà C (người chủ trì ZPLS)     | ☑️Tòa nhà A, B và C                                           | ☑️Tòa nhà A, B và C                                        |

#### <mark style="color:xanh dương;">Người dùng di động luôn đăng ký với mô-đun ZPLS được liên kết với cơ sở gốc của họ</mark>

Khi người dùng hoặc Thiết bị được Thêm vào Zoom Phone, một cơ sở “gốc” được liên kết tĩnh với người dùng hoặc Thiết bị đó cho đến khi được cập nhật khác đi bởi quản trị viên tài khoản. Điều này có nghĩa là nếu một người dùng di chuyển đến một Vị trí vật lý nằm ngoài cơ sở gốc được liên kết của họ, như một tòa nhà văn phòng được liên kết với một cơ sở khác, Zoom sẽ không tự động điều chỉnh cơ sở được gắn với người dùng đó. Do đó, nếu người dùng mất kết nối với các trung tâm dữ liệu Zoom Phone, người dùng sẽ cố gắng đăng ký với mô-đun ZPLS được liên kết với cơ sở gốc của họ, ngay cả khi họ đang ở một Vị trí khác.

{% hint style="success" %}
**Ví dụ:**

Một người dùng trong khuôn viên nhiều cơ sở có cơ sở tại Tòa nhà A (Cơ sở A) và tạm thời chuyển sang Tòa nhà B (Cơ sở B) để tham gia một cuộc họp. Trong khi họ ở Tòa nhà B, một Sự kiện ảnh hưởng đến dịch vụ xảy ra và chế độ sống sót được kích hoạt. Mặc dù người dùng đang ở trong Tòa nhà B, vì Cơ sở A là cơ sở gốc của họ, ứng dụng khách của người dùng sẽ cố gắng kết nối với mô-đun ZPLS được cấp phát tại cơ sở gốc của họ trong tòa nhà A.

Trong tình huống này, trạng thái sống sót của một người dùng được xác định bởi khả năng của Thiết bị người dùng trong việc đăng ký với mô-đun ZPLS trong cơ sở gốc của họ qua mạng khu vực khuôn viên. Nếu mạng khu vực khuôn viên bị ngắt trong khi người dùng ở xa cơ sở gốc của họ, người dùng không thể hưởng lợi từ mô-đun sống sót.
{% 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/vi/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.