직접 라우팅을 위한 로컬 미디어 최적화 문제

직접 라우팅에 대한 LMO(로컬 미디어 최적화)가 예상대로 작동하지 않을 수 있습니다. instance 경우 Microsoft Teams는 및 X-Ms-MediaPath 헤더를 X-Ms-UserLocation 보내지 않거나 헤더에 X-Ms-UserLocation 잘못된 위치가 포함되어 있거나 호출이 실패합니다.

이 문서에서는 이러한 문제를 해결하기 위해 시도할 수 있는 몇 가지 해결 방법을 제공합니다.

X-Ms-UserLocation 및 X-Ms-MediaPath 헤더가 전송되지 않음

LMO에는 X-Ms-UserLocation 및 X-Ms-MediaPath 헤더가 필요합니다. 이러한 헤더가 전송되지 않는 가장 일반적인 이유 중 하나는 게이트웨이가 LMO에 대해 올바르게 구성되지 않았기 때문입니다.

게이트웨이 구성을 검사 다음 Get-CsOnlinePSTNGateway cmdlet을 실행합니다.

Get-CSOnlinePSTNGateway | Select Identity, Fqdn, Enabled, MediaBypass, GatewaySiteId, ProxySbc, BypassMode

LMO를 사용하도록 설정하려면 이 cmdlet에서 선택한 모든 속성이 설정되어 있는지 확인합니다. 이는 에 특히 중요합니다 BypassMode. 다음은 이 cmdlet의 출력 예입니다.

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 주소를 식별한 다음 목록에 추가합니다.

1. Microsoft Teams 로그 파일을 엽니다.

2. MSTeams 진단 로그 [날짜]__[시간]_calling.txt 파일에서 클라이언트에 대해 나열된 공용 IP 주소를 찾습니다. 이 파일의 예는 다음과 같습니다.

   

3. Get-CsTenantTrustedIPAddress cmdlet을 실행하여 신뢰할 수 있는 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 주소가 이 목록에서 누락되었습니다.

4. New-CsTenantTrustedIPAddress cmdlet을 실행하여 누락된 IP 주소를 목록에 추가합니다.

   New-CsTenantTrustedIPAddress -IPAddress 123.456.123.0 -MaskBits 29 -Description "Seattle site trusted IP"
   

   cmdlet의 출력은 다음 예제와 유사해야 합니다.

   

   이제 클라이언트의 IP 주소가 신뢰할 수 있는 IP 주소 목록에 추가된 것을 볼 수 있습니다.

5. 새로 추가된 IP 주소를 즉시 인식할 수 있도록 Teams 클라이언트를 다시 시작합니다. 그렇지 않으면 목록을 업데이트하는 데 최대 30분이 걸릴 수 있습니다.

   다시 시작한 후 Teams는 다음 예제와 같이 신뢰할 수 있는 IP 주소 목록에서 클라이언트의 IP 주소와 일치하는 항목을 찾습니다.

   

LMO 및 LBR이 모두 사용하도록 설정된 경우 수신 호출이 실패하거나 음성 메일로 이동합니다.

이 문제가 발생할 가능성이 가장 높은 이유 중 하나는 호출이 수신된 SBC(세션 테두리 컨트롤러)에서 헤더 또는 라우팅 정보가 올바르게 구성되지 않았기 때문입니다.

SBC에서 보낸 SIP(세션 시작 프로토콜) 메시지 헤더에 다음 정보가 포함되어 있는지 확인하고 잘못된 경우 업데이트합니다.

• SIP URI에는 지역 SBC의 FQDN(정규화된 도메인 이름)이 포함됩니다.
• Contact 헤더에는 지역 SBC의 FQDN이 포함됩니다.
• Record-Route 프록시 SBC의 FQDN을 포함합니다.

지역 SBC에 대해 프록시 SBC가 정의되지 않은 경우 Record-Route만 확인됩니다. Record-Route 없는 경우 연락처 헤더가 선택됩니다.

헤더가 올바르게 구성된 경우 SBC에서 잘못 구성된 라우팅으로 인해 문제가 발생할 수 있습니다.

SBC에 LBR(Location-Based 라우팅)이 사용하도록 설정되어 있는지 확인합니다. 매개 변수를 GatewaySiteLbrEnabledTrue로 설정해야 합니다.

또한 호출을 시작하는 클라이언트와 동일한 사이트에 SBC를 할당해야 합니다.

참고: 프록시 SBC를 LBR에 사용하도록 설정할 필요가 없습니다.

SBC 할당이 올바른지 확인하려면 Teams 클라이언트 로그에 등록된 사용자 사이트를 식별하고 SBC의 할당 정보와 비교합니다.

1. Microsoft Teams 로그 파일을 엽니다.

2. MSTeams 진단 로그 [날짜]__[시간]_calling.txt 파일에 나열된 사용자 사이트 정보를 식별합니다. 이 파일의 예는 다음과 같습니다.

   

3. Get-CsOnlinePSTNGateway cmdlet을 실행하여 SBC의 구성을 검사. 표시되는 출력은 다음 예제와 유사합니다.

   

4. 2단계의 출력에서 사용자 사이트 정보에 나열된 매개 변수의 networksiteId 값은 "베트남"입니다. 그러나 3단계의 출력에서 SBC의 구성에 나열된 해당 GatewaySiteId 매개 변수의 값은 "인도"입니다. 이는 일치하지 않습니다. SBC의 구성을 업데이트하려면 다음과 같이 Set-CsOnlinePSTNGateway cmdlet을 실행합니다.

   Set-CSOnlinePSTNGateway -Identity "VNsbc.contoso.com" -GatewaySiteID "Vietnam"
   

   다음으로 cmdlet을 Get-CsOnlinePSTNGateway 실행하여 SBC의 업데이트된 구성을 확인합니다. 이제 출력에 매개 변수에 대한 올바른 값이 GatewaySiteId 표시됩니다.

   

아직 해결되지 않았습니까? Microsoft 커뮤니티로 이동하세요.