Microsoft Teams 통화 흐름
팁
Teams가 네트워크를 활용하는 방법과 최적의 네트워크 연결을 계획하는 방법을 알아보려면 이 세션을 시청하세요. Teams 네트워크 계획.
개요
이 문서에서는 Teams가 다양한 토폴로지에서 Microsoft 365 통화 흐름을 사용하는 방법을 설명합니다. 또한 피어 투 피어 미디어 통신에 사용되는 고유한 Teams 흐름을 설명합니다. 이 문서에서는 이러한 흐름, 해당 목적, 네트워크에서의 원본 및 종료에 대해 설명합니다. 이 문서의 용도로 다음을 가정합니다.
Flow X는 온-프레미스 클라이언트에서 클라우드의 Microsoft 365 서비스와 통신하는 데 사용됩니다. 고객 네트워크에서 시작되며 Microsoft 365에서 엔드포인트로 종료됩니다.
Flow Y는 온-프레미스 클라이언트에서 Microsoft 365에 종속성이 있는 인터넷의 서비스와 통신하는 데 사용됩니다. 고객 네트워크에서 시작되며 인터넷에서 엔드포인트로 종료됩니다.
이 문서에서는 다음 정보를 다룹니다.
배경. 흐름이 트래버스할 수 있는 네트워크, 트래픽 유형 및 고객 네트워크에서 Microsoft 365 서비스 엔드포인트로의 연결 지침과 같은 배경 정보를 제공합니다. 또한 타사 구성 요소와의 상호 운용성과 Teams에서 미디어 흐름을 선택하는 데 사용하는 원칙에 대해서도 설명합니다.
다양한 토폴로지에서 흐름을 호출합니다. 다양한 토폴로지에서 호출 흐름의 사용을 보여 줍니다. 각 토폴로지에 대해 섹션은 지원되는 모든 흐름을 열거하고 이러한 흐름이 여러 사용 사례에서 사용되는 방법을 보여 줍니다. 각 사용 사례에 대해 흐름 다이어그램을 사용하여 흐름의 시퀀스 및 선택을 설명합니다.
Express 경로 최적화가 있는 Teams. 간단한 토폴로지를 사용하여 설명된 최적화를 위해 Express Route를 배포할 때 이러한 흐름을 사용하는 방법을 설명합니다.
배경
네트워크 세그먼트
고객 네트워크. 제어하고 관리하는 네트워크 세그먼트입니다. 이 세그먼트에는 유선 또는 무선, 사무실 건물 간 연결, 온-프레미스 데이터 센터에 대한 연결, 인터넷 공급자, Express Route 또는 기타 개인 피어링에 대한 연결 등 고객 사무실 내의 모든 고객 연결이 포함됩니다.
일반적으로 고객 네트워크에는 방화벽 및/또는 프록시 서버가 있는 여러 네트워크 경계가 있으며, 이 경계는 organization 보안 정책을 적용하며 사용자가 설정하고 구성하는 특정 네트워크 트래픽만 허용합니다. 이 네트워크를 관리하기 때문에 네트워크의 성능을 직접 제어할 수 있습니다. 네트워크 평가를 완료하여 네트워크의 사이트 내에서 그리고 네트워크에서 Microsoft 365 네트워크로 성능의 유효성을 검사하는 것이 좋습니다.
인터넷. 고객 네트워크 외부에서 Microsoft 365에 연결하는 사용자가 사용하는 전체 네트워크의 일부인 네트워크 세그먼트입니다. 이 세그먼트는 고객 네트워크에서 Microsoft 365로의 일부 트래픽에서도 사용됩니다.
방문했거나 게스트 프라이빗 네트워크입니다. 사용자와 게스트가 방문할 수 있는 공용 인터넷은 아닌 고객 네트워크 외부의 네트워크 세그먼트입니다. 예를 들어 Teams를 배포하지 않는 홈 프라이빗 네트워크 또는 엔터프라이즈 프라이빗 네트워크, Teams 서비스와 상호 작용하는 사용자 및 해당 고객이 상주할 수 있습니다.
참고
Microsoft 365에 대한 연결도 이러한 네트워크에 적용됩니다.
Microsoft 365. Microsoft 365 서비스를 지원하는 네트워크 세그먼트입니다. 대부분의 위치에서 고객 네트워크에 근접한 에지로 전 세계에 분산되어 있습니다. 함수에는 전송 릴레이, 회의 서버 및 미디어 프로세서가 포함됩니다.
Express 경로(선택 사항). 전체 네트워크의 일부인 네트워크 세그먼트는 Microsoft 365 네트워크에 대한 전용 프라이빗 연결을 제공합니다.
트래픽 유형
실시간 미디어. 오디오, 비디오 및 화면 공유 워크로드를 지원하는 RTP(실시간 전송 프로토콜) 내에 캡슐화된 데이터입니다. 일반적으로 미디어 트래픽은 대기 시간이 매우 중요합니다. 이 트래픽이 가능한 가장 직접적인 경로를 사용하고 UDP와 TCP를 전송 계층 프로토콜로 사용하려고 합니다. 이 프로토콜은 품질 관점에서 대화형 실시간 미디어에 가장 적합한 전송입니다. (최후의 수단으로 미디어는 TCP/IP를 사용할 수 있으며 HTTP 프로토콜 내에서도 터널될 수 있지만 품질이 좋지 않아 권장되지 않습니다.) RTP 흐름은 페이로드만 암호화되는 SRTP를 사용하여 보호됩니다.
신호. 클라이언트와 서버 간의 통신 링크 또는 활동을 제어하는 데 사용되는 다른 클라이언트(예: 호출이 시작될 때)와 인스턴트 메시지를 배달합니다. 대부분의 신호 트래픽은 HTTPS 기반 REST 인터페이스를 사용하지만 일부 시나리오(예: Microsoft 365와 세션 테두리 컨트롤러 간의 연결)에서는 SIP 프로토콜을 사용합니다. 이 트래픽은 대기 시간에 훨씬 덜 민감하지만 엔드포인트 간의 대기 시간이 몇 초를 초과하는 경우 서비스 중단 또는 통화 시간 초과가 발생할 수 있음을 이해하는 것이 중요합니다.
Microsoft 365에 연결
Teams는 인터넷에 연결해야 합니다. Teams 엔드포인트 URL 및 IP 주소 범위는 Office 365 URL 및 IP 주소 범위에 나열됩니다. TCP 포트 80 및 443 및 UDP 포트 3478(STUN), 3479(오디오), 3480(비디오) 및 3481(공유/VBSS)에 대한 개방형 연결이 필요합니다.
Teams 미디어 흐름 연결은 표준 IETF ICE(Interactive Connectivity Establishment) 절차를 사용하여 구현됩니다.
상호 운용성 제한
타사 미디어 릴레이. Teams 미디어 흐름(즉, 미디어 엔드포인트 중 하나가 Teams인 경우)은 Teams만 트래버스하거나 네이티브 미디어 릴레이를 비즈니스용 Skype 수 있습니다. 타사 미디어 릴레이와의 상호 운용성은 지원되지 않습니다. (PSTN을 사용하는 경계의 타사 SBC는 SRTP를 사용하여 보호된 RTP/RTCP 스트림을 종료하고 다음 홉에 릴레이하지 않아야 합니다.)
타사 SIP 프록시 서버. 타사 SBC 및/또는 게이트웨이가 있는 Teams 신호 SIP 대화 상자는 Teams를 트래버스하거나 네이티브 SIP 프록시를 비즈니스용 Skype 수 있습니다. 타사 SIP 프록시와의 상호 운용성은 지원되지 않습니다.
타사 B2BUA(또는 SBC). PSTN을 들어오고 받는 Teams 미디어 흐름은 타사 SBC에 의해 종료됩니다. 그러나 Teams 네트워크 내의 타사 SBC(타사 SBC가 두 Teams 또는 비즈니스용 Skype 엔드포인트를 중재하는 경우)와의 상호 운용성은 지원되지 않습니다.
Microsoft Teams에 권장되지 않는 기술
VPN 네트워크. 미디어 트래픽(또는 흐름 2')은 권장되지 않습니다. VPN 클라이언트는 분할 터널링을 사용하고 Lync 미디어가 VPN 터널을 우회하도록 설정에 지정된 대로 외부 비 VPN 사용자처럼 Teams 미디어 트래픽을 라우팅해야 합니다.
참고
타이틀은 Lync를 나타내지만 Teams에도 적용할 수 있습니다.
패킷 셰이퍼. 모든 종류의 패킷 스니퍼, 패킷 검사 또는 패킷 셰이퍼 디바이스는 Teams 미디어 트래픽에 권장되지 않으며 품질이 크게 저하할 수 있습니다.
원칙
Microsoft Teams의 통화 흐름을 이해하는 데 도움이 되는 네 가지 일반적인 원칙이 있습니다.
Microsoft Teams 컨퍼런스는 첫 번째 참가자가 참가한 동일한 지역에서 Microsoft 365가 주최합니다. (일부 토폴로지에서 이 규칙에 예외가 있는 경우 이 문서에 설명되어 있으며 적절한 호출 흐름에 의해 설명됩니다.)
Microsoft 365의 Teams 미디어 엔드포인트는 통화 유형이 아닌 미디어 처리 요구 사항에 따라 사용됩니다. 예를 들어 지점 간 호출은 클라우드의 미디어 엔드포인트를 사용하여 기록 또는 녹음/녹화를 위해 미디어를 처리할 수 있지만, 두 참가자와의 회의는 클라우드에서 미디어 엔드포인트를 사용하지 않을 수 있습니다. 그러나 대부분의 회의는 회의 호스팅 위치에 할당된 혼합 및 라우팅 목적으로 미디어 엔드포인트를 사용합니다. 클라이언트에서 미디어 엔드포인트로 전송되는 미디어 트래픽은 고객 네트워크 방화벽 제한으로 인해 필요한 경우 Microsoft 365에서 전송 릴레이를 직접 라우팅하거나 사용할 수 있습니다.
피어 투 피어 호출에 대한 미디어 트래픽은 호출이 클라우드의 미디어 엔드포인트를 의무화하지 않는다고 가정하고 사용 가능한 가장 직접적인 경로를 사용합니다(이전 원칙 참조). 기본 경로는 원격 피어(클라이언트)로 직접 이동하지만 해당 경로를 사용할 수 없는 경우 하나 이상의 전송 릴레이가 트래픽을 릴레이합니다. 미디어 트래픽은 미디어 품질에 영향을 주므로 패킷 셰이퍼, VPN 서버 등과 같은 서버를 역방향으로 전환하지 않는 것이 좋습니다.
신호 트래픽은 항상 사용자에게 가장 가까운 서버로 이동합니다.
선택한 미디어 경로에 대한 세부 정보에 대한 자세한 내용은 Microsoft Teams의 미디어 흐름 이해 - BRK4016 참조하세요.
다양한 토폴로지의 호출 흐름
Teams 토폴로지
이 토폴로지는 비즈니스용 Skype 서버 또는 전화 시스템 직접 라우팅과 같은 온-프레미스 배포 없이 클라우드에서 Teams 서비스를 활용하는 고객이 사용합니다. 또한 Microsoft 365에 대한 인터페이스는 Azure Express Route 없이 인터넷을 통해 수행됩니다.
그림 1 - Teams 토폴로지
다음 사항에 유의하세요.
- 다이어그램의 화살표 방향은 엔터프라이즈 경계의 연결에 영향을 주는 통신의 시작 방향을 반영합니다. 미디어용 UDP의 경우 첫 번째 패킷이 역방향으로 흐를 수 있지만 이러한 패킷은 다른 방향 흐름의 패킷까지 차단될 수 있습니다.
- Teams는 비즈니스용 Skype Online과 함께 배포되므로 클라이언트는 "Teams/SFB 사용자"로 표시됩니다.
문서의 뒷부분에 있는 다음 선택적 토폴로지에서 자세한 내용을 확인할 수 있습니다.
- 비즈니스용 Skype 온-프레미스 배포는 Teams 하이브리드 토폴로지에서 설명합니다.
- 전화 시스템 직접 라우팅(PSTN 연결용)은 직접 라우팅 토폴로지가 있는 Teams에서 설명합니다.
- Express 경로는 Express Route 최적화를 사용하는 Teams에서 설명합니다.
흐름 설명:
- 흐름 2 – 사용자 Teams 환경의 일부로 고객 네트워크의 사용자가 인터넷으로 시작한 흐름을 나타냅니다. 이러한 흐름의 예로는 DNS 및 피어 투 피어 미디어가 있습니다.
- Flow 2' – 고객 네트워크에 대한 VPN을 사용하여 원격 모바일 Teams 사용자가 시작한 흐름을 나타냅니다.
- 흐름 3 – 원격 모바일 Teams 사용자가 Microsoft 365 Teams 엔드포인트로 시작한 흐름을 나타냅니다.
- 흐름 4 – 고객 네트워크의 사용자가 Microsoft 365 Teams 엔드포인트로 시작하는 흐름을 나타냅니다.
- 흐름 5 – Teams 사용자와 다른 Teams 또는 고객 네트워크 내의 비즈니스용 Skype 사용자 간의 피어 투 피어 미디어 흐름을 나타냅니다.
- 흐름 6 – 원격 모바일 Teams 사용자와 다른 원격 모바일 Teams 또는 인터넷을 통해 비즈니스용 Skype 사용자 간의 피어 투 피어 미디어 흐름을 나타냅니다.
사용 사례: 일대일
일대일 호출은 호출자가 로컬, 릴레이 및 반사(릴레이에서 볼 수 있는 클라이언트의 공용 IP 주소) 후보를 포함하여 IP 주소/포트로 구성된 후보 집합을 가져오는 공통 모델을 사용합니다. 호출자는 이러한 후보를 호출된 당사자에게 보냅니다. 또한 호출된 당사자는 비슷한 후보 집합을 가져와서 호출자에게 보냅니다. STUN 연결 검사 메시지는 어떤 호출자/호출된 파티 미디어 경로가 작동하는지 찾는 데 사용되며 가장 적합한 작업 경로가 선택됩니다. 미디어(즉, SRTP를 사용하여 보호되는 RTP/RTCP 패킷)는 선택한 후보 쌍을 사용하여 전송됩니다. 전송 릴레이는 Microsoft 365의 일부로 배포됩니다.
로컬 IP 주소/포트 후보 또는 반사 후보가 연결되어 있는 경우 미디어에 대해 클라이언트(또는 NAT 사용) 간의 직접 경로가 선택됩니다. 클라이언트가 모두 고객 네트워크에 있는 경우 직접 경로를 선택해야 합니다. 이를 위해서는 고객 네트워크 내에서 직접 UDP 연결이 필요합니다. 클라이언트가 모두 유목민 클라우드 사용자인 경우 NAT/방화벽에 따라 미디어에서 직접 연결을 사용할 수 있습니다.
한 클라이언트가 고객 네트워크의 내부이고 한 클라이언트가 외부(예: 모바일 클라우드 사용자)인 경우 로컬 또는 반사 후보 간의 직접 연결이 작동하지 않을 수 있습니다. 이 경우 옵션은 두 클라이언트에서 전송 릴레이 후보 중 하나를 사용하는 것입니다(예: 내부 클라이언트는 Microsoft 365의 전송 릴레이에서 릴레이 후보를 얻었습니다. 외부 클라이언트는 STUN/RTP/RTCP 패킷을 전송 릴레이로 보낼 수 있어야 합니다). 또 다른 옵션은 내부 클라이언트가 모바일 클라우드 클라이언트에서 가져온 릴레이 후보에게 보내는 것입니다. 미디어에 대한 UDP 연결은 권장되지만 TCP가 지원됩니다.
개략적인 단계:
- Teams 사용자 A는 흐름 2를 사용하여 DNS(URL 도메인 이름)를 확인합니다.
- Teams 사용자 A는 흐름 4를 사용하여 Teams 전송 릴레이에 미디어 릴레이 포트를 할당합니다.
- Teams 사용자 A는 흐름 4를 사용하여 ICE 후보자와 함께 "초대"를 Microsoft 365로 보냅니다.
- Microsoft 365는 흐름 4를 사용하여 Teams 사용자 B에 알림을 보냅니다.
- Teams 사용자 B는 흐름 4를 사용하여 Teams 전송 릴레이에 미디어 릴레이 포트를 할당합니다.
- Teams 사용자 B는 흐름 4를 사용하여 ICE 후보와 함께 "답변"을 보내며 흐름 4를 사용하여 Teams 사용자 A로 다시 전달됩니다.
- Teams 사용자 A 및 Teams 사용자 B는 ICE 연결 테스트를 호출하고 사용 가능한 최상의 미디어 경로가 선택됩니다(다양한 사용 사례에 대한 다음 다이어그램 참조).
- Teams 사용자는 흐름 4를 사용하여 Microsoft 365로 원격 분석을 보냅니다.
고객 네트워크 내에서:
그림 2 - 고객 네트워크 내
7단계에서는 피어 투 피어 미디어 흐름 5가 선택됩니다.
미디어는 양방향입니다. 흐름 5의 방향은 한쪽이 이 문서의 모든 흐름과 일치하는 연결 관점에서 통신을 시작한다는 것을 나타냅니다. 이 경우 두 엔드포인트가 고객 네트워크 내에 있기 때문에 어떤 방향이 사용되는지는 중요하지 않습니다.
외부 사용자에 대한 고객 네트워크(Teams 전송 릴레이에서 릴레이된 미디어):
그림 3 - 외부 사용자에 대한 고객 네트워크(Teams 전송 릴레이에서 릴레이된 미디어)
7단계에서는 고객 네트워크에서 Microsoft 365로의 흐름 4와 원격 모바일 Teams 사용자에서 Microsoft 365로의 흐름 3이 선택됩니다. 이러한 흐름은 Microsoft 365 내에서 Teams 전송 릴레이에 의해 릴레이됩니다.
미디어는 양방향입니다. 여기서 방향은 연결 관점에서 통신을 시작하는 쪽을 나타냅니다. 이 경우 이러한 흐름은 서로 다른 전송 프로토콜 및 주소를 사용하여 신호 및 미디어에 사용됩니다.
외부 사용자(직접 미디어)에 대한 고객 네트워크:
그림 4 - 외부 사용자에 대한 고객 네트워크(직접 미디어)
7단계에서는 고객 네트워크에서 인터넷(클라이언트의 피어)으로의 흐름 2가 선택됩니다.
원격 모바일 사용자가 있는 직접 미디어(Microsoft 365를 통해 릴레이되지 않음)는 선택 사항입니다. 즉, 고객은 Microsoft 365에서 전송 릴레이를 통해 미디어 경로를 적용하기 위해 이 경로를 차단할 수 있습니다.
미디어는 양방향입니다. 흐름 2에서 원격 모바일 사용자로의 방향은 한쪽이 연결 관점에서 통신을 시작한다는 것을 나타냅니다.
VPN 사용자를 내부 사용자로(Teams 전송 릴레이에 의해 릴레이된 미디어)
그림 5 - 내부 사용자에게 VPN 사용자(Teams 전송 릴레이에서 릴레이된 미디어)
VPN 간에 고객 네트워크로의 신호는 흐름 2'를 사용합니다. 고객 네트워크와 Microsoft 365 간의 신호는 흐름 4를 사용합니다. 그러나 미디어는 VPN을 우회하고 Microsoft 365의 Teams 미디어 릴레이를 통해 흐름 3과 4를 사용하여 라우팅됩니다.
VPN 사용자를 내부 사용자로(직접 미디어)
그림 6 - 내부 사용자에 대한 VPN 사용자(직접 미디어)
VPN 간에 고객 네트워크로의 신호는 흐름 2'를 사용합니다. 고객 네트워크와 Microsoft 365 간의 신호는 흐름 4를 사용합니다. 그러나 미디어는 VPN을 우회하고 고객 네트워크에서 인터넷으로 흐름 2를 사용하여 라우팅됩니다.
미디어는 양방향입니다. 원격 모바일 사용자에 대한 흐름 2의 방향은 한쪽이 연결 관점에서 통신을 시작한다는 것을 나타냅니다.
외부 사용자에 대한 VPN 사용자(직접 미디어)
그림 7 - 외부 사용자에 대한 VPN 사용자(직접 미디어)
VPN 사용자 간에 고객 네트워크로의 신호는 흐름 2'를 사용하고 흐름 4에서 Microsoft 365로 이동하는 것입니다. 그러나 미디어는 VPN을 우회하고 흐름 6을 사용하여 라우팅됩니다.
미디어는 양방향입니다. 원격 모바일 사용자에게 흐름 6의 방향은 한쪽이 연결 관점에서 통신을 시작한다는 것을 나타냅니다.
사용 사례: Microsoft 365 트렁크를 통해 PSTN에 대한 Teams
Microsoft 365에는 PSTN(공용 전환 전화 네트워크)에서 전화를 걸고 받을 수 있는 전화 시스템이 있습니다. PSTN 트렁크가 전화 시스템 통화 플랜을 사용하여 연결된 경우 이 사용 사례에 대한 특별한 연결 요구 사항이 없습니다. (자체 온-프레미스 PSTN 트렁크를 Microsoft 365에 연결하려는 경우 전화 시스템 직접 라우팅을 사용할 수 있습니다.)
그림 8 - Microsoft 365 트렁크를 통해 PSTN으로 Teams
사용 사례: Teams 모임
VBSS(오디오/비디오/화면 공유) 회의 서버는 Microsoft 365의 일부입니다. 고객 네트워크에서 연결할 수 있어야 하며 Nomadic Cloud 클라이언트에서 연결할 수 있어야 하는 공용 IP 주소가 있습니다. 각 클라이언트/엔드포인트는 회의 서버에 연결할 수 있어야 합니다.
내부 클라이언트는 일대일 호출에 대해 설명한 것과 동일한 방식으로 로컬, 반사 및 릴레이 후보를 가져옵니다. 클라이언트는 초대를 통해 이러한 후보자를 회의 서버로 보냅니다. 회의 서버는 공개적으로 연결할 수 있는 IP 주소가 있으므로 릴레이를 사용하지 않으므로 로컬 IP 주소 후보와 응답합니다. 클라이언트 및 회의 서버는 일대일 호출에 대해 설명된 것과 동일한 방식으로 연결을 검사.
다음 사항에 유의하세요.
Teams 클라이언트는 비즈니스용 Skype 모임에 참가할 수 없으며 비즈니스용 Skype 클라이언트는 Teams 모임에 참가할 수 없습니다.
PSTN 사용자는 필요에 따라 모임의 이끌이 PSTN 통화 및/또는 회의 프로비저닝에 따라 "Dials IN" 또는 "Dialed OUT"입니다.
게스트 또는 고객은 엄격한 규칙으로 FW/NAT를 사용하여 보호되는 게스트 프라이빗 네트워크에서 가입할 수 있습니다.
그림 9 - Teams 모임
사용 사례: 온-프레미스에서 비즈니스용 Skype 페더레이션
Microsoft 365에서 Teams 전송 릴레이로 릴레이된 미디어
그림 10 - Microsoft 365에서 Teams 전송 릴레이로 릴레이된 미디어
다음 사항에 유의하세요.
페더레이션은 정의상 두 테넌트 간의 통신입니다. 이 경우 Teams를 사용하는 테넌트 A는 온-프레미스에서 비즈니스용 Skype 사용하는 테넌트 B와 페더레이션됩니다. 테넌트 B가 Microsoft 365도 사용하는 경우 비즈니스용 Skype 클라이언트는 흐름 3을 사용하여 Microsoft 365에 연결했을 것입니다.
페더레이션된 비즈니스용 Skype 클라이언트에서 온-프레미스 비즈니스용 Skype 서버 신호 및 미디어가 이 문서의 scope 벗어났습니다. 그러나 명확성을 위해 여기에 설명되어 있습니다.
Teams와 비즈니스용 Skype 간의 신호는 게이트웨이에 의해 브리지됩니다.
이 경우 미디어는 Teams 전송 릴레이에서 흐름 4를 사용하여 고객 네트워크 및 원격 비즈니스용 Skype 클라이언트로 릴레이됩니다.
페더레이션된 테넌트에서 비즈니스용 Skype Media Relay에서 미디어 릴레이
그림 11 - 페더레이션된 테넌트에서 비즈니스용 Skype Media Relay가 릴레이한 미디어
다음 사항에 유의하세요.
페더레이션된 비즈니스용 Skype 클라이언트에서 온-프레미스 비즈니스용 Skype 서버 대한 신호 및 미디어가 이 문서의 scope 않습니다. 그러나 명확성을 위해 여기에 설명되어 있습니다.
Teams와 비즈니스용 Skype 간의 신호는 게이트웨이에 의해 브리지됩니다.
이 경우 미디어는 흐름 2를 사용하여 온-프레미스 Media Relay를 비즈니스용 Skype 고객 네트워크에 릴레이됩니다. (페더레이션된 고객 네트워크의 Teams 사용자에서 원격 Media Relay로의 트래픽은 역방향 트래픽이 흐르기 시작할 때까지 Media Relay에 의해 처음에 차단됩니다. 그러나 양방향 흐름은 양방향으로 연결을 엽니다.)
직접(피어 투 피어)
그림 12 - 직접(피어 투 피어)
Teams 하이브리드 토폴로지
이 토폴로지에는 비즈니스용 Skype 온-프레미스 배포가 있는 Teams가 포함됩니다.
그림 13 - Teams 하이브리드 토폴로지
위 다이어그램의 화살표 방향은 엔터프라이즈 경계의 연결에 영향을 주는 통신의 시작 방향을 반영합니다. 미디어용 UDP의 경우 첫 번째 패킷이 역방향으로 흐를 수 있지만 이러한 패킷은 다른 방향 흐름의 패킷까지 차단될 수 있습니다.
Teams는 비즈니스용 Skype Online과 함께 배포되므로 클라이언트는 "Teams/SFB 사용자"로 표시됩니다.
추가 흐름(Teams 토폴로지 위):
- 흐름 5A – 고객 네트워크 내 Teams 사용자와 고객 네트워크 에지의 비즈니스용 Skype 온-프레미스 미디어 릴레이 간의 피어 투 피어 미디어 흐름을 나타냅니다.
사용 사례: 일대일로 비즈니스용 Skype Teams
고객 네트워크 내 하이브리드
그림 14 - 고객 네트워크 내 하이브리드
Teams와 비즈니스용 Skype 간의 신호는 게이트웨이에 의해 브리지됩니다. 그러나 미디어는 흐름 5를 사용하여 고객 네트워크 내에서 직접 피어 투 피어로 라우팅됩니다.
외부 비즈니스용 Skype 사용자가 있는 하이브리드 고객 네트워크 - Microsoft 365에서 릴레이
그림 15 - 외부 비즈니스용 Skype 사용자가 있는 하이브리드 고객 네트워크 - Microsoft 365에서 릴레이
다음 사항에 유의하세요.
비즈니스용 Skype 클라이언트에서 온-프레미스 비즈니스용 Skype 서버 대한 신호 및 미디어가 이 문서의 scope 않습니다. 그러나 명확성을 위해 여기에 설명되어 있습니다.
Teams와 비즈니스용 Skype 간의 신호는 게이트웨이에 의해 브리지됩니다.
미디어는 흐름 4를 통해 Teams 전송 릴레이를 통해 고객 네트워크로 릴레이됩니다.
외부 비즈니스용 Skype 사용자가 있는 하이브리드 고객 네트워크 - 온-프레미스 Edge에서 릴레이
그림 16 - 외부 비즈니스용 Skype 사용자가 있는 하이브리드 고객 네트워크 - 온-프레미스 Edge에서 릴레이
다음 사항에 유의하세요.
비즈니스용 Skype 클라이언트에서 온-프레미스 비즈니스용 Skype 서버 신호 및 미디어가 이 문서의 scope 않습니다. 그러나 명확성을 위해 여기에 설명되어 있습니다.
신호는 게이트웨이에 의해 브리지됩니다.
미디어는 비즈니스용 Skype 온-프레미스 Edge 내의 비즈니스용 Skype Media Relay를 통해 미디어 흐름 5A를 사용하여 고객 네트워크 내 Teams 사용자에게 릴레이됩니다.
전화 시스템 직접 라우팅 토폴로지가 있는 팀
이 토폴로지에는 전화 시스템 직접 라우팅이 있는 Teams가 포함됩니다.
직접 라우팅을 사용하면 지원되는 온-프레미스 SBC(고객 소유 세션 테두리 컨트롤러) 하드웨어 디바이스를 Microsoft 365에 페어링한 다음 전화 통신 트렁크를 해당 디바이스에 연결하여 타사 PSTN(공용 전환 전화 네트워크) 서비스 공급자를 사용할 수 있습니다.
이 시나리오를 지원하려면 고객은 Microsoft의 인증된 파트너 중 한 곳에서 직접 라우팅을 위해 인증된 SBC를 배포해야 합니다. SBC는 공급업체에서 권장하는 대로 구성해야 하며 직접 UDP 트래픽에 대해 Microsoft 365에서 라우팅할 수 있어야 합니다. 미디어는 Teams 및/또는 비즈니스용 Skype 클라이언트에서 SBC(Teams 게이트웨이 우회)로 직접 흐르거나 Teams 게이트웨이를 통과할 수 있습니다. 트렁크가 Teams 게이트웨이를 우회하도록 구성된 SBC와의 연결은 SBC가 ICE-Lite를 지원하는 ICE를 기반으로 하며 Teams/비즈니스용 Skype 미디어 엔드포인트는 ICE Full Form을 지원합니다.
*그림 17 - 전화 시스템 직접 라우팅 토폴로지가 있는 Teams
다음 사항에 유의하세요.
위 다이어그램의 화살표 방향은 엔터프라이즈 경계의 연결에 영향을 주는 통신의 시작 방향을 반영합니다. 미디어용 UDP의 경우 첫 번째 패킷이 역방향으로 흐를 수 있지만 다른 방향의 패킷이 흐를 때까지 이러한 패킷이 차단될 수 있습니다.
Teams는 비즈니스용 Skype Online과 함께 배포되므로 클라이언트는 "Teams/SFB 사용자"로 표시됩니다.
추가 흐름(Teams 온라인 토폴로지 위):
- Flow 4' - 클라우드의 Teams 미디어 서버와 온-프레미스 SBC 간의 연결을 설정하는 데 사용되는 Microsoft 365에서 고객 네트워크로의 흐름을 나타냅니다.
- 흐름 5B – 바이패스 모드의 직접 라우팅 SBC를 사용하여 고객 네트워크 내 Teams 사용자 간의 미디어 흐름을 나타냅니다.
- Flow 5C – PSTN 헤어핀 호출 바이패스 모드에서 직접 라우팅 SBC 간 미디어 흐름을 다른 직접 라우팅 SBC로 나타냅니다.
직접 라우팅을 사용하는 내부 사용자(Teams 전송 릴레이에서 릴레이된 미디어)
그림 18 - 직접 라우팅을 사용하는 내부 사용자(Teams 전송 릴레이에서 미디어 릴레이)
다음 사항에 유의하세요.
SBC에는 Microsoft 365에서 라우팅할 수 있는 공용 IP 주소가 있어야 합니다.
SBC에서 Microsoft 365로의 신호 및 미디어와 그 반대의 경우 흐름 4 및/또는 흐름 4'를 사용합니다.
고객 네트워크 내의 클라이언트에서 Microsoft 365로의 신호 및 미디어는 흐름 4를 사용합니다.
직접 라우팅을 사용하는 원격 사용자(미디어가 MP(미디어 서버)를 통해 라우팅됨)
그림 19 - 직접 라우팅을 사용하는 원격 사용자(미디어가 MP(미디어 서버)를 통해 라우팅됨)
다음 사항에 유의하세요.
SBC에는 Microsoft 365에서 라우팅할 수 있는 공용 IP 주소가 있어야 합니다.
SBC에서 Microsoft 365로의 신호 및 미디어와 그 반대의 경우 흐름 4 및/또는 흐름 4'를 사용합니다.
인터넷의 클라이언트에서 Microsoft 365로의 신호 및 미디어는 흐름 3을 사용합니다.
내부 사용자 직접 라우팅(미디어 바이패스)
그림 20 - 내부 사용자 직접 라우팅(미디어 바이패스)
다음 사항에 유의하세요.
SBC에는 Microsoft 365에서 라우팅할 수 있는 공용 IP 주소가 있어야 합니다.
SBC에서 Microsoft 365로 신호를 보냅니다. 그 반대의 경우 흐름 4 및/또는 흐름 4'를 사용합니다.
고객 네트워크 내의 클라이언트에서 Microsoft 365로의 신호는 흐름 4를 사용합니다.
고객 네트워크 내의 클라이언트에서 고객 네트워크 내의 SBC로의 미디어는 흐름 5B를 사용합니다.
직접 라우팅을 사용하는 원격 사용자(Teams 전송 릴레이에서 릴레이된 미디어 바이패스)
그림 21 - 직접 라우팅을 사용하는 원격 사용자(Teams 전송 릴레이에서 릴레이된 미디어 바이패스)
다음 사항에 유의하세요.
SBC에는 Microsoft 365 및 인터넷에서 라우팅할 수 있는 공용 IP 주소가 있어야 합니다.
SBC에서 Microsoft 365로 신호를 보냅니다. 그 반대의 경우도 흐름 4 및/또는 흐름 4'를 사용합니다.
인터넷의 클라이언트에서 Microsoft 365로의 신호는 흐름 3을 사용합니다.
인터넷의 클라이언트에서 고객 네트워크 내의 SBC로의 미디어는 Teams 전송 릴레이에서 릴레이된 흐름 3과 4를 사용합니다.
원격 사용자 직접 라우팅(미디어 바이패스 직접)
그림 22 - 원격 사용자 직접 라우팅(미디어 바이패스 직접)
다음 사항에 유의하세요.
SBC에는 Microsoft 365 및 인터넷에서 라우팅할 수 있는 공용 IP 주소가 있어야 합니다.
SBC에서 Microsoft 365로 신호를 보냅니다. 그 반대의 경우도 흐름 4 및/또는 흐름 4'를 사용합니다.
인터넷의 클라이언트에서 Microsoft 365로의 신호는 흐름 3을 사용합니다.
인터넷의 클라이언트에서 고객 네트워크 내의 SBC로의 미디어는 흐름 2를 사용합니다.
직접 라우팅(미디어 바이패스) – PSTN 헤어핀 호출(앞으로 호출/전송으로 인해)
그림 23 - 직접 라우팅(미디어 바이패스) - PSTN 헤어핀 호출(앞으로 호출/전송으로 인해)
다음 사항에 유의하세요.
SBC에는 Microsoft 365에서 라우팅할 수 있는 공용 IP 주소가 있어야 합니다.
SBC에서 Microsoft 365로 신호를 보냅니다. 그 반대의 경우도 흐름 4 및/또는 흐름 4'를 사용합니다.
호출이 PSTN에서 PSTN으로 고정된 후 클라이언트가 신호 및 미디어 루프에서 벗어났습니다.
고객 네트워크 내의 SBC instance A에서 고객 네트워크 내의 SBC instance B로의 미디어(여기서 A와 B는 동일한 instance 수 있습니다)는 흐름 5C를 사용합니다.
직접 라우팅(Microsoft 365를 통한 미디어) – 두 테넌트에서 PSTN 헤어핀 호출
그림 24 - 직접 라우팅(Microsoft 365를 통한 미디어) - 두 테넌트에서 PSTN 헤어핀 호출
다음 사항에 유의하세요.
SBC에는 Microsoft 365에서 라우팅할 수 있는 공용 IP 주소가 있어야 합니다.
SBC에서 Microsoft 365로 신호를 보냅니다. 그 반대의 경우도 흐름 4 및/또는 흐름 4'를 사용합니다.
호출이 PSTN에서 PSTN으로 고정된 후 클라이언트가 신호 및 미디어 루프에서 벗어났습니다.
고객 네트워크 X에서 SBC로의 SBC instance A에서 SBC로 instance B는 Microsoft 365 Media Server를 통해 릴레이되어야 하며 바이패스 모드를 사용할 수 없습니다.
Express 경로 최적화를 사용하는 Teams
그림 25 - Express 경로 최적화가 있는 Teams
Express Route가 정당화되고 배포되는 경우 Teams 흐름을 흐름 4에서 흐름 1로, 흐름 4에서 흐름 1로 다시 라우팅할 수 있습니다. 그러나 Teams 애플리케이션은 흐름 4 및 4'를 사용하여 인터넷을 통해 다른 Microsoft 365 흐름에 대한 종속성이 강합니다. 따라서 이러한 흐름은 차단해서는 안 됩니다.
비즈니스용 Skype 하이브리드 Edge 트래픽은 외부 사용자와 통신하고 다른 테넌트와 페더레이션하기 위해 Express Route가 아닌 인터넷으로 라우팅됩니다.
비대칭 흐름을 방지하려면 다시 라우팅이 양방향이어야 합니다. 즉, 고객 네트워크 내의 주소는 최적화에 따라 인터넷 또는 Express Route를 통해 라우팅할 수 있지만 둘 다 통해 라우팅할 수는 없습니다.
외부 사용자에 대한 고객 네트워크(Teams 전송 릴레이에서 릴레이된 미디어):
그림 26 - 외부 사용자에 대한 고객 네트워크(Teams 전송 릴레이에서 릴레이된 미디어)
상위 수준 단계:
- 고객 네트워크 내의 Teams 사용자는 flow2를 사용하여 DNS(URL 도메인 이름)를 확인합니다.
- 고객 네트워크 내의 Teams 사용자는 흐름 1을 사용하여 Teams 전송 릴레이에 미디어 릴레이 포트를 할당합니다.
- 고객 네트워크 내의 Teams 사용자는 흐름 1을 사용하여 ICE 후보와 함께 "초대"를 Microsoft 365로 보냅니다.
- Microsoft 365는 흐름 3을 사용하여 외부 Teams 사용자에게 알림을 보냅니다.
- Teams 외부 사용자는 흐름 3을 사용하여 Teams 전송 릴레이에 미디어 릴레이 포트를 할당합니다.
- Teams 외부 사용자는 흐름 3을 사용하여 ICE 후보와 함께 "답변"을 보내며 흐름 1을 사용하여 Teams 사용자 A에게 다시 전달됩니다.
- Teams 사용자 A 및 Teams 사용자 B는 ICE 연결 테스트를 호출하고 Teams 전송 릴레이에서 릴레이되는 흐름 1과 3을 선택합니다.
- Teams 사용자는 흐름 1과 3을 사용하여 Microsoft 365로 원격 분석을 보냅니다.
참고
흐름 4를 요구하는 다른 마이크로 서비스에서 Teams 애플리케이션의 종속성을 지원하려면 흐름 4를 사용하도록 설정해야 합니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기