ダイレクト ルーティングを計画する
ダイレクト ルーティングを使用すると、サポートされている顧客が提供するセッション ボーダー コントローラー (SBC) を Microsoft Teams Phone に接続できます。 この機能を使用すると、次の図に示すように、Teams とのオンプレミスの公衆交換電話網 (PSTN) 接続を構成できます。
Microsoft Teamsを使用
Direct Routing のデプロイを計画することは、実装を成功させるために重要です。 この記事では、インフラストラクチャとライセンスの要件について説明し、SBC 接続に関する情報を提供します。 構成を開始する前に、この記事を必ずお読みください。これについては、「 ダイレクト ルーティングの構成」で説明されています。
ダイレクト ルーティングを使用すると、SBC をほぼすべてのテレフォニー トランクに接続したり、サードパーティの PSTN 機器と相互接続することができます。 ダイレクト ルーティングを使用すると、次のことが可能になります。
Teams Phone でほぼすべての PSTN トランクを使用します。
サード パーティのプライベート ブランチ交換 (PBX)、アナログ デバイス、Teams など、顧客所有のテレフォニー機器間の相互運用性を構成します。
Microsoft では、Microsoft 通話プランなどのクラウド内の音声ソリューションも提供しています。 ただし、次の場合は、直接ルーティングが組織に最適な場合があります。
Microsoft 通話プランは、お客様の国/地域では利用できません。
組織では、サード パーティ製のアナログ デバイス、コール センターなどへの接続が必要です。
組織は PSTN 通信事業者と既存の契約を持っています。
音声ソリューションの詳細については、「Teams 音声 ソリューションを計画する」を参照してください。
ダイレクト ルーティングでは、ユーザーがスケジュールされた会議に参加すると、ダイヤルイン番号は Microsoft 電話会議サービスによって提供されます。これには適切なライセンスが必要です。 ダイヤルアウト時に、電話会議はオンライン通話機能を使用して通話を発信します。これには適切なライセンスが必要です。 ユーザーが Microsoft 電話会議ライセンスを持っていない場合、通話はダイレクト ルーティング経由でルーティングされます。 詳細については、「 電話会議を使用した直接ルーティング」を参照してください。
ダイレクト ルーティングでは、Microsoft 通話プランの別のライセンスを持つユーザーもサポートされています。 詳細については、「 通話プランとオペレーター接続を使用したダイレクト ルーティング」を参照してください。
インフラストラクチャの要件
ダイレクト ルーティングを展開するためのサポートされる SBC、ドメイン、およびその他のネットワーク接続要件のインフラストラクチャ要件を次の表に示します。
インフラストラクチャ要件 | 次のものが必要です |
---|---|
セッション ボーダー コントローラー (SBC) | サポートされている SBC。 詳細については、「 サポートされる SBC」を参照してください。 |
SBC に接続されているテレフォニー トランク | SBC に接続されている 1 つ以上のテレフォニー トランク。 一方の端では、SBC はダイレクト ルーティングを介して Teams Phone に接続します。 SBC は、PBX、アナログ テレフォニー アダプターなどのサード パーティのテレフォニー エンティティにも接続できます。 SBC に接続されている PSTN 接続オプションは機能します。 (SBC への PSTN トランクの構成については、SBC ベンダーまたはトランク プロバイダーを参照してください)。 |
Microsoft 365 組織 | Microsoft Teams ユーザーのホームに使用する Microsoft 365 組織、および SBC への構成と接続。 |
ユーザー レジストラー | ユーザーは Microsoft 365 に所属している必要があります。 会社にオンプレミスの Skype for Business 環境があり、Microsoft 365 へのハイブリッド接続がある場合、オンプレミスのユーザーに対して Teams で音声を有効にすることはできません。 ユーザーのレジストラーを確認するには、次の Teams PowerShell コマンドレットを使用します。 Get-CsOnlineUser -Identity <user> | fl HostingProvider コマンドレットの出力には、次の情報が表示されます。 HostingProvider : sipfed.online.lync.com |
ドメイン | Microsoft 365 または Office 365 組織に追加された 1 つ以上のドメイン。 テナント用に自動的に作成される既定のドメイン *.onmicrosoft.com は使用できません。 ドメインを表示するには、次の Teams PowerShell コマンドレットを使用します。 Get-CsTenant | fl Domains ドメインと Microsoft 365 または Office 365 組織の詳細については、「 ドメインに関する FAQ」を参照してください。 |
SBC のパブリック IP アドレス | SBC への接続に使用できるパブリック IP アドレス。 SBC の種類に基づいて、SBC は NAT を使用できます。 |
SBC の完全修飾ドメイン名 (FQDN) | SBC の FQDN。FQDN のドメイン部分は、Microsoft 365 または Office 365 組織に登録されているドメインの 1 つです。 詳細については、「 SBC ドメイン名」を参照してください。 |
SBC のパブリック DNS エントリ | SBC FQDN をパブリック IP アドレスにマッピングするパブリック DNS エントリ。 |
SBC のパブリック信頼証明書 | ダイレクト ルーティングとのすべての通信に使用する SBC の証明書。 詳細については、「 SBC のパブリック信頼された証明書」を参照してください。 |
ダイレクト ルーティングの接続ポイント | ダイレクト ルーティングの接続ポイントは、次の 3 つの FQDN です。sip.pstnhub.microsoft.com – グローバル FQDN、最初に試行する必要があります。sip2.pstnhub.microsoft.com セカンダリ FQDN、地理的に 2 番目の優先度のリージョンにマップされます。sip3.pstnhub.microsoft.com – 第 3 の FQDN、地理的に 3 番目の優先度のリージョンにマップされます。構成要件については、「 SIP シグナリング: FQDN」を参照してください。 |
ダイレクト ルーティング メディアのファイアウォール IP アドレスとポート | SBC は、クラウド内の次のサービスと通信します。 - シグナリングを処理する SIP プロキシ - メディア バイパスがオンになっている場合を除き、メディア を処理するメディア プロセッサ これら 2 つのサービスは、このドキュメントで後述する Microsoft Cloud で個別の IP アドレスを持ちます。 詳細については、「URL と IP アドレス範囲」の「Microsoft Teams」セクションを参照してください。 |
メディア トランスポート プロファイル | TCP/RTP/SAVP UDP/RTP/SAVP |
ライセンスとその他の要件
ダイレクト ルーティング ユーザーには、Microsoft 365 で次のライセンスが割り当てられている必要があります。
- Teams Phone
- Microsoft Teams
電話会議ライセンスが必要な場合の詳細については、「 電話会議を使用した直接ルーティング」を参照してください。
ダイレクト ルーティングでは、Microsoft 通話プランのライセンスを持つユーザーもサポートされています。 詳細については、「 通話プランとオペレーター接続を使用したダイレクト ルーティング」を参照してください。
ライセンスの詳細については、「 Microsoft Teams ライセンス と Microsoft Teamsアドオン ライセンス」を参照してください。
注: ダイレクト ルーティングは、アイランド モードではサポートされていません。
電話会議を使用したダイレクト ルーティング
このセクションでは、ダイレクト ルーティングと電話会議を使用する場合の要件と考慮事項について説明します。
GCC High および DoD G5 ユーザーの場合、Microsoft では、ダイレクト ルーティングを構成し、組織のテナントに電話会議番号を追加するまで、G5 に含まれる電話会議コンポーネントを無効にすることをお勧めします。
GCC High および DoD G3 ユーザーの場合、Microsoft では、ダイレクト ルーティングを構成し、組織のテナントに電話会議番号を追加するまで、電話会議ライセンス アドオンを割り当てないようにすることをお勧めします。
詳細については、「 GCC High と DoD のダイレクト ルーティングを使用した電話会議」を参照してください。
計画外の通話エスカレーションと電話会議ライセンス
Teams ユーザーは、1 対 1 の Teams から PSTN または Teams 間の通話を開始し、PSTN 参加者を追加できます。 通話のパスは、通話をエスカレートするユーザーに Microsoft 電話会議ライセンスが割り当てられているかどうかによって異なります。
通話をエスカレートする Teams ユーザーに Microsoft 電話会議ライセンスが割り当てられている場合、エスカレーションは Microsoft 電話会議サービスを通じて行われます。 既存の通話に招待されたリモート PSTN 参加者は、着信通話に関する通知を受け取り、エスカレーションを開始した Teams ユーザーに割り当てられた Microsoft ブリッジの数を確認します。
通話をエスカレートする Teams ユーザーに Microsoft 電話会議ライセンスが割り当てられない場合、エスカレーションはダイレクト ルーティング インターフェイスに接続されているセッション ボーダー コントローラーを介して行われます。 通話に招待されたリモート PSTN 参加者は、着信通話に関する通知を受け取り、エスカレーションを開始した Teams ユーザーの数を確認します。 エスカレーションに使用される特定の SBC は、ユーザーのルーティング ポリシーによって定義されます。
次のことを確認する必要があります。
CsOnlineVoiceRoutingPolicy がユーザーに割り当てられます。
プライベート呼び出しを許可するは、Microsoft Teamsのテナント レベルで有効になっています。
通話プランとオペレーター接続を使用したダイレクト ルーティング
ダイレクト ルーティングでは、Microsoft 通話プランのライセンスを取得しているか、オペレーター接続電話番号を割り当てられているユーザーもサポートしています。 通話プランまたはオペレーター接続が有効な Teams Phone ユーザーは、ダイレクト ルーティング インターフェイスを使用して一部の通話をルーティングできます。
同じユーザーの通話プランまたはオペレーター接続とダイレクト ルーティング接続の混在は省略可能ですが、便利な場合があります。 たとえば、ユーザーに Microsoft 通話プランまたはオペレーター接続番号が割り当てられているが、SBC を使用していくつかの呼び出しをルーティングする場合です。
最も一般的なシナリオの 1 つは、サード パーティの PBX への呼び出しです。 この構成では、サード パーティの PBX に接続されている電話への呼び出しはダイレクト ルーティングを使用してルーティングされるため、PSTN を経由せずにエンタープライズ ネットワーク内に留まります。 一方、他のすべての呼び出しは、ユーザーに割り当てられた PSTN 接続方法 (Microsoft 通話プランまたはオペレーター接続) に基づいて PSTN にルーティングされます。
Teams Phone ライセンスの詳細については、「 Microsoft Teamsアドオン ライセンス」を参照してください。
サポートされているエンドポイント
エンドポイントとして次のものを使用できます。
任意の Teams クライアント。
共通エリア電話。 ダイレクト ルーティングを使用して共通エリア電話を設定する場合、通話プラン ライセンスは必要ありません。 詳細については、「 Microsoft Teamsの共通エリア電話を設定する」を参照してください。
SBC ドメイン名
SBC ドメイン名は、テナントのドメインに登録されている名前のいずれかからである必要があります。
次の表は、テナントに登録されている DNS 名の例、名前を SBC の FQDN として使用できるかどうか、および有効な FQDN 名の例を示しています。 SBC の FQDN 名に *.onmicrosoft.com テナントを使用できないことに注意してください。
DNS 名 | SBC FQDN に使用できます | FQDN 名の例 |
---|---|---|
contoso.com | Yes |
有効な名前: sbc1.contoso.com ssbcs15.contoso.com europe.contoso.com |
contoso.onmicrosoft.com | いいえ | *.onmicrosoft.com ドメインの使用は、SBC 名ではサポートされていません |
新しいドメイン名を使用するとします。 たとえば、テナントには、テナントに登録されているドメイン名として contoso.com があり、sbc1.sip.contoso.com を使用する必要があります。
SBC と名前 sbc1.sip.contoso.com をペアリングする前に、テナントのドメインにドメイン名 sip.contoso.com を登録する必要があります。 ドメイン名を登録する前に SBC と sbc1.sip.contoso.com をペアリングしようとすると、"このテナント用に構成されていないため、"sbc1.sip.contoso.com" ドメインを使用できません" というエラーが表示されます。
ドメイン名を追加したら、UPN user@sip.contoso.com を使用してユーザーを作成し、Teams ライセンスを割り当てる必要があります。 テナントのドメインに追加されたドメイン名を完全にプロビジョニングし、新しい名前のユーザーを作成し、ユーザーにライセンスを割り当てるには、最大で 24 時間かかることがあります。
会社が 1 つのテナントに複数の SIP アドレス空間を持っている可能性があります。 たとえば、ある会社は SIP アドレス空間として contoso.com し、2 つ目の SIP アドレス空間として fabrikam.com します。 一部のユーザーはアドレス user@contoso.com を持ち、一部のユーザーはアドレス user@fabrikam.comを持っています。
SBC で必要な FQDN は 1 つだけであり、ペアのテナント内の任意のアドレス空間からユーザーにサービスを提供できます。 たとえば、sbc1.contoso.com という名前の SBC は、これらの SIP アドレス空間が同じテナントに登録されている限り、 user@contoso.com および user@fabrikam.com アドレスを持つユーザーの PSTN トラフィックを受信および送信できます。
注意
Azure Communication Services ダイレクト ルーティングの SBC FQDN は、Teams ダイレクト ルーティングの SBC FQDN とは異なる必要があります。
SBC のパブリック信頼証明書
Microsoft では、認定署名要求 (CSR) を生成して、SBC の証明書を要求することをお勧めします。 SBC の CSR の生成に関する具体的な手順については、SBC ベンダーが提供する相互接続の手順またはドキュメントを参照してください。
注意
ほとんどの証明機関 (CA) では、秘密キーサイズが少なくとも 2048 である必要があります。 CSR を生成する場合は、この点に注意してください。
証明書には、共通名 (CN) またはサブジェクト別名 (SAN) フィールドとして SBC FQDN が必要です。
または、ダイレクト ルーティングでは CN または SAN のワイルドカードがサポートされており、ワイルドカードは標準 の RFC HTTP Over TLS に準拠している必要があります。
たとえば、*.contoso.com を使用します。これは SBC FQDN sbc.contoso.com と一致しますが、sbc.test.contoso.com と一致しません。
ダイレクト ルーティング SIP インターフェイスは、Microsoft 信頼されたルート証明書プログラムの一部である証明機関 (CA) によって署名された証明書のみを信頼します。 プログラムの一部である CA が SBC 証明書に署名していることを確認します。 また、証明書の拡張キー使用法 (EKU) 拡張機能に、サーバー認証とクライアント認証が含まれていることも確認します。
詳細については、「 プログラム要件 - Microsoft 信頼されたルート プログラム 」および「 含まれる CA 証明書の一覧」を参照してください。
注意
2023 年 8 月末、Microsoft 365 は、新しい CA "DigiCert Global Root G2" によって発行された TLS 証明書を使用するようにサービスを更新します。 サービスに影響を与える可能性のあるエラーを回避するには、新しいルート CA を含むように SBC の証明書ルート ストアを更新する必要があります。 詳細については、「 SIP 証明書から MSPKI 証明機関への変更」を参照してください。
Office 365 GCCH および DoD 環境での直接ルーティングの場合、次のいずれかのルート証明機関が証明書を生成する必要があります。
- DigiCert グローバル ルート CA
- DigiCert High Assurance EV Root CA
注意
SBC 上の Teams 接続に対して相互 TLS (MTLS) サポートが有効になっている場合は、Teams TLS コンテキストの SBC 信頼されたルート ストアに Baltimore CyberTrust Root 証明書と DigiCert グローバル ルート G2 証明書をインストールする必要があります。 (これは、Microsoft サービス証明書でこれら 2 つのルート証明書のいずれかを使用するためです)。これらのルート証明書をダウンロードするには、「 Microsoft 365 Encryption チェーン」を参照してください。 詳細については、「 Office TLS 証明書の変更」を参照してください。
MTLS 接続が Teams インフラストラクチャから発信されていることを確認するには、Teams サーバー側の証明書に次のチェックを実装するように SBC を構成する必要があります。
証明書発行チェーンが、次のいずれかのルート CA から発生していることを確認します。
証明書 "サブジェクトの別名" に "sip.pstnhub.microsoft.com" が含まれていることを確認します。
SIP シグナリング: FQDN、ポート、フェールオーバー メカニズム
ダイレクト ルーティングは、次の環境で提供されます。
- Microsoft 365 または Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
GCC、GCC High、DoD などの政府環境の詳細については、「 Office 365 と米国政府の環境」を参照してください。
以降のセクションでは、FQDN、ポート、フェールオーバー メカニズムに関する情報について説明します。
SIP シグナリング: FQDN
次のセクションでは、さまざまな Microsoft クラウド環境の FQDN 接続ポイントについて説明します。
Microsoft 365、Office 365、および Office 365 GCC 環境
これらの環境では、ダイレクト ルーティングの接続ポイントは次の 3 つの FQDN です。
sip.pstnhub.microsoft.com – グローバル FQDN – を最初に試す必要があります。 SBC がこの名前を解決する要求を送信すると、Microsoft Azure DNS サーバーは、SBC に割り当てられているプライマリ Azure データセンターを指す IP アドレスを返します。 割り当ては、データセンターのパフォーマンス メトリックと SBC への地理的近接性に基づいています。 返される IP アドレスは、プライマリ FQDN に対応します。
sip2.pstnhub.microsoft.com – セカンダリ FQDN – 地理的に 2 番目の優先度リージョンにマップされます。
sip3.pstnhub.microsoft.com – 第 3 の FQDN – 地理的に 3 番目の優先度のリージョンにマップされます。
次の 3 つの FQDN を順番に配置する必要があります。
最適なエクスペリエンスを提供します (読み込みの少なく、最初の FQDN のクエリによって割り当てられた SBC データセンターに最も近い)。
SBC からの接続が確立され、一時的な問題が発生しているデータセンターにフェールオーバーを提供します。 詳細については、「 フェールオーバー メカニズム」を参照してください。
FQDN sip.pstnhub.microsoft.com、sip2.pstnhub.microsoft.com、sip3.pstnhub.microsoft.com は、次のサブネットの IP アドレスに解決されます。
- 52.112.0.0/14
- 52.122.0.0/15
ファイアウォールでこれらすべての IP アドレス範囲のポートを開き、アドレスとの間でシグナリングを行う送受信トラフィックを許可する必要があります。
注: Teams SIP エンドポイントからの SBC への受信 SIP トラフィックは、前述の FQDN から解決される IP だけでなく、これらのサブネット内のすべての IP から発信される可能性があります。 SIP ピアリングを設定する方法の詳細については、SBC のドキュメントを参照してください。
Office GCC DoD 環境
Office GCC DoD 環境では、ダイレクト ルーティングの接続ポイントは次の FQDN です。
sip.pstnhub.dod.teams.microsoft.us – グローバル FQDN。 Office 365 DoD 環境は米国のデータ センターにのみ存在します。セカンダリ FQDN とターシャリ FQDN はありません。
FQDN sip.pstnhub.dod.teams.microsoft.us は、次のサブネットから IP アドレスに解決されます: 52.127.64.0/21
シグナリングのためにアドレスとの間の送受信トラフィックを許可するには、ファイアウォールでこれらのすべての IP アドレスのポートを開く必要があります。
Office 365 GCC High 環境
Office 365 GCC High 環境では、ダイレクト ルーティングの接続ポイントは次の FQDN です。
sip.pstnhub.gov.teams.microsoft.us – グローバル FQDN。 GCC High 環境は米国のデータ センターにのみ存在します。セカンダリ FQDN とターシャリ FQDN はありません。
FQDN sip.pstnhub.gov.teams.microsoft.us は、次のサブネットから IP アドレスに解決されます: 52.127.88.0/21
シグナリングのためにアドレスとの間の送受信トラフィックを許可するには、ファイアウォールでこれらのすべての IP アドレスのポートを開く必要があります。
SIP シグナリング: ポート
ダイレクト ルーティングが提供される Microsoft 365 または Office 365 環境では、次のポートを使用する必要があります。
交通 | 開始 | 終了 | 送信元ポート | 宛先ポート |
---|---|---|---|---|
SIP/TLS | SIP プロキシ | SBC | 1024 – 65535 | SBC で定義されている (Office 365 GCC High/DoD の場合は、ポート 5061 のみを使用する必要があります) |
SIP/TLS | SBC | SIP プロキシ | SBC で定義されている | 5061 |
SIP シグナリング: フェールオーバー メカニズム
sip.pstnhub.microsoft.com を解決するために、SBC は DNS クエリを作成します。 SBC の場所とデータセンターのパフォーマンス メトリックに基づいて、プライマリ データセンターが選択されます。
プライマリ データセンターで問題が発生した場合、SBC は sip2.pstnhub.microsoft.com を試行します。これにより、2 番目に割り当てられたデータセンターに解決されます。 まれに、2 つのリージョンのデータセンターを使用できない場合、SBC は最後の FQDN (sip3.pstnhub.microsoft.com) を再試行します。これにより、3 次データセンター IP が提供されます。
次の表は、プライマリ、セカンダリ、およびターシャリー の各データセンター間の関係をまとめたものです。
プライマリ データセンターが | EMEA | NOAM | アジア |
---|---|---|---|
セカンダリ データセンター (sip2.pstnhub.microsoft.com) | 私達 | EU | 私達 |
第 3 データセンター (sip3.pstnhub.microsoft.com) | アジア | アジア | EU |
メディア トラフィック: ポート範囲、メディア プロセッサ、CODECS
メディア トラフィック: ポート範囲
メディア バイパスなしでダイレクト ルーティングを展開する場合は、次の要件が適用されます。 メディア バイパスのファイアウォール要件については、「 ダイレクト ルーティングを使用したメディア バイパスの計画」を参照してください。
メディア トラフィックは、Microsoft Cloud 内の別のサービスとの間で送受信されます。 メディア トラフィックの IP アドレス範囲は次のとおりです。
注意
このドキュメントに記載されている IP 範囲はダイレクト ルーティングに固有であり、Teams クライアントに関して推奨される IP 範囲とは異なる場合があります。
Microsoft 365、Office 365、および Office 365 GCC 環境
Microsoft 365、Office 365、および Office 365 GCC 環境では、IP アドレス範囲は次のとおりです。
- 52.112.0.0/14 (52.112.0.0 から 52.115.255.255 への IP アドレス)
- 52.120.0.0/14 (52.120.0.0 から 52.123.255.255 への IP アドレス)
Office 365 DoD 環境
Office 365 DoD 環境では、IP アドレス範囲は次のとおりです。
- 52.127.64.0/21
Office 365 GCC High 環境
Office 365 GCC High 環境では、IP アドレス範囲は次のとおりです。
- 52.127.88.0/21
すべての環境
メディア プロセッサのポート範囲を次の表に示します。
交通 | 開始 | 終了 | 送信元ポート | 宛先ポート |
---|---|---|---|---|
UDP/SRTP | メディア プロセッサ | SBC | 3478-3481 および 49152 – 53247 | SBC で定義されている |
UDP/SRTP | SBC | メディア プロセッサ | SBC で定義されている | 3478-3481 および 49152 – 53247 |
注意
Microsoft では、SBC での同時呼び出しごとに少なくとも 2 つのポートを推奨しています。
メディア トラフィック: プロセッサの地域
メディア トラフィックは、メディア プロセッサと呼ばれるコンポーネントを通過します。 メディア プロセッサは、次のように SIP プロキシと同じデータセンターに配置されます。
- NOAM (米国中南部、米国西部と米国東部のデータセンターに 2 つ)
- ヨーロッパ (英国南部、フランス中部、アムステルダム、ダブリンのデータセンター)
- アジア (シンガポール データセンター)
- 日本 (JP 東日本および西データセンター)
- オーストラリア (AU 東部および南東部のデータセンター)
- LATAM (ブラジル南部)
メディア トラフィック: コーデック
次のセクションでは、メディア トラフィックのコーデックについて説明します。
SBC とクラウド メディア プロセッサまたは Microsoft Teams クライアント間のレッグ
メディア バイパス ケースと非バイパス ケースの両方に適用されます。
セッション ボーダー コントローラーとクラウド メディア プロセッサ (メディア バイパスなし) 間、または Teams クライアントと SBC (メディア バイパスが有効な場合) の間の直接ルーティング インターフェイスでは、次のコーデックを使用できます。
- 非メディア バイパス (SBC からクラウド メディア プロセッサ): SILK、G.711、G.722、G.729
- メディア バイパス (SBC から Teams クライアント): SILK、G.711、G.722、G.729
オファーから望ましくないコーデックを除外することで、セッション ボーダー コントローラーで特定のコーデックを強制的に使用できます。
クライアントとクラウド メディア プロセッサMicrosoft Teams間の脚
メディア以外のバイパス ケースにのみ適用されます。 メディア バイパスでは、メディアは Teams クライアントと SBC の間で直接流れます。
クラウド メディア プロセッサと Teams クライアントの間の脚では、SILK または G.722 が使用されます。 この脚のコーデックの選択は、複数のパラメーターを考慮した Microsoft アルゴリズムに基づいています。
注意
メディアの再ターゲット設定はサポートされていません。 通話中に、ダイレクト ルーティング SBC SIP 再招待 (オファー) に新しいメディア IP アドレス、ポート、またはトランスポートが含まれている場合、メディアは PSTN Hub から新しいターゲットに送信されません。 RFC 3264 8.3.1 では、メディアの再ターゲットのサポートは省略可能です (必須ではありません)。
サポートされているセッション ボーダー コントローラー (SBC)
Microsoft では、ダイレクト ルーティングとペアリングする認定された SBC のみがサポートされています。 Enterprise Voice は企業にとって重要であるため、Microsoft は選択した SBC で集中的なテストを実行し、SBC ベンダーと連携して 2 つのシステムに互換性があることを確認します。
検証されたデバイスは、Teams ダイレクト ルーティングの認定済みとして一覧表示されます。 認定されたデバイスは、すべてのシナリオで動作することが保証されています。
サポートされている SBC の詳細については、「 ダイレクト ルーティングの認定を受けたセッション ボーダー コントローラー」を参照してください。
サポートの境界
Microsoft では、認定されたデバイスで使用する場合にのみ、直接ルーティングを使用した Teams Phone がサポートされます。 問題が発生した場合は、まず SBC ベンダーのカスタマー サポートにお問い合わせください。 必要に応じて、SBC ベンダーは内部チャネルを通じて問題を Microsoft にエスカレートします。 Microsoft は、認定されていないデバイスが直接ルーティングを介して Teams Phone に接続されているサポート ケースを拒否する権利を留保します。 Microsoft が、お客様の直接ルーティングの問題がベンダーの SBC デバイスにあると判断した場合、お客様は SBC ベンダーに再びサポートを提供する必要があります。
関連項目
- ダイレクト ルーティングを構成する
- ビデオ セッション: Microsoft Teamsでのダイレクト ルーティング。