직접 라우팅을 사용하여 기존 전화 통신 서비스에 연결
Azure Communication Services 직접 라우팅을 사용하면 기존 전화 통신 인프라를 Azure에 연결할 수 있습니다. 이 문서에는 지원되는 SBC(Session Border Controller)를 직접 라우팅에 연결하는 데 필요한 상위 수준 단계와 사용하도록 설정된 통신 리소스에 음성 라우팅을 사용하는 방법이 나와 있습니다.
Azure Communication Services 직접 라우팅이 조직에 적합한 솔루션인지 여부에 관한 내용은 Azure 전화 통신 개념을 참조하세요. 필수 조건과 배포 계획에 관한 내용은 Communication Services 직접 라우팅 인프라 요구 사항을 참조하세요.
SBC를 Azure Communication Services와 연결
도메인 소유권 유효성 검사
다음 지침에 따라 SBC의 도메인 소유권에 대한 유효성을 검사합니다.
아웃바운드 음성 라우팅 구성
음성 라우팅 빠른 시작을 참조하여 SBC를 추가하고 아웃바운드 음성 라우팅 규칙을 구성합니다.
세션 경계 컨트롤러 연결 상태
이제 SBC 연결 상태가 Azure Portal에 표시됩니다. TLS(전송 계층 보안) 상태 및 SIP OPTIONS를 고려합니다.
각 상태 표시기의 가능한 값
TLS 상태 - 트렁크의 TLS 연결 상태:
- 알 수 없음 - SBC가 지난 15분 동안 TLS 핸드셰이크를 시도하지 않았음을 나타냅니다.
- 활성 - TLS 연결이 설정되었음을 나타냅니다.
- CertExpiring - SBC 인증서가 만료되고 있음을 나타냅니다.
- CertExpired - SBC 인증서가 만료되었음을 나타냅니다.
SIP OPTIONS(Ping) - SIP OPTIONS 메시지 교환 상태:
- 알 수 없음 - SBC가 SIP 옵션을 보내지 않았음을 나타냅니다.
- 활성 - OPTIONS가 전송되고 수신되고 있음을 나타냅니다.
- 만료됨 - SBC에서 SIP OPTIONS를 보내고 있지만 지난 15분 동안 OPTIONS 메시지를 받지 못했음을 나타냅니다.
- 오류 - OPTIONS 교환에 오류가 있음을 나타냅니다.
상태 - 트렁크의 전체 상태:
- 알 수 없음 - 알 수 없는 상태를 나타냅니다.
- 온라인 - SBC 연결이 정상임을 나타냅니다.
- 경고 - TLS 또는 Ping이 만료되었음을 나타냅니다.
참고 항목
새 트렁크를 방금 구성한 경우 상태를 업데이트하는 데 최대 15분이 걸릴 수 있습니다.
Important
전화를 걸거나 받기 전에 SBC 상태가 온라인인지 확인합니다.
아웃바운드 음성 라우팅 고려 사항
Azure Communication Services 직접 라우팅에는 착신 번호 패턴을 기반으로 특정 SBC로 통화를 보낼 수 있는 라우팅 메커니즘이 있습니다.
직접 라우팅 구성을 리소스에 추가하면 이 리소스의 인스턴스(ID)에서 만들어진 모든 통화가 먼저 직접 라우팅 트렁크를 시도합니다. 라우팅은 전화를 건 번호와 리소스에 대해 구성된 음성 경로의 일치 항목을 기반으로 합니다.
- 일치 항목이 있는 경우 통화는 직접 라우팅 트렁크를 통과합니다.
- 일치하는 항목이 없으면 다음 단계는
callAgent.startCall메서드의alternateCallerId매개 변수를 처리하는 것입니다. - 리소스가 음성 통화(PSTN)에 대해 사용하도록 설정되어 있고 Microsoft에서 구입한 번호가 하나 이상 있는 경우
alternateCallerId가 선택됩니다. alternateCallerId가 리소스에 대해 구매한 번호와 일치하면 Microsoft 인프라를 사용하여 음성 통화(PSTN)를 통해 통화가 라우팅됩니다.alternateCallerId매개 변수가 구매한 번호와 일치하지 않으면 통화가 실패합니다.
다이어그램은 Azure Communication Services 음성 라우팅 논리를 보여 줍니다.
음성 라우팅 예제
다음 예제에서는 통화 흐름의 음성 라우팅을 표시합니다.
참고 항목
모든 예제에서 더 높은 음성 경로는 우선 순위가 더 높지만 경로의 SBC는 임의 순서로 시도됩니다.
단일 경로 예제:
패턴 ^\+1(425|206)(\d{7})$를 사용하여 하나의 음성 경로를 만들고 여기에 sbc1.contoso.biz 및 sbc2.contoso.biz를 추가한 경우 사용자가 +1 425 XXX XX XX 또는 +1 206 XXX XX XX에 전화를 걸면 해당 통화는 먼저 SBC sbc1.contoso.biz 또는 sbc2.contoso.biz로 라우팅됩니다. SBC를 둘 다 사용할 수 없으면 통화가 끊어집니다.
두 개 경로 예제:
예를 들어, 패턴 ^\+1(425|206)(\d{7})$를 사용하여 하나의 음성 경로를 만들고 여기에 sbc1.contoso.biz와 sbc2.contoso.biz를 추가한 다음, sbc3.contoso.biz 및 sbc4.contoso.biz와 함께 동일한 패턴을 사용하여 두 번째 경로를 만들었습니다. 이 경우 사용자가 +1 425 XXX XX XX 또는 +1 206 XXX XX XX에 전화를 걸면 해당 통화는 먼저 SBC sbc1.contoso.biz 또는 sbc2.contoso.biz로 라우팅됩니다. sbc1과 sbc2를 둘 다 사용할 수 없는 경우에는 우선 순위가 낮은 경로가 시도됩니다(sbc3.contoso.biz 및 sbc4.contoso.biz). 두 번째 경로의 SBC를 둘 다 사용할 수 없으면 통화가 끊어집니다.
세 개 경로 예제:
예를 들어, 패턴 ^\+1(425|206)(\d{7})$를 사용하여 하나의 음성 경로를 만들고 여기에 sbc1.contoso.biz와 sbc2.contoso.biz를 추가한 다음, sbc3.contoso.biz 및 sbc4.contoso.biz와 함께 동일한 패턴을 사용하여 두 번째 경로를 만들고, sbc5.contoso.biz와 함께 ^+1(\d[10])$를 사용하여 세 번째 경로를 만들었습니다. 이 경우 사용자가 +1 425 XXX XX XX 또는 +1 206 XXX XX XX에 전화를 걸면 해당 통화는 먼저 SBC sbc1.contoso.biz 또는 sbc2.contoso.biz로 라우팅됩니다. sbc1과 sbc2를 둘 다 사용할 수 없는 경우에는 우선 순위가 낮은 경로가 시도됩니다(sbc3.contoso.biz 및 sbc4.contoso.biz). 두 번째 경로의 SBC를 사용할 수 없는 경우 세 번째 경로가 시도됩니다. sbc5도 사용할 수 없으면 통화가 끊어집니다. 또한 사용자가 +1 321 XXX XX XX에 전화를 걸면 통화가 sbc5.contoso.biz로 연결되고 사용할 수 없으면 통화가 끊어집니다.
참고 항목
음성 라우팅에서 다음 SBC로의 장애 조치(failover)는 응답 코드 408, 503 및 504에 대해서만 작동합니다.
참고 항목
모든 예제에서 전화를 건 번호가 패턴과 일치하지 않으면 통신 리소스에 대해 구매한 번호가 있고 이 번호가 애플리케이션에서 alternateCallerId로 사용되지 않는 한 통화가 끊어집니다.
인바운드 통화 관리
일반적인 인바운드 통화 관리의 경우 호출 자동화 SDK를 사용하여 전화번호로 들어오거나 Azure Communication Services 직접 라우팅을 통해 수신된 인바운드 통화를 수신 대기하고 관리하는 애플리케이션을 빌드합니다. 고객 서비스 고객을 위한 옴니채널에 대해서는 다음 지침을 참조하세요.