RTC 아키텍처의 기본 구성 요소

통신 산업에서 RTC는 일반적으로 지연 시간이 최소인 두 엔드포인트 간의 라이브 미디어 세션을 말합니다. 이러한 세션은 다음과 관련이 있을 수 있습니다.

• 두 당사자 간의 음성 세션(예: 전화 시스템, 모바일 또는 VoIP(VoIP over IP))

• 인스턴트 메시징(예: 채팅 및 인스턴트 릴레이 채팅(IRC))

• 라이브 비디오 세션(예: 화상 회의 및 텔레프레즌스)

위의 각 솔루션에는 공통적인 일부 구성 요소(예: 인증, 권한 부여 및 액세스 제어, 트랜스코딩, 버퍼링 및 릴레이 등을 제공하는 구성 요소)와 전송된 미디어 유형에 고유한 일부 구성 요소(예: 브로드캐스트 서비스, 메시징 서버 및 대기열 등)가 있습니다. 이 섹션에서는 다음 그림과 같이 음성 및 비디오 기반 RTC 시스템과 모든 관련 구성 요소를 정의하는 데 중점을 둡니다.

RTC의 필수 아키텍처 구성 요소

소프트스위치/PBX

소프트스위치 또는 PBX는 음성 전화 시스템의 핵심이며 다양한 구성 요소를 사용하여 엔터프라이즈 내부 또는 외부에서 음성 통화를 설정, 유지 관리 및 라우팅하기 위한 인텔리전스를 제공합니다. 엔터프라이즈의 모든 구독자는 전화를 받거나 걸려면 소프트스위치에 등록해야 합니다. 소프트스위치의 중요한 기능은 각 구독자를 추적하고 음성 네트워크 내의 다른 구성 요소를 사용하여 구독자에게 연락하는 방법을 추적하는 것입니다. 

세션 경계 컨트롤러(SBC)

세션 경계 컨트롤러(SBC)는 음성 네트워크의 엣지에 위치하며 모든 수신 및 발신 트래픽(제어 및 데이터 영역 모두)을 추적합니다. SBC의 주요 책임 중 하나는 음성 시스템이 악의적으로 사용되지 않도록 보호하는 것입니다. SBC는 외부 연결을 위해 세션 시작 프로토콜(SIP) 트렁크와 상호 연결하는 데 사용할 수 있습니다. 또한 일부 SBCs는 CODECs를 한 형식에서 다른 형식으로 변환하기 위한 트랜스코딩 기능을 제공합니다. 또한 대부분의 SBCs 방화벽이 설치된 네트워크에서도 호출이 설정되도록 하는 데 도움이 되는 네트워크 주소 변환(NAT) 순회 기능을 제공합니다.

PSTN 연결

VoIP(VoIP over IP) 솔루션은 퍼블릭 전화 교환 네트워크(PSTN) 게이트웨이 및 SIP 트렁크를 사용하여 레거시 PSTN 네트워크에 연결합니다.

PSTN 게이트웨이

PSTN 게이트웨이는 CODEC 트랜스코딩을 사용하여 실시간 전송 프로토콜(RTP)과 시간 분할 멀티플렉싱(TDM) 간에 SIP와 SS7 간의 신호와 미디어 간의 신호를 변환합니다. PSTN 게이트웨이는 항상 PSTN 네트워크와 가까운 엣지에 위치합니다.

SIP 트렁크

SIP 트렁크에서 엔터프라이즈는 TDM(SS7 기반) 네트워크에 대한 호출을 종료하지 않고 엔터프라이즈와 통신 간의 흐름은 IP를 통해 유지됩니다. 대부분의 SIP 트렁크는 SBCs를 사용하여 설정됩니다. 기업은 특정 범위의 IP 주소, 포트 등을 허용하는 등 통신사의 사전 정의된 보안 규칙에 동의해야 합니다.

미디어 게이트웨이(트랜스코더)

사용자는 오디오 및/또는 비디오와 선택적 데이터 및 기타 정보를 사용하여 실시간으로 통신합니다. 통신하려면 두 디바이스가 각 미디어 트랙에 대해 상호 이해한 코덱에 동의할 수 있어야 공유 미디어를 성공적으로 통신하고 제공할 수 있습니다. 모든 WebRTC 호환 브라우저는 오디오, VP8 및 비디오에 대한 H.264 제한 기준 프로파일에 대한 온라인 위치 지정 사용자 지원(OPUS) 및 G711을 지원해야 합니다. 

WebRTC 에코시스템 외부의 일반적인 음성 솔루션은 다양한 유형의 CODECs 허용합니다. 일부 일반적인 CODECs는 북미의 경우 G.711 μ-law, G.711 A-law, G.729 및 G.722입니다. 서로 다른 두 CODECs를 사용하는 두 디바이스가 서로 통신하면 미디어 게이트웨이는 디바이스 간의 CODEC 흐름을 변환합니다. 즉, 미디어 게이트웨이는 미디어를 처리하고 최종 디바이스가 서로 통신할 수 있도록 합니다.

WebRTC의 푸시 알림

WebRTC 구현은 모바일 디바이스에서 매우 일반적입니다. 웹 브라우저와 달리 모바일 디바이스는 웹 소켓 연결을 오랫동안 열어 둘 수 없습니다. 따라서 호출 및 메시지와 같은 모든 종료 요청에 대해 WebRTC 서버의 푸시 알림에 의존해야 합니다.

Amazon Simple Notification Service(Amazon SNS)를 사용하면 모바일 디바이스의 앱에 푸시 알림을 보낼 수 있습니다. 이러한 앱은 Apple iOS 또는 Android와 같은 다양한 운영 체제에서 실행될 수 있습니다. 다음 그림은 WebRTC 알림 서버에서 WebRTC 모바일 엔드포인트에 이르기까지 푸시 알림 흐름에 대한 개략적인 개요를 보여줍니다.

푸시 알림용 Amazon SNS

WebRTC 및 WebRTC 게이트웨이

웹 실시간 통신(WebRTC)을 사용하면 API를 사용하여 웹 브라우저에서 호출을 설정하거나 백엔드 서버에서 리소스를 요청할 수 있습니다. 이 기술은 클라우드 기술을 염두에 두고 설계되었으므로 호출을 설정하는 데 사용할 수 있는 다양한 APIs를 제공합니다. 일부 음성 솔루션(SIP 포함)은 이러한 APIs를 지원하지 않으므로 API 호출을 SIP 메시지로 변환하는 데 WebRTC 게이트웨이가 필요하며 그 반대의 경우도 마찬가지입니다.   

다음 그림은 고가용성 WebRTC 아키텍처의 설계 패턴을 보여줍니다. WebRTC 클라이언트에서 들어오는 트래픽은 Amazon EC2 Auto Scaling 그룹의 일부인 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행되는 WebRTC가 있는 Application Load Balancer(ALB)와 균형을 이룹니다.

음성용 RTC 시스템의 기본 토폴로지

SIP 및 RTP 트래픽의 또 다른 설계 패턴은 다음 그림과 같이 가용 영역 전체에서 액티브-패시브 모드에서 Amazon EC2의 SBCs 페어를 사용하는 것입니다. 여기서는 실패 시 탄력적 IP 주소를 인스턴스 간에 동적으로 이동할 수 있으며, 여기서 도메인 이름 서비스(DNS)를 사용할 수 없습니다.

Virtual Private Cloud(VPC)에서 Amazon EC2를 사용하는 RTC 아키텍처