최근 발전하고 있는 IP기반의 네트워킹 기술덕분에 일견에는 미디어폰을 구현하기 위한 기능들이 전혀 새로운 기술이 아닌 기존 제품에서 몇 가지의 기능을 추가하면 되는 듯한 인상을 주고 있다. 하지만 실제 현실적으로 미디어폰을 구현하기 위해 필요한 기능을 구현하는 것은 직관적으로 생각하는 것보다 매우 어려울 수 있다. 예를 들어 미디어폰을 구성하는 기능을 크게 구분하면 아래와 같은 요소들이 있다.
1) 핵심 네트워크 기능을 담당하는 프로토콜
2) 핵심 네트워크 기능을 이용해서 전화기의 기능을 구현하는 소프트웨어
3) 미디어 플레이어에 미디어 데이터를 공급하는 기능
4) 실제 미디어를 해석하는 코덱을 통해 미디어를 재생하는 미디어 엔진
5) 복잡한 내부의 기능을 단순화 하여 사용자와 소통할 수 있도록 하는 UI
6) 보안 요소
7) 사용자가 원하는 요소를 수정할 수 있도록 하는 제어 세팅 기능 등
1)번부터 7)번까지를 효율적으로 관리하면서도 사용자가 쉽게 이용할 수 있도록 간결한 UI를 공급하는 면까지 미디어폰의 기능의 각 요소를 구현하는 것은 물론이고, 모두를 통합해서 하나의 제품으로 만드는 것은 결코 단순한 작업이 아니다.
이러한 배경을 충분히 이해한다면 기존 제품에 미디어폰의 기능을 추가할 때 레퍼런스 디자인(Reference Design)- 각 개별적인 구성요소들을 모두 연결해서 미디어폰의 기본적인 기능들을 수행하도록 이미 엔지니어링 작업을 마무리 한 프로토타입(Prototype)- 을 통해서 최종 양산 제품을 만드는 작업에 집중을 해서 제품의 차별성에 더욱 역량을 집중하는 것이 중요하다.
미디어폰 개요
보통 미디어폰은 VoIP 전화기 기능에 터치 스크린 기반의 큰 화면이 있는 디바이스를 말한다. 터치 기반의 화면은 웹 컨텐츠나, 오디오, 사진 혹은 비디오를 출력한다. 이런 면에서 볼 때, 미디어폰이 핸드폰과 경쟁관계처럼 보일 수 있지만, 사실은 여러 가지 면에서 보완적인 부분이 많다.
미디어폰은 PC에서 처럼 여러 가지 온라인상의 정보를 확인할 수 있도록 되어 있으며 음악, 비디오 등의 미디어를 출력할 수 있도록 되어 있지만, PC와의 가장 큰 차이점은 전화기와 같이 사용자가 이러한 기능이 필요할 때 언제든지 사용할 수 있다는 점이다. 또한 위젯을 사용하면 PC보다 훨씬 간결하면서 사용하기 쉽도록 사용자 인터페이스를 구성할 수 있다.
미디어폰은 어떤 면에서는 핸드폰보다 훨씬 폭 넓은 사용성을 제공할 수 있다. 정보를 확인하기 용이하도록 보통 핸드폰보다 크고 넓은 화면을 제공하며, 3G망보다 빠른 Wi-Fi (무선네트워크)혹은 인터넷선 연결을 통해서 온라인 미디어 정보에 접근하기 좀 더 용이하도록 되어 있다. 보통 무선 핸드셋을 통해서, 전화기와 동일한 모양의 핸드셋이나, 혹은 스피커 폰을 통해서, 좋은 통화품질을 제공하기도 한다.
보통 다른 제품과 마찬가지로 미디어폰도 사용하는 목적에 따라, 일반 소비자 가전제품 혹은 비지니스 영역을 목적으로한 제품으로 구분할 수 있다. 소비자 가전제품을 타겟 시장으로 한다면 날씨, 뉴스, Social Networks, 사진, 음악, YouTube와 같은 온라인 비디오, 영화 등을 주된 정보로 활용할 수 있으며, 비지니스 시장을 타겟 한다면 이러한 정보 기반 위에, 사내 서비스와의 확장, 사내 일정관리, 사내공지, 직원 교육용 비디오 등과 연계할 수 있도록 서비스를 확장할 수도 있을 것이다.
즉 요약하면 미디어폰은 기존 전화기의 기능을 그대로 유지하면서 자주 사용하는 인터넷 응용프로그램이나 온/오프라인 정보를 사용자가 가장 쉽게 사용할 수 있는 형태의 정보로 전달할 수 있는 기기라고 보면 될 것이다.
미디어폰 사례
이미 기존 시장에 많이 유통되고 있는 미디어 폰은 다음과 같다. 1세대의 미디어폰 제품들의 경우는 기본적인 웹 컨텐츠에 접근하고, 미디어를 출력하는 정도의 기능만 갖고 있다. 하지만 추후 출시되는 제품들의 경우는 여러가지 응용프로그램 및 통합 메시지 관리 및 유무선 연동 서비스 등 각종 서비스가 추가되는 형태로 발전할 것으로 예상한다.
미디어폰 시장
소비자 가전제품
소비자 가전제품 시장은 두 가지 경향을 보이고 있다. 이동통신사와 일정 기간 동안의 약정을 통해서 단말기의 일부에만 보조금을 지급하는 경우와 전체에 대해서 보조금을 지급하는 방식으로 구분된다. In-Stat의 "The Media Phone Has Arrived"에 의하면 2013년까지 4천 8백만 개의 미디어폰이 이통사에 의한 100% 보조금 방식으로 시장에 공급되는 반면 일부 보조금 방식에 의한 유통은 2천 3백만 개 정도에 그칠 것으로 예상하고 있다. 이러한 경향을 보면 미래엔 점점 더 많은 미디어폰이 이동 통신사에 의해서 무료로 소비자에게 공급될 것으로 시장을 예측할 수 있다.
미디어폰 시장은 북미에서 시작되어 유럽시장이 가장 크게 성장할 것으로 보이며, 아시아 태평양 시장(일본, 한국, 대만, 홍콩, 그리고 싱가폴)이 조기에 도입하는 유저가 가장 많을 것으로 예측된다.
미디어폰으로 인한 수익은(폰을 공급함으로써 발생하는 서비스 수익, 응용프로그램 판매수익, 음악, 영화 등 미디어 컨텐츠 판매수익 등 기기를 통해서 얻는 부가수익) 이동 통신사 보조금을 통한 경우 2013년까지 약 8십 억불(미화) 정도의 시장이 될 것으로 보이며, 일부 보조금의 경우엔 4십 억불 미만의 시장일 것으로 예측하고 있다.
기업시장
기업시장의 경우엔 일반 소비자 가전시장에 비해서, 조금 다른 단말이 요구될 수 있다. 물론 기본적인 기능은 크게 다르지 않다. 보통 기업 시장은 무선환경에서 사용가능하고, Wideband("HD") 코덱(codec)을 지원하고 다양한 기업용 보안 모듈을 탑재하고 엔터프라이즈 네트워크 환경을 지원할 수 있는(예를 들어 VLANs) 단말을 필요로 할 것이다.
기업시장 중 매우 빠른 성장 잠재력이 있는 니치 시장으로는 병원을 대상으로 한 시장이 있을 수 있다. 즉 병원의 편의시설을 병실 내의 큰 LCD 를 통해서 서비스를 제공하는 등의 서비스가 가능할 수 있다. 새로운 광고시장을 창출할 수도 있다. 미디어폰을 이용해서 사용자 주변의 음식점 광고를 유치할 수 있다고 상상해 보면(LBS : Location Based Service) 유저가 광고를 보다가 쉽게 몇 번의 터치 조작을 통해서 저녁식사를 예약하는 것도 먼 미래의 이야기가 아니다.
물론 이런 시장을 모두 합한 것보다 더욱 성장 잠재력이 큰 시장은 현재의 전화기 시스템을 PBX 확장을 통해서, IP 전화기로 대체하는 시장일 것이다. In-Stat 에 따르면 현재 오직 40%의 PBX시장만이 IP전화기를 활용하고 있다고 한다. 이것은 더욱 편리한 기능과 장점이 수반되지 않는다면, IP 전화기로 전환하는 일이 쉽지 않을 수도 있다는 점을 시사하고 있다.
따라서 항상 필요 시 사용할 수 있도록 Always-on 이 가능한 단말의 신뢰성, 멀티미디어와 통신 기능의 조화, 이를 모두 만족하면서 빠른 성능을 보장하는 것이야 말로 미디어폰을 기업시장에 도입하는데 필요한 핵심적인 요소라고 할 수 있다.
2013년까지 약 천만 개 이상의 기업용 미디어폰 단말이 전세계 적으로 판매될 것이다. 이로 인해 약 30억 불(미화) 가까운 연간 수익을 기대할 수 있을 것으로 생각한다.
미디어폰 구축하기
이제 실제 미디어폰을 만들기 위해 필요한 구성 요소를 살펴본다. 먼저 미디어폰의 필수 구성요소는 아래와 같다.
·하드웨어 플랫폼
·운영체제 또는 RTOS
·VoIP/미디어 프로토콜
·미디어 엔진
하드웨어
물론 미디어폰의 하드웨어 구성요소는 여느 제품과 마찬가지로 타겟 시장의 요구조건과 연관성이 매우 높다. 일반적으로 오디오만 재생하거나 VoIP만을 요구하는 경우가 비디오를 지원하는 하드웨어보다 더욱 낮은 스펙으로 구현이 가능할 것이다. 일단 비디오 기능이 지원 되야 하는 경우는 하드웨어의 CPU가 고사양이 요구되거나, 비디오 처리만 담당하는 독립적인 하드웨어를 필요로 할 수도 있다. 또한 최근의 트랜드를 지원하는 첨단의 UI를 필요로 할 경우도 고사양의 CPU나 그래픽 하드웨어의 가속기능이 필요할 것이다.
대부분 첨단 기술을 반영한 미디어폰을 만들 경우는 인텔의 아톰 프로세서나 NVIDIA의 테그라(Tegra) 프로세서를 사용하며, 중간 정도의 성능을 요할 경우는 TI의 OMAP, Freescale MX, 또는 ARM9계열의 CPU를 사용하기도 한다. 하지만 이러한 CPU를 사용할 경우라도 VoIP처리를 위해서 독립적인 하드웨어를 사용하기도 한다(VoIP의 신뢰성을 위해서) Analog Device의 Blackfin CPU의 경우 기본적인 VoIP처리를 담당하는 폰에 사용하거나 멀티 CPU의 제품 디자인에서 VoIP부분을 담당하는 목적으로 사용하기도 한다.
운영체제 또는 RTOS
흔히 사용되는 OS로는 사용자 인터페이스를 쉽게 만들 수 있으면서 시스템의 안정성을 유지할 수 있다는 점에서 Linux, Android 그리고 Windows CE의 OS등이 미디어폰의 OS로 빈번히 사용된다. 하지만 CPU의 사양이 저사양인 경우 이러한 OS들을 이용하면 UI를 처리하는 동안에 VoIP 기능을 제대로 지원하지 않을 수도 있다.
이런 경우의 해결책은 주 CPU의 OS로 RTOS(실시간 OS)를 사용하거나, 멀티 코어를 지원하는 CPU를 사용해서 각각 처리영역을 구분해 주는 등의 방법이 있다.
즉, 하나의 프로세서는 UI를 잘 지원하는 OS를 할당해서 UI를 담당하도록 하고 다른 하나의 CPU는 실시간 OS등으로 시스템의 핵심 기능 및 응답성 등을 보장하는 방법으로 문제를 해결할 수 있다. 또한 OS 이외에도 시스템에 사용되는 기기의 드라이버 및 빠른 네트워크 스택, 그리고 파일 시스템 등을 모두 갖추어야 할 것이다.
VoIP/미디어 프로토콜
여러가지 프로토콜 중 SIP, SDP, RTP, STUN/ICE는 VoIP 응용제품을 구현하는 데 있어서 반드시 필요한 핵심 프로토콜들이다. 또한 RTSP, SDP, RTP와 HTTP 와 같은 프로토콜들은 미디어를 재생하는데 반드시 필요한 프로토콜이다. 하지만 이런 코어 프로토콜들만 있다고 VoIP시스템이 완성되는 것은 아니다. 이 프로토콜들을 유기적으로 구동하는데 필요한 계층을 추가적으로 구현해야 한다.
SIP(Session Initiation Protocol)은 보이스 콜을 연결하거나 통제하는데 필요한 신호를 보낼 때 사용하는 프로토콜이다. 그리고 SDP(Session Description Protocol)는 실제 통화의 성격 및 특성과 관련된 정보를 메타데이터로 SIP 메시지 안에 포함해서 전송하는데 사용하는 프로토콜이다. 예를 들어, SDP는 어떤 미디어 데이터를 선택 할(어떤 코덱들을 지원하는지 등의 정보) 수 있는 지 등의 정보를 포함하고 있다.
SIP 프로토콜은 일반적인 성격의 프로토콜로서 텔레포니(Telephony)환경에서 사용하는데 필요한 내용만 담고 있는 것은 아니다. 미디어폰을 구현하기 위해서는 "콜매니저(call manager)"라고 하는 계층을 추가로 구현해야 한다. 콜매니저는 일반 SIP 프로토콜을 텔레포니(Telephony) 프로토콜로 사용할 때 반드시 필요한 API를 제공해 주는 역할을 한다.
예를 들어 콜매니저를 통해서 전화를 걸 때 "INVITE" 메시지를 전송해 줄 때와 전화가 잠시 통화 대기 상태에 있으면서 다른 전화를 컨퍼런스 라인 에 추가 할 때, "INVI TE"메시지를 보낼 때와는 서로 다른 파라미터를 사용해야 하는데 콜매니저는 이에 필요한 API를 제공한다.
특히 통화대기 상태의 경우, API는 Peer에게 현재 자신이 "Send Only" 모드라는 신호를 보낸다. 이때 상대방에서 아무런 메시지도 전송하지 않는 경우 Peer는 상대방이 Listen상태가 아니므로 어떤 미디어 데이터도 전송하면 안되는 상태로 해석한다. 즉, 양쪽 모두 어떤 미디어 데이터도 전송하지 않는 상태가 논리적으로는 통화대기 상태다. 하지만, 이러한 기능을 지원하는 통화대기 상태는 SIP프로토콜 자체에는 없는 기능이다.
통화 중 현재의 active call을 다른 번호로 전달하는 "call forward" 기능도 비슷한 복잡도를 갖고 있지만, 역시 SIP 프로토콜 자체엔 함수로 정의가 되어 있지 않으며 여러 명이 통화를 하는 컨퍼런스콜의 경우는 근본적으로 SIP 프로토콜의 범위를 넘어가므로 콜매니저 계층에서 별도로 구현해야 하는 기능이다.
STUN(Simple Traversal of User Datagram Protocol through Network Address Translators (NATs)) 과 ICE(Interactive Connectivity Establishment; 보통 STUN과 TURN을 사용하는 경우(Traversal Using Relay NAT)) 는 방화벽 혹은 NAT(일반적으로 Router에서 사설 IP로 교환하는 경우) 환경에서 VoIP Call을 가능하도록 하는 경우에 사용하는 프로토콜이다.
사실 일반적인 소비자들의 VoIP사용환경은 방화벽 또는 NAT 환경을 사용하고 있기 때문에 VoIP 기능을 사용자 환경에 설치할 경우 STUN혹은 ICE를 사용하지 않으면 문제가 발생할 수 있다. (기업 환경에서는 VoIP전화기가 사내의 네트워크에서 방화벽을 거치지 않은 채 클라이언트와 서버가 연결되는 경우가 대부분이다)
이러한 문제의 원인은 방화벽이나 NAT를 사용하는 라우터 바깥 쪽의 네트워크 환경에서는 VoIP폰의 IP주소를 알 수가 없기 때문에 발생한다. 즉, SIP와 SDP 프로토콜들이 전화기의 Network Identity(주소)를 찾아서 메시지 혹은 미디어 정보를 보내려고 시도할 때 전화기의 정확한 IP주소를 알아낼 수가 없기 때문에 연결에 실패하게 된다.
이때 STUN과 ICE를 사용하면 SIP과 SDP프로토콜들을 이용할 때 바깥쪽의 네트워크 에도 전화기의 IP주소를 알려줄 수 있기 때문에 방화벽 및 NAT환경에서는 반드시 필요한 요소다. STUN은 여러 가지 NAT 방법을 사용하는 라우터에도 대부분 작동하긴 하지만 대부분의 경우 ICE가 STUN이 잘 작동하지 않는 환경에서도 작동하기 때문에 좀 더 신뢰성이 있다.
RTSP(Real Time Streaming Protocol)은 SIP와 비슷하게 신호를 보내는 역할을 하는 프로토콜이다. 하지만 RTSP는 미디어 재생을 집중적으로 처리하는 프로토콜이다. RTSP는 직관적으로 보아도 알 수 있는 PLAY, PAUSE와 같은 메시지를 갖고 있다. 하지만 SEEK, FAST FORWARD, REVERSE 등과 같은 메시지는 명확히 정의가 되어 있지 않기 때문에, 별도의 코드를 만들어야 할 수도 있다.
"TRICK PLAY"란 기법이 있는데, 이 기업을 사용하면 상기 기능들에 대해서 보완이 가능하다. 하지만 불행히도 이 기법이 모든 미디어 타입에 대해서 기능을 보완해 주는 것은 아니다(예를 들면, 어떤 코덱은 SEEK(찾기) 기능을 근본적으로 지원하지 않을 수도 있다). RTSP또한 SIP와 같은 목적으로 SDP를 사용하기도 한다(SDP는 지원 가능한 코덱 LIST를 메타데이터로 갖고 있다).
HTTP(Hypertext Transfer Protocol) 는 때때로 미디어를 스트리밍 하는데 사용하기도 한다. HTTP는 방화벽 등을 통과하는데 있어 비교적 다른 프로토콜에 비해서 단순한 방법을 지원할 수 있기 때문이다. 하지만 이 경우는 미디어의 시작과 끝나는 부분에 관한 매우 제한적인 범위의 제어만 가능하다. 일반적으로 HTTP는 하나의 데이터 채널에 대해서만 사용이 가능하지만, 미디어 파일을 읽고 출력하는 방법으로 오디오와 비디오를 동시에 스트리밍 할 수 있다.
또한 다른 프로토콜들도 HTTP 레이어 위에서 동작하도록 함으로써 부가적인 기능을 구현할 수 있다. 예를 들면, ICY(I Can Yell, SHOUTcast Software의 프로토콜 이름) 를 HTTP위에 사용함으로써 라디오 방송을 스트리밍 할 수도 있다. 이 경우엔 ICY 프로토콜이 오디오 스트림 안에서 현재 재생 되고 있는 음악의 이름과 아티스트 이름 등의 메타데이터를 전달하는 역할을 한다.
또한 비슷한 방법으로 HTTP는 다른 프로토콜들이 방화벽을 쉽게 통과할 수 있도록 하는 터널 역할을 해주기도 한다. 이런 방법으로 가장 흔하게 이용되는 프로토콜은 RTSP 등이다.
마지막으로 RTP(Real Time Protocol)은 VoIP의 경우와 RTSP의 경우에 전달되는 미디어의 컨텐츠를 전달하는 역할을 담당하는 프로토콜이다. VoIP의 경우엔 일반적으로 하나의 스트림 데이터가 있는 경우가 대부분이지만 RTT(Real-Time Text)의 경우나 비디오 컨퍼런스의 경우는 보통 여러 개의 스트림 데이터들이 하나의 세션에 전달되기도 한다. 보통 RTSP의 경우는 비디오와 오디오가 전송되기 때문에 2개의 스트림을 활용하는 경우가 일반적이다.
보통 다수의 RTP스트림의 싱크를 맞추는 일은 매우 복잡하다. 때문에 복수개의 RTP스트림들의 싱크를 돕기 위해서 RTCP(RTP Control Protocol)이 사용된다. RTCP는 모든 미디어 스트림에게 타임스탬프(Timestamp) 정보를 공급하면서, 동시에 QoS(Quality of Service) Feedback 정보를 공급해 준다. 만일 품질이 떨어지는 경우엔(즉, 많은 패킷들이 네트워크상에서 손실되거나, 혹은 다수의 패킷이 처리하는 과정에서 느린 프로세서에 의해서 손실될 경우), 서버에 요청해서 코덱을 교체하거나 비디오의 경우에 해상도 혹은 비트 레이트(Bit Rate)를 낮추어 전송을 시도하는 등의 제어를 할 수 있다.
상기 언급된 프로토콜들은 대부분 네트워크상으로 전송되는 프로토콜들이지만, 컨텐츠 스트링안에 TRP를 통해서 내장될 수 있는 프로토콜들도 있다. (ICY과 같은 프로토콜이 대표적임) 예를 들어 H.264 컨텐츠는 흔히 RFC3984, "H.264 비디오 컨텐츠를 위한 RTP Payload format"에 정의되어 있는 대로 컨텐츠가 인코딩 되어 있다. 그리고 AAC 오디오는 AD TS(Audio Data Transport Stream)에 패키지 되어 있는 경우가 대부분이다. ADTS는 여러 개의 프레임들로 구성되어 있으며 각각의 프레임에는 AAC오디오 데이터로 되어 있는 헤더파일을 포함하고 있다.
미디어 엔진
미디어 엔진은 스트리밍 데이터들을 받아 미디어 혹은 오디오 컨텐츠를 처리하는 일을 담당한다. 따라서 미디어 엔진은 IP 네트워크와 인터페이스를 해야 하며, 미디어 코덱들을 불러서 처리해야 하고 시스템에서 사용하는 적당한 포맷으로 컨텐츠를 가져와야 하며, 오디오와 비디오의 품질을 높이기 위한 추가적인 기능을 수행하는 알고리즘을 포함하고 있다.
IP 네트워크와 인터페이스하는 부분은 기존 PSTN 환경에서는 없었던 새로운 문제를 유발한다. 대표적인 문제로는 네트워크상의 지연(패킷이 한쪽에서 다른 목적지로 전송 하는데는 시간이 소요됨), Jitter(항상 일정하지 않은 지연문제), 그리고 패킷이 손실되는(어떤 패킷들은 네트워크상에서 손실되어 다른 목적지로 도착하지 못할 수도 있다) 문제 등이 있을 수 있다. 네트워크상의 지연이 하드웨어적인 문제라면 하드웨어의 개선 이외엔 할 수 있는 일이 없지만, 미디어 엔진이 잘 설계되어 컨텐츠를 처리하는데 필요이상 지연되지 않도록 설계를 하는 것이 매우 중요하다.
Jitter는 Jitter 버퍼를 이용해서 처리할 수 있다. 즉, Jitter 버퍼는 네트워크상의 패킷들이 큐에 도착하도록 해서 큐에 도착한 이후에만 처리는 하는 방법을 의미한다. 이렇게 큐를 이용하면 오디오 및 비디오 컨텐츠를 항상 일정한 간격으로 처리해서 사용자에게 연속적으로 데이터를 보낼 수 있다. Jitter 버퍼는 충분한 패킷을 큐에 쌓이도록 설계해야만 한다. 하지만 패킷을 큐에 쌓는 것 또한 또다른 지연을 야기하므로 충분히 성능을 낼 수 있도록 하는 면과 미디어의 품질을 개선하는 것은 항상 상충관계가 발생할 수 있다.
적응형 Jitter 버퍼는 네트워크의 상태에 따라 패킷이 큐에 저장되는 것을 조절하는 기능이다. 예를 들면 음성 데이터를 버퍼링 하는 경우엔 몇 밀리 초의 음성 데이터를 바탕으로 통화를 하는 것이 더욱 자연스러울 수 있다. 왜냐하면, 서로 다른 코덱들이 패킷별로 서로 다른 구간만큼 인코딩을 하기 때문이다.
따라서 기업 환경에서는 사내 네트워크를 이용하기 때문에 Jitter가 큰 문제가 되지 않을 수 있다. 따라서 이 경우는 Jitter가 40-60ms의 음성 데이터만 필요로 한다. 하지만 일반 공용망(Internet)을 통하는 경우엔 Jitter 버퍼가 150ms 정도의 음성데이터를 큐에 저장해야 하는 경우도 발생할 수 있다. 또는 바다를 건너는 인터넷 망을 사용하는 경우는 크게는 500ms의 음성데이터를 Jitter큐에 저장해야 하는 경우도 있다.
미디어 코덱(a COder-DECoder, or COmpression-DECompression)을 호출하는 과정은 인코딩 된 데이터를 받아서 디코딩 하는 부분의 코덱에 데이터를 넘겨주고, 아직 인코딩이 되지 않은 데이터를 받아서 코더 부분에 데이터를 넘겨주는 역할을 의미한다. VoIP(혹은 비디오 컨퍼런스콜)의 경우는 양쪽의(즉 인코딩, 디코딩) 과정이 모두 사용되며 엔터테인먼트 미디어 (MP3 데이터나, 비디오 데이터들)의 경우는 보통 디코딩하는 과정만 필요하다. 보통 미디어폰에서는 다양한 코덱들을 사용한다.
VoIP의 경우엔 협대역(narrowband) 코덱들(기존의 PSTN망과 비슷한 코덱들)이나 광대역(wideband 혹은 HD코덱들, Narrowband의 경우에 비해서 두배 혹은 더 큰 배수의 대역의 오디오 샘플 레이트(Sample Rate)를 지원함, 따라서 매우 자연스러운 음성을 지원함) 코덱들을 사용한다. 코덱의 성능에 대한 평가는 보통 네트워크의 대역(얼마나 음성이 압축되어 있는지)에 대한 평가와 압축하고 다시 압축을 풀었을 때 음성의 품질에 대한 평가(보통 MOS (Mean Opinion Score)를 통한 평가)를 통해서 이루어진다.
또한 코덱들은 추가적인 음질개선에 대한 기능을 지원하기도 한다. 예를 들면, 패킷이 손실되어 있는 상황에서도 얼마나 음성 품질을 유지할 수 있는지(예를 들어, "Packet Loss Concealment"(즉, 패킷 손실에 대한 은폐)), 그러나 전자와 후자의 평가기준은 매우 상이하므로 이러한 특징들을 개별적으로 잘 평가한 후 코덱을 선정해야 할 것이다.
일반적으로 웹 기반 미디어의 경우에 현재 가장 많이 사용하는 코덱은 비디오에 H.264(또는 MPEG-4 AVC혹은 MPEG-4 Part 10) 혹은 VC-1 등의 코덱이 활용되고 있으며, 오디오 쪽은 MP3혹은 AAC(Advanced Audio Coding, 몇 가지 다른 버전이 있음)이 가장 일반적으로 사용되고 있는 코덱이다.
이 두 가지 비디오 코덱은 산업 전반에 걸쳐 많은 지원을 받고 있는데, 다수의 칩셋들이 H.264/VC-1을 하드웨어적으로 지원하는 기능을 포함하고 있다. 특히 비디오 해상도나 데이터 전송률이 큰 경우는 이런 하드웨어적인 지원이 큰 도움이 된다.
비디오 데이터가 디코딩 되고 나서도 화면에 그대로 표시될 준비가 끝난 것은 아니다. 이런 디코딩된 비디오 데이터는 컬러 영역에 쓰여질 수 있도록 변환과정이 한 번 더 필요하다. 보통 압축이 풀린 비디오 데이터는 YUV포맷인 경우가 많다. 이 경우는 반드시 RGB(Red-Green-Blue)포맷으로 변경이 되어야만 화면 혹은 LCD 영역에 표시할 수 있다. 이러한 변환 작업은 여러 가지 수학 함수를 사용하여 이루어 지며, 이 작업은 각 프레임 별로 이루어 져야 한다(예를 들어, 1초에 30회씩), 이런 계산과정은 하드웨어적인 가속이 지원되지 않는다면, 디코딩 작업만으로 CPU성능의 대부분을 소모할 수도 있다.
마지막으로 CPU에 큰 영향을 주는 비디오의 구성요소는 스케일링(scaling, 사이즈 조정)과 관련된 부분이다. 전체화면으로 변경하는 경우, 표시할 비디오가 화면의 사이즈나 해상도와 맞지 않아 스케일을 조정해야 하는 경우가 빈번히 발생할 수 있다. 이 경우도 수학 함수를 많이 사용하므로 역시 하드웨어적인 가속이 없다면 CPU를 크게 점유할 수 있다.
컨텐츠가 화면과 스피커를 통해서 출력될 준비가 모두 끝나더라도 추가적으로 품질을 향상시키거나 여러 가지 미디어 제어를 위해서 추가적으로 처리를 하는 루틴이 필요할 수도 있다. 특히 VoIP영역에서는 주파수 영역을 조정하는 과정이 주변 잡음을 소거해서 음질을 향샹 하는데 큰 도움을 줄 수 있다. 만일 스피커폰 기능을 사용한다고 하면 에코를 제거하는 부분이 전이중(Full Duplex) 오디오 통신을 하는데 품질을 크게 개선하는 키가 될 수 있다.
VAD(Voice Activity Detection)은 패킷을 전송할지 말아야 할 지를 가늠하는 매우 중요한 역할을 한다. 즉, 아무도 말을 하고 있지 않을 때 패킷을 전송할 이유가 없는 것이다. 반대의 경우, 패킷이 전송되지 않을 땐 아무런 소리가 나지 않는 것 보다 평소의 주변 잡음의 정도만큼 적당한 레벨의 소음을 출력해서(Comfort Noise) 사용자에게 편안한 느낌을 전달하는 것 또한 매우 중요하다(통화 중 갑자기 진공상태로 묵음이 된다면 사용자가 매우 불편을 느낄 수 있다). 즉, Comfort Noise는 항상 배경 소음 정도를 감지해서, 대화가 이어지지 않더라도 주변 소음과 비슷한 소리를 출력할 수 있도록 하는 역할을 담당한다.
오디오/비디오의 경우 모두 주파수 영역의 EQ(Equaliz ation)은 품질을 향상 하는데 매우 유용하게 사용할 수 있다. 즉 노이즈 제거, 대비 향상(Contrast Enhancement), Qua lity deinterlacing및 deblocking 등은 이러한 주파수 영역 EQ의 몇 가지 예시라 할 수 있다.
6월호에는 VoIP의 구성 요소 중 아래의 내용에 대해서 계속된다.
·Internet protocols
·Security protocols
·GUI with support for widgets
·The overall Application
[About Unicoi Systems]
Unicoi Systems(유니코이 시스템즈)는 임베디드 기기에 필요한 실시간 오디오 비디오, 그리고 데이터 처리와 관련된 소프트웨어를 선도하고 있는 Global 기업이다. 2000년도 Georgia주 Atlanta 를 기반으로 시작해서 현재 전세계 300개 이상의 주요 기업들이 제품 개발시 Unicoi의 Fusion Software에 의존을 하고 있다.
Unicoi 사의 소프트폰(SoftPhone) 솔루션
Unicoi사의 Fusion SoftPhone Reference Design은 VoIP 응응프로그램을 제작할 경우 필요한 모든 솔루션을 제공한다. 강력한 Fusion Call Manager(FCM)는 SIP,SDP 등 내부의 복잡한 프로토콜을 관리하면서 외부로는 단순한 개발자 API를 제공하고 있다. 때문에 개발시 FCM을 이용해서 GUI 와, VoIP 내부의 기능들을 쉽게 연결할 수 있다. 또한 Unicoi SoftPhone RD는 플랫폼(Platform) 독립적이기 때문에 어떤 OS에서도 쉽게 구동할 수 있도록 되어 있다. Win32기반의 Winows CE/Windows Mobile/Linux/Android/ MacOS등 각종 OS기반의 포팅 예제가 있기 때문에 Fusion SoftPhone RD를 활용한다면, 사용자 인터페이스 부분에 역량을 집중해서 제품을 쉽게 완성할 수 있다.
>>> 저자 및 본 Article에 대한 소개
Jason Robertson
Unicoi Systems의 기술을 총괄하는 부사장이며, Web Browser, VoIP, Networking protocols, XML등과 같은 제품의 설계 및 개발을 총괄하고 있다. Unicoi이전에는 Veriprise Wireless, Inc사의 수석 시스템 설계 총괄을 역임하고, Motorola에서 수석 소프트웨어 개발 담당을 역임했다. "IP 미디어폰과 레퍼런스 디자인-Reference Designs and IP Media Phones" 란 제목의 본 기고는 , 2010년 Silicon Valley에서 열리는 Embedded System Conference 에서 발표하는 주제로, Jason 부사장은 이곳에 연설하는 연사로 초대되었다.
>>> 번역자 소개
Allan Kim
Allan은 Unicoi Systems 에서 한국 시장 개발을 담당하고 있으며, 현재는 한국 지사 설립 작업을 진행하고 있다.
성원호/ 디오이즈 대표
디오이즈(www.dioiz.com)는 Unicoi의 한국 총판이며, 국내에서의 1차 기술지원을 담당하고 있다.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음