olive 발신의 기본 컨셉.
발신을 하기 위해서는 3가지 자원(AGENT, PLAN, Dial List)가 필요하다.
이 3 가지 자원을 하나의 단위로 묶은 것이 바로 Campaign.
3 가지 자원이 모두 가용할 때, 발신이 시작된다.(실제로는 Trunk 자원 및 기타 자원이 필요하지만 논외로 한다.)
이제 겨우 슬슬 전체적인 그림이 잡혀가는 것 같다.
머릿속으로만 구상했던 개발 컨셉과 동작 방식들을 직접 구현해가면서 나타나는 컨셉 오류들과 함수명 짓는것이 제일 힘들었다.
아무튼.. 늦었지만 대략적인 olive-0.0.1 버전을 위한 단계별 목표를 세워보았다.
Stage1 : 고객 Dialing, 대기 상담원 연결, 결과 처리
– 가장 기본적인 Predictive 방식만을 적용한다. 현재 캠페인에 할당되어 있는 대기중인 상담원만을 기준으로 발신을 시도하고 연결한다.
Stage2 : API
– RESTful API 를 구현한다.
– 캠페인의 생성/변경/삭제, 상담원 생성/변경/삭제, 전략 생성/변경/삭제 까지를 목표로 한다.
Stage3 : Packaging and documentation.
– olive 설치와 사용을 위한 Makefile, 문서화를 한다.
– olive 발신의 컨셉에 대한 충분한 설명을 목표로 한다.
드디어, 어제 저녁 첫콜을 통과시켰다. 예쓰!!!!!!!!!!!!!!!! 🙂
이제 결과 데이터 정리 후, 하나씩 진행하면 되겠다. 🙂
계속 transfer 단계에서 진행이 안되고 있다.
문제는 Redirect 이후, 결과를 작성할 때, 상담원 transfer 결과를 도출하기가 까다롭다는 것.
상담원이 응대를 했는지 안했는지에 대한 결과를 어떻게 알아내야 할지.. 흐음…
쉬운 것 같은데.. 은근히 까다로운 면이 있다.
오늘 다시 현상을 분석했다.
결과는 다음과 같았다.
Asterisk-1.8, channel redirect – OK
Asterisk-13.2, channel redirect – NO
즉, 1.8 버전에서는 되는데, 13.2 버전에서는 안되는 것이었다.
SVN 에서 최신의 소스를 받아서 무슨일이 있었는지 비교해 보았다.
엄청난 차이가 있었다.
한가지 의심스러운 부분이 있었는데…
if (chan2->pbx) {
ast_set_flag(chan2, AST_FLAG_BRIDGE_HANGUP_DONT); /* don’t let the after-bridge code run the h-exten */
}
최신의 소스에서는 위의 부분이 삭제되어 있었던 것. 옵션만봐서는 Bridge 후에 채널을 끊지 않도록 하는 라인 같았다.
해당 부분과 옵션에 대한 Define 만 넣고 다시 컴파일을 한 후 테스트를 해보았으나, 실패. 단순한 소스 수정이 아닌것 같았다.
변경 이력은 다음과 같았다.
Merge in the bridge_construction branch to make the system use the Bridging API.
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
아마도 각각 사용하던 Bridge 설정을 모듈 설정을 따라가도록 수정한 것 같았다.
직장 동료들에게 물어보니 1.8 과 13.2 버전에는 엄청난 차이가 있어서 1.8에서 동작한다고 해서 13.2에서 도동작한다는 보장이 없다는 것이었다.
이 문제를 어떻게 풀어야 할지 좀 걱정이 된다.