CTI에서 WebRTC와 WebSocket은 어떻게 쓰일까? 브라우저 소프트폰과 실시간 전화 연동 구조

1장 전화기 없는 콜센터는 어떻게 가능할까#

전통적인 콜센터 상담원 자리에는 보통 두 가지 장비가 있었습니다.

하나는 고객정보를 조회하는 PC이고, 다른 하나는 실제 통화를 처리하는 전화기입니다.

상담원은 PC에서 CRM을 보고 전화기로 고객과 통화했습니다.

CTI는 이 두 시스템을 연결했습니다.

하지만 최근의 상담 환경에서는 물리적인 전화기 없이 웹브라우저 하나로 CRM과 전화 기능을 함께 제공하는 구조를 만들 수 있습니다.

상담원이 브라우저에서 로그인하면:

  • 고객정보 조회
  • 전화 착신
  • 전화 발신
  • 통화 보류
  • 호 전환
  • 통화 종료

까지 하나의 화면에서 처리할 수 있습니다.

이러한 구조를 가능하게 하는 대표적인 기술이 WebRTC와 WebSocket입니다.

원본 자료에서도 CTI 연동 방식 중 WebRTC와 WebSocket을 브라우저 기반 소프트폰에서 사용하는 기술로 설명합니다.

2장 WebRTC란 무엇인가#

WebRTC는 Web Real-Time Communication의 약자입니다.

브라우저나 애플리케이션에서 실시간으로:

  • 음성
  • 영상
  • 데이터

를 주고받을 수 있도록 하는 기술입니다.

원본 자료에서는 WebRTC를 별도의 플러그인 없이 브라우저에서 음성·영상·데이터 통신을 할 수 있게 해주는 개방형 표준으로 설명합니다.

콜센터에서는 특히 브라우저 기반 소프트폰을 구현할 수 있다는 점이 중요합니다.

3장 WebSocket이란 무엇인가#

WebSocket은 웹브라우저와 서버 사이에 지속적인 양방향 통신 채널을 만들 수 있는 기술입니다.

일반적인 웹 요청은:

브라우저 → 요청 → 서버
브라우저 ← 응답 ← 서버

형태입니다.

하지만 콜센터에서는 서버에서 갑자기 발생하는 이벤트를 즉시 브라우저에 전달해야 합니다.

예를 들어:

  • 전화가 들어옴
  • 통화가 연결됨
  • 상담원이 Ready 상태로 변경됨
  • 통화가 종료됨

같은 이벤트는 사용자가 요청할 때까지 기다릴 수 없습니다.

서버가 즉시 상담원 화면에 전달해야 합니다.

이때 WebSocket과 같은 실시간 통신 채널을 사용할 수 있습니다.

4장 WebRTC와 WebSocket은 같은 기술인가#

아닙니다.

이 둘은 역할이 다릅니다.

WebRTC#

실제 음성·영상·데이터 통신을 담당합니다.

WebSocket#

브라우저와 서버 사이에서 실시간 메시지나 시그널링 데이터를 전달하는 데 사용할 수 있습니다.

쉽게 구분하면:

WebRTC = 실제 통화

WebSocket = 통화를 연결하고 상태를 전달하는 통신 채널

로 이해하면 좋습니다.

5장 왜 WebRTC만으로는 통화 연결이 완성되지 않을까#

WebRTC는 실시간 미디어 전송 기능을 제공하지만 시그널링 방식 자체를 표준으로 강제하지 않습니다.

원본 자료에서도 WebRTC는 시그널링을 표준에 포함하지 않으며 SIP, XMPP, WebSocket 또는 자체 프로토콜 등을 사용할 수 있다고 설명합니다.

즉 WebRTC가 통화 데이터를 전달하려면 먼저:

  • 누구와 통화할 것인지
  • 어떤 코덱을 사용할 것인지
  • 어느 IP와 포트로 연결할 것인지

같은 정보를 상대방과 교환해야 합니다.

이 정보 교환 과정이 시그널링 Signaling입니다.

6장 WebSocket이 시그널링에 사용되는 이유#

WebSocket은 브라우저와 서버가 연결을 계속 유지하며 양방향 메시지를 주고받을 수 있습니다.

그래서 WebRTC 통화 연결에 필요한:

  • Offer
  • Answer
  • ICE Candidate
  • 전화 상태 이벤트

등을 전달하는 채널로 사용할 수 있습니다.

구조를 단순화하면 다음과 같습니다.

상담원 브라우저
      ↕
   WebSocket
      ↕
시그널링 서버
      ↕
상대방 브라우저

이 과정으로 연결 정보를 교환한 뒤 실제 음성과 영상은 WebRTC 미디어 경로로 전달됩니다.

7장 브라우저 기반 CTI 구조#

브라우저 기반 상담 시스템에서는 전통적인 전화기 기능이 웹 애플리케이션 안으로 들어올 수 있습니다.

예를 들어:

상담원 브라우저
 ├─ CRM 화면
 ├─ 고객정보
 ├─ 상담이력
 ├─ CTI 이벤트
 └─ WebRTC 소프트폰

와 같은 형태입니다.

상담원은 별도의 하드웨어 전화기를 조작하지 않고 브라우저에서 고객과 통화할 수 있습니다.

원본 자료에서도 WebRTC의 콜시스템 활용 중 하나로 브라우저 기반 소프트폰과 별도 프로그램 설치가 필요 없는 구조를 제시합니다.

8장 전통적인 CTI 구조와 비교하면#

전통적인 구조는 다음처럼 볼 수 있습니다.

전화기
  ↕
 PBX
  ↕
CTI 서버
  ↕
 CRM

브라우저 기반 구조에서는 다음과 같이 바뀔 수 있습니다.

브라우저 상담 화면
 ├─ CRM
 ├─ CTI 기능
 └─ WebRTC 소프트폰
       ↕
  시그널링 서버
       ↕
 PBX / Contact Center

즉 과거에는 전화기와 업무 화면이 물리적으로 분리되어 있었다면 브라우저 기반 환경에서는 하나의 사용자 인터페이스로 통합될 수 있습니다.

9장 WebRTC의 3가지 핵심 요소#

원본 자료에서는 WebRTC의 핵심 구성요소를 세 가지로 정리합니다.

MediaStream#

마이크와 카메라에서 음성·영상 스트림을 얻습니다.

브라우저에서는 getUserMedia와 연결되는 개념입니다.

RTCPeerConnection#

상대방과 실시간 미디어 연결을 구성합니다.

코덱 협상과 암호화된 미디어 연결을 처리합니다.

RTCDataChannel#

음성이나 영상뿐 아니라 데이터도 실시간으로 주고받을 수 있습니다.

예를 들어:

  • 파일
  • 채팅
  • 협업 데이터

등을 전달할 수 있습니다.

10장 콜센터에서는 주로 MediaStream이 어떻게 쓰일까#

상담원의 브라우저에서 고객과 음성 통화를 하려면 먼저 마이크 입력이 필요합니다.

흐름은 다음과 같습니다.

상담원 헤드셋
 ↓
브라우저 마이크 권한
 ↓
MediaStream
 ↓
WebRTC
 ↓
상대방

영상 상담이라면 카메라까지 추가됩니다.

즉 MediaStream은 실제 상담원의 음성과 영상을 WebRTC 통신에 사용할 수 있게 만드는 시작점입니다.

11장 RTCPeerConnection은 무엇을 담당하는가#

RTCPeerConnection은 WebRTC에서 실제 연결을 만드는 핵심 객체입니다.

원본 자료에서는 다음 기능과 연결합니다.

  • P2P 미디어 연결
  • 코덱 협상
  • 암호화

즉 단순히 오디오 데이터를 보내는 것이 아니라:

어떤 방식으로 연결할 것인가

를 관리하는 핵심 구성요소입니다.

12장 RTCDataChannel은 콜센터에서 어디에 쓸 수 있을까#

RTCDataChannel은 음성이나 영상과 별도로 데이터를 전달할 수 있는 채널입니다.

원본 자료에서는:

  • 파일 전송
  • 채팅
  • 협업

등을 예로 제시합니다.

예를 들어 영상 상담에서 상담원이 고객에게 문서나 안내 데이터를 전달하는 등의 구조를 생각할 수 있습니다.

13장 WebRTC 통화가 연결되는 전체 흐름#

원본 자료에서는 WebRTC 통화 성립 과정을 다음 순서로 설명합니다.

  1. getUserMedia
  2. RTCPeerConnection 생성
  3. Offer/Answer 교환
  4. ICE Candidate 교환
  5. ICE Connectivity Check
  6. DTLS Handshake
  7. SRTP
  8. 미디어 송수신

처음 보면 복잡하지만 크게 세 부분으로 나누면 쉽습니다.

첫 번째#

마이크·카메라 준비

두 번째#

연결 가능한 네트워크 경로 찾기

세 번째#

암호화된 음성·영상 통신 시작

입니다.

14장 Offer와 Answer란 무엇인가#

WebRTC에서는 양쪽이 어떤 방식으로 통신할지 협상해야 합니다.

한쪽에서:

Offer

를 만들고 상대방이 이를 받은 뒤:

Answer

를 반환합니다.

이 과정에는 SDP Session Description Protocol가 사용됩니다.

원본 자료에서는:

createOffer
↓
SDP
↓
상대방 전달
↓
createAnswer
↓
SDP

흐름으로 설명합니다.

15장 SDP는 무엇인가#

SDP는 통화 연결에 필요한 미디어 정보를 표현하는 데 사용됩니다.

예를 들어:

  • 오디오 사용 여부
  • 비디오 사용 여부
  • 코덱
  • 네트워크 정보

등을 협상하는 데 사용됩니다.

즉 SDP 자체가 음성을 전달하는 것은 아닙니다.

어떤 조건으로 통화할지를 설명하는 정보라고 이해하면 됩니다.

16장 ICE Candidate란 무엇인가#

WebRTC에서는 두 통신 당사자가 서로 연결될 수 있는 네트워크 경로를 찾아야 합니다.

이때 가능한:

  • IP 주소
  • 포트
  • 네트워크 경로

정보를 ICE Candidate로 교환합니다.

원본 자료에서는 양측이 가능한 IP와 포트를 발견한 뒤 이를 시그널링 채널을 통해 교환한다고 설명합니다.

17장 ICE가 필요한 이유#

회사나 가정의 PC는 대부분 인터넷에 직접 노출되어 있지 않습니다.

방화벽이나 NAT 뒤에 있습니다.

따라서 단순히:

상대방 IP로 바로 연결하면 된다.

라고 생각하기 어렵습니다.

ICE는 여러 후보 경로를 찾고 실제 통신 가능한 경로를 확인하는 역할을 합니다.

18장 STUN과 TURN은 어디에서 등장하는가#

WebRTC 네트워크 연결에서는 STUN과 TURN도 중요한 개념입니다.

원본 WebRTC 흐름에서는 ICE Connectivity Check 과정에서 STUN Binding Request로 실제 도달 가능한 경로를 확인한다고 설명합니다.

직접 연결이 어려운 네트워크 환경에서는 중계 서버가 필요한 구조도 존재할 수 있습니다.

ThinkX에서 개념적으로는 다음처럼 이해하면 됩니다.

ICE = 연결 경로 찾기

STUN = 외부에서 보이는 네트워크 정보 확인에 활용

TURN = 직접 연결이 어려울 때 미디어 중계에 활용

입니다.

19장 DTLS와 SRTP는 왜 필요한가#

콜센터 통화에는 고객의 음성이 포함됩니다.

따라서 미디어 데이터를 평문으로 전달하면 보안 문제가 발생할 수 있습니다.

원본 자료에서는 WebRTC 보안에서:

  • DTLS
  • SRTP
  • HTTPS

를 중요하게 제시합니다.

DTLS#

미디어 통신에 사용할 암호화 키를 협상합니다.

SRTP#

실제 음성·영상 데이터를 암호화해 전송합니다.

20장 브라우저 마이크 권한이 필요한 이유#

WebRTC에서 브라우저가 사용자의 마이크나 카메라를 임의로 사용할 수 있어서는 안 됩니다.

따라서 사용자 권한이 필요합니다.

원본 자료에서도:

마이크와 카메라는 사용자의 명시적 동의

가 필요하다고 설명합니다.

상담 시스템을 웹으로 구축할 때는 단순히 CTI 서버만 정상이라고 끝나는 것이 아니라 브라우저 권한도 확인해야 합니다.

21장 HTTPS가 중요한 이유#

원본 자료에서는 getUserMedia가 보안 컨텍스트에서 동작하기 때문에 HTTPS가 필요하다고 설명합니다.

따라서 웹 기반 소프트폰을 구축하면서 HTTPS 설정이 잘못되면:

  • 마이크 접근 실패
  • 카메라 접근 실패
  • WebRTC 기능 제한

등이 발생할 수 있습니다.

22장 WebRTC의 음성 코덱#

원본 자료에서는 WebRTC 음성 코덱의 예로 Opus를 제시합니다.

콜센터에서 음성 코덱은 다음 요소에 영향을 줄 수 있습니다.

  • 음질
  • 네트워크 대역폭
  • 지연
  • 다른 전화 시스템과의 호환

브라우저 WebRTC와 기존 PBX가 서로 다른 코덱이나 미디어 방식을 사용한다면 중간 게이트웨이나 SBC에서 변환이 필요할 수도 있습니다.

23장 WebRTC를 기존 PBX에 바로 연결할 수 있을까#

원본 자료에서는 WebRTC를 기존 SIP/PBX에 연결하려면 WebRTC-SIP 게이트웨이 또는 상용 SBC가 필요한 구조를 설명합니다.

이유는 브라우저 WebRTC와 기존 전화망의 통신 방식이 완전히 동일하지 않기 때문입니다.

개념적으로는 다음과 같습니다.

브라우저 WebRTC
      ↕
WebRTC-SIP Gateway
      ↕
     SIP
      ↕
     PBX

게이트웨이가 두 환경 사이를 연결합니다.

24장 WebRTC-SIP Gateway는 무슨 역할을 하는가#

WebRTC 환경과 SIP 전화망 사이에서 다음 요소를 연결할 수 있습니다.

  • 시그널링
  • 코덱
  • 미디어
  • 보안
  • 세션

원본 자료에서는 예시로 Janus, FreeSWITCH, Asterisk 또는 상용 SBC를 언급합니다.

중요한 것은 특정 제품명이 아니라 브라우저 통신과 기존 전화망 사이에 변환 계층이 필요할 수 있다는 구조입니다.

25장 Pure WebRTC 구조#

원본 자료에서는 콜센터 통합 패턴 중 하나로 Pure WebRTC를 제시합니다.

구조를 단순화하면:

브라우저 A
   ↕
WebSocket Signaling
   ↕
브라우저 B

실제 음성·영상
브라우저 A ↔ 브라우저 B

처럼 생각할 수 있습니다.

미디어는 P2P 또는 SFU를 사용할 수 있고 시그널링은 WebSocket을 사용할 수 있습니다.

26장 WebRTC-SIP 통합 구조#

기존 콜센터 PBX가 SIP 기반이라면 다음 형태를 생각할 수 있습니다.

상담원 브라우저
     ↓
   WebRTC
     ↓
WebRTC-SIP Gateway
     ↓
    SIP
     ↓
PBX / Contact Center

이 구조를 사용하면 상담원은 브라우저에서 통화하면서 기존 SIP 기반 콜센터 인프라와 연결될 수 있습니다.

27장 WebRTC + Contact Center 구조#

원본 자료에서는 또 다른 형태로 WebRTC + Contact Center 패턴을 제시합니다.

이 경우 벤더의 자체 시그널링을 사용하면서 미디어는 WebRTC 또는 RTP 방식으로 처리될 수 있습니다.

즉 현대적인 컨택센터에서는 반드시 하나의 표준 구조만 존재하는 것이 아닙니다.

벤더 플랫폼에 따라:

  • 시그널링
  • 미디어
  • CTI API

구조가 달라질 수 있습니다.

28장 WebSocket은 CTI 이벤트에도 적합하다#

브라우저 상담 화면에서는 통화 미디어뿐 아니라 CTI 이벤트도 실시간으로 받아야 합니다.

예를 들어 서버에서:

Ringing

이벤트가 발생하면 브라우저는 즉시:

고객 전화가 들어왔습니다.

라는 화면을 표시해야 합니다.

이런 구조에서는 WebSocket을 이용해 서버 이벤트를 실시간으로 전달할 수 있습니다.

PBX
 ↓
CTI 서버
 ↓
WebSocket
 ↓
상담원 브라우저

처럼 이해할 수 있습니다.

29장 브라우저 CTI의 인바운드 흐름#

고객이 전화를 걸었을 때 하나의 예시 흐름을 만들어보겠습니다.

고객
 ↓
PSTN / SIP
 ↓
PBX / Contact Center
 ↓
ACD
 ↓
CTI 서버
 ↓
WebSocket 이벤트
 ↓
상담원 브라우저
 ↓
Screen Pop

동시에 실제 음성은 WebRTC 기반 소프트폰으로 연결될 수 있습니다.

즉 한 통의 전화에서도:

전화 상태 이벤트

와

음성 미디어

가 서로 다른 경로를 사용할 수 있습니다.

30장 CTI 이벤트와 음성 미디어를 구분해야 한다#

이 부분은 매우 중요합니다.

전화 한 통을 웹에서 처리한다고 해서 모든 데이터가 WebSocket 하나를 통해 이동하는 것은 아닙니다.

개념적으로:

CTI 상태 이벤트#

WebSocket 등의 실시간 메시지 채널

실제 음성#

WebRTC 미디어

로 나눌 수 있습니다.

즉:

상태 정보 → WebSocket
음성·영상 → WebRTC

처럼 이해하면 구조가 훨씬 선명해집니다.

31장 WebRTC와 RTP의 관계#

기존 VoIP 시스템에서는 실제 음성 미디어를 RTP로 전달합니다.

WebRTC 역시 실시간 미디어 전송 기술을 사용하지만 보안과 브라우저 환경에 맞는 구조를 갖습니다.

원본 자료에서는 WebRTC-SIP 게이트웨이 패턴에서:

WebRTC ↔ RTP 변환

이 이루어지는 형태를 제시합니다.

따라서 기존 PBX와 웹 기반 소프트폰을 연동하면 미디어 변환이 중요한 설계 요소가 될 수 있습니다.

32장 브라우저 기반 소프트폰의 장점#

원본 자료에서 WebRTC의 콜시스템 활용 가치 중 하나는 별도의 프로그램 설치 없이 브라우저에서 통화할 수 있다는 것입니다.

이를 상담원 환경에서 보면 다음과 같은 변화가 가능합니다.

  • 하드웨어 전화기 의존 감소
  • CRM과 전화 UI 통합
  • 웹 애플리케이션 기반 배포
  • 키오스크·모바일·웹으로 채널 확장
  • 음성뿐 아니라 영상 상담 지원

33장 상담원 자리도 단순해질 수 있다#

전통적인 상담원 자리:

PC
+
전화기
+
헤드셋

브라우저 소프트폰 환경:

PC
+
브라우저
+
헤드셋

처럼 바뀔 수 있습니다.

전화 기능이 브라우저 안으로 들어오기 때문입니다.

다만 실제 서비스에서는 네트워크 품질, 브라우저 권한, 장비 호환성 등을 함께 고려해야 합니다.

34장 키오스크와 WebRTC#

원본 자료에서는 WebRTC를 브라우저뿐 아니라 앱과 키오스크의 실시간 통화에도 활용할 수 있는 기술로 분류합니다.

예를 들어 매장 키오스크에서:

상담원 연결

버튼을 누르면 원격 상담원과 음성 또는 영상 상담을 연결하는 구조를 만들 수 있습니다.

이 경우 WebRTC는 현장 단말과 상담센터를 연결하는 실시간 통신 기술이 될 수 있습니다.

35장 영상 상담으로 확장하면#

음성 통화만 지원하는 CTI에서 영상 상담으로 확장하면 추가로:

  • 카메라
  • 비디오 스트림
  • 영상 코덱
  • 화면 공유

등이 필요합니다.

WebRTC는 원본 자료에서:

  • 음성
  • 영상
  • 화면 공유
  • 데이터 채널

과 연결됩니다.

따라서 웹 기반 CTI를 영상 상담 플랫폼으로 확장할 수 있는 기반이 됩니다.

36장 WebSocket 연결이 끊기면 어떤 문제가 생길까#

브라우저 상담 프로그램이 실시간 CTI 이벤트를 WebSocket으로 받고 있다고 가정해보겠습니다.

연결이 끊기면:

  • Ringing 이벤트 미수신
  • 통화 종료 상태 미반영
  • 상담원 상태 동기화 오류
  • Screen Pop 실패

같은 문제가 생길 수 있습니다.

전화 자체의 미디어 경로가 별도로 유지되고 있다면 통화는 되는데 화면 상태만 맞지 않는 현상도 가능할 수 있습니다.

이는 기존 CTI 서버 장애와 비슷한 형태입니다.

37장 WebRTC 장애와 WebSocket 장애는 다르다#

두 문제를 구분해야 장애 분석이 쉬워집니다.

WebRTC 문제#

  • 음성이 안 들림
  • 마이크 연결 실패
  • 영상 안 보임
  • 통화 연결 실패

WebSocket·CTI 이벤트 문제#

  • 전화는 되는데 Screen Pop 안 됨
  • 통화 상태가 화면에 반영되지 않음
  • 상담원 상태 갱신 실패

즉:

미디어 문제

와

이벤트 문제

를 나누어 봐야 합니다.

38장 브라우저에서 통화가 안 될 때 확인할 것#

WebRTC 기반 소프트폰 장애에서는 다음 범주를 나누어 볼 수 있습니다.

브라우저 권한#

마이크·카메라 권한 확인

HTTPS#

보안 컨텍스트 확인

시그널링#

Offer·Answer 및 WebSocket 연결 확인

ICE#

연결 가능한 네트워크 경로 확인

미디어#

코덱과 SRTP 상태 확인

CTI#

상담원 상태와 전화 이벤트 전달 확인

이처럼 브라우저 소프트폰은 웹 애플리케이션과 전화 시스템의 문제를 함께 봐야 합니다.

39장 WebRTC 보안에서 기억할 것#

원본 자료에서는 다음 요소를 핵심으로 제시합니다.

HTTPS#

브라우저 미디어 권한 사용을 위한 보안 환경

DTLS#

암호화 키 협상

SRTP#

음성·영상 미디어 암호화

사용자 권한#

마이크·카메라 접근 동의

즉 WebRTC는 단순히 브라우저에서 음성을 전송하는 기술이 아니라 보안된 실시간 미디어 통신 구조를 갖습니다.

40장 CTI 보안과 WebRTC 보안을 함께 봐야 한다#

브라우저 기반 상담 시스템에서는 두 종류의 보안을 모두 고려해야 합니다.

CTI 명령 보안#

누가 발신·전환·종료 명령을 실행할 수 있는가

미디어 보안#

누가 실제 음성과 영상에 접근할 수 있는가

따라서:

  • 상담원 인증
  • 세션 관리
  • API 권한
  • WebSocket 인증
  • 미디어 암호화

등을 하나의 구조로 봐야 합니다.

41장 기존 CTI와 브라우저 CTI의 차이#

항목 전통적인 CTI 브라우저 기반 CTI
상담 단말 전화기 + PC 브라우저 + 헤드셋
통화 전화기·소프트폰 WebRTC 가능
실시간 화면 이벤트 CTI 클라이언트 WebSocket 등
CRM 별도 프로그램 가능 웹 UI 통합 가능
배포 단말별 프로그램 가능 웹 기반 가능
영상 상담 별도 시스템 필요 가능 WebRTC로 확장 가능

핵심은 전화와 업무 화면의 경계가 점점 줄어든다는 것입니다.

42장 WebRTC와 WebSocket을 한 문장으로 구분하면#

가장 쉽게 기억하면 다음과 같습니다.

WebRTC는 브라우저에서 실제 음성·영상 통신을 담당하고, WebSocket은 통화 연결에 필요한 시그널링이나 CTI 상태 이벤트를 실시간으로 전달하는 데 활용할 수 있다.

즉:

WebRTC = 미디어

WebSocket = 실시간 메시지

입니다.

43장 CTI 관점에서 가장 중요한 구조#

CTI 관점에서 보면 다음 구조가 핵심입니다.

PBX / Contact Center
        ↕
     CTI 서버
        ↕
     WebSocket
        ↕
상담원 브라우저
 ├─ CRM
 └─ WebRTC 소프트폰

전화 상태는 CTI와 WebSocket으로 전달하고 실제 음성은 WebRTC로 처리하는 구조를 생각할 수 있습니다.

WebRTC·WebSocket CTI FAQ#

WebRTC란 무엇인가?#

브라우저·앱·키오스크에서 실시간 음성·영상·데이터 통신을 할 수 있게 해주는 기술입니다. 원본 자료에서는 브라우저 기반 소프트폰의 핵심 기술로 설명합니다.

WebSocket은 CTI에서 무엇에 사용할 수 있는가?#

브라우저와 서버 사이에서 Ringing, Established, Released 같은 실시간 전화 상태나 시그널링 메시지를 전달하는 데 활용할 수 있습니다.

WebRTC와 WebSocket은 같은 기술인가?#

아닙니다. WebRTC는 주로 음성·영상 미디어 통신을 담당하고 WebSocket은 실시간 메시지 전달에 사용할 수 있습니다.

WebRTC에는 시그널링 기능이 포함되어 있는가?#

원본 자료에서는 WebRTC 표준이 특정 시그널링 방식을 포함하지 않으며 WebSocket, SIP 또는 자체 프로토콜 등을 사용할 수 있다고 설명합니다.

WebRTC의 핵심 구성요소는 무엇인가?#

원본 자료에서는 MediaStream, RTCPeerConnection, RTCDataChannel을 세 가지 핵심으로 제시합니다.

WebRTC를 기존 SIP PBX와 연결할 수 있는가?#

원본 자료에서는 WebRTC-SIP 게이트웨이나 상용 SBC를 통해 연동하는 구조를 설명합니다.

WebRTC 통화의 기본 흐름은 무엇인가?#

getUserMedia → RTCPeerConnection → Offer/Answer → ICE Candidate → Connectivity Check → DTLS → SRTP → 미디어 송수신 순으로 설명됩니다.

WebRTC에서 HTTPS가 필요한 이유는 무엇인가?#

원본 자료에서는 getUserMedia가 보안 컨텍스트에서 동작하므로 HTTPS가 필요하다고 설명합니다.

전화는 되는데 Screen Pop만 안 된다면 WebRTC 문제인가?#

반드시 그렇지는 않습니다. 음성 통화와 CTI 이벤트는 다른 경로로 처리될 수 있으므로 WebSocket이나 CTI 이벤트 전달 문제를 별도로 확인해야 합니다.

핵심 정리#

브라우저 기반 CTI에서는 WebRTC와 WebSocket이 서로 다른 역할을 담당합니다.

WebRTC는:

음성

영상

실시간 미디어

를 처리합니다.

WebSocket은:

시그널링

CTI 이벤트

상담원 상태

같은 실시간 메시지를 전달하는 데 활용할 수 있습니다.

전체 구조를 간단히 보면:

PBX / Contact Center
        ↓
     CTI 서버
        ↓
     WebSocket
        ↓
상담원 브라우저
        ↓
      WebRTC
        ↓
   실제 음성·영상

입니다.

원본 자료에서도 WebRTC·WebSocket을 브라우저 기반 소프트폰의 CTI 연동 기술로 분류하고 있으며, WebRTC는 MediaStream·RTCPeerConnection·RTCDataChannel을 핵심 구성요소로 갖습니다.

또한 WebRTC는 특정 시그널링 프로토콜을 자체적으로 강제하지 않으므로 WebSocket이나 SIP 등의 방식을 선택할 수 있습니다. 기존 SIP/PBX와 연결할 때는 WebRTC-SIP 게이트웨이나 SBC가 필요한 구조도 존재합니다.

가장 짧게 정리하면 다음과 같습니다.

WebRTC는 통화하고, WebSocket은 통화에 필요한 실시간 정보를 전달한다.

이 페이지의 목차