직접 라우팅의 새로운 기능
이 문서에서는 직접 라우팅의 새로운 사항에 대해 설명합니다. 업데이트를 자주 확인합니다.
새 Survivable Branch Appliance 버전(v2024.8.15.1)을 사용할 수 있습니다.
직접 라우팅 버전에 대한 새로운 SBA(Survivable Branch Appliance)는 2024년 9월 23일부터 사용할 수 있습니다. 최신 버전은 다음 기능을 지원합니다.
- SBC를 통해 미디어가 흐르는 로컬 SBA/SBC를 통해 PSTN을 호출합니다.
- SBC를 통해 미디어가 흐르는 로컬 SBA/SBC를 통해 PSTN 호출을 수신합니다.
- PSTN 호출을 보류하고 다시 시작합니다.
- 블라인드 전송.
- 단일 전화 번호 또는 Teams 사용자에게 착신 전환합니다.
- 단일 전화 번호 또는 Teams 사용자에게 응답되지 않은 전화 전달.
- 들어오는 PSTN 호출을 통화 큐 또는 자동 전화 교환 번호로 로컬 에이전트로 리디렉션합니다.
- 들어오는 PSTN 통화를 통화 큐 또는 자동 전화 교환 번호로 대체 통화 큐 또는 자동 전화 교환 번호로 리디렉션합니다.
- VoIP 대체. VoIP 호출을 시작할 수 없고 수신 당사자에 PSTN 번호가 있는 경우 PSTN 호출이 시도됩니다.
- 로컬 사용자 간의 VoIP 호출입니다. 두 사용자가 동일한 SBA 뒤에 등록된 경우 PSTN 호출 대신 VoIP 호출을 시작할 수 있으며 SBA는 호출을 지원합니다. 최신 버전을 얻으려면 SBC 공급업체에 문의하세요. 지원되는 SBC 공급업체 목록은 세션 테두리 컨트롤러 구성을 참조하세요. SBA(Survivable Branch Appliance)에 대한 자세한 내용은 직접 라우팅을 위한 SBA(Survivable Branch Appliance)를 참조하세요.
SBC 인증서 EKU 확장 테스트
2024년 3월 5일(UTC 오전 9시부터) Microsoft는 24시간 인프라 테스트를 수행합니다. 이 시간 동안 SBC(세션 테두리 컨트롤러) 인증서는 EKU(확장 키 사용) 확장에 대한 클라이언트 및 서버 인증을 모두 포함해야 합니다. 서비스 저하를 방지하기 위해 인증서의 EKU 확장에 서버 인증 및 클라이언트 인증이 포함되어 있는지 확인해 주시기를 부탁드립니다.
SCC 인증서 EKU 확장에 서버 및 클라이언트 인증이 모두 포함되지 않으면 SCC가 Microsoft 인프라에 연결할 수 없습니다.
EKU에 대한 서버 및 클라이언트 인증을 모두 요청하는 최종 스위치는 2024년 3월 19일에 수행됩니다.
자세한 내용은 SBC에 대한 신뢰할 수 있는 공용 인증서를 참조하세요.
DoD 및 GCCH 클라우드에서 MSPKI 인증 기관 변경에 대한 SIP 인증서
Microsoft 365는 다른 CA(루트 인증 기관)의 TLS 인증서를 사용하도록 메시징, 모임, 전화 통신, 음성 및 비디오를 구동하는 서비스를 업데이트하고 있습니다. 영향을 받는 엔드포인트에는 Office 365 Government - GCCH(GCC High) 및 DoD 배포의 PSTN 트래픽에 사용되는 Microsoft Teams 직접 라우팅 SIP 엔드포인트가 포함됩니다. SIP 엔드포인트용 새 CA에서 발급한 인증서로의 전환은 2024년 5월에 시작됩니다. 즉, 2024년 4월 말 이전에 조치를 취해야 합니다.
새로운 루트 CA "DigiCert 글로벌 루트 G2"는 Windows, macOS, Android 및 iOS를 비롯한 운영 체제와 Microsoft Edge, Chrome, Safari 및 Firefox와 같은 브라우저에서 널리 신뢰됩니다. 그러나 SBC에 수동으로 구성된 인증서 루트 저장소가 있는 것일 수 있습니다. 그렇다면 서비스에 영향을 주지 않도록 새 CA를 포함하도록 SBC CA 스토어를 업데이트해야 합니다. 허용되는 CA 목록에 새 루트 CA가 없는 SCC는 인증서 유효성 검사 오류를 수신하며, 이는 서비스의 가용성 또는 기능에 영향을 미칠 수 있습니다. 이전 CA와 새 CA는 모두 SBC에서 신뢰할 수 있어야 합니다. 이전 CA를 제거하지 마세요. SBC에서 허용된 인증서 목록을 업데이트하는 방법은 SBC 공급업체 설명서를 참조하세요. 이전 및 새 루트 인증서는 모두 SBC에서 신뢰할 수 있어야 합니다. 현재 Microsoft SIP 인터페이스에서 사용하는 TLS 인증서는 다음 루트 CA까지 연결됩니다.
CA의 일반 이름: DigiCert SHA1(Global Root CA Thumbprint): a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 이전 CA 인증서는 DigiCert에서 직접 다운로드할 수 있습니다. http://cacerts.digicert.com/DigiCertGlobalRootCA.crt
Microsoft SIP 인터페이스에서 사용하는 새 TLS 인증서는 이제 루트 CA: CA의 일반 이름: DigiCert SHA1(Global Root G2 지문): df3c24f9bfd666761b268073fe06d1cc8d4f82a4 새 CA 인증서를 DigiCert에서 직접 다운로드할 수 있습니다. https://cacerts.digicert.com/DigiCertGlobalRootG2.crt
자세한 내용은 변경 전에 SBC 인증서 구성을 테스트하고 확인하려면 Microsoft의 https://docs.microsoft.com/en-us/microsoft-365/compliance/encryption-office-365-tls-certificates-changes?view=o365-worldwide 기술 지침을 참조하세요. Microsoft는 SBC 어플라이언스가 새 루트 CA(DigiCert Global Root G2)에서 발급된 인증서를 신뢰하는지 확인하는 데 사용할 수 있는 테스트 엔드포인트를 준비했습니다. SBC가 이 엔드포인트에 대한 TLS 연결을 설정할 수 있는 경우 Teams 서비스에 대한 연결은 변경의 영향을 받지 않아야 합니다. 이러한 엔드포인트는 음성 트래픽이 아닌 SIP OPTIONS ping 메시지에만 사용해야 합니다. 프로덕션 엔드포인트가 아니며 중복 구성으로 뒷받침되지 않습니다. 즉, 몇 시간 동안 지속되는 가동 중지 시간이 발생하며 약 95%의 가용성이 예상됩니다.
GCCH용 테스트 엔드포인트 FQDN: x.sip.pstnhub.infra.gov.teams.microsoft.us 포트: 5061
DoD용 테스트 엔드포인트 FQDN: x.sip.pstnhub.infra.dod.teams.microsoft.us 포트: 5061
새 MSPKI 인증 기관으로 SIP 인증서 최종 전환
9월 5일과 19일에 두 번의 테스트를 마친 후 Microsoft는 10월 3일 오전 10시 UTC부터 새로운 CA(인증 기관)로 최종 전환을 수행합니다. 모든 Microsoft SIP 엔드포인트는 인증서 체인이 "DigiCert 글로벌 루트 G2" CA(인증 기관)로 롤업되는 인증서를 사용하도록 점진적으로 전환됩니다.
SBC(세션 테두리 컨트롤러)가 새 CA(인증 기관)로 제대로 구성되지 않은 경우 전환 후 직접 라우팅 수신 및 발신 호출이 실패합니다. SBC 구성에 대한 추가 지침은 SBC 공급업체에 직접 문의하세요.
변경 요구 사항 및 테스트는 메시지 센터 게시물뿐만 아니라 Microsoft 관리 포털의 서비스 상태 인시던트(MC540239, TM614271, MC663640, TM674073, MC674729)를 통해 직접 라우팅 고객에게 전달되었습니다.
MSPKI 인증 기관에 대한 SIP 인증서 추가 테스트 변경
9월 19일(UTC 오후 4시부터) Microsoft는 인증서 체인이 "DigiCert 글로벌 루트 G2" CA(인증 기관)로 롤업되는 인증서를 사용하기 위해 모든 Microsoft SIP 엔드포인트가 전환되는 24시간 테스트를 수행합니다. SBC 구성에 새 CA(인증 기관)를 추가해야 하며 이전 Baltimore CA는 보존되어야 합니다. 는 이전 CA를 대체하지 않습니다. SBC가 이 CA를 신뢰하지 않는 경우 테스트 중에 Teams SIP 엔드포인트에 연결할 수 없습니다. 새 CA(인증 기관)로의 최종 전환은 10월 3일에 수행됩니다.
변경 전에 SBC 인증서 구성을 테스트하고 확인하려는 경우 Microsoft는 SBC 어플라이언스가 새 루트 CA(DigiCert Global Root G2)에서 발급된 인증서를 신뢰하는지 확인하는 데 사용할 수 있는 테스트 엔드포인트를 준비했습니다. 이 엔드포인트는 음성 트래픽이 아닌 SIP 옵션 ping 메시지에만 사용해야 합니다. SBC가 이 엔드포인트에 대한 TLS 연결을 설정할 수 있는 경우 Teams 서비스에 대한 연결은 변경의 영향을 받지 않아야 합니다.
테스트 엔드포인트 FQDN: sip.mspki.pstnhub.microsoft.com
포트: 5061
MSPKI 인증 기관 변경 테스트에 대한 SIP 인증서
9월 5일(UTC 오전 9시부터) Microsoft는 인증서 체인이 "DigiCert 글로벌 루트 G2" CA(인증 기관)로 롤업되는 인증서를 사용하기 위해 모든 Microsoft SIP 엔드포인트가 전환되는 24시간 테스트를 수행합니다. SBC에서 이 CA를 신뢰하지 않는 경우 Teams SIP 엔드포인트에 연결하지 못할 수 있습니다.
변경 전에 SBC 인증서 구성을 테스트하고 확인하려는 경우 Microsoft는 SBC 어플라이언스가 새 루트 CA(DigiCert Global Root G2)에서 발급된 인증서를 신뢰하는지 확인하는 데 사용할 수 있는 테스트 엔드포인트를 준비했습니다. 이 엔드포인트는 음성 트래픽이 아닌 SIP 옵션 ping 메시지에만 사용해야 합니다. SBC가 이 엔드포인트에 대한 TLS 연결을 설정할 수 있는 경우 Teams 서비스에 대한 연결은 변경의 영향을 받지 않아야 합니다.
테스트 엔드포인트 FQDN: sip.mspki.pstnhub.microsoft.com
포트: 5061
MSPKI 인증 기관 변경에 대한 SIP 인증서
Microsoft 365는 다른 CA(루트 인증 기관)의 TLS 인증서를 사용하도록 메시징, 모임, 전화 통신, 음성 및 비디오를 구동하는 서비스를 업데이트하고 있습니다. 현재 루트 CA가 2025년 5월에 만료되기 때문에 이 변경이 수행되고 있습니다. 영향을 받는 엔드포인트에는 TLS 연결을 활용하는 PSTN 트래픽에 사용되는 모든 Microsoft SIP 엔드포인트가 포함됩니다. 새 CA에서 발급한 인증서로의 전환은 8월 말에 시작됩니다.
새로운 루트 CA "DigiCert 글로벌 루트 G2"는 Windows, macOS, Android 및 iOS를 비롯한 운영 체제와 Microsoft Edge, Chrome, Safari 및 Firefox와 같은 브라우저에서 널리 신뢰됩니다. 그러나 SBC에 수동으로 구성된 인증서 루트 저장소가 있고 업데이트해야 할 수 있습니다. 허용되는 CA 목록에 새 루트 CA가 없는 SCC는 인증서 유효성 검사 오류를 수신하며, 이는 서비스의 가용성 또는 기능에 영향을 미칠 수 있습니다. SBC에서 허용된 인증서 목록을 업데이트하는 방법은 SBC 공급업체 설명서를 참조하세요.
현재 Microsoft SIP 인터페이스에서 사용하는 TLS 인증서는 다음 루트 CA까지 연결됩니다.
CA의 일반 이름: Baltimore CyberTrust 루트 지문(SHA1): d4de20d05e66fc53fe1a50882c78db2852cae474
이제 Microsoft SIP 인터페이스에서 사용하는 새 TLS 인증서가 다음 루트 CA에 연결됩니다.
CA의 일반 이름: DigiCert 전역 루트 G2 지문(SHA1): df3c24f9bfd666761b268073fe06d1cc8d4f82a4
새 CA 인증서는 DigiCert: DigiCert 글로벌 루트 G2에서 직접 다운로드할 수 있습니다.
자세한 내용은 Office TLS 인증서 변경 내용을 참조하세요.
새 직접 라우팅 SIP 엔드포인트
Microsoft는 Teams 직접 라우팅 SIP 엔드포인트에 새로운 신호 IP를 도입할 예정입니다. 이 변경 내용이 서비스 가용성에 영향을 주지 않도록 하려면 세션 테두리 컨트롤러 및 방화벽이 권장 서브넷 52.112.0.0/14 및 52.122.0.0/15를 분류 및 ACL 규칙에 사용하도록 구성되어 있는지 확인합니다. 자세한 내용은 Microsoft 365, Office 365 및 Office 365 GCC 환경을 참조하세요.
SIP 옵션을 기반으로 하는 트렁크 강등 논리
트렁크 상태에 대한 SIP 옵션 기반의 새로운 기능이 도입되었습니다. 게이트웨이 구성에서 사용하도록 설정되면(Set-CsOnlinePSTNGateway cmdlet 및 SendSipOptions 매개 변수 참조) 아웃바운드 호출에 대한 라우팅 논리는 SIP 옵션을 주기적으로 보내지 않는 트렁크를 Microsoft 백 엔드로 강등합니다(예상 기간은 분당 SBC에서 보낸 하나의 SIP 옵션). 이러한 강등된 트렁크는 아웃바운드 호출에 사용할 수 있는 트렁크 목록의 끝에 배치되며 마지막으로 시도되어 통화 설정 시간이 감소할 수 있습니다.
Microsoft 지역(NOAM, EMEA, APAC, OCEA) SIP 프록시로 5분 이내에 하나 이상의 SIP 옵션을 보내지 않는 해당 기능에 대해 사용하도록 설정된 모든 트렁크는 강등된 것으로 간주됩니다. 트렁크가 Microsoft 지역 SIP 프록시의 하위 집합에만 SIP 옵션을 보내는 경우 이러한 경로가 먼저 시도되고 나머지는 강등됩니다.
참고
SIP 옵션을 보내지 않는 모든 SBC( SendSipOptions 가 true로 설정된 고객 또는 운송업체 테넌트에서 구성됨)가 강등됩니다. 해당 동작을 원하지 않는 고객은 SBC 구성에서 SendSipOptions를false 로 설정해야 합니다. SBC 구성이 이동 통신 사업자 또는 고객 테넌트 아래에 있는 통신 사업자 트렁크도 마찬가지입니다. 이러한 경우 SendSipOptions 가 true로 설정된 경우 SBC는 SIP 옵션을 보냅니다.
SIP 지원
2022년 6월 1일에 Microsoft는 직접 라우팅 구성에서 sip-all.pstnhub.microsoft.com 및 sip-all.pstnhub.gov.teams.microsoft.us FQDN에 대한 지원을 제거합니다.
6월 1일 이전에 수행된 작업이 없는 경우 사용자는 직접 라우팅을 통해 전화를 걸거나 받을 수 없습니다.
서비스 영향을 방지하려면 다음을 수행합니다.
- 분류 또는 ACL 규칙에 권장 서브넷(52.112.0.0/14 및 52.120.0.0/14)을 사용합니다.
- 직접 라우팅에 대한 세션 테두리 컨트롤을 구성할 때 sip-all FQDN 사용을 중단합니다.
자세한 내용은 직접 라우팅 계획을 참조하세요.
참고
이 문서에 제시된 IP 범위는 직접 라우팅과 관련이 있으며 Teams 클라이언트에 권장되는 IP 범위와 다를 수 있습니다.
TLS 인증서
Microsoft 365는 다른 CA(루트 인증 기관) 집합을 사용하도록 Teams 및 기타 서비스를 업데이트하고 있습니다.
자세한 내용과 영향을 받는 서비스의 전체 목록은 Microsoft Teams를 포함한 Microsoft 365 서비스에 대한 TLS 인증서 변경을 참조하세요.
인증 기관
2022년 2월 1일부터 직접 라우팅 SIP 인터페이스는 Microsoft 신뢰할 수 있는 루트 인증서 프로그램의 일부인 CA(인증 기관)에서 서명한 인증서만 신뢰합니다. 서비스에 영향을 주지 않도록 다음 단계를 수행합니다.
- SBC 인증서가 Microsoft 신뢰할 수 있는 루트 인증서 프로그램의 일부인 CA에 의해 서명되었는지 확인합니다.
- 인증서의 EKU(확장 키 사용) 확장에 "서버 인증"이 포함되어 있는지 확인합니다.
Microsoft 신뢰할 수 있는 루트 인증서 프로그램에 대한 자세한 내용은 프로그램 요구 사항 - Microsoft 신뢰할 수 있는 루트 프로그램을 참조하세요.
신뢰할 수 있는 CA 목록은 Microsoft 포함된 CA 인증서 목록을 참조하세요.
헤더 바꾸기
2022년 4월부터 직접 라우팅은 Replaces 헤더가 정의된 SIP 요청을 거부합니다. Microsoft에서 Replaces 헤더를 SBC(Session Border Controller)로 보내는 흐름에는 변경 내용이 없습니다.
SBC 구성을 확인하고 SIP 요청에서 Replaces 헤더를 사용하지 않는지 확인합니다.
TLS1.0 및 1.1
Microsoft는 고객에게 동급 최고의 암호화를 제공하기 위해 TLS(전송 계층 보안) 버전 1.0 및 1.1을 더 이상 사용하지 않을 계획입니다. 2022년 4월 3일에 Microsoft는 직접 라우팅 SIP 인터페이스에 TLS1.2를 강제로 사용합니다.
서비스에 영향을 주지 않으려면 SCC가 TLS1.2를 지원하도록 구성되어 있고 다음 암호 그룹 중 하나를 사용하여 연결할 수 있는지 확인합니다.
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 예: ECDHE-RSA-AES256-GCM-SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 예: ECDHE-RSA-AES128-GCM-SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 예: ECDHE-RSA-AES256-SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 예: ECDHE-RSA-AES128-SHA256