이제 겨우 슬슬 전체적인 그림이 잡혀가는 것 같다.
머릿속으로만 구상했던 개발 컨셉과 동작 방식들을 직접 구현해가면서 나타나는 컨셉 오류들과 함수명 짓는것이 제일 힘들었다.
아무튼.. 늦었지만 대략적인 olive-0.0.1 버전을 위한 단계별 목표를 세워보았다.
Stage1 : 고객 Dialing, 대기 상담원 연결, 결과 처리
– 가장 기본적인 Predictive 방식만을 적용한다. 현재 캠페인에 할당되어 있는 대기중인 상담원만을 기준으로 발신을 시도하고 연결한다.
Stage2 : API
– RESTful API 를 구현한다.
– 캠페인의 생성/변경/삭제, 상담원 생성/변경/삭제, 전략 생성/변경/삭제 까지를 목표로 한다.
Stage3 : Packaging and documentation.
– olive 설치와 사용을 위한 Makefile, 문서화를 한다.
– olive 발신의 컨셉에 대한 충분한 설명을 목표로 한다.
계속 transfer 단계에서 진행이 안되고 있다.
문제는 Redirect 이후, 결과를 작성할 때, 상담원 transfer 결과를 도출하기가 까다롭다는 것.
상담원이 응대를 했는지 안했는지에 대한 결과를 어떻게 알아내야 할지.. 흐음…
쉬운 것 같은데.. 은근히 까다로운 면이 있다.
채널 redirect 이 안되는 문제가 발생했다.
문제 없이 당연히 되리라고 생각했는데, 생각만큼 되지는 않는 것 같다.
무엇이 문제일까?
IRC에 물어봐도 딱히 답을 얻지는 못했다.
느낌상 고생좀 할 것 같다.
일주일 전, 한가지 풀리지 않는 문제가 있었다.
바로 Call transfer 에 관한 문제였다.
일단 parking 된 channel 을 Transfer 하고 싶은데, AMI 명령어 만으로는 해결이 안되는 것이었다.
물론 AMI 명령어로 Transfer 와 관련된 명령이 있긴했다.
blindtransfer
redirect
하지만 내가 원하는 것은 아니었다. 왜냐하면 위의 명령어들은 peer 로 transfer 를 하는 것이 아닌, context 의 extension 으로 transfer 를 하는 것이기 때문이다.
한참동안 고민을 하다가 Asterisk IRC 채널에 물어보고 답변을 들었다.
“Asterisk 는 그렇게 동작을 안해. 왜냐하면 그렇게 디자인 된 것이 아니거든. Transfer 를 하고자 한다면, 어느 순간에는 Dialplan 을 써야할 때가 올꺼야.”
그랬었다. 애초에 불가능한 것이었다.
그랬는데.. 그새 깜박했다.
왜냐하면.. 오늘 또 똑같은 질문을 했기 때문이다.
I thought it was clear a week ago when you asked the same thing and got the same answer’
하아.. 부끄러운 질문이었다.. ^^;;;;
바쁜 주말이었다.
Make call 관련 버그때문에 너무 신경이 쓰이는 주말이었다.
다음에 같은 실수를 하지 않을까 싶은 마음에 버그 내용을 정리한다.
버그 현상은 다음과 같았다.
1. Originate
2. Create new channel
3. Dial begin
4. Hangup – Almost immediate call hangup after dial begin
원래 의도했던 상황은 다음과 같았다.
1. Originate
2. Create new channel
3. Dial begin
4. Dial End – Wait until destination pick up the phone or 30 seconds.5. Parked call
6. Hangup
자꾸만 Dial begin 직후 콜이 끊어지는 것이었다. Asterisk cli 에서 명령어로 거의 같은 옵션으로 originate 를 했을 때는 예상했던 시나리오 대로 흘러갔다.
이상했다… 문제가 될 부분은 없어보였는데, 콜이 너무 빨리 종료되는 것이 이상했다.
무엇이 문제일까?
테스트 환경은 다음과 같았다.
테스트 전화번호는 IBK VIP 고객 센터 전화번호였다.
100% 응대를 하는 곳이었다.트렁크 관련 설정 역시 문제가 될 부분은 없었다.
다른 VoIP Client 프로그램으로 테스트시 정상이었다.
즉, 테스트 환경으로 인한 문제는 아니었다.
콜이 끊어지는 현상은 크게 두 가지로 분석할 수 있었다.
발신자 쪽에서 끊던가, 수신자 쪽에서 끊던가.
Hangup event 발생시, Hangup 사유가 같이 따라온다.
처음에는 그 부분을 눈여겨 보지 않았다.
단지 문제 해결에만 급급해서 로그분석을 게을리 했기 때문이다.
Hangup 사유는 3번 Remote end is ringing 이었다.
AST_CONTROL_RINGING = 3, /*!< Remote end is ringing */
이게 무슨 말이냐면.. 상대쪽 전화기에 벨이 울리고 있는데, 우리쪽에서 전화를 끊은 것이다.
이제,상대쪽 전화기의 문제는 아니라는 점이 명백해졌다.
그렇다면 문제는 단 하나, 프로그램상에서 originate 를 할때 전달되는 옵션에 문제가 있는 것이다.
왜냐하면 cli 에서는 문제가 없기 때문이다.
프로그램에서 originate 를 할 때 옵션을 넣는 부분들을 하나씩 하나씩 주석 처리하고 다시 테스트를 했다.
그리고 문제를 찾았다.
문제는 Originate 시, 설정하는 timeout 에 있었다.
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerAction_Originate
에 originate 명령에 대한 설명이 나와있다.
본디, originate 시, 30초의 timeout 을 주려고 생각했었다.
그런데, 문제는 단위가 ms(밀리초) 단위였던 것.
그런데 거기까지 생각을 못하고 그냥 30 을 입력해 버린 것이었다.
그렇게 되니, 단지 30 ms 까지만 대기하고 timeout으로 콜을 끊어버린 것이 문제였다.
설정값 30 을 30000 으로 수정 후, 문제가 해결되었다.
고생은 했지만, 이래저래 얻은 것이 많은 버그였다. 🙂