직접 라우팅 계획
직접 라우팅을 사용하면 지원되는 고객이 제공하는 SBC(세션 테두리 컨트롤러)를 Microsoft Teams 휴대폰에 연결할 수 있습니다. 이 기능을 사용하면 다음 다이어그램과 같이 Teams를 사용하여 온-프레미스 PSTN(공용 전화망) 연결을 구성할 수 있습니다.
직접 라우팅 배포를 계획하는 것은 성공적인 구현의 핵심입니다. 이 문서에서는 인프라 및 라이선스 요구 사항을 설명하고 SBC 연결에 대한 정보를 제공합니다. 직접 라우팅 구성에 설명된 구성을 시작하기 전에 이 문서를 읽어야 합니다.
직접 라우팅을 사용하면 SBC를 거의 모든 전화 통신 트렁크에 연결하거나 타사 PSTN 장비와 상호 연결할 수 있습니다. 직접 라우팅을 사용하면 다음을 수행할 수 있습니다.
Teams Phone에서 거의 모든 PSTN 트렁크를 사용합니다.
타사 PBX(프라이빗 분기 교환), 아날로그 디바이스 및 Teams와 같은 고객 소유 전화 통신 장비 간의 상호 운용성을 구성합니다.
Microsoft는 Microsoft 통화 플랜과 같은 클라우드 내 음성 솔루션도 제공합니다. 그러나 다음과 같은 경우 직접 라우팅이 조직에 가장 적합할 수 있습니다.
Microsoft 통화 플랜은 해당 국가/지역에서 사용할 수 없습니다.
조직에서는 타사 아날로그 디바이스, 콜 센터 등에 연결해야 합니다.
조직에는 PSTN 통신 사업자와 기존 계약이 있습니다.
음성 솔루션에 대한 자세한 내용은 Teams 음성 솔루션 계획을 참조하세요.
직접 라우팅을 사용하면 사용자가 예약된 모임에 참가할 때 전화 접속 번호는 적절한 라이선스가 필요한 Microsoft 오디오 회의 서비스에서 제공됩니다. 전화 걸기 시 오디오 회의는 적절한 라이선스가 필요한 온라인 통화 기능을 사용하여 통화를 배치합니다. 사용자에게 Microsoft 오디오 회의 라이선스가 없는 경우 호출은 직접 라우팅을 통해 라우팅합니다. 자세한 내용은 오디오 회의를 사용하여 직접 라우팅을 참조하세요.
직접 라우팅은 Microsoft 통화 플랜에 대한 다른 라이선스가 있는 사용자도 지원합니다. 자세한 내용은 통화 플랜 및 운영자 연결을 사용하여 직접 라우팅을 참조하세요.
인프라 요구 사항
직접 라우팅을 배포하기 위한 지원되는 SCC, 도메인 및 기타 네트워크 연결 요구 사항에 대한 인프라 요구 사항은 다음 표에 나와 있습니다.
인프라 요구 사항 | 다음이 필요합니다. |
---|---|
세션 테두리 컨트롤러(SBC) | 지원되는 SBC입니다. 자세한 내용은 지원되는 SCC를 참조하세요. |
SBC에 연결된 전화 통신 트렁크 | SBC에 연결된 하나 이상의 전화 통신 트렁크입니다. 한쪽 끝에서 SBC는 직접 라우팅을 통해 Teams Phone에 연결합니다. 또한 SBC는 PBX, 아날로그 전화 통신 어댑터 등과 같은 타사 전화 통신 엔터티에 연결할 수도 있습니다. SBC에 연결된 모든 PSTN 연결 옵션이 작동합니다. (SBC에 대한 PSTN 트렁크 구성의 경우 SBC 공급업체 또는 트렁크 공급자를 참조하세요.) |
Microsoft 365 조직 | Microsoft Teams 사용자 홈에 사용하는 Microsoft 365 조직과 SBC에 대한 구성 및 연결. |
사용자 등록 기관 | 사용자는 Microsoft 365에 있어야 합니다. 회사에 Microsoft 365에 대한 하이브리드 연결이 있는 온-프레미스 비즈니스용 Skype 환경이 있는 경우 온-프레미스에 있는 사용자에 대해 Teams에서 음성을 사용하도록 설정할 수 없습니다. 사용자의 등록자를 확인하려면 다음 Teams PowerShell cmdlet을 사용합니다. Get-CsOnlineUser -Identity <user> | fl HostingProvider cmdlet의 출력은 다음을 표시해야 합니다. HostingProvider : sipfed.online.lync.com |
도메인 | Microsoft 365 또는 Office 365 조직에 하나 이상의 도메인이 추가되었습니다. 테넌트용으로 자동으로 만들어지는 기본 도메인 *.onmicrosoft.com 사용할 수 없습니다. 도메인을 보려면 다음 Teams PowerShell cmdlet을 사용할 수 있습니다. Get-CsTenant | fl Domains 도메인 및 Microsoft 365 또는 Office 365 조직에 대한 자세한 내용은 도메인 FAQ를 참조하세요. |
SBC의 공용 IP 주소 | SBC에 연결하는 데 사용할 수 있는 공용 IP 주소입니다. SBC 유형에 따라 SBC는 NAT를 사용할 수 있습니다. |
SBC에 대한 FQDN(정규화된 도메인 이름) | FQDN의 도메인 부분은 Microsoft 365 또는 Office 365 조직의 등록된 도메인 중 하나인 SBC용 FQDN입니다. 자세한 내용은 SBC 도메인 이름을 참조하세요. |
SBC에 대한 공용 DNS 항목 | SBC FQDN을 공용 IP 주소에 매핑하는 공용 DNS 항목입니다. |
SBC에 대한 신뢰할 수 있는 공용 인증서 | 직접 라우팅과의 모든 통신에 사용할 SBC에 대한 인증서입니다. 자세한 내용은 SBC에 대한 신뢰할 수 있는 공용 인증서를 참조하세요. |
직접 라우팅을 위한 연결점 | 직접 라우팅의 연결점은 다음과 같은 세 가지 FQDN입니다.sip.pstnhub.microsoft.com – 전역 FQDN을 먼저 시도해야 합니다.sip2.pstnhub.microsoft.com – 보조 FQDN은 지리적으로 두 번째 우선 순위 지역에 매핑됩니다.sip3.pstnhub.microsoft.com – 3차 FQDN은 지리적으로 세 번째 우선 순위 지역에 매핑됩니다.구성 요구 사항에 대한 자세한 내용은 SIP 신호: FQDN을 참조하세요. |
직접 라우팅 미디어의 방화벽 IP 주소 및 포트 | SBC는 클라우드에서 다음 서비스와 통신합니다. - 신호를 처리하는 SIP 프록시 - 미디어 바이패스가 켜진 경우를 제외하고 미디어를 처리하는 미디어 프로세서 이 두 서비스에는 Microsoft Cloud에 별도의 IP 주소가 있으며, 이 문서의 뒷부분에서 설명합니다. 자세한 내용은 URL 및 IP 주소 범위의 Microsoft Teams 섹션을 참조하세요. |
미디어 전송 프로필 | TCP/RTP/SAVP UDP/RTP/SAVP |
라이선스 및 기타 요구 사항
직접 라우팅 사용자에게는 Microsoft 365에 할당된 다음 라이선스가 있어야 합니다.
- Teams 전화
- Microsoft Teams
오디오 회의 라이선스가 필요한 시기에 대한 자세한 내용은 오디오 회의를 사용하여 직접 라우팅을 참조하세요.
직접 라우팅은 Microsoft 통화 플랜에 대한 라이선스가 부여된 사용자도 지원합니다. 자세한 내용은 통화 플랜 및 운영자 연결을 사용하여 직접 라우팅을 참조하세요.
라이선스에 대한 자세한 내용은 Microsoft Teams 라이선스 및 Microsoft Teams 추가 기능 라이선스를 참조하세요.
참고: 직접 라우팅은 아일랜드 모드에서 지원되지 않습니다.
오디오 회의를 사용하여 직접 라우팅
이 섹션에서는 직접 라우팅 및 오디오 회의를 사용할 때의 요구 사항 및 고려 사항에 대해 설명합니다.
GCC High 및 DoD G5 사용자의 경우 직접 라우팅을 구성할 때까지 G5에 포함된 오디오 회의 구성 요소를 사용하지 않도록 설정하고 조직의 테넌트에 오디오 회의 번호를 추가하는 것이 좋습니다.
GCC High 및 DoD G3 사용자의 경우 직접 라우팅을 구성할 때까지 오디오 회의 라이선스 추가 기능을 할당하지 말고 조직의 테넌트에 오디오 회의 번호를 추가하는 것이 좋습니다.
자세한 내용은 GCC High 및 DoD에 대한 직접 라우팅을 사용하여 오디오 회의를 참조하세요.
계획되지 않은 통화 에스컬레이션 및 오디오 회의 라이선스
Teams 사용자는 일대일 Teams-PSTN 또는 Teams-To-Teams 통화를 시작하고 PSTN 참가자를 추가할 수 있습니다. 호출이 수행되는 경로는 통화를 에스컬레이션하는 사용자에게 Microsoft 오디오 회의 라이선스가 할당되었는지 여부에 따라 달라집니다.
통화를 에스컬레이션하는 Teams 사용자에게 Microsoft 오디오 회의 라이선스가 할당된 경우 에스컬레이션은 Microsoft 오디오 회의 서비스를 통해 발생합니다. 기존 통화에 초대된 원격 PSTN 참가자는 들어오는 통화에 대한 알림을 받고 에스컬레이션을 시작한 Teams 사용자에게 할당된 Microsoft 브리지 수를 확인합니다.
통화를 에스컬레이션하는 Teams 사용자에게 Microsoft 오디오 회의 라이선스가 할당되지 않은 경우 직접 라우팅 인터페이스에 연결된 세션 테두리 컨트롤러를 통해 에스컬레이션이 발생합니다. 통화에 초대된 원격 PSTN 참가자는 들어오는 통화에 대한 알림을 받고 에스컬레이션을 시작한 Teams 사용자의 수를 확인합니다. 에스컬레이션에 사용되는 특정 SBC는 사용자의 라우팅 정책에 의해 정의됩니다.
다음을 확인해야 합니다.
CsOnlineVoiceRoutingPolicy가 사용자에게 할당됩니다.
프라이빗 통화 허용은 Microsoft Teams의 테넌트 수준에서 사용하도록 설정됩니다.
통화 플랜 및 운영자 연결을 사용하여 직접 라우팅
직접 라우팅은 Microsoft 통화 플랜에 대한 라이선스가 부여되거나 운영자 연결 전화 번호가 할당된 사용자를 지원합니다. 통화 플랜 또는 운영자 연결이 설정된 Teams 전화 사용자는 직접 라우팅 인터페이스를 사용하여 일부 통화를 라우팅할 수 있습니다.
동일한 사용자에 대한 통화 플랜 또는 운영자 연결 및 직접 라우팅 연결을 혼합하는 것은 선택 사항이지만 유용할 수 있습니다. 예를 들어 사용자에게 Microsoft 통화 플랜 또는 운영자 연결 번호가 할당되었지만 SBC를 사용하여 일부 호출을 라우팅하려는 경우입니다.
가장 일반적인 시나리오 중 하나는 타사 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 | 예 |
유효한 이름: sbc1.contoso.com ssbcs15.contoso.com europe.contoso.com |
contoso.onmicrosoft.com | 아니요 | *.onmicrosoft.com 도메인 사용은 SBC 이름에 대해 지원되지 않습니다. |
새 도메인 이름을 사용하려는 경우를 가정합니다. 예를 들어 테넌트는 contoso.com 테넌트에서 등록된 도메인 이름으로 사용하고 sbc1.sip.contoso.com 사용하려고 합니다.
이름 sbc1.sip.contoso.com SBC를 페어링하려면 먼저 테넌트의 도메인에 sip.contoso.com 도메인 이름을 등록해야 합니다. 도메인 이름을 등록하기 전에 SBC와 sbc1.sip.contoso.com 페어링하려고 하면 "이 테넌트용으로 구성되지 않았기 때문에 "sbc1.sip.contoso.com" 도메인을 사용할 수 없습니다." 오류가 표시됩니다.
도메인 이름을 추가한 후에는 UPN user@sip.contoso.com 을 사용하여 사용자를 만들고 Teams 라이선스를 할당해야 합니다. 테넌트의 도메인에 추가된 후 도메인 이름을 완전히 프로비전하고, 새 이름을 가진 사용자를 만들고, 사용자에게 라이선스를 할당하는 데 최대 24시간이 걸릴 수 있습니다.
회사에 하나의 테넌트에서 여러 SIP 주소 공간이 있을 수 있습니다. 예를 들어 회사에서 SIP 주소 공간으로 contoso.com 두 번째 SIP 주소 공간으로 fabrikam.com 수 있습니다. 일부 사용자에게는 주소 user@contoso.com 가 있고 일부 사용자에게는 주소 user@fabrikam.com가 있습니다.
SBC에는 하나의 FQDN만 필요하며 쌍을 이루는 테넌트의 주소 공간에서 사용자를 서비스할 수 있습니다. 예를 들어 이름이 sbc1.contoso.com SBC는 주소 user@contoso.com 가 있는 사용자와 동일한 테넌트에서 이러한 SIP 주소 공간이 등록된 한 PSTN 트래픽을 수신하고 user@fabrikam.com 보낼 수 있습니다.
참고
Azure Communication Services 직접 라우팅의 SBC FQDN은 Teams 직접 라우팅의 SBC FQDN과 달라야 합니다.
SBC에 대한 신뢰할 수 있는 공용 인증서
CSR(인증 서명 요청)을 생성하여 SBC에 대한 인증서를 요청하는 것이 좋습니다. SBC용 CSR 생성에 대한 구체적인 지침은 SBC 공급업체에서 제공하는 상호 연결 지침 또는 설명서를 참조하세요.
참고
대부분의 CA(인증 기관)에서는 프라이빗 키 크기가 2048 이상이어야 합니다. CSR을 생성할 때는 이 점을 염두에 두어야 합니다.
인증서에는 SBC FQDN이 CN(일반 이름) 또는 SAN(주체 대체 이름) 필드여야 합니다.
또는 직접 라우팅은 CN 및/또는 SAN에서 와일드카드를 지원하며 와일드카드는 TLS를 통한 표준 RFC HTTP를 준수해야 합니다.
예를 들어 SBC FQDN sbc.contoso.com 일치하지만 sbc.test.contoso.com 일치하지 않는 *.contoso.com 사용하는 것이 있습니다.
직접 라우팅 SIP 인터페이스는 Microsoft 신뢰할 수 있는 루트 인증서 프로그램의 일부인 CA(인증 기관)에서 서명한 인증서만 신뢰합니다. 프로그램의 일부인 CA가 SBC 인증서에 서명하는지 확인합니다. 또한 인증서의 EKU(확장 키 사용) 확장에 서버 인증 및 클라이언트 인증이 포함되어 있는지 확인합니다.
자세한 내용은 프로그램 요구 사항 - Microsoft 신뢰할 수 있는 루트 프로그램 및 포함된 CA 인증서 목록을 참조하세요.
참고
2023년 8월 말에 Microsoft 365는 새 CA "DigiCert Global Root G2"에서 발급한 TLS 인증서를 사용하도록 서비스를 업데이트합니다. 서비스에 영향을 미칠 수 있는 오류를 방지하려면 새 루트 CA를 포함하도록 SBC의 인증서 루트 저장소를 업데이트해야 합니다. 자세한 내용은 MSPKI 인증 기관 변경에 대한 SIP 인증서를 참조하세요.
Office 365 GCCH 및 DoD 환경의 직접 라우팅의 경우 다음 루트 인증 기관 중 하나가 인증서를 생성해야 합니다.
- DigiCert 글로벌 루트 CA
- DigiCert High Assurance EV 루트 CA
참고
SBC의 Teams 연결에 대해 MTLS(상호 TLS) 지원이 사용하도록 설정된 경우 Teams TLS 컨텍스트의 SBC 신뢰할 수 있는 루트 저장소에 Baltimore CyberTrust Root 및 DigiCert 글로벌 루트 G2 인증서를 설치해야 합니다. (이는 Microsoft 서비스 인증서가 이러한 두 루트 인증서 중 하나를 사용하기 때문입니다.) 이러한 루트 인증서를 다운로드하려면 Microsoft 365 암호화 체인을 참조하세요. 자세한 내용은 Office TLS 인증서 변경 내용을 참조하세요.
MTLS 연결이 Teams 인프라에서 시작되었는지 확인하려면 Teams 서버 쪽 인증서에서 다음 검사를 구현하도록 SBC를 구성해야 합니다.
인증서 발급 체인이 다음 루트 CA 중 하나에서 시작되었는지 확인합니다.
인증서 "주체 대체 이름"에 "sip.pstnhub.microsoft.com"이 포함되어 있는지 확인합니다.
SIP 신호: FQDN, 포트, 장애 조치(failover) 메커니즘
직접 라우팅은 다음 환경에서 제공됩니다.
- Microsoft 365 또는 Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
GCC, GCC High 및 DoD와 같은 정부 환경에 대한 자세한 내용은 Office 365 및 미국 정부 환경을 참조하세요.
다음 섹션에서는 FQDN, 포트 및 장애 조치(failover) 메커니즘에 대한 정보를 설명합니다.
SIP 신호: FQDN
다음 섹션에서는 다양한 Microsoft 클라우드 환경에 대한 FQDN 연결 지점에 대해 설명합니다.
Microsoft 365, Office 365 및 Office 365 GCC 환경
이러한 환경에서 직접 라우팅의 연결점은 다음과 같은 세 가지 FQDN입니다.
전역 FQDN인 sip.pstnhub.microsoft.com 먼저 시도해야 합니다. SBC가 이 이름을 확인하기 위한 요청을 보내면 Microsoft Azure DNS 서버는 SBC에 할당된 기본 Azure 데이터 센터를 가리키는 IP 주소를 반환합니다. 할당은 데이터 센터의 성능 메트릭과 SBC에 대한 지리적 근접성을 기반으로 합니다. 반환된 IP 주소는 기본 FQDN에 해당합니다.
sip2.pstnhub.microsoft.com – 보조 FQDN – 지리적으로 두 번째 우선 순위 지역에 매핑됩니다.
sip3.pstnhub.microsoft.com – 3차 FQDN – 지리적으로 세 번째 우선 순위 지역에 매핑됩니다.
다음 세 가지 FQDN을 순서대로 배치해야 합니다.
최적의 환경(첫 번째 FQDN을 쿼리하여 할당된 SBC 데이터 센터에 덜 로드되고 가장 가깝음)을 제공합니다.
SBC에서 임시 문제가 발생하는 데이터 센터에 연결할 때 장애 조치(failover)를 제공합니다. 자세한 내용은 장애 조치(failover) 메커니즘을 참조하세요.
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 엔드포인트에서 SCC로의 인바운드 SIP 트래픽은 이전에 언급한 FQDN에서 확인하는 IP뿐만 아니라 이러한 서브넷의 모든 IP에서 발생할 수 있습니다. SIP 피어링을 설정하는 방법에 대한 자세한 내용은 SBC 설명서를 참조하세요.
Office GCC DoD 환경
Office GCC DoD 환경에서 직접 라우팅에 대한 연결점은 다음 FQDN입니다.
sip.pstnhub.dod.teams.microsoft.us – 전역 FQDN. Office 365 DoD 환경은 미국 데이터 센터에만 존재하므로 보조 및 3차 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 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 신호: 장애 조치(failover) 메커니즘
sip.pstnhub.microsoft.com 해결하기 위해 SBC는 DNS 쿼리를 만듭니다. SBC 위치 및 데이터 센터 성능 메트릭에 따라 기본 데이터 센터가 선택됩니다.
기본 데이터 센터에 문제가 발생하는 경우 SBC는 두 번째 할당된 데이터 센터로 해결되는 sip2.pstnhub.microsoft.com 시도합니다. 두 지역의 데이터 센터를 사용할 수 없는 드문 경우 SBC는 3차 데이터 센터 IP를 제공하는 마지막 FQDN(sip3.pstnhub.microsoft.com)을 다시 시도합니다.
다음 표에는 주 데이터 센터, 보조 데이터 센터 및 3차 데이터 센터 간의 관계가 요약되어 있습니다.
기본 데이터 센터가 인 경우 | 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(IP 주소는 52.112.0.0에서 52.115.255.255로)
- 52.120.0.0/14(IP 주소는 52.120.0.0에서 52.123.255.255로)
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에서 동시 호출당 두 개 이상의 포트를 권장합니다.
미디어 트래픽: 프로세서 지리
미디어 트래픽은 미디어 프로세서라는 구성 요소를 통해 흐릅니다. 미디어 프로세서는 다음과 같이 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는 직접 라우팅과 페어링하기 위해 인증된 SCC만 지원합니다. Enterprise Voice는 비즈니스에 중요하기 때문에 Microsoft는 선택한 SBC를 사용하여 집중적인 테스트를 실행하고 SBC 공급업체와 협력하여 두 시스템이 호환되는지 확인합니다.
유효성이 검사된 디바이스는 Teams 직접 라우팅에 대해 인증됨으로 나열됩니다. 인증된 디바이스는 모든 시나리오에서 작동하도록 보장됩니다.
지원되는 SBC에 대한 자세한 내용은 직접 라우팅에 대해 인증된 세션 테두리 컨트롤러를 참조하세요.
지원 경계
Microsoft는 인증된 디바이스에서 사용하는 경우에만 직접 라우팅이 포함된 Teams Phone을 지원합니다. 문제가 있는 경우 먼저 SBC 공급업체의 고객 지원에 문의해야 합니다. 필요한 경우 SBC 공급업체는 내부 채널을 통해 문제를 Microsoft로 에스컬레이션합니다. Microsoft는 인증되지 않은 디바이스가 직접 라우팅을 통해 Teams Phone에 연결된 지원 사례를 거부할 권리가 있습니다. Microsoft에서 고객의 직접 라우팅 문제가 공급업체의 SBC 디바이스에 있다고 판단하는 경우 고객은 지원을 위해 SBC 공급업체에 다시 참여해야 합니다.
참고 항목
- 직접 라우팅 구성
- 비디오 세션: Microsoft Teams의 직접 라우팅.