> 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/ja/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を割り当てます。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/ja/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.