행복만땅 개발자

하지만 이러한 환경은 아주 드물고 대부분의 통화를 하는 유저들은  Non IP 네트워크에 존재 합니다.

예를 들면 아래 <그림2> 처럼 어떤 회사에서 본 지사들 간에 VoIP 를 구축 했다고 하죠.

윗 그림에서 보면 두 사이트 간의 전화 통화는 라우터를 통한 IP 네트워크를 거치게 되어 있습니다.하지만 자세히 보시면 라우터는 PBX 와 연결이 되어 있습니다.

PBX는 IP 장비가 아닙니다. 즉 IP 프로토콜을 이해 할수 없는 장비 입니다.

따라서 PBX가 전송하는 음성이나 통화를 제어하는 시그널들은 IP 패킷이 아닙니다.

이 경우에 라우터는 게이트웨이로서의 역할을 수행해서 PBX 가 보내는 모든 시그널들을 변환하여 IP 네트워크에서 사용할수 있는 형태로 변환 해야 합니다.

또 반대로 IP 네트워크에서 콜(Call)을 처리하는 시그널링(H.323 이나 MGCP나 SIP 등등)을 PBX가 이해 할수 있는 형태로 변환해야 합니다.

또한 위의 경우에 만약 어떤 유저가 같은 회사의 소속원이 아닌(즉 VoIP 네트워크를 벗어난) 협력사로 전화를 하거나 자기 집으로 전화를 하려면 PSTN(전화 공중망)을 거쳐야 합니다.이 경우 라우터는 전화국에 있는 CO 스위치와 연결 됩니다.이 경우에도 CO 스위치는 IP 장비가 아니고 따라서 라우터는 게이트웨이의 역할 이 필요 합니다.

오늘의 결론은 이렇게 “게이트웨이는 IP 네트워크와 Non IP 네트워크 사이에서 음성 미디어나 시그널의 변환을 제공하는 장비이다” 입니다.

앞으로 게이트웨이에서 사용되는 여러가지 시그널링과 필요로하는 기능들을 다룰 것 입니다.

<그림1> 은 넷미팅 같은 보이스 어플리케이션을 사용하는 PC 간의 보이스 전송시에 보이스 패킷의 처리 과정을 보여 주고 있습니다.실제로  <그림1> 처럼 보이스 패킷이 전달되기 위해서는 이 과정에 앞서서 송수신 단말간에 사용하는 프로토콜 (H.323,MGCP,SIP,Skinny등등)에 따라  콜 셋업 과정과 콜 파라미터협의 (Negotiations) 과정이 수행되어져야 합니다.

이러한 내용은 추후에 다루어 질 겁니다.어쨌든 이러한 과정이 별 문제없이 잘 진행되었다고 가정하고 이제 실제 미디어 스트림이 전송된다고 보았을 때 보이스의 처리 과정을 보도록 하지요. 차례대로 보면은요…

(1)어플리케이션(넷미팅이나 소프트폰 등등)에서 보이스 Payload를 발생시킵니다.

여기에서는  160Byte로 되어 있죠? G.711일 경우는 디폴트 Payload 사이즈가 160 Byte 입니다. G.711 코덱은 10ms 마다 보이스의 Digitization 이 발생됩니다. (이걸 앞서 인코딩 타임이라고 했습니다.참고로 G.729도 10ms 이지요?) 즉 DSP 를 통해서 보이스 아웃풋 샘플이 10ms 마다 생기는 것 이지요. 패킷을 구성시에 이러한 아웃풋을 두개를 모아 만듭니다. 두개를 모으는 이유는  보이스 프래임 하나당 하나의 패킷을 만들면 오버헤드가 너무 커지기 때문 입니다. 그러니까 디폴트일 경우 G.711 패킷의 생성은 매 20ms 가 걸리는 것 이지요. G.711의 초당 (즉,1000ms당) 전송 트래픽이 64Kbps(8,000Byte) 이므로 10ms 마다  발생되 

는 보이스 Payload 는 80Byte이고 20ms를 모으면 160Byte가 됩니다.

(2) 어플리케이션에서 만들어진 보이스 Payload는 RTP 프로토콜을 거치게 됩니다.

RTP 프로토콜은 나중에 칼럼에서 자세하게 따로 소개해드릴 중요한 프로토콜 입니다. 일단은 RTP 라는 프로토콜은 IP 네트워크에서 보이스나 비디오와 같은 멀티미디어 트래픽을 전송하기위해 사용되는 프로토콜이라고  알아두시고요 RTP 프로토콜은 UDP 프로토콜 기반에서 동작 합니다. 또 기본 RTP 헤더는 12 바이트 입니다.

다음으로는…

트랜스포트 레이어에서 상대방 (Destination) UDP 포트 넘버가 여기에서는 5004번 으로 인켑슐레이션 됩니다. 앞서 말씀 드린 것 처럼 이앞서의 과정에서 콜 파라미터 협의(Negotiation)과정 이 있다고 했는데…이 과정에서 상대방(수신측)이 송신측 에게 보이스 트래픽을 전송할 때 사용하도록 알려준 UDP 포트 넘버입니다. 따라서 RTP 가 사용하는 UDP 포트는 항상 Dynamic 하게 결정 됩니다. 참고로 이러한 UDP 헤더는 8 바이트 입니다.

(3) 이제 네트워크 레이어 입니다. 네트워크 프로토콜이 당연히 IP 이니까…20 바이트의 IP

헤더가 인켑슐레이션 됩니다. 여기에서는  자신의 IP 는 10.0.1.2 상대방 IP는 10.0.2.3 으로 인켑슐레이션 됩니다.

(4)데이터링크 레이어 에서는 피지컬 어드레스를 인켑슐레이션 합니다.

이 시나리오 에서는 보이스 콜의 상대방 IP 가 리모트 서브넷에 존재 하므로 디폴트 게이트웨이 의 IP 인 10.0.1.1. 에 대해 ARP 를 수행하고 디폴트 게이트웨이인 10.0.1.1 의 맥어드레스로 인켑슐레이션 하게 됩니다.  여기에서 18 바이트의 이더넷 헤더가 붙게 됩니다.

(5) 디폴트 게이트웨이는 목적지 맥 주소가 자신으로 되어있는 프레임을 수신하고 프레임 헤더를 벗겨내고 IP 헤더를 확인합니다.

(6) 그리고 라우팅 테이블을 확인하여 패킷의 목적지 IP 주소인 10.0.2.3 네트워크의 아웃바운드 인터페이스와 인켑슐레이션 타입을 알아 냅니다.

(7) 패킷이 해당 인터페이스로 스위칭 되고 미디어 타입에 맞게 인켑슐레이션 되어져서 전송 됩니다.

(8)다음 홉에 있는 라우터 역시 앞서와 같이 라우팅 테이블을 참조합니다.

(9) 이경우는 자신의 이더넷 인터페이스의 서브넷이 10.0.2.0 네트워크 이므로 10.0.2.3 호스트에 대해 ARP 를 수행해서 맥주소를 알아내고 패킷을 다시 새로운 프래임 헤더로 인켑슐레이션해서 전송합니다.

(10)자… 이제 목적지 호스트는 목적지 맥 주소가 자신으로 되어 있는 이더넷 프레임을 수신하고 프레임 헤더를 벗겨내고 네트워크 레이어로 올립니다.

(11)네트워크 레이어 에서는 목적지 IP 가 자신임을 확인이 되면 UDP 헤더의 포트 넘버를 확인하고 해당 포트로 넘깁니다.

(12) 해당 UDP 포트를 사용하는 RTP 프로토콜에서 수신된 보이스 트래픽에 대한 처리를 수행합니다.( 추후에 다루겠습니다.)

(13) 수신된 보이스 Payload 는 어플리케이션에 의해 바로 재생되지 않고 일시적으로 버퍼링을 하고 버퍼가 100%가 되면은 어플리케이션에 의해 재생이 됩니다. 이때 사용되는 버퍼를 Jitter 버퍼 또는 Dejitter 버퍼 라고 합니다.

여러분들이 윈도우의 미디어 플레이어 같은 툴로 인테넷상의 멀티미디어 프레임을 수신할 때 이러한 버퍼를 이용하는 것을 보셨을 겁니다. 이렇게 버퍼링을 하는 이유는 IP 네트워크상에서 미디어 프레임의 전송 속도가 일정치를 못하기 때문에 끊김없이 규칙적인 재생을 하기 위함 입니다. 이러한 동작도 RTP 프로토콜이 관여 됩니다.

오늘 내용이 좀 길었죠? 사실 간단한 그림인데…글로 풀어 쓰면 상당히 길어 지는군요.

다음 시간에는 패킷의 오버헤더에 대해 알아 보도록 하겠습니다.제가 칼럼을 진행하면서 아직은 설명하지 않고 있는 용어들이 불가피하게 간혹 나옵니다.예를 들면 위에서 H.323,MGCP 라든지 RTP 같은 용어 등등요.이런 것들은 아직은 여러분들이 받아들이기엔 이른 것 들이기 때문에 추후에 다루어질 내용들 입니다. 따라서 아직은 제가 설명 드린 내용만 받아 들이시구 그냥 그런 거 구나 하고 넘어가시면 됩니다.^^