ダイレクト ルーティングのローカル メディア最適化 (LMO) が期待どおりに機能しない場合があります。 たとえば、Microsoft Teams は ヘッダーと ヘッダーをX-Ms-UserLocation送信しないか、ヘッダーにX-Ms-UserLocation間違った場所が含まれているか、呼び出しが失敗X-Ms-MediaPathします。
この記事では、これらの問題を解決するための解決策をいくつか示します。
X-Ms-UserLocation ヘッダーと X-Ms-MediaPath ヘッダーは送信されません
LMO には X-Ms-UserLocation と X-Ms-MediaPath ヘッダーが必要です。 これらのヘッダーが送信されない最も一般的な理由の 1 つは、ゲートウェイが LMO 用に正しく構成されていないことです。
ゲートウェイ構成をチェックするには、次の Get-CsOnlinePSTNGateway コマンドレットを実行します。
Get-CSOnlinePSTNGateway | Select Identity, Fqdn, Enabled, MediaBypass, GatewaySiteId, ProxySbc, BypassMode
LMO を有効にするには、このコマンドレットで選択されているすべてのプロパティが設定されていることを確認します。 これは、 にとって特に重要 BypassModeです。 このコマンドレットからの出力の例を次に示します。
Identity : VNsbc.contoso.com
Fqdn : VNsbc.contoso.com
Enabled : True
MediaBypass : True
GatewaySiteId : Vietnam
ProxySbc : proxysbc.contoso.com
BypassMode : Always
Identity : proxysbc.contoso.com
Fqdn : proxysbc.contoso.com
Enabled : True
MediaBypass : True
GatewaySiteId : Singapore
ProxySbc :
BypassMode : Always
メモ： ここに表示される値は、表示される値とは異なる場合があります。
X-Ms-UserLocation ヘッダーで送信された場所が間違っている
ヘッダー内 X-Ms-UserLocation のネットワークの場所の情報が 外部として指定されているが、 内部の値が表示されると予想される場合は、Teams クライアントのパブリック IP アドレスが信頼できる IP アドレスの一覧のエントリと一致しないことを意味します。
この問題を解決するには、Teams によって使用されるクライアントのパブリック IP アドレスを特定し、一覧に追加します。
Microsoft Teams ログ ファイルを開きます。
MSTeams Diagnostics Log [Date]__[Time]_calling.txt ファイルで、クライアントに一覧表示されているパブリック IP アドレスを探します。 このファイルの例を次に示します。
Get-CsTenantTrustedIPAddress コマンドレットを実行して、信頼された IP アドレスの一覧を取得します。
Get-CsTenantTrustedIPAddress表示される出力は次のようになります。
Identity : 192.168.0.0 RemoteMachine : WU22A00TAD02.lync2A001.local MaskBits : 24 Description : Private IP subnet IPAddress : 192.168.0.0 Element : <TrustedIPAddress IPAddress="192.168.0.0" MaskBits="24" Description="Private IP subnet" xmlns="urn:schema:Microsoft.Rtc.Management.Settings.TenantNetworkConfiguration.2017" />手順 2 で識別されたクライアントの IP アドレスがこの一覧に表示されていないことに注意してください。
New-CsTenantTrustedIPAddress コマンドレットを実行して、不足している IP アドレスを一覧に追加します。
New-CsTenantTrustedIPAddress -IPAddress 123.456.123.0 -MaskBits 29 -Description "Seattle site trusted IP"コマンドレットの出力は、次の例のようになります。
クライアントの IP アドレスが信頼された IP アドレスの一覧に追加されたことがわかります。
新しく追加された IP アドレスをすぐに認識できるように、Teams クライアントを再起動します。 それ以外の場合、リストの更新には最大 30 分かかることがあります。
再起動後、Teams は、次の例に示すように、信頼された IP アドレスの一覧にクライアントの IP アドレスの一致を見つけます。
着信呼び出しが失敗するか、LMO と LBR の両方が有効になっている場合はボイスメールに移動します
この問題が発生する最も可能性の高い理由の 1 つは、呼び出しを受信したセッション ボーダー コントローラー (SBC) でヘッダーまたはルーティング情報が正しく構成されていないことです。
SBC から送信されたセッション開始プロトコル (SIP) メッセージ ヘッダーに次の情報が含まれていることを確認し、正しくない場合は更新します。
- SIP URI には、リージョン SBC の完全修飾ドメイン名 (FQDN) が含まれています。
- Contact ヘッダーには、リージョン SBC の FQDN が含まれています。
- Record-Route には、プロキシ SBC の FQDN が含まれています。
プロキシ SBC がリージョン SBC に対して定義されていない場合は、Record-Route のみがチェックされます。 Record-Route が見つからない場合は、[連絡先] ヘッダーがオンになります。
ヘッダーが正しく構成されている場合、SBC でのルーティングが正しく構成されていないことが原因で問題が発生する可能性があります。
SBC で Location-Based ルーティング (LBR) が有効になっていることを確認します。 パラメーターは GatewaySiteLbrEnabledTrue に設定する必要があります。
また、SBC は、呼び出しを開始しているクライアントと同じサイトに割り当てる必要があります。
メモ： プロキシ SBC を LBR に対して有効にする必要はありません。
SBC の割り当てが正しいかどうかを判断するには、Teams クライアント ログに登録されているユーザー サイトを特定し、SBC の割り当て情報と比較します。
Microsoft Teams ログ ファイルを開きます。
MSTeams Diagnostics Log [Date]__[Time]_calling.txt ファイルに一覧表示されているユーザー サイト情報を特定します。 このファイルの例を次に示します。
Get-CsOnlinePSTNGateway コマンドレットを実行して、SBC の構成をチェックします。 表示される出力は、次の例のようになります。
手順 2 の出力では、ユーザー サイト情報に
networksiteId記載されているパラメーターの値は "Vietnam" です。ただし、手順 3 の出力では、SBC の構成に記載されている同等GatewaySiteIdのパラメーターの値は "India" です。これは不一致です。 SBC の構成を更新するには、次のように Set-CsOnlinePSTNGateway コマンドレットを実行します。Set-CSOnlinePSTNGateway -Identity "VNsbc.contoso.com" -GatewaySiteID "Vietnam"次に、コマンドレットを
Get-CsOnlinePSTNGateway実行して、SBC の更新された構成を確認します。 これで、出力にパラメーターの正しい値がGatewaySiteId表示されます。
さらにヘルプが必要ですか? Microsoft コミュニティを参照してください。