기술 세미나 주제는 "DTMF on VoIP"( 세미나 주제 제목이 그럴싸함 으흐흐 ^_________^)
팀내 기술 세미나라서 많은 인원이 참석하지는 못했지만.. 그래도 프로젝트 뛰면서 틈틈히 한달 정도 공부하면서 준비했던거라서 시간이 부족하지는 않았습니다.
물론 세미나가 끝나고 QnA 시간에 H.323관련 질문을 하셔서 답변은 못해드렸지만...
아는 만큼 나름 답변을 ^__________________^
아래와 같은 질문을 받았는데.. 예상치도 못한 질문이라 답변을 못드렸습니다.
VoIP에서 DTMF tone 전송 방식에 대하여 준비하였는데... ㅎㄷㄷ;;
암튼... 일단 세미나가 끝난 후에 따로 테스트를 하였습니다....
*혹시 아래 내용중에 틀린 내용이 있으면 꼭 댓글 부탁드립니다. 제가 이것 저것 검색하면서 공부한 것이라 부족하고 틀린 내용이 있을 수 있습니다. 비밀글 아니어도 상관이 없습니다. 정확한 정보 전달을 목적으로 하기 때문에, 전혀 민망해 하지 않습니다. 고수님들의 지식을 꼭 전수해주시기 바랍니다.
질문 내용은
RFC2833방식에서 digit버튼을 누르고 있는 동안에 call을 종료할 때에 어떻게 동작하는지에
대하여 테스트를 해보았습니다.
1. digit을 누르고 있는 동안에 랜선을 뽑았을 때
2. digit을 누르고 있는 동안에 Call 종료 버튼을 눌렀을 때
테스트 장비는 삼성 VoIP전화기(이거 테스트 다 거치고 출시한 제품인데 버그가 좀 있음)와 EyeBeam 소프트폰입니다.
그런데 문제는 삼성 VoIP전화기에서는 DTMF duration이 안됩니다.
버튼을 길게 누를 수 없게
되어 있습니다. DTMF는 정확하게 전송이 되나 버튼을 길게 누르고 있으면 "띠~~~~~~~"소리가 계속 나는게 아니라.
"띠~익"하고 바로 end message(Inband방식에도 불구하고)를 전송하더라고요. 이것은 제조사마다 DTMF tone 생성 방식이 틀릴 수 있다고 합니다.
DTMF duration이 제대로 작동하지 않으므로, 삼성폰->eyebeam의 경우를 테스트를
할 수 없어서 eyebeam->삼성폰 으로 테스트를 했습니다.
- 버튼을 누르고 있는 동안에 LAN선을 뽑았을 때,
당연히 END message가 전송이 안됩니다. END message는 버튼에서 손을 뗄때 전화기에서 만들어서 보내지는데, 아직
손을 떼지 않았기 때문입니다. 뭐 이것은 테스트 안해도 아시겠지만.. 정확한 것이 좋기 때문에 테스트를 해봤습니다.
- 버튼을 누르고 있는 동안에 Call End 버튼을 눌렀을 때,
버튼을 누르고 있는 동안에 DTMF tone은 계속적으로 전송이되며, call
end버튼을 누를 때 마다 end메시지는 전송이 됩니다만, 호는 계속적으로 established되어 있습니다.
이게 아마 소프트적으로 "2"번 버튼을 누르고 있다가 다른 버튼을 누르게 되면은
순간 "2"버튼에서 손을 떼었다고 생각하여 end message를 보내는 것 같습니다.
아래는 테스트하면서 알게 된 점입니다.
DTMF를 생성하는
방식은 제조사 마다 틀린 것 같습니다. (DTMF 생성 방식과 전송 방식
구분)
아래 표는 삼성폰 -> 소프트폰, 소프트폰 -> 삼성폰 으로 테스트를 한 결과
입니다.
삼성 VoIP폰 -> 소프트 폰
소프트 폰 -> 삼성
VoIP폰
Bypass
버튼을 계속 누르고 있을 수 없음.
버튼을 누르고 있어도 Local DTMF tone이 짧게 생성. 수신측에서도 짧은 DTMF
tone을 들을 수 있음.
버튼을 누르고 있는 만큼 Local DTMF tone발생. 수신측에서도 동일한 duration만큼
DTMF tone을 들을 수 있음.
RFC2833
버튼을 계속 누르고 있을 수 없음.
버튼을 누르고 있어도 end message를 바로 전송해버림. Local DTMF tone도 짧게 생성됨.
버튼을 누르고 있는 동안 DTMF tone발생, end message는 손을 뗄때
전송.
SIP INFO
버튼을 한번 누르고 나서 짧은 시간 후 DTMF tone발생(발신자와 수신자간에 DTMF tone
시간 차이가 있음)
버튼을 누르고 짧은 시간 후에 DTMF tone 발생(발신자와 수신자간에 DTMF tone
시간 차이가 있음)
결론적으로, VoIP폰이든 소프트폰이든 DTMF 전송 방식은 동일합니다.
(bypass의 경우 음성코덱으로 압축(payload type 0), RFC2833의 경우
rtpevent(payload type 101), SIP INFO의 경우 SIP INFO method이용)
하지만 DTMF 생성 방식은 제조사마다 다르게 동작하는 것 같습니다.
RFC2833의 방식은 Inband방식이기 때문에 버튼을 누르고 있는 동안 계속적으로 DTMF
tone을 수신자측에 보내주어야 하지만, 삼성 폰에서는 버튼을 누르고 있어도 바로 end message가 전송됩니다. 그러나 eyebeam의
경우는 계속적으로 DTMF tone을 전송하다가 버튼에서 손을 떼는 순간에 end message를 전송합니다.
Bypass의 경우에는 음성 코덱으로 압축하여 DTMF를 전송하고, 수신자 측에서는 동일한
음성코덱으로 디코딩하기 때문에, 디코딩 과정에서 DTMF가 오인될
가능성이 있지만, RFC2833의 경우는 DTMF를 payload type 101에
실어서 보내주고, 수신자 측에서 이 payload type 101을 찾아서 DTMF를 판별하기 때문에, DTMF가 유실될 확률(RFC2833은 UDP기반)은 있지만 잘못 판단될 수는 없다고 알고 있습니다.
A Session Border Controller (SBC) is a session-aware device that manages VoIP and MoIP calls at the borders of an IP network. Unlike most network devices session border controllers are aware of the relationship between the two parts of a VoIP call: signalling and media.
SBCs can be divided into two types of architectures:
1. The stand-alone Session Border Controller - this contains all of the intelligence and resources needed to process both the signalling and the media of the VoIP call. 2. The distributed Session Border Controller - In this case the signalling and media functions are divided between two systems that communicate with each other.
SBC의 태생(?)을 알아보자..
NAT/방화벽 Traversal(우회) 문제를 해결하기 위해 아래와 같은 몇가지 기술들이 제안됐다 그 중의 하나가 B2BUA 방식인데, B2BUA는 SIP 프록시 서버의 일종이다. 이러한 프록시 서버의 기능을 이용해 NAT 문제를 해결할 수 있다. SIP 프로토콜에서 완전한 SIP 전송을 위한 프록시로 전송하는 것이다. B2BUA는 ALG와 달리 세션 및 미디어 전송에 대한 상태 정보(statful information)를 모두 관리하며, 주소 변환, 라우팅 제어도 함께 수행한다. 완벽히 NAT 문제를 해결할 수 있으나, 성능에 많은 영향을 미치는 단점이 있고, 방화벽 기능 결합이 어려운 단점이 있다. 이런 방식으로 기능을 수행하는 상용화된 장비로는 SBC(Session Border Controller)가 있다.
B2BUA방식을 간단히 설명하면은 "B2BUA는 두 사용자 에이전트 사이에 호출을 설정하는데, 각 사용자 에이전트를 개별적으로 호출한 다음 둘을 연결하는 방법입니다."
VoIP 단말(#1)이 INVITE 메시지를 보내면 SBC가 이를 받아 SDP 내부의 사설 IP를 자신의 공인 IP로 바꾸어 소프트스위치에 포워딩한다. 수신단말(#2)은 SDP 정보안의 IP주소를 통해 미디어 패킷을 SBC에게 전송하고 SBC는 이를 다시 송신단말(#1)에게 보냄으로써 미디어 데이터의 NAT 통과를 지원한다. http://blog.naver.com/bryan0907/40019354014
Dialog Designer에서 직접 Drag&Drop을 이용하여 Variable을 생성하는 법이 아니라... 코딩을 하여서도 Variable을 생성할 수 있다.
<variable factoryID="" name="NULL" owner="" type="" value="" version="1.0"/> -> NULL이라는 Simple Variable을 만드는 법
<variable factoryID="" name="Send:LU" owner="" type="" value="00000000" version="1.0"/> -> Send라는 ComplexVariable에 LU라는 Field를 추가하여 그 값을 "00000000" 로 초기화 하는 법
위와 같은 방법을 이용하게 된다면... 대량의 Variables을 어렵지 않게 만들 수 있다.
이 글은 승열이와 후니의 쉽게 쓴 시스코 보이스 네트워킹을 읽고 필요한 부분만 정리했음을 밝힙니다.
이 글은 시스코 보이스 네트워킹을 읽고 필요한 부분만 정리했음을 밝힙니다.
VoIP 콜 컨트롤 프로토콜 중 대표적인 것들은 H.323, MGCP, SIP입니다.
VoIP 콜 컨트롤 프로토콜은 크게 '중앙형 콜 컨트롤 프로토콜'과 '분산형 콜 컨트롤 프로토콜'로 다시 나눌 수 있다. 이 중에서 분산형 콜 컨트롤 프로토콜이란 콜을 구성하고, 관리하고, 종료하는 등의 기능을 콜을 만드는 양쪽의 송/수신 시스템이 갖는 것입니다. 이러한 분산형 콜 컨트롤 중 대표적인 것은 H.323과 SIp 프로토콜입니다. H.323 프로토콜은 별도의 서버 없이 터미널과 터미널 간에 또는 게이트웨이와 게이트웨이 간에 콜을 구성할 수 있습니다. 이러한 분산형 프로토콜은 별도의 서버없이 터미널과 터미널 간에 또는 게이트 웨이와 게이트웨이간에 콜을 구성할 수 있습니다. 하지만 각각의 사이트마다 콜에 대한 제어권을 가지기 때문에 중앙에서 일관성 있게 통제 할 수 없다.
반면 중앙형 콜 컨트롤 프로토콜(Centralized call control protocol)은 콜을 구성하고 관리하는 모든 제어권을 중앙에 있는 별도의 시스템이 관리한다. 각각의 게이트웨이에서는 자신의 사이트에서 콜이 발생할 경우 이러한 이벤트에 대해 중앙에 있는 서버에 보고 합니다. 이러한 중앙형 콜 컨트롤 프로토콜 중 대표적인 것은 MGCP(Medial Gateway Control Protocol)와 시스코의 SCCP(Skinny Client Control Protocol)등입니다.
sipservlet.jar
