Azure 직접 라우팅 인프라 요구 사항
이 문서에서는 Azure 직접 라우팅 배포를 계획할 때 명심해야 하는 인프라, 라이선스 및 SBC(Session Border Controller) 연결 세부 정보에 대해 설명합니다.
인프라 요구 사항
다음 표에는 Azure 직접 라우팅을 배포하기 위해 지원되는 SBC, 도메인 및 기타 네트워크 연결 요구 사항에 대한 인프라 요구 사항이 나와 있습니다.
| 인프라 요구 사항 | 다음이 필요합니다. |
|---|---|
| SBC(Session Border Controller) | 지원되는 SBC입니다. 자세한 내용은 지원되는 SBC를 참조하세요. |
| SBC에 연결된 전화 통신 트렁크 | SBC에 연결된 하나 이상의 전화 통신 트렁크입니다. SBC는 한쪽 끝에서 직접 라우팅을 통해 Azure Communication Service에 연결합니다. 또한 SBC는 PBX, 아날로그 전화 통신 어댑터와 같은 타사 전화 통신 엔터티에도 연결할 수 있습니다. SBC에 연결된 모든 PSTN(Public Switched Telephony Network) 연결 옵션이 작동합니다. (SBC에 대한 PSTN 트렁크 구성은 SBC 공급업체 또는 트렁크 공급자에게 문의하세요.) |
| Azure 구독 | Communication Services 리소스와 SBC에 대한 구성 및 연결을 만드는 데 사용하는 Azure 구독입니다. |
| Communication Services 액세스 토큰 | 호출을 수행하려면 voip 범위를 포함하는 유효한 액세스 토큰이 필요합니다. 액세스 토큰 참조 |
| SBC에 대한 공용 IP 주소 | SBC에 연결하는 데 사용할 수 있는 공용 IP 주소입니다. SBC의 유형에 따라 SBC에서 NAT를 사용할 수 있습니다. |
| SBC의 FQDN(정규화된 도메인 이름) | 자세한 내용은 SBC 인증서 및 도메인 이름을 참조하세요. |
| SBC의 퍼블릭 DNS 항목 | SBC FQDN을 공용 IP 주소에 매핑하는 공용 DNS 항목입니다. |
| SBC의 신뢰할 수 있는 퍼블릭 인증서 | Azure 직접 라우팅과의 모든 통신에 사용되는 SBC의 인증서입니다. 자세한 내용은 SBC 인증서 및 도메인 이름을 참조하세요. |
| SIP 신호 및 미디어를 위한 방화벽 IP 주소 및 포트 | SBC는 클라우드의 다음 서비스와 통신합니다. 신호를 처리하는 SIP 프록시 미디어를 처리하는 미디어 프로세서 이러한 두 서비스는 이 문서의 뒷부분에 설명된 Microsoft Cloud에 별도의 IP 주소가 있습니다. |
SBC 인증서 및 도메인 이름
CSR(인증 서명 요청)을 통해 SBC의 인증서를 요청하는 것이 좋습니다. SBC의 CSR을 생성하는 방법에 대한 자세한 내용은 SBC 공급업체에서 제공하는 상호 연결 지침 또는 설명서를 참조하세요.
참고 항목
대부분의 CA(인증 기관)에서는 크기가 2,048 이상인 프라이빗 키를 요구합니다. CSR을 생성할 때 이 점을 반드시 기억하세요.
인증서는 CN(일반 이름) 또는 SAN(주체 대체 이름) 필드에 SBC FQDN이 있어야 합니다. 인증서는 중간 공급자가 아닌 인증 기관에서 직접 발급해야 합니다.
또는 Communication Services 직접 라우팅이 CN 및/또는 SAN의 와일드카드를 지원하고, 와일드카드가 표준 RFC HTTP Over TLS를 준수해야 합니다.
이미 Office 365를 사용하고 Microsoft 365 관리 Center에 등록된 도메인이 있는 고객은 동일한 도메인의 SBC FQDN을 사용할 수 있습니다.
예제에서는 SBC FQDN sbc.contoso.com과 일치하지만 sbc.test.contoso.com과는 일치하지 않는 *.contoso.com을 사용합니다.
참고 항목
Azure Communication Services 직접 라우팅의 SBC FQDN은 Teams 직접 라우팅의 SBC FQDN과 달라야 합니다.
Communication Services는 Microsoft 신뢰할 수 있는 루트 인증서 프로그램의 일부인 CA(인증 기관)에서 서명한 인증서만 신뢰합니다. SBC 인증서가 프로그램의 일부인 CA에 의해 서명되었으며 인증서의 EKU(확장 키 사용) 확장에 서버 인증이 포함되어 있는지 확인하세요. 자세히 보기:
프로그램 요구 사항 - Microsoft 신뢰할 수 있는 루트 프로그램
Important
Azure Communication Services 직접 라우팅은 TLS 1.2 이상 버전만 지원합니다. 서비스에 영향을 주지 않으려면 SBC가 TLS1.2를 지원하도록 구성되어 있고 SIP 신호에 다음 암호 그룹 중 하나를 사용하여 연결할 수 있는지 확인합니다.
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
SRTP 미디어의 경우 AES_CM_128_HMAC_SHA1_80만 지원됩니다.
SBC 페어링은 Communication Services 리소스 수준에서 작동합니다. 즉, 여러 SCC를 하나의 Communication Services 리소스에 페어링할 수 있습니다. 그러나 단일 SBC를 두 개 이상의 Communication Services 리소스에 페어링할 수는 없습니다. 여러 리소스에 연결하려면 고유한 SBC FQDN이 필요합니다.
SBC에서 직접 라우팅 연결에 대해 MTLS(상호 TLS) 지원을 사용하도록 설정한 경우 직접 라우팅 TLS 컨텍스트의 SBC 신뢰할 수 있는 루트 저장소에 Baltimore CyberTrust Root 및 DigiCert Global Root G2 인증서를 설치해야 합니다. (이는 Microsoft 서비스 인증서가 이러한 두 루트 인증서 중 하나를 사용하기 때문입니다.) 이러한 루트 인증서를 다운로드하려면 Office 365 암호화 체인을 참조하세요. 자세한 내용은 Office TLS 인증서 변경을 참조하세요.
SIP 신호: FQDN
Communication Services 직접 라우팅의 연결점은 다음 세 가지 FQDN입니다.
- sip.pstnhub.microsoft.com – 글로벌 FQDN – 먼저 시도해야 합니다. SBC에서 이 이름을 확인하도록 요청을 보내면 Microsoft Azure DNS 서버가 SBC에 할당된 기본 Azure 데이터 센터를 가리키는 IP 주소를 반환합니다. 할당은 데이터 센터의 성능 메트릭과 SBC에 대한 지리적 근접성을 바탕으로 이루어집니다. 반환된 IP 주소는 1차 FQDN에 해당합니다.
- sip2.pstnhub.microsoft.com – 2차 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 (IP addresses from 52.112.0.0 to 52.115.255.255)52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)
신호 처리를 위해 이러한 모든 IP 주소 범위에 대한 방화벽 포트를 열어 해당 주소에서 들어오고 나가는 트래픽을 허용합니다.
SIP 신호: 포트
Communication Services Azure 직접 라우팅에 다음 포트를 사용합니다.
| 트래픽 | 보낸 사람 | 수행할 작업 | 원본 포트 | 대상 포트 |
|---|---|---|---|---|
| SIP/TLS | SIP 프록시 | SBC | 1024–65535 | SBC에 정의됨 |
| SIP/TLS | SBC | SIP 프록시 | SBC에 정의됨 | 5061 |
SIP 신호 처리를 위한 장애 조치(Failover) 메커니즘
SBC는 DNS 쿼리를 수행하여 sip.pstnhub.microsoft.com을 확인합니다. SBC 위치 및 데이터 센터 성능 메트릭에 따라 1차 데이터 센터가 선택됩니다. 1차 데이터 센터에서 문제가 발생할 경우 SBC는 두 번째로 할당된 데이터 센터를 확인하는 sip2.pstnhub.microsoft.com을 시도하며, 드문 경우지만 두 지역의 데이터 센터를 사용할 수 없는 경우 SBC는 3차 데이터 센터 IP를 제공하는 마지막 FQDN(sip3.pstnhub.microsoft.com)을 다시 시도합니다.
미디어 트래픽: IP 및 포트 범위
미디어 트래픽은 미디어 프로세서라고 하는 별도의 서비스를 오갑니다. 미디어 트래픽의 IP 주소 범위는 신호와 동일합니다.
52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)
포트 범위
미디어 프로세서의 포트 범위는 다음 표에 나와 있습니다.
| 트래픽 | 보낸 사람 | 수행할 작업 | 원본 포트 | 대상 포트 |
|---|---|---|---|---|
| UDP/SRTP | 미디어 프로세서 | SBC | 49152–53247 | SBC에 정의됨 |
| UDP/SRTP | SBC | 미디어 프로세서 | SBC에 정의됨 | 49152–53247 |
참고 항목
Microsoft는 SBC에서 동시 호출당 두 개 이상의 포트를 권장합니다.
미디어 트래픽: 미디어 프로세서 지리
미디어 프로세서는 SIP 프록시와 동일한 데이터 센터에 배치됩니다.
- NOAM(미국 중남부, 미국 서부에 2개, 미국 동부 데이터 센터)
- 유럽(서유럽, 북유럽, 스웨덴, 프랑스 중부)
- 아시아(싱가포르 데이터 센터)
- 일본(일본 동부 및 서부 데이터 센터)
- 오스트레일리아(오스트레일리아 동부 및 남동부 데이터 센터)
- 라틴 아메리카(브라질 남부)
- 아프리카(남아프리카 공화국 북부)
미디어 트래픽: 코덱
SBC와 클라우드 미디어 프로세서 간 레그.
세션 경계 컨트롤러와 클라우드 미디어 프로세서 간의 레그에 있는 Azure 직접 라우팅 인터페이스는 다음과 같은 코덱을 사용할 수 있습니다.
- SILK, G.711, G.722, G.729
제품에서 원치 않는 코덱을 제외하여 세션 경계 컨트롤러의 특정 코덱을 강제로 사용할 수 있습니다.
Communication Services 호출 SDK 앱과 클라우드 미디어 프로세서 간 레그
클라우드 미디어 프로세서와 Communication Services 호출 SDK 앱 간의 레그에는 G.722가 사용됩니다. 이 레그에 더 많은 코덱을 추가하는 작업이 진행 중입니다.