IVR 소프트웨어 개발 살펴보기

Question

내가 일하는 회사는 잠재적 인 PBX/IVR 또는 PBX 콤보와 호환되거나 자체 호스팅 솔루션을 제공하는 IVR 구현을 찾고 있습니다.

그래서 잠재적 인 플랫폼과 인터페이스하고 IVR에 대한 통화 제어 및 음성 대화/상호 작용을 제공하는 응용 프로그램을 만드는 것이 좋습니다.

기술 지금까지 Java API를 사용하는 Java Telephony API (JTAPI)와 Java Call Control (JAIN-JCC) API 및 기타 기술에 대해 살펴 보았습니다. 이 API의 기본 요지는 나에게 의미가 있지만, 내가 조합 할 수없는 것은 호출 제어 및 음성 IVR/VXML 용 응용 프로그램이 전화 시스템에 플랫폼 독립적 인 방식으로 인터페이스하는 방식입니다. 전화 시스템에서 정확히 전화를 받으려면 어떻게해야합니까?

이 API 및 라이브러리는이 질문을 답장하지 않은 것으로 보입니다. 플랫폼 독립적 솔루션은 불가능하며 항상 구현 특정 사항이 될 것이라고 생각합니다. JAIN-SIP도 있습니다. 모든 통화를 SIP로 변환 할 수 있다면이 방법으로 일반 통화 제어/IVR 애플리케이션을 만들 수 있습니다.

만약 내가 여기에 어떤 잘못이나 오해가 있어도 용서해 주었다면, 어떤 종류의 통신 기술에 대해서 완전히 새로운 것입니다. 나는 매우 고맙게 여길 것입니다. 세부 구현 레벨의 연결은이 시점에서 매우 퍼지기도하고 때로는 약간의 손을 잡아야합니다. 올바른 방향으로 어떤 도움이나 푸시가 도움이 될 것입니다.

저는 지난 주 사양 및 API를 쏟아 부었습니다. :)

편집 - 우리는 가능하면 비용면에서 현명한면에서이를 개발하는 것을 선호한다는 것을 잊어 버렸습니다. 가능하다면 통합 플랫폼에 돈을 쓰려고하지 않습니다. 그게 내 일이야 :)

Answer 1

나는 몇 년 전에 VoiceGenie에서 일했다 : 나는 그들이 지금 무엇을하고 있는지 알지 못하기 때문에 여기에서 과거 시제를 사용한다. 그 일을)은 VoiceXML을 엔진 :

• 는 리눅스 박스
• 인가는 음성 - 투 - 텍스트 타사을 가지고 (엔진 관련 API와 인터페이스하여)
• VoiceXML을 해석하여 (자체 VoiceXML 파서 사용) 타사 Speech-to-text 및 텍스트 - 투 - 스피치 엔진을 구동하여 실행합니다. 음성 엔진은

그들은 제어 시스템에 전화를 자신의 상자를 인터페이스에 저를 고용 : 내가했다 시스코의가 (반대로, 내가 VoiceGenie 이제 제네시스가 소유 한 것을 참조) 것을 한 첫 번째 시스템. 그들의 엔진은 또한 non-VoiceXML 애플리케이션을 지원했다. 자바 애플리케이션 인터페이스를 공개했다.

결론적

:

• 각종 전화 시스템 독점 호 제어 API를 가지고; 표준 통화 제어 프로토콜 (예 : SIP) 및/또는 API (예 : JTAPI, TAPI, CCXML)를 지원할 수 있으며, 지원하는 경우 더 많거나 적은 수준으로 수행 할 수 있습니다.
• 일부 통합 API를 제공하는 타사 엔진 (예 : Genesys Voice Platform, Microsoft Office Communications Server 및 기타)을 찾을 수 있으며 다른 구성 요소와의 상호 운용성을 처리하고 지원할 수 있습니다.

저는이 필드에 제품 관리자, 시스템 엔지니어, 네트워크 설계자, 도메인 전문가가 아닙니다.

---

하지만 그들은 모두 일반적으로 일부에만 독점, 광고/또는 일부 지원을 하나 개 이상의 표준을 지원하는 프로토콜과 API의

의 소수를 지원합니다.

그래서 아이디어는 가장 많이 지원되는 API 또는 프로토콜에 인터페이스하는 것입니다.

저는 비즈니스 사례에 의문을 가지고 있지만 특정 도메인 전문 지식과 제품/구현 지식을 가진 전화 기술자를 찾아 이야기해야한다고 생각합니다. 나는 소프트웨어 개발자로서 일함으로써 위에 게시 한 것을 만났지만 도메인 전문 기술은 가지고 있지 않습니다.

SIP입니까?

SIP는 API가 아니라 프로토콜입니다. 이 물건은 레이어에 있습니다. 예를 들면 다음과 같이 사용할 수 있습니다.

• 하위 레벨 : 자체 API가있는 SIP 프로토콜 스택. 이 API를 사용하고 SIP 대화 상자의 모양을 이해하고 SIP를 이해하는 시스템과 통화하십시오 (

  )

• 상위 레벨 : VoiceXML/CCXML 엔진 (또는 TAPI 또는 JTAPI 엔진); XML을 작성하거나 TAPI 및 JTAPI API를 사용합니다. 및 엔진 (엔진에 따라 다름)에는 SIP를 사용하는 구성 요소와 통신하는 데 사용되는 내장 SIP 스택이있을 수 있으며 다른 SIP (비 SIP) 프로토콜을 사용하는 구성 요소에 대한 다른 프로토콜 스택을 가질 수 있습니다 .

시스코 단지 내가 그들의 "지능형 연락처 관리"(즉, 콜 센터) 시스템과 통신하기 위해 사용할 수있는 하나의 (독점) 프로토콜을했다. 제네시스는 독점적 인 API/프로토콜을 갖고 있지 않다고 생각합니다. 그럼 내 전화 제어 및 IVR 솔루션은 최고의 SIP 정면으로 구현 될 경우

JTAPI 응용 프로그램 또는 일부 변형에 끝?

나는 당신이하고 싶은 것에 대해 혼란 스럽습니다. 스택에서 당신이되고 싶은 곳은 혼란 스럽습니다. (당신은 어려울 것이다, 그들과 함께 완료하는 것을 시도하지 않는 한) 그들이 당신을 위해 무엇을 할 수 있는지 알아 :

나는 아마도 당신 에게서는 공급 업체와 얘기 할 수 있다고 생각합니다.

"잠재적 인 PBX/IVR 또는 PBX 콤보"의 의미를 좁힐 수 있습니까?

Answer 2

또 다른 질문으로 우리는 JTAPI를 사용하여 여러 전화 통신 시스템 (보드, PBX 및 IP 전화) 및 플랫폼을 지원하는 인터페이스를 만드는 오픈 소스 프로젝트를 발견했습니다. 이 방법은 내가 언급 한 것처럼 응용 프로그램을 개발할 수 있고 시스템에 관계없이 여러 가지 다른 시스템에서 작동하도록 할 수 있습니다.나는 예외가 있는지가하고 있지만, 이것은 그들 중 대다수와 함께 작동하도록되어 - TAPI 어쨌든 널리 승인 된 표준의 종류는 점을 고려 :

http://gjtapi.sourceforge.net/

Answer 3

: '일반 JTAPI'라는

그 Twilio으로 고통과 개발 시간을 절약하십시오. 기본적으로 PSTN/VOIP 연결을 처리하며 XML/HTTP REST로 수행 할 작업을 알려줍니다. Java를 포함하여 helper libraries in a variety of languages입니다.

Answer 4

나는이 공간에서 수년 동안 일했습니다. ChrisW의 대답은 아주 좋습니다. 유사한 상황에있는 사람들에게 도움이되는 몇 가지 추가 정보가 있습니다.

응용 프로그램을 호스팅하는 경우 대부분의 통합 문제가 사라 지므로 전제 솔루션을 제공한다고 가정합니다. 기능을 변경해야하고 대화 상자 및 비즈니스 논리에서 전화 통신 논리를 분리 한 경우 번역이 너무 어려워서는 안됩니다.

IVR/PBX의 통합 문제는 여러 가지 방법으로 표시 :

전화 : 전화하여

가, 내 말은 첫째 자 통화 제어합니다. 전화선의 특징.

• 콜 도착 정보 (ANI/DNIS). VoiceXML과 같은 상위 레벨에서 작업하고 있다면 여전히 다양한 문제가있을 수 있습니다. 그냥 약간 :
  • 데이터 존재. 모든 스위치가이 데이터를 제공하는 것은 아닙니다. 더 나쁜 것은 특정 스위치 구성에서만 데이터를 사용할 수 있다는 것입니다. 이러한 구성은 응용 프로그램이나 콜센터의 다른 요구 (전송)와 충돌 할 수 있습니다.
  • 데이터 형식. 응용 프로그램에 따라 문제가 될 수도 있고 아닐 수도 있지만 데이터 형식은 스위치마다 조금씩 다를 수 있습니다.
• 다양한 전송 유형. 주변 텔레포니 네트워크의 아키텍처에 따라 전송 유형이 달라질 수 있습니다. 일반적으로 VoiceXML에서 사용할 수있는 기본 후크 플래시 전송은 로컬 콜센터의 상담원이나 ACD로 전송할 때 작동합니다. 그러나 오프 사이트/오프 PBX/PBX-PBX 전송은 감독 (2 단계) 전송으로 수행해야합니다. VoiceXML 표준은 이러한 유형의 전송을 다루지 않습니다. 블라인드 전송 및 회의 만 다루지 만 대부분의 플랫폼은 추가 전송 논리에 액세스 할 수있는 메커니즘을 제공합니다.

컴퓨터 전화 통합 (CTI) : CTI으로

, 내가 PBX와 데이터 통합을 통해 첫 번째 또는 제 3 자의 통화 제어를 의미한다.

• 기능상의 차이점. 아마도 대부분은 상상할 수 있습니다. ACD가있는 콜센터에 있으면 정말 복잡 할 수 있습니다. ACD 기능은 공급 업체와 매우 다른 공급 업체가 될 수 있습니다.
• 이벤트 스트림/데이터 형식. 다시 말하지만, 그들은 매우 다를 수 있습니다. 일부 스위치에서는 풍부한 이벤트 세트를 얻을 수 있습니다. 일부 환경에서는 사실상 아무 것도 볼 수 없습니다.
• 통화 추적.데이터 팝업을 위해 스위치 주변의 통화를 추적하는 것은 전화 참조 ID를 가져 와서 데이터를 키로 사용하여 데이터베이스에 데이터를 고정하는 것처럼 항상 쉬운 것은 아닙니다. 여러 스위치에서 통화가 시스템을 따라 이동하면 ref ID가 변경됩니다. 변환을 추적하고 내부 참조 ID에 대해 업데이트하려면 소프트웨어를 작성해야합니다. 아, 모든 스위치가 ref id를 지원하지는 않습니다 ...

요약하면 스위치 간 차이점을 볼 수는 없지만 동일한 프로토콜을 전환 할 수 있습니다. 서비스/구성 클래스 및 장치별로 차이점이 있습니다. 나중에는 상담원의 책상에 설정된 전화기를 기반으로 다른 행동을 볼 수 있음을 의미합니다 (CTI 데이터 팝업과 관련 있음).

이 모든 것을 숨기고 범용 솔루션이 존재 할 수없는 차이점을 주어진 단 하나의 해결책이 없습니다. 그러나 특정 사용 사례에 대한 제한된 모델을 만들 수 있습니다. 그것은 매우 쉽지 않고 정규화 레이어를 생성하기 위해 스위치에 많은 경험이 필요합니다. 그래서 지금은 문제의 더 큰 영역 (예, 다른 사람이 :-(가) 몇 가지 조언을 요약 한 것을

:

• 전화 통신 로직에서 응용 프로그램 로직을 분리 당신이 필요합니다 가정합니다. 콜 센터 당신이 활용 또는 적어도 특정을 존중합니다 예상대로 전화 통신 통합을위한 모듈에 여러 개의 플러그. 당신의 정상화 층 근처
• 않도록 스위치 특정 기능을 제공합니다. 당신은 당신이 에이전트에 배포하는 경우를 피할 수 없을 것입니다 데스크톱 ACD 구성 (통화가 보고서에 올바르게 표시되지 않으면 고객을 잃을 위험이 있음)
• 광범위한 전화 통신 프로토콜을 지원하고 풍부한 확장형 전송 기능 세트를 제공하는 기본 IVR 공급 업체를 선택하십시오.
• 표준은 ... 가난한 ... 그들은 모두 당신입니다. VoiceXML에 애플리케이션을 작성하십시오. 기본 공급 업체가 지원할 수없는 스위치 나 콜 센터에서 거래하는 경우 IVR 공급 업체를 변경할 수 있습니다.
• 다양한 CTI 프로토콜이 있습니다. TAPI, JTAPI, TSAPI, CSTA 등등. 대답이 하나도 없습니다. 좀 더 일관된 API를 제공하는 상업용 표준화 레이어가 두 개 있지만 기능 및 이벤트 스트림은 여전히 ​​스위치마다 다릅니다. 여러 인터페이스를 작성하거나 타사 API를 지불 할 계획을 세우십시오. 제 3 자 제품의 비용이 고가의 애드온이 될 수 있기 때문에 쉽게 대답 할 수는 없지만 광범위한 스위치를 구현하려는 개발 노력은 훨씬 더 많을 수 있습니다.
• 제한된 스위치 공급 업체 또는 CTI 서버 (예 : Cisco ICM, Genesys T-Server)의 파트너입니다. 그것은 시장을 제한하지만 통합 비용을 최소화합니다. 그러나 이러한 파트너십을 통해 판매를 활용하고 더 많은 고객을 확보 할 수 있습니다.

Answer 5

IVR을 개발하기 위해 웹/편안하고 API를 사용하는 것이 훨씬 쉽습니다. 이러한 API 제공 업체가 몇 가지 있습니다.

Twilio는 미국의 주위에 가장 인기있는 솔루션이며, 또한 최근 영국을 지원.

Hoiio는 홍콩과 싱가포르 등 아시아 국가 좋다. 내가 구현 특정 솔루션의 어떤 종류를 제공해야합니다하지만 그들은 모두 일반적으로 프로토콜 및 API의 한 줌을 지원하는 각 전화 시스템 때문에 -