TSAPI와 JTAPI란? CTI 연동 인터페이스와 Avaya·Cisco 전화 제어 구조 이해하기

1장 CTI에서 API가 필요한 이유#

콜센터 시스템은 하나의 프로그램으로만 구성되지 않습니다.

전화는 PBX에서 처리하고, 상담원은 CRM을 사용하며, ACD는 전화를 분배하고, CTI 서버는 전화 상태와 업무 화면을 연결합니다.

문제는 이 시스템들이 서로 다른 방식으로 동작한다는 것입니다.

PBX는 다음과 같은 전화 상태를 알고 있습니다.

전화가 들어왔는가
어느 내선에서 벨이 울리는가
상담원이 전화를 받았는가
통화가 보류되었는가
다른 상담원에게 전환되었는가
통화가 종료되었는가

반면 CRM에서는 다음과 같은 기능이 필요합니다.

고객정보 자동 표시
고객번호 클릭 후 발신
통화 시작·종료 시간 기록
상담원 상태 표시
상담이력 자동 연결

이 둘을 연결하려면 PBX가 알고 있는 전화 상태를 애플리케이션에서 사용할 수 있는 인터페이스가 필요합니다.

이때 등장하는 대표적인 CTI 기술이 TSAPI와 JTAPI입니다.

원본 자료에서도 TSAPI와 JTAPI를 Avaya·Cisco 등 CTI 환경에서 사용되는 연동 방식으로 분류하고 있습니다.

2장 TSAPI란 무엇인가#

TSAPI는 Telephony Services API 계열의 CTI 인터페이스입니다.

핵심 역할은 전화 시스템에서 발생하는 이벤트와 통화 제어 기능을 외부 애플리케이션에서 사용할 수 있도록 연결하는 것입니다.

쉽게 표현하면:

PBX에서 일어나는 일을 프로그램이 알 수 있도록 해주는 통로

라고 이해할 수 있습니다.

예를 들어 고객이 상담원에게 전화를 걸면 PBX에서는 착신 이벤트가 발생합니다.

TSAPI를 사용하는 CTI 시스템에서는 이 이벤트를 받아:

어느 번호에서 전화가 왔는지
어느 상담원에게 연결되는지
통화가 언제 연결됐는지

등을 업무 시스템에 전달할 수 있습니다.

3장 JTAPI란 무엇인가#

JTAPI는 이름 그대로 Java 기반 애플리케이션에서 전화 기능을 연동하기 위한 API로 이해할 수 있습니다.

CTI 시스템이 Java로 개발되어 있다면 PBX와 전화 기능을 연결하는 인터페이스로 사용할 수 있습니다.

즉 개념적으로:

TSAPI

→ CTI 전화 서비스 인터페이스

JTAPI

→ Java 환경에서 전화 기능을 다루는 인터페이스

라고 구분할 수 있습니다.

원본 자료에서는 TSAPI와 JTAPI를 함께 CTI 연동 방식으로 분류하고 있습니다.

4장 TSAPI와 JTAPI는 왜 필요한가#

PBX가 있다고 해서 CRM이 자동으로 전화 상태를 알 수 있는 것은 아닙니다.

예를 들어 전화가 상담원에게 들어왔다고 하겠습니다.

PBX는:

내선 2101에 전화가 들어왔다.

는 것을 알고 있습니다.

하지만 CRM은 기본적으로 이 사실을 모릅니다.

CTI 인터페이스를 통해 이벤트가 전달되면:

PBX
 ↓
TSAPI / JTAPI 등의 CTI 인터페이스
 ↓
CTI 서버
 ↓
CRM
 ↓
고객정보 표시

와 같은 흐름을 만들 수 있습니다.

즉 TSAPI와 JTAPI는 전화 시스템 내부의 상태를 외부 애플리케이션으로 꺼내는 연결 통로라고 이해하면 쉽습니다.

5장 TSAPI와 JTAPI가 CTI 구조에서 위치하는 곳#

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

전화기 / 상담원 단말
        ↓
       PBX
        ↕
 TSAPI / JTAPI
        ↕
     CTI 서버
        ↕
 CRM / 상담 프로그램

중요한 점은 TSAPI나 JTAPI가 CRM 자체는 아니라는 것입니다.

또 PBX를 대신하는 것도 아닙니다.

PBX와 CTI 애플리케이션 사이에서 전화 기능을 프로그램으로 이용할 수 있게 해주는 인터페이스입니다.

6장 TSAPI·JTAPI를 통해 받을 수 있는 대표적인 전화 이벤트#

CTI 환경에서 대표적으로 다루는 이벤트에는 다음과 같은 것들이 있습니다.

Ringing#

전화가 상담원 단말에 착신되어 벨이 울리는 상태입니다.

Established#

실제 통화가 연결된 상태입니다.

Held#

통화를 보류한 상태입니다.

Transferred#

통화를 다른 상담원이나 내선으로 전환한 상태입니다.

Released#

통화가 종료된 상태입니다.

원본 CTI 자료에서도 Ringing, Established, Released, Held, Transferred 등을 대표적인 CTI 이벤트로 제시합니다.

이런 이벤트들이 CTI 인터페이스를 통해 업무 시스템으로 전달되면 CRM 화면도 전화 상태에 맞춰 자동으로 움직일 수 있습니다.

7장 전화 이벤트와 CRM은 어떻게 연결되는가#

고객이 전화했을 때 Screen Pop이 발생하는 상황을 생각해보겠습니다.

전형적인 흐름은 다음과 같습니다.

고객 전화
 ↓
PBX
 ↓
착신 이벤트 발생
 ↓
CTI 인터페이스
 ↓
CTI 서버
 ↓
CRM
 ↓
고객정보 조회
 ↓
Screen Pop

CRM은 PBX에 직접 접근하지 않아도 됩니다.

CTI 계층을 통해 필요한 이벤트를 받아 업무 화면을 변경할 수 있습니다.

8장 TSAPI·JTAPI는 이벤트만 받는 기술인가#

아닙니다.

CTI는 전화 이벤트를 받는 것뿐 아니라 전화 제어 명령을 반대로 보낼 수도 있습니다.

예를 들어 상담원이 CRM에서 고객 번호를 클릭한다고 하겠습니다.

CRM
 ↓
Click-to-Call 요청
 ↓
CTI 서버
 ↓
CTI API
 ↓
PBX
 ↓
상담원 전화기
 ↓
고객에게 발신

처럼 동작할 수 있습니다.

즉 CTI 인터페이스는 크게 두 역할을 합니다.

PBX → 애플리케이션

→ 이벤트 전달

애플리케이션 → PBX

→ 전화 제어

입니다.

9장 CTI에서 사용할 수 있는 대표적인 제어 기능#

원본 CTI 자료에서는 상담원이 화면에서 사용할 수 있는 주요 통화 제어 기능으로 다음을 제시합니다.

Click-to-Call
Answer
Hold
Retrieve
Transfer
Conference
Hangup

이를 각각 살펴보겠습니다.

Click-to-Call#

CRM의 전화번호를 클릭해서 발신합니다.

Answer#

착신된 전화를 받습니다.

Hold#

현재 통화를 보류합니다.

Retrieve#

보류된 통화를 다시 연결합니다.

Transfer#

다른 상담원이나 내선으로 통화를 넘깁니다.

Conference#

여러 사람을 하나의 통화에 참여시킵니다.

Hangup#

통화를 종료합니다.

10장 TSAPI와 Third-Party CTI의 관계#

앞에서 First-Party와 Third-Party CTI를 구분했습니다.

TSAPI와 같은 인터페이스는 특히 중앙 CTI 서버가 PBX의 전화 상태를 관리하는 구조를 이해할 때 함께 생각하기 좋습니다.

Third-Party CTI 구조는 다음처럼 볼 수 있습니다.

상담원 CRM
    ↓
 CTI 서버
    ↓
 CTI API
    ↓
   PBX
    ↓
상담원 단말

중앙 CTI 서버가 여러 상담원과 전화기의 상태를 관리합니다.

따라서 대규모 콜센터에서는 전화기 하나만 제어하는 것이 아니라 전체 상담원 상태를 중앙에서 관리하는 구조가 중요합니다.

11장 Avaya 환경에서 TSAPI와 JTAPI#

원본 자료에서는 Avaya Aura 구조에서 AES Application Enablement Services가 CTI API를 제공하며 TSAPI와 JTAPI를 사용한다고 설명합니다.

원본에 제시된 Avaya Aura 구성은 다음과 같습니다.

CM Communication Manager#

핵심 PBX 역할을 담당합니다.

System Manager#

중앙 관리와 인증 역할을 담당합니다.

Session Manager#

SIP 라우팅과 세션 관리에 사용됩니다.

AES Application Enablement Services#

외부 애플리케이션이 전화 시스템과 연동할 수 있도록 CTI API를 제공하는 계층입니다.

원본에서는 AES와 TSAPI·JTAPI를 직접 연결해 설명하고 있습니다.

12장 Avaya CTI 구조를 단순화하면#

Avaya 환경을 개념적으로 단순화하면 다음과 같이 이해할 수 있습니다.

상담원 전화기
      ↓
Avaya Communication Manager
      ↕
      AES
      ↕
 TSAPI / JTAPI
      ↕
   CTI 서버
      ↕
      CRM

실제 구축 구조는 제품 구성과 환경에 따라 달라질 수 있지만, 원본 자료에서 핵심적으로 설명하는 관계는:

Communication Manager

AES

TSAPI/JTAPI

입니다.

13장 Cisco 환경과 JTAPI#

원본 자료에서는 CTI 개요에서 TSAPI/JTAPI를 Avaya·Cisco 같은 벤더 환경과 연결하고 있습니다.

Cisco 계열 콜시스템 역시 PBX 또는 콜 제어 플랫폼과 외부 애플리케이션을 연결할 때 CTI 인터페이스가 필요합니다.

이때 중요한 것은 제품 이름 자체를 외우는 것이 아니라 구조를 이해하는 것입니다.

전화 시스템
 ↓
CTI 인터페이스
 ↓
CTI 애플리케이션
 ↓
CRM

벤더가 달라지더라도 핵심 원리는 같습니다.

14장 벤더별 CTI 차이는 왜 생기는가#

콜센터에는 다양한 PBX와 컨택센터 솔루션이 존재합니다.

예를 들어 원본 자료에는 다음 벤더들이 별도로 분류되어 있습니다.

Cisco
Avaya
Genesys
Asterisk
FreeSWITCH
3CX

각 제품은 전화 이벤트를 전달하는 방식과 API 구조가 다를 수 있습니다.

그래서 CTI 서버에서는 종종 벤더별 차이를 흡수하는 중간 계층이 필요합니다.

원본 CTI 시스템 구성에서도 CTI 서버의 역할 중 하나로:

PBX 이벤트를 수신하고 정규화하여 벤더 차이를 흡수한다

고 설명합니다.

15장 이벤트 정규화란 무엇인가#

예를 들어 두 종류의 PBX가 있다고 하겠습니다.

PBX A:

ESTABLISHED

PBX B:

CALL_CONNECTED

처럼 같은 의미를 다른 이름으로 전달할 수 있습니다.

CRM이 모든 벤더의 이벤트를 직접 이해하려면 복잡해집니다.

그래서 CTI 미들웨어가 이를:

CALL_CONNECTED

같은 내부 표준 이벤트로 변환할 수 있습니다.

즉:

벤더별 PBX 이벤트
        ↓
   CTI 미들웨어
        ↓
  내부 표준 이벤트
        ↓
       CRM

처럼 구성할 수 있습니다.

이것이 CTI 서버가 필요한 중요한 이유 중 하나입니다.

16장 TSAPI와 CRM을 직접 연결하면 안 되는가#

기술적으로 특정 환경에서는 직접적인 구조를 만들 수 있겠지만 대형 콜센터에서는 보통 여러 요구사항이 존재합니다.

예를 들어:

상담원 매핑
세션 관리
장애 복구
이벤트 정규화
권한 관리
다중 CRM 연동
통계 시스템 연계

등입니다.

그래서 원본 자료의 구조에서도 CRM과 PBX 사이에 CTI 미들웨어를 두는 형태를 제시합니다.

구조를 단순화하면:

CRM
 ↕
CTI Middleware
 ↕
PBX

입니다.

17장 CTI 미들웨어가 필요한 이유#

CTI 미들웨어는 단순 전달자보다 훨씬 많은 역할을 할 수 있습니다.

이벤트 변환#

PBX 이벤트를 CRM에서 사용할 수 있는 형식으로 변환합니다.

상담원 매핑#

내선번호와 상담원 ID를 연결합니다.

명령 라우팅#

어느 상담원의 어떤 단말로 전화 명령을 보낼지 판단합니다.

연결 복구#

PBX 연결이 끊어졌을 때 다시 연결합니다.

상태 관리#

현재 통화와 상담원 상태를 관리합니다.

원본에서도 CTI 서버 역할로 이벤트 정규화, 단말 매핑, 명령 라우팅, 재접속과 세션 복구를 제시합니다.

18장 TSAPI·JTAPI와 상담원 상태#

CTI에서는 전화 상태뿐 아니라 상담원 상태도 중요합니다.

대표적으로:

Login
Logout
Ready
Not Ready
After Call Work

같은 상태를 관리합니다.

원본 자료에서는 이러한 상태가 ACD의 콜 분배와도 연결된다고 설명합니다.

예를 들어 상담원이 Ready라면 전화를 받을 수 있지만 Not Ready라면 콜 분배 대상에서 제외될 수 있습니다.

19장 CTI API와 ACD의 관계#

CTI와 ACD는 다른 시스템이지만 실제 콜센터에서는 밀접하게 연결됩니다.

ACD는:

누구에게 전화를 분배할 것인가

를 결정합니다.

CTI는:

그 전화 상태와 상담원 상태를 애플리케이션에 어떻게 전달할 것인가

를 처리합니다.

예를 들어:

상담원 Ready
 ↓
ACD가 분배 대상에 포함
 ↓
고객 전화 착신
 ↓
CTI 이벤트 발생
 ↓
CRM Screen Pop

처럼 하나의 흐름으로 동작할 수 있습니다.

20장 TSAPI·JTAPI와 Screen Pop#

Screen Pop을 구현하려면 전화가 어느 상담원에게 들어왔는지 알아야 합니다.

전형적인 흐름은 다음과 같습니다.

고객
 ↓
PBX
 ↓
전화 착신 이벤트
 ↓
CTI API
 ↓
CTI 서버
 ↓
상담원 식별
 ↓
CRM
 ↓
고객정보 화면 표시

원본 자료에서도 Screen Pop은:

호 착신 → PBX → CTI 이벤트 → CRM → 고객정보 표시

의 흐름으로 설명합니다.

21장 ANI와 DNIS도 CTI 이벤트에서 중요하다#

Screen Pop에서는 어떤 전화가 들어왔는지만으로는 충분하지 않습니다.

고객이나 업무를 식별할 수 있는 정보도 필요합니다.

원본 자료에서는 다음 두 값을 중요하게 설명합니다.

ANI#

Automatic Number Identification

발신번호입니다.

고객 식별에 사용할 수 있습니다.

DNIS#

Dialed Number Identification Service

고객이 어떤 번호로 전화했는지를 나타냅니다.

업무, 캠페인 또는 IVR 진입점을 구분하는 데 활용할 수 있습니다.

22장 CTI API 장애가 발생하면 어떤 현상이 나타날까#

PBX와 CTI 서버 사이의 연동이 끊어지면 전화 통화와 업무 화면의 상태가 분리될 수 있습니다.

예를 들어:

전화는 울리지만 Screen Pop이 안 됨
전화는 연결됐지만 CRM에는 Ringing 상태
통화가 끝났지만 CRM에서는 통화 중
상담원 상태가 실제와 다르게 표시됨
Click-to-Call이 실행되지 않음

같은 현상이 발생할 수 있습니다.

원본 자료에서도 CTI 서버 장애 시 전화는 가능하지만 화면 연동이 끊길 수 있다고 설명합니다.

23장 이벤트 누락이 왜 위험한가#

CTI 시스템은 이벤트의 순서로 전화 상태를 추적할 수 있습니다.

예를 들어:

Ringing
 ↓
Established
 ↓
Held
 ↓
Retrieved
 ↓
Released

순서로 이벤트가 발생했다고 하겠습니다.

그런데 Released가 누락되면 CRM은 실제 통화가 끝났는데도 계속 통화 중이라고 판단할 수 있습니다.

따라서 CTI 시스템에서는 단순히 API 연결 여부뿐 아니라:

이벤트 순서
이벤트 누락
중복 이벤트
재접속 후 상태 복구

도 중요합니다.

24장 CTI API에서 Call ID가 중요한 이유#

전화 한 통에는 여러 이벤트가 발생합니다.

예를 들어:

착신

연결

보류

재개

전환

종료

가 모두 같은 통화에 속할 수 있습니다.

따라서 시스템에서는 이 이벤트들이 같은 통화에 해당한다는 것을 식별할 값이 필요합니다.

SIP에서도 Call-ID가 사용되고, CTI 시스템에서도 통화를 추적할 수 있는 고유 식별값이 중요합니다.

이 식별자를 이용하면 장애 로그에서 하나의 통화를 처음부터 끝까지 추적할 수 있습니다.

25장 CTI API 보안도 중요하다#

전화 제어 API는 단순 조회 API가 아닙니다.

권한이 있다면 실제 전화 기능을 움직일 수 있습니다.

원본 자료에서는 CTI API가 외부에 잘못 노출될 경우 임의 발신이나 통화 제어와 관련된 보안 위험이 있으므로 인증, 암호화, 권한 통제가 필요하다고 설명합니다.

따라서 CTI 인터페이스에서는 다음 요소가 중요합니다.

인증
권한 제어
세션 관리
접근제어
암호화
감사로그

26장 전화 API를 일반 업무 API처럼 보면 안 되는 이유#

일반적인 조회 API에서 문제가 발생하면 잘못된 데이터가 표시되는 수준에 그칠 수 있습니다.

하지만 CTI 제어 API는:

전화를 걸고
전화를 끊고
통화를 보류하고
다른 사람에게 전환

할 수 있습니다.

즉 실제 통신 행위에 영향을 줍니다.

따라서 누가 어떤 단말을 제어할 수 있는지 명확하게 제한해야 합니다.

27장 TSAPI와 JTAPI의 차이를 어떻게 기억하면 좋을까#

ThinkX에서 개념적으로 이해할 때는 다음처럼 기억하면 충분합니다.

TSAPI#

전화 서비스를 애플리케이션에 연결하는 CTI 인터페이스

JTAPI#

Java 애플리케이션에서 전화 기능을 사용할 수 있도록 하는 인터페이스

둘 모두 목적은 비슷합니다.

전화 기능을 프로그램에서 사용할 수 있게 만드는 것

입니다.

28장 TSAPI·JTAPI와 SIP는 같은 것인가#

같은 역할로 보면 안 됩니다.

SIP는 전화 세션을 설정하고 종료하는 시그널링 프로토콜입니다.

반면 TSAPI와 JTAPI는 CTI 애플리케이션이 전화 시스템의 상태와 제어 기능을 사용할 수 있도록 하는 애플리케이션 인터페이스입니다.

간단히 구분하면:

SIP = 전화 세션 제어 프로토콜

TSAPI·JTAPI = 전화 기능을 애플리케이션에 연결

입니다.

29장 SIP와 CTI API가 함께 존재할 수 있는 이유#

콜센터에서는 실제 통화 흐름과 업무 애플리케이션 연동이 동시에 필요합니다.

예를 들어 실제 전화는 SIP를 통해 연결되지만 CRM에서는 CTI API를 통해 전화 상태를 전달받을 수 있습니다.

         SIP
전화기 ↔ PBX
          ↕
       CTI API
          ↕
       CTI 서버
          ↕
         CRM

따라서 SIP와 CTI API는 경쟁 관계라기보다 서로 다른 역할을 담당합니다.

30장 TSAPI·JTAPI와 WebRTC·WebSocket의 관계#

원본 자료에서는 TSAPI·JTAPI와 함께 WebRTC·WebSocket도 CTI 연동 방식으로 제시합니다.

WebRTC와 WebSocket은 특히 브라우저 기반 소프트폰이나 웹 상담 프로그램에서 중요합니다.

전통적인 CTI 환경이:

전화기 + PBX + CTI 서버 + CRM

이었다면 브라우저 기반 환경은:

브라우저
 ├─ CRM
 ├─ 소프트폰
 └─ CTI 이벤트

처럼 화면과 전화 기능이 하나의 애플리케이션에 통합될 수 있습니다.

31장 그렇다면 TSAPI와 JTAPI는 사라지는 기술인가#

그렇게 단순하게 볼 수는 없습니다.

콜센터에는 여전히 다양한 온프레미스 PBX와 기존 CTI 시스템이 운영되고 있고, 기존 업무 시스템 역시 상당 기간 유지될 수 있습니다.

동시에 클라우드 컨택센터에서는 REST API, WebSocket, WebRTC, SDK 같은 방식이 더 중요해질 수 있습니다.

즉 CTI 기술은 한 번에 교체되는 것이 아니라 기존 PBX 중심 방식과 클라우드 API 중심 방식이 함께 존재하는 구조로 이해하는 편이 좋습니다.

32장 CTI 개발자가 TSAPI·JTAPI를 알아야 하는 이유#

CTI를 개발하거나 운영한다면 단순히 API 이름을 아는 것보다 다음 구조를 이해하는 것이 중요합니다.

첫째#

전화는 PBX에서 발생합니다.

둘째#

PBX 이벤트를 CTI 인터페이스가 외부로 전달합니다.

셋째#

CTI 서버가 이를 상담원·CRM 데이터와 연결합니다.

넷째#

CRM의 명령은 반대로 CTI를 거쳐 전화 시스템으로 전달됩니다.

즉 핵심은:

Call Event + Agent + CRM + Control

을 연결하는 것입니다.

33장 CTI 장애를 분석할 때 인터페이스를 기준으로 나누는 방법#

Screen Pop이 안 된다고 하겠습니다.

다음 순서로 볼 수 있습니다.

1. PBX에서 전화 이벤트가 발생했는가#

전화 시스템 확인

2. CTI API까지 이벤트가 전달됐는가#

PBX와 CTI 인터페이스 확인

3. CTI 서버가 이벤트를 받았는가#

CTI 세션 확인

4. 상담원 매핑이 정상인가#

내선과 상담원 ID 확인

5. CRM으로 이벤트가 전달됐는가#

CTI와 CRM 연동 확인

6. CRM이 고객을 조회했는가#

CRM과 DB 확인

이렇게 단계별로 보면 원인을 훨씬 빠르게 좁힐 수 있습니다.

34장 TSAPI·JTAPI를 현장 관점에서 한 문장으로 설명하면#

기술적인 이름이 어려워 보여도 역할은 비교적 단순합니다.

PBX가 가지고 있는 전화 상태와 전화 제어 기능을 외부 CTI 애플리케이션에서 사용할 수 있게 해주는 인터페이스다.

즉 전화 시스템과 소프트웨어 사이의 번역 창구라고 생각하면 쉽습니다.

35장 CTI 인터페이스 구조 핵심 비교#

구분	역할
PBX	실제 전화 호 처리
TSAPI/JTAPI	전화 기능을 애플리케이션에 제공
CTI 서버	이벤트 정규화·상담원 매핑·명령 라우팅
CRM	고객정보·상담이력 처리
ACD	상담원에게 호 분배
SIP	전화 세션 시그널링
WebRTC	브라우저 기반 실시간 음성·영상
WebSocket	브라우저와 서버 간 실시간 이벤트 전달에 활용

TSAPI·JTAPI FAQ#

TSAPI란 무엇인가#

전화 시스템의 이벤트와 제어 기능을 외부 CTI 애플리케이션에서 사용할 수 있게 하는 인터페이스 계열입니다.

JTAPI란 무엇인가#

Java 애플리케이션에서 전화 기능을 연동하기 위한 CTI 인터페이스입니다.

TSAPI와 JTAPI는 어디에 사용되는가#

원본 자료에서는 Avaya·Cisco 등 벤더 환경에서 사용하는 CTI 연동 방식으로 제시합니다.

Avaya에서 TSAPI와 JTAPI는 어디와 연결되는가#

원본 자료에서는 Avaya Aura의 AES Application Enablement Services가 CTI API로 TSAPI와 JTAPI를 제공하는 구조를 설명합니다.

TSAPI와 SIP는 같은 기술인가#

아닙니다. SIP는 통화 세션을 설정·종료하는 시그널링 프로토콜이고 TSAPI는 애플리케이션과 전화 시스템을 연동하는 CTI 인터페이스입니다.

TSAPI·JTAPI를 이용하면 어떤 이벤트를 받을 수 있는가#

CTI 환경에서는 Ringing, Established, Held, Transferred, Released 같은 전화 상태 이벤트를 다룹니다.

전화 제어도 가능한가#

CTI 구조에서는 Click-to-Call, Answer, Hold, Transfer, Conference, Hangup 같은 기능을 애플리케이션에서 제어할 수 있습니다.

CTI API가 끊기면 전화도 끊기는가#

구조에 따라 다릅니다. 원본 자료에서는 CTI 장애 시 전화는 가능하지만 화면 연동이 중단될 수 있는 상황을 설명합니다.

CTI API에서 보안이 중요한 이유는 무엇인가#

실제 발신·종료·전환 같은 전화 제어 기능을 실행할 수 있기 때문입니다.

핵심 정리#

TSAPI와 JTAPI는 CTI 시스템에서 PBX와 업무 애플리케이션을 연결하는 전화 연동 인터페이스입니다.

전체 구조는 다음처럼 이해할 수 있습니다.

전화기
 ↓
PBX
 ↕
TSAPI / JTAPI
 ↕
CTI 서버
 ↕
CRM

TSAPI·JTAPI를 통해 CTI 시스템은:

Ringing

Established

Held

Transferred

Released

같은 전화 이벤트를 업무 시스템으로 전달할 수 있고,

반대로:

Click-to-Call

Answer

Hold

Transfer

Conference

Hangup

같은 전화 제어 기능을 수행할 수 있습니다.

원본 자료에서는 특히 Avaya Aura의 AES가 TSAPI·JTAPI 같은 CTI API를 제공하는 구조를 설명합니다.

가장 짧게 정리하면 다음 한 문장으로 기억하면 됩니다.

TSAPI와 JTAPI는 PBX의 전화 기능을 CTI 프로그램에서 사용할 수 있게 만들어주는 연결 인터페이스다.