Azure 직접 라우팅 인프라 요구 사항

중요

이 문서에 설명된 기능은 현재 공개 미리 보기 상태입니다. 이 미리 보기 버전은 서비스 수준 계약 없이 제공되며 프로덕션 워크로드에는 사용하지 않는 것이 좋습니다. 특정 기능이 지원되지 않거나 기능이 제한될 수 있습니다. 자세한 내용은 Microsoft Azure Preview에 대한 추가 사용 약관을 참조하세요.

중요

Dynamics 365 Omnichannel 고객의 경우 Microsoft는 모든 직접 라우팅 관련 시나리오에 대한 GA 수준의 지원을 제공합니다. Dynamics Omnichannel 음성에 대한 자세한 내용은 음성 채널 소개를 참조하세요.

이 문서에서는 Azure 직접 라우팅 배포 계획으로 염두에 두어야 하는 SBC(인프라, 라이선스 및 세션 테두리 컨트롤러) 연결 세부 정보를 설명합니다.

인프라 요구 사항

다음 표에는 Azure 직접 라우팅을 배포하기 위해 지원되는 SBC, 도메인 및 기타 네트워크 연결 요구 사항에 대한 인프라 요구 사항이 나와 있습니다.

인프라 요구 사항 다음이 필요합니다.
SBC(세션 경계 컨트롤러) 지원되는 SBC입니다. 자세한 내용은 지원되는 SBC를 참조하세요.
SBC에 연결된 전화 통신 트렁크 SBC에 연결된 하나 이상의 전화 통신 트렁크입니다. SBC는 한쪽 끝에서 직접 라우팅을 통해 Azure Communication Service에 연결합니다. 또한 SBC는 PBX, 아날로그 전화 통신 어댑터와 같은 타사 전화 통신 엔터티에 연결할 수도 있습니다. SBC에 연결된 모든 PSTN(공용 전화 통신 네트워크) 연결 옵션이 작동합니다. (SBC에 대한 PSTN 트렁크 구성은 SBC 공급업체 또는 트렁크 공급자에게 문의하세요.)
Azure 구독 ACS 리소스와 Communication Services 리소스에 대한 구성 및 연결을 만드는 데 사용하는 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을 생성할 때는 이 점을 염두에 두어야 합니다.

인증서에는 SBC FQDN이 CN(일반 이름) 또는 SAN(주체 대체 이름) 필드여야 합니다. 인증서는 중간 공급자가 아닌 인증 기관에서 직접 발급해야 합니다.

또는 Communication Services 직접 라우팅은 CN 및/또는 SAN에서 와일드카드를 지원하며 와일드카드는 표준 RFC HTTP Over TLS를 준수해야 합니다.

이미 Office 365 사용하고 Microsoft 365 관리 Center에 도메인이 등록된 고객은 동일한 도메인의 SBC FQDN을 사용할 수 있습니다. 이전에 O365에서 사용되지 않은 도메인을 프로비전해야 합니다.

예제에서는 SBC FQDN sbc.contoso.com과 일치하지만 sbc.test.contoso.com과는 일치하지 않는 \*.contoso.com을 사용합니다.

참고

Azure Communication Services 직접 라우팅의 SBC FQDN은 Teams 직접 라우팅의 SBC FQDN과 달라야 합니다.

중요

공개 미리 보기 기간에만 해당: Teams에 등록되지 않은 도메인에 와일드카드 인증서를 사용하려는 경우 지원 티켓을 제기하면 해당 인증서를 신뢰할 수 있는 도메인으로 추가합니다.

Communication Services는 Microsoft 신뢰할 수 있는 루트 인증서 프로그램의 일부인 CA(인증 기관)에서 서명한 인증서만 신뢰합니다. SBC 인증서가 프로그램의 일부인 CA에서 서명하고 인증서의 EKU(확장 키 사용) 확장에 서버 인증이 포함되어 있는지 확인합니다. 자세한 정보:

프로그램 요구 사항 - Microsoft 신뢰할 수 있는 루트 프로그램

포함된 CA 인증서 목록

중요

Azure Communication Services 직접 라우팅은 TLS 1.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-SHA2566

SBC 페어링은 Communication Services 리소스 수준에서 작동합니다. 즉, 여러 SCC를 단일 Communication Services 리소스에 페어링할 수 있습니다. 그러나 단일 SBC를 둘 이상의 Communication Services 리소스에 페어링할 수는 없습니다. 여러 리소스에 연결하려면 고유한 SBC FQDN이 필요합니다.

SIP 신호: FQDN

Communication Services 직접 라우팅의 연결점은 다음 세 가지 FQDN입니다.

  • 전역 FQDN인 sip.pstnhub.microsoft.com 먼저 시도해야 합니다. SBC가 이 이름을 확인하는 요청을 보내면 Microsoft Azure DNS 서버는 SBC에 할당된 기본 Azure 데이터 센터를 가리키는 IP 주소를 반환합니다. 할당은 데이터 센터의 성능 메트릭과 SBC에 대한 지리적 근접성을 바탕으로 이루어집니다. 반환된 IP 주소는 1차 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 (IP addresses from 52.112.0.1 to 52.115.255.254)
  • 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254)

신호 처리를 위해 이러한 모든 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차 데이터 센터가 선택됩니다. 기본 데이터 센터에 문제가 발생하는 경우 SBC는 두 번째 할당된 데이터 센터로 확인되는 sip2.pstnhub.microsoft.com 시도하고, 드물게 두 지역의 데이터 센터를 사용할 수 없는 경우 SBC는 3차 데이터 센터 IP를 제공하는 마지막 FQDN(sip3.pstnhub.microsoft.com)을 다시 시도합니다.

미디어 트래픽: IP 및 포트 범위

미디어 트래픽은 미디어 프로세서라고 하는 별도의 서비스를 오갑니다. Communication Services용 미디어 프로세서를 게시하는 순간에는 모든 Azure IP 주소를 사용할 수 있습니다. 전체 주소 목록을 다운로드합니다.

포트 범위

미디어 프로세서의 포트 범위는 다음 표에 나와 있습니다.

트래픽 시작 대상 원본 포트 대상 포트
UDP/SRTP 미디어 프로세서 SBC 3478-3481 및 49152-53247 SBC에 정의됨
UDP/SRTP SBC 미디어 프로세서 SBC에 정의됨 3478-3481 및 49152-53247

참고

Microsoft는 SBC에서 동시 호출당 두 개 이상의 포트를 권장합니다.

미디어 트래픽: 미디어 프로세서 지리

미디어 프로세서는 SIP 프록시와 동일한 데이터 센터에 배치됩니다.

  • NOAM(미국 중남부, 미국 서부 및 미국 동부 데이터 센터 2개)
  • 유럽(영국 남부, 프랑스 중부, 암스테르담 및 더블린 데이터 센터)
  • 아시아(싱가포르 데이터 센터)
  • 일본(일본 동부 및 서부 데이터 센터)
  • 오스트레일리아(오스트레일리아 동부 및 남동부 데이터 센터)
  • LATAM(브라질 남부)
  • 아프리카(남아프리카 공화국 북부)

미디어 트래픽: 코덱

SBC와 클라우드 미디어 프로세서 사이의 다리입니다.

세션 경계 컨트롤러와 클라우드 미디어 프로세서 간의 레그에 있는 Azure 직접 라우팅 인터페이스는 다음과 같은 코덱을 사용할 수 있습니다.

  • SILK, G.711, G.722, G.729

제품에서 원치 않는 코덱을 제외하여 세션 경계 컨트롤러의 특정 코덱을 강제로 사용할 수 있습니다.

Communication Services 호출 SDK 앱과 클라우드 미디어 프로세서 간 레그

클라우드 미디어 프로세서와 Communication Services 호출 SDK 앱 간의 레그에는 G.722가 사용됩니다. 이 다리에 더 많은 코덱을 추가하는 작업이 진행 중입니다.

지원되는 SBC(세션 경계 컨트롤러)

다음 단계

개념 설명서

빠른 시작