Azure Communications Gateway 배포
이 문서에서는 Azure에서 Azure Communications Gateway 리소스를 계획하고 만드는 과정을 안내합니다.
필수 조건
Azure Communications Gateway 배포 준비를 완료합니다. 해당 절차에 따라 수집한 모든 정보에 액세스할 수 있는지 확인합니다.
Important
Azure Communications Gateway를 사용하려면 통신 사업자여야 합니다.
Operator Connect 또는 Teams Phone Mobile의 경우 Microsoft와 Operator Connect 또는 Teams Phone Mobile 계약도 체결해야 합니다. 이러한 프로그램에 대한 자세한 내용은 Operator Connect 또는 Teams Phone Mobile을 참조하세요.
Zoom Phone 클라우드 피어링의 경우 Zoom Phone 클라우드 피어링 공급자가 되려면 Zoom 온보딩 프로세스도 시작해야 합니다. 클라우드 피어링에 대한 자세한 내용은 Zoom의 클라우드 피어링 정보를 참조하세요.
Important
선택한 통신 서비스에 대한 온보딩 프로세스와 온보딩 프로세스로 인해 발생하는 모든 종속성을 완전히 이해해야 합니다.
배포 및 온보딩 프로세스에 충분한 경과 시간을 허용합니다. 예를 들어, 새 Azure Communications Gateway 리소스를 네트워크에 연결하기 전에 프로비전하려면 최대 2주를 기다려야 할 수 있습니다.
두 가지 형식의 테스트를 위해 전 세계적으로 라우팅 가능한 번호를 소유해야 합니다.
- 배포 및 통합 중 담당자의 통합 테스트
- 선택한 통신 서비스별 서비스 검증(지속 통화 테스트)
다음 표에서는 할당해야 하는 숫자 수를 설명합니다.
| 서비스 | 통합 테스트 번호 | 서비스 확인 번호 |
|---|---|---|
| 운영자 연결 | 1(최소) | - 프로덕션 배포: 6 - 랩 배포: 3 |
| Teams 전화 모바일 | 1(최소) | - 프로덕션 배포: 6 - 랩 배포: 3 |
| Microsoft Teams 직접 라우팅 | 1(최소) | 없음(해당 사항 없음) |
| Zoom Phone 클라우드 피어링 | 1(최소) | - 미국 및 캐나다: 6 - 기타 국가: 2 |
| Azure 연산자 콜 보호 미리 보기 | 1(최소) | 없음(해당 사항 없음) |
Important
서비스 확인 번호는 배포 전체 기간 동안 사용할 수 있어야 합니다.
Azure Communications Gateway 리소스 만들기
Azure Portal을 사용하여 Azure Communications Gateway 리소스를 만듭니다.
Azure Portal에 로그인합니다.
페이지 위쪽의 검색 창에서 Communications Gateway를 검색하고 Communications Gateway를 선택합니다.
만들기 옵션을 선택합니다.
Azure Communications Gateway 배포를 위한 기본 정보 수집에서 수집한 정보를 사용하여 기본 사항 구성 탭의 필드를 작성한 후 다음: 서비스 지역을 선택합니다.
서비스 지역에 대한 구성 값 수집에서 수집한 정보를 사용하여 서비스 지역 탭의 필드를 작성한 후 다음: 통신 서비스를 선택합니다.
통신 서비스 구성 탭에서 지원하려는 통신 서비스를 선택하고 각 통신 서비스에 대한 구성 값 수집에서 수집한 정보를 사용하여 필드를 작성한 다음 다음: 테스트 회선을 선택합니다.
서비스 확인 번호 값 수집에서 수집한 정보를 사용하여 테스트 회선 구성 탭의 필드를 작성한 후 다음: 태그를 선택합니다.
- 통합 테스트를 위해 숫자를 구성하지 마세요.
- Microsoft Teams 직접 라우팅 및 Azure 연산자 콜 보호 미리 보기에는 서비스 확인 번호가 필요하지 않습니다.
(선택 사항) Azure Communications Gateway 리소스에 대한 태그 구성: 만들려는 각 태그에 대한 이름 및 값을 입력합니다.
검토 + 만들기를 선택합니다.
구성을 올바르게 입력했다면 Azure Portal 화면 상단에 유효성 검사 통과 메시지가 표시됩니다. 검토 + 만들기 섹션으로 이동합니다.
구성을 올바르게 입력하지 않은 경우 Azure Portal은 구성이 잘못된 섹션에 대해 오류 기호를 표시합니다. 섹션을 선택하고 오류 메시지에 있는 정보를 사용하여 구성을 수정한 다음 검토 + 만들기 섹션으로 돌아갑니다.
Azure Communications Gateway 구성 제출
구성을 확인하고 요구 사항과 일치하는지 확인합니다. 구성이 올바르면 만들기를 선택합니다.
리소스가 프로비전되면 배포 완료 메시지가 나타납니다. 리소스 그룹으로 이동을 선택한 다음, 올바른 Azure Communications Gateway 리소스가 새 리소스 그룹에 포함되어 있는지 확인합니다.
참고 항목
즉시 전화를 걸 수는 없습니다. 리소스가 트래픽을 처리할 준비가 되기 전에 이 가이드의 나머지 단계를 완료해야 합니다.
프로비전이 완료되기를 기다리기
리소스가 프로비전될 때까지 기다립니다. 리소스가 준비되면 리소스 개요의 프로비전 상태 필드가 "완료"로 변경됩니다. 프로비전 상태 필드가 "완료"인지 주기적으로 확인하는 것이 좋습니다. 이 단계는 최대 2주가 걸릴 수 있습니다.
네트워크에 Azure Communications Gateway 연결
리소스가 프로비전되면 Azure Communications Gateway를 네트워크에 연결할 수 있습니다.
- 온보딩 팀과 TLS 인증서 정보를 교환합니다.
- Azure Communications Gateway는 DigiCert Global Root G2 인증서 및 Baltimore CyberTrust Root 인증서를 루트 CA(인증 기관) 인증서로 지원하도록 미리 구성되어 있습니다. 네트워크가 Azure Communications Gateway에 제공하는 인증서가 다른 루트 CA 인증서를 사용하는 경우 온보딩 팀에 이 루트 CA 인증서를 제공합니다.
- Azure Communications Gateway 인증서의 루트 CA 인증서는 DigiCert Global Root G2 인증서입니다. 네트워크에 이 루트 인증서가 없으면 https://www.digicert.com/kb/digicert-root-certificates.htm에서 다운로드하여 네트워크에 설치합니다.
- Azure Communications Gateway의 안정성에 설명된 호출 라우팅 요구 사항을 충족하도록 인프라를 구성합니다.
- 네트워크에 따라 SBC, 소프트스위치 및 ACL(액세스 제어 목록)을 구성해야 할 수도 있습니다.
Important
SBC를 구성할 때, Azure Communications Gateway에서 사용하는 IP 주소는 유지 관리, 크기 조정 또는 재해 시나리오의 결과로 변경될 수 있으므로 방화벽 및 ACL은 네트워크가 온보딩 팀에서 제공한 /28 IP 범위 모두에서 트래픽을 수신할 수 있는지 확인합니다.
- Azure 연산자 콜 보호 미리 보기를 사용하는 경우 네트워크(일반적으로 SBC)의 구성 요소는 SIPREC SRC(세션 기록 클라이언트) 역할을 해야 합니다.
- 네트워크는 Azure Communications Gateway에 대한 지역별 FQDN으로 SIP 트래픽을 보내야 합니다. 이러한 FQDN을 찾으려면:
- Azure Portal에 로그인합니다.
- 페이지 상단의 검색 표시줄에서 Communications Gateway 리소스를 검색합니다.
- Azure Communications Gateway 리소스에 대한 개요 페이지로 이동합니다.
- 각 서비스 위치 섹션에서 호스트 이름 필드를 찾습니다. 보안 연결을 보장하려면 이 호스트 이름에 대해 TLS 연결의 유효성을 검사해야 합니다.
_sip._tls.<regional-FQDN-from-portal>을 사용하여 각 지역에 대한 SRV 조회를 구성하는 것이 좋습니다.<regional-FQDN-from-portal>을 리소스의 개요 페이지에 있는 호스트 이름 필드의 지역별 FQDN으로 바꿉니다.
- Azure Communications Gateway에 통합 MCP가 포함된 경우 MCP에 대한 연결을 구성합니다.
- Azure Communications Gateway 리소스에 대한 개요 페이지로 이동합니다.
- 각 서비스 위치 섹션에서 MCP 호스트 이름 필드를 찾습니다.
- 다음 형식의 iFC로 테스트 번호를 구성하고
<mcp-hostname>을 해당 구독자가 기본 지역의 MCP 호스트 이름으로 바꿉니다.<InitialFilterCriteria> <Priority>0</Priority> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>1</ConditionNegated> <Group>0</Group> <SessionCase>4</SessionCase> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:<mcp-hostname>;transport=tcp;service=mcp</ServerName> <DefaultHandling>0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria>
- Azure Communications Gateway에 대한 모든 트래픽이 Microsoft Azure Peering Service Voice(MAPS Voice라고도 함) 또는 ExpressRoute Microsoft Peering을 통해 이루어지도록 라우터 및 피어링 연결을 구성합니다.
- 온-프레미스 에지 라우터에서 BFD(양방향 전달 검색)를 사용하도록 설정하여 링크 오류 검색 속도를 향상합니다.
- 간격은 150ms(또는 150ms를 사용할 수 없는 경우 300ms)여야 합니다.
- MAPS Voice를 사용하면 BFD는 각 PNI(개인 네트워크 인터페이스)에 대해 BGP 피어를 불러와야 합니다.
- 통신 플랫폼에 대한 기타 요구 사항을 충족합니다(예: Operator Connect 또는 Teams Phone Mobile에 대한 네트워크 연결 사양). Operator Connect 또는 Teams Phone Mobile 사양에 액세스해야 하는 경우 온보딩 Teams에 문의하세요.
업그레이드, 유지 관리 및 리소스 상태에 대한 경고 구성
Azure Communications Gateway는 Azure Service Health 및 Azure Resource Health와 통합됩니다.
- Azure Service Health의 Service Health 알림을 사용하여 예정된 업그레이드 및 예약된 유지 관리 작업을 알려드립니다.
- Azure Resource Health는 Resource Health에 대한 개인 설정 대시보드를 제공하므로 리소스의 현재 및 과거 상태를 확인할 수 있습니다.
운영팀에 대해 다음 경고를 설정해야 합니다.
- 업그레이드 및 유지 관리 작업의 서비스 상태 알림에 대한 경고입니다.
- Azure Communications Gateway의 상태 변경의 리소스 상태에 대한 경고입니다.
경고를 사용하면 운영 팀에 변경 내용에 대한 사전 경고를 보낼 수 있습니다. 예를 들어, 이메일 및/또는 SMS 알림을 구성할 수 있습니다. 경고 개요는 Azure Monitor 경고란?를 참조하세요. Azure Service Health 및 Azure Resource Health에 대한 자세한 내용은 Azure Service Health란? 및 Resource Health 개요를 참조하세요.