Azure Communications Gateway の Provisioning API を統合する (プレビュー)
この記事では、Azure Communications Gateway の Provisioning API (プレビュー) と統合する必要がある場合について説明し、作業開始の概要を説明します。 これは、電気通信事業者のために働くソフトウェア開発者を対象としています。
Provisioning API を使用すると、顧客の詳細情報と、顧客に割り当てた番号を使用して Azure Communications Gateway を構成できます。 "バックエンド サービス同期" に Provisioning API を使用する場合は、エンタープライズ顧客の詳細情報と割り当てる番号を使用して、Operator Connect と Teams Phone Mobile の環境をプロビジョニングすることもできます。 このフロースルー プロビジョニングを使用すると、サービスの開始後に API を使って顧客と番号を管理するという Operator Connect と Teams Phone Mobile の要件を満たすことができます。
Provisioning API は REST API です。
Provisioning API と統合するかどうかは、選択した通信サービスによって異なります。
| 通信サービス | Provisioning API の統合 | 目的 |
|---|---|---|
| Microsoft Teams Direct Routing | サポート (番号管理ポータルの代わりとして) | - Direct Routing の各顧客に関連付けられたサブドメインを構成する。 - (Microsoft 365 環境での必要に応じて) 各顧客に固有の DNS レコードを生成する。 - 番号が Direct Routing に対して有効になっていることを示す。 - (省略可能) ネットワークへのメッセージのカスタム ヘッダーを構成する。 |
| オペレーター接続 | 推奨 | - (推奨) Operator Connect API との相互運用 (バックエンド サービス同期を使用) による Operator Connect の顧客のフロースルー プロビジョニング。 - (省略可能) ネットワークへのメッセージのカスタム ヘッダーを構成する。 |
| Teams Phone Mobile | 推奨 | - (推奨) Operator Connect API との相互運用 (バックエンド サービス同期を使用) による Teams Phone Mobile の顧客のフロースルー プロビジョニング。 |
| Zoom Phone Cloud Peering | サポート (番号管理ポータルの代わりとして) | - 番号が Zoom に対して有効になっていることを示す。 - (省略可能) ネットワークへのメッセージのカスタム ヘッダーを構成する。 |
| Azure Operator 通話保護プレビュー | サポート (番号管理ポータルの代わりとして) | - Azure Operator 通話保護で番号が有効になっていることを示す。 - Azure Operator 通話保護の自動プロビジョニング。 |
ヒント
Azure Communications Gateway の番号管理ポータルには、手動プロビジョニングに同等の機能が用意されています。 ただし、サービスを開始した後は、Operator Connect と Teams Phone Mobile のフロースルー プロビジョニングに番号管理ポータルを使用することはできません。
前提条件
「Azure Communications Gateway をデプロイする」を終了している必要があります。
Provisioning API (プレビュー) へのアクセスが許可されている IP アドレスを持つマシンにアクセスできる必要があります。 この IP アドレス (または範囲) の許可リストは、Azure Communications Gateway のデプロイの一部として構成されたものです。
Provisioning API (プレビュー) について学習し、BSS クライアントの変更を計画する
API と統合するには、Provisioning API に接続できる BSS クライアントを作成 (または更新) する必要があります。 Provisioning API では、マシン間の OAuth 2.0 クライアント資格情報認証フローがサポートされています。 クライアントは認証され、承認された API 呼び出しをユーザーの操作なしでそれ自体として行います。
API リファレンスの「主要な概念」と「例」の情報を使用して、API で使用できるリソースと、組織が行う必要がある要求を確認します。
- "アカウント" リソースは、オペレーターの顧客 (通常は企業) と、サービス プロビジョニングのための顧客ごとの設定の表現です。
- "番号" リソースはアカウントに属しています。 番号、番号で利用するサービス (たとえば Microsoft Teams Direct Routing)、追加の番号ごとの構成を表現します。
- "情報の要求 (RFI)" リソースは、Operator Connect と Teams Phone Mobile を通じてオペレーターからのサービスを受けることに関心を示したオペレーターの顧客 (通常は企業) の表現です。
Provisioning API には 1 分あたり 100 要求のレート制限があり、すべてのリソースを対象に適用されます。 複数のリソースを更新するバッチ要求は、1 つの要求としてカウントされます。
Azure Communications Gateway に接続するように BSS クライアントを構成する
Provisioning API (プレビュー) は、provapi.<base-domain> のポート 443 で使用できます。ここで <base-domain> は Azure Communications Gateway リソースのベース ドメインです。
ヒント
ベース ドメインを検索するには:
- Azure portal にサインインします。
- Azure Communications Gateway リソースの [概要] に移動し、[プロパティ] を選択します。
- Domain という名前のフィールドを見つけます。
DNS レコードの有効期間 (TTL) は 60 秒です。 リージョンに障害が発生すると、Azure では、別のリージョンを参照するように DNS レコードが更新されます。そのため、新しい DNS 参照を行うクライアントは新しいリージョンの詳細を受信します。 クライアントで新しい DNS 参照を行い、タイムアウトまたは 5xx 応答の 60 秒後に要求を再試行できるようにすることをお勧めします。
API リファレンスの「作業の開始」セクションを使用して、Azure と BSS クライアントを構成し、BSS クライアントが Provisioning API にアクセスできるようにします。
次の手順は、必要な Azure 構成をまとめたものです。 必要な構成値を含む詳細については、API リファレンスの「作業の開始」セクションを参照してください。
- Azure Communications Gateway のデプロイと同じ Azure テナントに BSS クライアントを登録します。 このプロセスにより、アプリの登録が作成されます。
- アプリ登録の所有者として自分自身を割り当てます。
- API リファレンスで定義されているスコープでアプリの登録を構成します。 この構成によって、アプリケーションが Provisioning API へのアクセスを許可されていることを Azure に指示します。
- テナントの管理者として、割り当てたアプリ ロールをアプリケーションで使用できるようにします。