> 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/zh/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/rest-of-world-elin-direct-number-model.md).

# 世界其他地区—ELIN / 直线号码模型

在美国和加拿大之外（以及对于不使用 Zoom 进行紧急呼叫的 BYOC 客户），地址无法直接在呼叫信令中传输。相反，系统依赖 ELIN（有关 ELIN 类型的完整说明，请参见第 2 节）。

**ELIN 流程：** 用户拨打紧急号码 **→** Zoom 通过网络数据检测位置 **→** 该位置的 ELIN 用作通话ID **→** PSAP 在运营商的数据库中查找该 ELIN **→** 预先注册的地址会返回给 PSAP 以便调度。

#### 工作原理

1. 管理员在 Zoom 中定义公司位置，每个位置都有一个 ELIN：一个电话号码，其地址已预先在运营商处注册，以匹配该位置
2. 当用户从检测到的位置发起紧急呼叫时，Zoom 会使用该位置的 ELIN 作为外拨通话ID
3. PSAP 接收呼叫，看到 ELIN，并在运营商的数据库中查找为该号码注册的地址
4. 对 ELIN 的回拨会路由到原始分机，持续约 2 小时。2 小时窗口结束后，通话ID 缓存将被清除，对该号码的任何回拨都会收到“呼叫无法完成”的消息。

#### 关键限制

* **地址必须预先由运营商配置：** 当管理员配置位置并分配 ELIN 时，该 ELIN 的地址必须已经在运营商处注册
* **每个位置都需要自己的 ELIN：** 一个在运营商数据库中注册了正确地址的专用电话号码
* **仅分机用户** 需要来自本地紧急池的 ELIN（见第 2 节）；池中号码的录制地址应设置为站点的默认地址
* **个人位置 - 不支持 ELIN：** 在美国/加拿大以外，个人位置不支持 ELIN。每个用户只能创建与其分配的 DID 数量相同的个人位置，因为用户的 DID 充当其个人位置的 ELIN。仅分机用户在此模型中根本无法创建个人位置，因为他们没有可作为 ELIN 使用的 DID。
* **激活最多可能需要 10 天：** 将 DID 的录制地址与运营商变更可能需要长达 10 天才能传播

#### 无位置匹配时的回退（世界其他地区）

如果未找到网络匹配，则会将发起方通话ID发送到 PSAP，PSAP 会对与该号码相关联的录制地址进行数据库查询。


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://library.zoom.com/technical-library/zh/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/rest-of-world-elin-direct-number-model.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.