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

• 적용 대상:

  Microsoft Teams

PSTN(공용 전화망) 음성은 음성 품질에 대한 기대가 높은 중요 비즈니스용 애플리케이션으로 간주됩니다. Microsoft Teams 전화 대한 직접 라우팅을 사용하면 전 세계 다양한 기업에서 다양한 네트워크 토폴로지 및 로컬 전화 통신 설정을 수용하기 위해 미디어 트래픽 흐름을 제어할 수 있습니다.

직접 라우팅을 위한 로컬 미디어 최적화를 사용하면 다음을 통해 음성 품질을 관리할 수 있습니다.

• Teams 클라이언트와 고객 SBC(세션 테두리 컨트롤러) 간에 미디어 트래픽이 흐르는 방식을 제어합니다.

• 회사 네트워크 서브넷의 경계 내에서 미디어를 로컬로 유지합니다.

• SCC가 개인 IP가 있는 회사 방화벽 뒤에 있고 Microsoft에 직접 표시되지 않더라도 Teams 클라이언트와 SCC 간에 미디어 스트림을 허용합니다.

로컬 미디어 최적화는 다음 두 가지 시나리오를 지원합니다.

• 기본 SIP(세션 시작 프로토콜) 트렁크에 연결된 중앙 집중식 SBC를 통해 모든 로컬 트렁크의 중앙 집중화 이 시나리오는 회사의 모든 로컬 지점에 전화 통신 서비스를 제공합니다.

• SCC의 가상 네트워크 토폴로지입니다. 이 시나리오에서 로컬 지점의 SBC는 외부 IP 주소를 통해 Teams 전화 표시되고 통신하는 중앙 프록시 SBC에 연결됩니다. 가상 네트워크 토폴로지에서 다운스트림 SCC는 내부 IP를 통해 통신하며 Teams 전화 직접 표시되지 않습니다.

이 문서에서는 기능 기능, 고객 시나리오 및 솔루션에 대해 설명합니다. 구성에 대한 자세한 내용은 로컬 미디어 최적화 구성을 참조하세요.

참고

인트라넷 경계 내에서 미디어를 로컬로 유지하려면 로컬 미디어 최적화를 사용하는 것이 좋습니다. 그러나 미디어 바이패스가 이미 있고 SCC의 공용 IP 주소만 사용하는 경우 로컬 미디어 최적화로 이동할 필요가 없습니다. Media Bypass를 계속 사용할 수 있습니다. 자세한 내용은 미디어 바이패스 계획을 참조하세요.

로컬 미디어 최적화를 지원하는 SBC 공급업체에 대한 자세한 내용은 직접 라우팅을 위해 인증된 세션 테두리 컨트롤러를 참조하세요.

지원되는 고객 시나리오

이 논의에서는 Contoso가 다음과 같이 전 세계에서 여러 비즈니스를 운영하고 있다고 가정합니다. (유럽 및 APAC 지역은 예제로만 사용됩니다. 회사에 비슷한 요구 사항이 있는 여러 지역이 있을 수 있습니다.)

• 유럽에서 Contoso는 약 30개 국가/지역에 지사를 두고 있습니다. 각 사무실에는 자체 PBX(Private Branch Exchange)가 있습니다.

  Contoso는 30개의 유럽 사무소 모두에 대해 암스테르담이라는 한 위치에서 트렁크를 중앙 집중화하는 옵션을 제공했습니다. Contoso는 암스테르담에 SBC를 배포하고, 중앙 집중식 위치를 통해 통화를 실행할 수 있는 충분한 대역폭을 제공하고, 중앙 SIP 트렁크를 중앙 위치에 연결하고, 암스테르담의 모든 유럽 지역에 서비스를 제공하기 시작했습니다.

• APAC 지역에서 Contoso는 여러 국가/지역에 여러 지사를 두고 있습니다.

  많은 국가/지역에서 이 회사는 여전히 현지 지사에 TDM(시간 분할 멀티플렉싱) 트렁크를 보유하고 있습니다. TDM 트렁크의 중앙 집중화는 APAC 지역에서는 옵션이 아니므로 SIP로 전환할 수 없습니다. 수백 개의 게이트웨이(SCC)가 있는 APAC 지역에 50개 이상의 Contoso 지점이 있다고 가정합니다. 이 시나리오에서는 공용 IP 주소 및/또는 로컬 인터넷 중단이 없기 때문에 모든 게이트웨이를 직접 라우팅 인터페이스에 페어링할 수 없습니다. 또한 일부 국가/지역은 로컬 PSTN 네트워크 연결 없이는 충족할 수 없는 규정 요구 사항을 적용합니다.

Contoso는 비즈니스 요구 사항에 따라 직접 라우팅을 위한 로컬 미디어 최적화를 사용하여 두 가지 솔루션을 구현했습니다.

• 유럽에서는 모든 트렁크가 중앙 집중화되고 사용자 위치에 따라 중앙 SBC와 사용자 간에 미디어가 흐릅니다.

  • 사용자가 회사 네트워크의 로컬 서브넷(즉, 사용자가 내부)에 연결된 경우 미디어는 중앙 SBC의 내부 IP와 사용자의 Teams 클라이언트 간에 흐릅니다.

  • 사용자가 회사 네트워크의 경계 밖에 있는 경우(예: 사용자가 공용 무선 인터넷 연결을 사용하는 경우) 사용자는 외부로 간주됩니다. 이 경우 미디어는 중앙 SBC의 외부 IP와 Teams 클라이언트 간에 흐릅니다.

• APAC 지역에서는 중앙 집중식 프록시 SBC가 Microsoft 직접 라우팅과 쌍을 이루어 직접 라우팅 인터페이스와 로컬 지점의 다운스트림 SBC 간에 미디어를 전달합니다.

  로컬 지점의 다운스트림 SCC는 APAC의 직접 라우팅에 직접 표시되지 않지만 Set-CSOnlinePSTNGateway cmdlet을 사용하여 Teams 전화 내에 가상 네트워크 토폴로지를 만들어 쌍을 이루게 됩니다. 가능하면 미디어는 항상 로컬로 유지됩니다. 외부 사용자는 Teams 클라이언트와 프록시 SBC의 공용 IP 간에 미디어 흐름이 있습니다.

중앙 집중식 트렁크가 있는 중앙 SBC

연결된 중앙 집중식 SIP 트렁크가 있는 단일 중앙 SBC를 통해 모든 로컬 지점에 PSTN 서비스를 제공하는 솔루션을 빌드하기 위해 Contoso 테넌트 관리자는 하나의 SBC(centralsbc.contoso.com)를 서비스에 쌍으로 연결합니다. SBC에는 중앙 집중식 SIP 트렁크가 연결되어 있습니다.

• 사용자가 회사의 내부 네트워크에 있는 경우 SBC는 미디어용 SBC의 내부 IP를 제공합니다.

• 사용자가 회사 네트워크 외부에 있는 경우 SBC는 SBC의 외부(공용) IP를 제공합니다.

참고

예제, 테이블 또는 다이어그램 내의 모든 값은 그림 용도로만 제공됩니다.

표 1. SCC에 대한 네트워크 매개 변수 예제

위치	SBC FQDN	내부 서브넷	외부 NAT(신뢰할 수 있는 IP)	SBC 외부 IP 주소	SBC 내부 IP 주소
암스테르담	centralsbc.contoso.com	192.168.5.0/24	172.16.76.73	172.16.76.71	192.168.5.5
독일	배포되지 않음	192.168.6.0/24	172.16.76.74	배포되지 않음	배포되지 않음
프랑스	배포되지 않음	192.168.7.0/24	172.16.76.75	배포되지 않음	배포되지 않음

내부 사용자

다음 다이어그램은 사용자가 사용자의 홈 지점 또는 사이트의 회사 네트워크에 연결된 경우의 트래픽 흐름을 보여 줍니다.

온-프레미스에 있는 동안 사용자는 독일의 현지 지사에 할당됩니다. 사용자는 Teams를 통해 직접 라우팅 전화를 걸 수 있습니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신하지만 호출 중에 생성된 미디어는 중앙 SBC의 내부 IP 주소로 전달됩니다.

• SBC는 흐름을 Teams 전화 연결된 PSTN 네트워크로 리디렉션합니다.

• 중앙 SBC는 외부 IP 주소를 통해서만 Teams 전화 볼 수 있습니다.

다이어그램 1. 사용자가 중앙 집중식 SBC 및 연결된 중앙 집중식 SIP 트렁크가 있는 '홈' 사이트에 있는 경우 트래픽 흐름

외부 사용자

다음 다이어그램은 사용자가 온-프레미스에 있지 않고 회사 네트워크에 연결되지 않은 경우(즉, 사용자의 디바이스가 모바일 디바이스 또는 공용 Wi-Fi를 통해 인터넷에 연결되어 있는 경우) 트래픽 흐름을 보여 줍니다. 사용자는 Teams를 통해 직접 라우팅 전화를 걸 수 있습니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신하지만, 이 경우 호출 중에 생성된 미디어는 중앙 SBC의 외부 IP 주소로 전달됩니다.

• SBC는 흐름을 Teams 전화 연결된 PSTN 네트워크로 리디렉션합니다.

• 중앙 SBC는 외부 IP 주소를 통해서만 Teams 전화 볼 수 있습니다.

이 경우 사용자가 독일의 지사 또는 다른 지점의 로컬인지 여부에 관계없이 동작이 유사합니다. 사용자가 회사 네트워크의 경계 밖에 있기 때문에 사용자는 외부로 간주됩니다.

다이어그램 2. 사용자가 중앙 집중식 SBC 및 연결된 중앙 집중식 SIP 트렁크를 사용하여 외부에 있는 경우 트래픽 흐름

연결된 다운스트림 SBC가 있는 프록시 SBC

TDM 트렁크의 중앙 집중화가 옵션이 아닌 APAC 지역의 모든 로컬 지사에서 PSTN 서비스를 제공하는 솔루션을 빌드하기 위해 Contoso 관리자는 프록시 SBC라고도 하는 하나의 SBC(proxysbc.contoso.com)를 직접 라우팅 서비스에 연결합니다.

그런 다음 Contoso 관리자는 프록시 SBC proxysbc.contoso.com 통해 연결할 수 있음을 나타내는 일부 다운스트림 SBC를 추가합니다. 다운스트림 SCC에는 공용 IP가 없습니다. 그러나 음성 경로에 할당할 수 있습니다. 아래 표에는 네트워크 매개 변수 및 구성 예제가 표시됩니다.

사용자가 다운스트림 SBC가 있는 로컬 지점에 있는 경우 미디어 트래픽은 사용자와 로컬 다운스트림 SBC 간에 직접 흐릅니다. 사용자가 사무실 외부(공용 인터넷)에 있는 경우 미디어는 사용자에서 프록시 SBC의 공용 IP로 흐르며, 이를 관련 다운스트림 SBC에 프록시합니다.

표 2. 예제 SBC 네트워크 정보

위치	SBC FQDN	내부 서브넷	외부 NAT(신뢰할 수 있는 IP)	SBC 외부 IP 주소	SBC 내부 IP 주소
베트남	VNsbc.contoso.com	192.168.1.0/24	172.16.240.110	없음	192.168.1.5
인도네시아	IDsbc.contoso.com	192.168.2.0/24	172.16.240.120	없음	192.168.2.5
싱가포르	proxysbc.contoso.com	192.168.3.0/24	172.16.240.130	172.16.240.133	192.168.3.5

내부 사용자

다음 다이어그램은 사용자가 APAC 지역의 사무실 내에 있을 때 시나리오에 대한 높은 수준의 트래픽 흐름을 보여 주는 다이어그램입니다. 베트남의 현지 지사에 할당되고 온-프레미스에 있는 사용자는 Teams를 통해 직접 라우팅 전화를 걸 수 있습니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신하지만 호출 중에 생성된 미디어는 로컬 SBC의 내부 IP 주소로 전달됩니다.

• 로컬 SBC는 흐름을 싱가포르의 프록시 SBC 및 연결된 로컬 PSTN 네트워크로 리디렉션합니다.

• 프록시 SBC는 외부 IP 주소를 통해서만 Teams 전화 표시되며 다운스트림 SBC(이 경우 베트남의 로컬 SBC)에서 Teams 전화 흐름을 라우팅합니다.

• 로컬 지점의 다운스트림 SBC는 Teams 전화 직접 표시되지 않지만 로컬 미디어 최적화를 설정하는 동안 Contoso 관리자가 정의한 가상 네트워크 토폴로지 내에 매핑됩니다.

참고

구성된 로컬 미디어 최적화 모드에 따라 로컬 사용자와 로컬이 아닌 사용자에 대해 동작이 다를 수 있습니다.

가능한 모드 및 관련 동작에 대한 자세한 내용은 로컬 미디어 최적화 구성을 참조하세요.

다이어그램 3. 사용자가 프록시 SBC 및 연결된 다운스트림 SBC가 있는 "홈" 네트워크에 있는 경우 트래픽 흐름

외부 사용자

다음 다이어그램은 사용자가 회사 네트워크 경계를 벗어나는 경우의 트래픽 흐름을 보여 줍니다. 사용자가 온-프레미스에 있지 않습니다(회사 네트워크의 경계 내에 있지 않음). 사용자는 Teams를 통해 베트남의 전화 번호로 직접 라우팅 전화를 걸 수 있습니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신하지만 호출 중에 생성된 미디어는 먼저 싱가포르 프록시 SBC의 외부 IP 주소로 전달됩니다.

• 구성 및 음성 정책( 로컬 미디어 최적화 구성 참조)에 따라 프록시 SBC는 흐름을 베트남의 다운스트림 SBC로 리디렉션합니다.

• 베트남의 다운스트림 SBC는 연결된 로컬 PSTN 네트워크로 흐름을 리디렉션합니다.

• 프록시 SBC는 외부 IP 주소를 통해서만 Teams 전화 볼 수 있습니다.

• 로컬 지점의 다운스트림 SBC는 Teams 전화 직접 볼 수 없지만 로컬 미디어 최적화를 설정하는 동안 Contoso 관리자가 정의한 가상 네트워크 토폴로지 내에 매핑됩니다. 이 예제에서 사용자는 회사 네트워크의 경계를 벗어나기 때문에 외부로 간주됩니다.

다이어그램 4. 사용자가 프록시 SBC 및 연결된 다운스트림 SBC를 사용하여 외부에 있는 경우 트래픽 흐름

로컬 미디어 최적화 모드

로컬 미디어 최적화는 다음 두 가지 모드를 지원합니다.

• 모드 1: 항상 무시합니다. 이 경우 사용자가 내부인 경우 미디어는 내부 사용자의 실제 위치에 관계없이 로컬 다운스트림 SBC의 내부 IP 주소를 통해 흐릅니다. 예를 들어 다운스트림 SBC가 있는 동일한 지점 내 또는 일부 다른 지점에 있습니다.

• 모드 2: 로컬 사용자에만 해당합니다. 이 모드에서 미디어는 다운스트림 SBC와 동일한 지점의 내부 사용자가 생성한 경우에만 로컬 다운스트림 SBC의 내부 IP 주소로 직접 흐릅니다.

로컬 미디어 최적화 모드를 구분하려면 테넌트 관리자가 Set-CSonlinePSTNGateway cmdlet을 사용하여 모든 SBC에 대해 -BypassMode 매개 변수를 'Always' 또는 'OnlyForLocalUsers'로 설정해야 합니다. 자세한 내용은 로컬 미디어 최적화 구성을 참조하세요.

참고

사용자가 내부인 경우 내부 IP 주소를 통해 사용자와 SBC 간의 미디어 연결이 필요합니다. SBC가 미디어 연결을 위해 내부 IP를 제공하게 되므로 이 경우 미디어에 대한 대중 교통 릴레이로 대체되지 않습니다.

모드 1: 항상 무시

지점 간에 연결이 좋은 경우 권장 모드는 항상 무시입니다.

예를 들어 회사가 암스테르담에 중앙 집중식 SIP 트렁크가 있다고 가정합니다. 이 트렁크는 30개 국가/지역에 서비스를 제공하며 30개 사이트와 현지 사용자 간에 잘 연결되어 있습니다. 독일에는 로컬 SBC가 배포된 지점도 있습니다.

독일의 SBC는 "항상 바이패스" 모드로 구성할 수 있습니다. 사용자는 위치에 관계없이 SBC의 내부 IP 주소를 통해 SBC에 직접 연결합니다. 예를 들어 프랑스에서 독일로. 참조는 아래 다이어그램을 참조하세요.

다음은 두 가지 시나리오에 대해 설명합니다.

• 시나리오 1. 사용자가 온라인 음성 라우팅 정책에 정의된 SBC와 동일한 위치에 있습니다.

• 시나리오 2. 사용자와 게이트웨이는 서로 다른 사이트에 있습니다.

시나리오 1. 사용자가 온라인 음성 라우팅 정책에 정의된 SBC와 동일한 위치에 있습니다.

암스테르담의 SBC는 독일의 로컬 다운스트림 SBC에 대한 프록시 SBC로 구성됩니다. 사용자는 로컬 SBC의 회사 네트워크와 동일한 서브넷 내에 있는 독일에 있습니다. SCC(프록시 및 다운스트림)는 모두 Always Bypass 모드에 대해 구성됩니다. 온라인 음성 라우팅 정책은 독일 내 호출(지역 코드 +49 포함)을 독일의 로컬 SBC로 라우팅하도록 지정합니다. 다른 모든 호출은 암스테르담의 프록시 SBC로 라우팅되어야 합니다. 그러나 독일의 SBC가 실패하면 독일의 호출도 암스테르담의 프록시 SBC로 라우팅되어야 합니다. 다음 표에서는 예제 구성을 요약합니다.

표 3. 시나리오 1에 대한 예제 구성

사용자 물리적 위치	사용자가 숫자를 호출합니다.	온라인 음성 라우팅 정책	SBC에 대해 구성된 모드	미디어 흐름
독일	+49 1 437 2800	우선 순위 1: ^+49(\d{8})$ -DEsbc.contoso.com 우선 순위 2: .* - proxysbc.contoso.com	DEsbc.contoso.com – 항상 무시 proxysbc.contoso.com – 항상 무시	Teams 사용자 <–> DEsbc.contoso.com

아래 다이어그램은 독일의 내부 사용자가 Teams를 통해 독일의 번호로 직접 라우팅 전화를 걸 수 있는 높은 수준의 트래픽 흐름을 보여줍니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신합니다.

• 호출 중에 생성된 미디어는 로컬 SBC의 내부 IP 주소로 흐릅니다.

• 로컬 SBC는 암스테르담의 프록시 SBC 및 연결된 로컬 PSTN 네트워크로 흐름을 리디렉션합니다.

• 프록시 SBC는 외부 IP 주소를 통해서만 Teams 전화 표시되며 다운스트림 SBC(이 경우 독일의 로컬 SBC)에서 Teams 전화 흐름을 라우팅합니다.

• 로컬 지점의 다운스트림 SBC는 Teams 전화 직접 표시되지 않지만 로컬 미디어 최적화를 설정하는 동안 Contoso 관리자가 정의한 가상 네트워크 토폴로지 내에 매핑됩니다.

다이어그램 5. "Always Bypass" 모드가 있고 사용자가 "홈" 사이트에 있는 트래픽 흐름

시나리오 2: 사용자 및 게이트웨이가 서로 다른 사이트에 있습니다.

암스테르담의 SBC는 독일의 로컬 다운스트림 SBC에 대한 프록시 SBC로 구성됩니다. SCC(프록시 및 다운스트림)는 모두 Always Bypass 모드에 대해 구성됩니다. 현지 지사에 있는 프랑스의 내부 사용자가 독일에 직접 라우팅 전화를 걸고 있습니다. 온라인 음성 라우팅 정책은 독일(지역 번호 +49 포함)에 대한 호출을 독일의 로컬 SBC로 라우팅하도록 지정합니다. 다른 모든 호출은 암스테르담의 프록시 SBC로 라우팅되어야 합니다. 그러나 독일의 SBC가 실패하면 독일의 모든 호출은 암스테르담의 프록시 SBC로 라우팅되어야 합니다. 다음 표에서는 예제 구성을 요약합니다.

표 4. 시나리오 2에 대한 예제 구성

사용자 물리적 위치	사용자가 숫자를 호출합니다.	온라인 음성 라우팅 정책	SBC에 대해 구성된 모드	미디어 흐름
프랑스	+49 1 437 2800	우선 순위 1: ^+49(\d{8})$ -DEsbc.contoso.com 우선 순위 2: .* - proxysbc.contoso.com	DEsbc.contoso.com – 항상 proxysbc.contoso.com 무시 – 항상 무시	Teams 사용자 <– > DEsbc.contoso.com

다음 다이어그램은 프랑스에 있는 독일 내부 사용자가 Teams를 통해 독일의 번호로 직접 라우팅 전화를 걸 때의 높은 수준의 트래픽 흐름을 보여 줍니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신합니다.

• 통화 중에 생성된 미디어는 독일의 내부 IP 주소에 있는 SBC로 직접 전달됩니다.

• 독일의 SBC는 암스테르담의 프록시 SBC와 연결된 로컬 PSTN 네트워크로 흐름을 리디렉션합니다.

다이어그램 6. "Always Bypass" 모드가 있는 트래픽 흐름 및 사용자가 "홈" 사이트가 아니라 내부 네트워크에 있습니다.

모드 2: 로컬 사용자만

지역 지사 간에 연결이 좋지 않지만 각 지역 지점과 지역 사무실 간에 연결이 좋은 경우 권장 모드는 "로컬 사용자만 해당"입니다.

예를 들어 APAC 지역에서는 Contoso에 여러 국가/지역에 여러 사무실이 있다고 가정합니다. 많은 국가/지역의 경우 회사에 여전히 많은 지역 지사에 TDM 트렁크가 있기 때문에 SIP로 전환할 수 없습니다. TDM 트렁크의 중앙 집중화는 APAC 지역에서 옵션이 아닙니다. 또한 수백 개의 게이트웨이(SCC)가 있는 APAC 지역에 50개 이상의 Contoso 지점이 있습니다.

TDM 트렁크의 중앙 집중화가 옵션이 아닌 APAC 지역의 모든 로컬 지점에서 PSTN 서비스를 제공하는 솔루션을 빌드하기 위해 Contoso 관리자는 싱가포르의 한 지역 SBC를 프록시 SBC로 직접 라우팅 서비스에 연결합니다. 현지 지점 간의 직접 연결은 좋지 않지만 각 지역 지점과 싱가포르의 지역 SBC 간에는 좋은 연결이 있습니다. 지역 SBC의 경우 관리자는 'Always Bypass' 모드를 선택합니다. 로컬 다운스트림 SCC의 경우 관리자는 '로컬 사용자에 대해서만' 모드를 선택합니다.

다음은 두 가지 시나리오에 대해 설명합니다.

• 시나리오 1. 사용자가 온라인 음성 라우팅 정책에 정의된 SBC와 동일한 위치에 있습니다.

• 시나리오 2. 사용자 및 게이트웨이는 서로 다른 사이트에 있습니다.

시나리오 1. 사용자가 온라인 음성 라우팅 정책에 정의된 SBC와 동일한 위치에 있습니다.

싱가포르의 SBC가 베트남과 인도네시아의 로컬 다운스트림 SBC에 대한 프록시 SBC로 구성된다고 가정합니다. 사용자는 현지 SBC와 동일한 위치 내에 베트남에 있습니다. 온라인 음성 라우팅 정책은 베트남의 통화(지역 번호 +84 포함)를 베트남의 로컬 SBC로 라우팅하도록 지정합니다. 다른 모든 호출은 싱가포르의 프록시 SBC로 라우팅되어야 합니다. 그러나 베트남의 SBC가 실패하면 베트남의 호출은 싱가포르의 프록시 SBC로 라우팅되어야 합니다. 다음 표에서는 예제 구성을 요약합니다.

표 5. '로컬 사용자만 해당' 모드 시나리오 1에 대한 예제 구성

사용자 물리적 위치	사용자가 숫자를 호출합니다.	온라인 음성 라우팅 정책	SBC에 대해 구성된 모드	미디어 흐름
베트남	+84 4 3926 3000	우선 순위 1: ^+84(\d{9})$ -VNsbc.contoso.com 우선 순위 2: .* - proxysbc.contoso.com	VNsbc.contoso.com – 로컬 사용자에만 해당 proxysbc.contoso.com – 항상 무시	Teams 사용자 <–> VNsbc.contoso.com

다음 다이어그램에서는 온-프레미스에서 베트남의 현지 지사에 할당된 사용자가 Teams를 통해 직접 라우팅 전화를 걸 수 있습니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신합니다.

• 호출 중에 생성된 미디어는 로컬 SBC의 내부 IP 주소로 흐릅니다.

• 로컬 SBC는 흐름을 싱가포르의 프록시 SBC 및 연결된 로컬 PSTN 네트워크로 리디렉션합니다.

• 프록시 SBC는 외부 IP 주소를 통해서만 Teams 전화 표시되며 다운스트림 SBC(이 경우 베트남의 로컬 SBC)에서 Teams 전화 흐름을 라우팅합니다.

• 로컬 지점의 다운스트림 SBC는 Teams 전화 직접 볼 수 없지만 가상 네트워크 토폴로지 내에 매핑됩니다.

다이어그램 7. "로컬 사용자에 대해서만" 모드가 있고 사용자가 "홈" 사이트에 있는 트래픽 흐름

시나리오 2. 사용자 및 게이트웨이는 서로 다른 사이트에 있습니다.

싱가포르의 SBC가 베트남과 인도네시아의 로컬 다운스트림 SBC에 대한 프록시 SBC로 구성된다고 가정합니다. 현지 지사에 위치한 인도네시아의 내부 사용자가 베트남에 직접 라우팅 전화를 걸고 있습니다. 온라인 음성 라우팅 정책은 베트남(지역 번호 +84 포함)에 대한 호출을 베트남의 로컬 SBC로 라우팅하도록 지정합니다. 다른 모든 호출은 싱가포르의 프록시 SBC로 라우팅되어야 합니다. 그러나 베트남의 SBC가 실패하면 베트남에 대한 호출은 싱가포르의 프록시 SBC로 라우팅되어야 합니다. 싱가포르의 프록시 SBC는 'Always Bypass' 모드로 설정되고 베트남의 로컬 SBC는 '로컬 사용자만' 모드로 설정됩니다. 다음 표에서는 예제 구성을 요약합니다.

표 6. 사용자 구성

사용자 물리적 위치	사용자가 숫자를 호출합니다.	온라인 음성 라우팅 정책	SBC에 대해 구성된 모드	미디어 흐름
인도네시아	+84 4 3926 3000	우선 순위 1: ^+84(\d{9})$ -VNsbc.contoso.com 우선 순위 2: .* - proxysbc.contoso.com	VNsbc.contoso.com – 로컬 사용자에만 해당 proxysbc.contoso.com – 항상 무시	Teams 사용자 <–> proxysbc.contoso.com <–> VNsbc.contoso.com

다음 다이어그램에서 내부 사용자는 인도네시아 지점의 온-프레미스에서 Teams를 통해 베트남의 번호로 직접 라우팅 전화를 걸 수 있습니다.

• 사용자의 Teams 클라이언트는 REST API를 통해 직접 Teams 전화 통신합니다.

• 호출 중에 생성된 미디어는 먼저 프록시 SBC의 내부 IP 주소로 흐릅니다.

• 싱가포르의 프록시 SBC는 흐름을 베트남 다운스트림 SBC의 내부 IP 주소로 리디렉션하고 Teams 전화.

• 베트남의 다운스트림 SBC는 연결된 로컬 PSTN 네트워크로 흐름을 라우팅합니다.

• 프록시 SBC는 외부 IP 주소를 통해서만 Teams 전화 볼 수 있습니다.

• 로컬 지점의 다운스트림 SCC는 Teams 전화 직접 표시되지 않지만 가상 네트워크 토폴로지 내에 매핑됩니다.

다이어그램 8. "로컬 사용자만" 모드로 트래픽 흐름이 흐르고 사용자가 "홈" 사이트가 아니라 내부 네트워크에 있습니다.

.

알려진 동작

다음은 로컬 미디어 최적화를 사용할 때 관찰될 수 있는 동작 목록입니다.

제품 동작	참고
Teams 클라이언트 공용 IP가 고객 신뢰할 수 있는 IP 목록과 일치하지만 네트워크 사이트와 일치하지 않는 경우 Teams 클라이언트는 내부 로 식별되지 않습니다.	로컬 미디어 최적화를 사용하려면 나열된 신뢰할 수 있는 IP에서 만든 모든 연결에 대해 일치하는 네트워크 사이트가 필요합니다.
Teams 사용자는 통화를 보류합니다. PSTN 끝에서 음악이 재생되고 로컬 미디어 최적화가 작동합니다. Teams 사용자가 통화를 다시 시작합니다. PSTN에 대한 호출이 다시 시작되지만 로컬 미디어 최적화가 작동하지 않고 중앙(프록시) SBC를 통해 호출이 계속됩니다.	사용자가 MoH(대기 중인 음악 시작)를 호출하면 MoH가 보류된 사용자에게 도달하는 미디어 컨트롤러 및 미디어 프로세서(AVMCU 믹서 역할을 하는)를 호출하기 위해 통화 컨트롤러가 1:1에서 다중 파티 호출로 에스컬레이션됩니다. 호출이 다시 시작된 후 1:1 호출로의 에스컬레이션 해제는 디자인에 따라 발생하지 않습니다.
통화가 설정되는 동안 사용자는 몇 초 동안 침묵을 들을 수 있습니다.	로컬 미디어 최적화 아키텍처의 복잡성으로 인해 경우에 따라 이 문제가 발생할 수 있습니다.
음성 앱(예: 자동 전화 교환 및 통화 큐).	LMO가 구성된 환경에서 음성 앱을 배포할 수 있습니다. 그러나 음성 앱과 관련된 통화는 로컬 미디어 최적화에 최적화되지 않습니다. 대신 자동 전화 교환에서 로컬 미디어 최적화 사용자로의 전송을 제외하고 프록시 SBC를 통해 흐릅니다. 이러한 경우 호출은 직접 1:1 호출이므로 로컬 미디어 최적화 최적화 경로를 따릅니다. Location-Based 라우팅 시나리오는 음성 앱(자동 전화 교환 또는 통화 큐)을 참조하세요.