이전다음

4. VoIP 에 대한 기술정보

이제 우리는 VoIP 를 이해하는데 필요한 기술적인 내용을 다루게 된다.

4.1. VoIP 연결에 대한 개요

VoIP 통신을 위해 필요한 것은 :

  1. 우선 아날로그 음성을 디지털 신호 (bits 형태) 로 바꾸기 위해 ADC 가 필요하다.

  2. bits 형태의 정보는 전송에 유리한 형태로 압축되어야 한다 : 나중에 살펴보겠지만 이를 처리하는 프로토콜은 매우 많다.

  3. real-time protocol (통상 IP 에 얹은 UDP 위에 얹은 RTP 를 의미한다.) 를 통해 음성 패킷을 데이터 패킷에 담는다.

  4. 사용자를 호출하기 위해 신호 프로토콜이 필요하다 : ITU-T H323 가 있다.

  5. RX (수신측) 에서는 패킷을 해체하고 데이터를 추출한 다음, 그것을 아날로그 음성 신호로 변형한 다음 사운드카드 (또는 전화) 로 넘겨준다.

  6. 이 모든 동작은 실시간으로 이루어져야만 하는데, 그렇지 않다면 상대방의 목소리가 응답하는 데 너무 오랜 시간을 기다려야만 할 것이다. (4.6절 을 참조)

                         
                            기본구조

음성 )) ADC -   압축 알고리듬   -   TCP/IP 에 RTP 를 삽입  -------
                                                         ---->   |
                                                         <----   |
음성 (( DAC - 압축해제 알고리듬 -  TCP/IP 에서 RTP 를 추출 -------

4.2. 아날로그 신호를 디지털 신호로 변환하기

이 과정은 하드웨어를 통해 이루어지며, 통상 ADC 기능을 통합한 카드가 사용된다.

요즘의 모든 사운드카드는 16 bit, 22050 Hz 의 처리능력이 있으므로 (나이키스트 정리에 의해 샘플링에는 44100 Hz 가 필요하다.) 단위시간당 처리량은 2 bytes * 44100 (초당 샘플 수) = 88200 Bytes/s 가 되며, 스테레오 스트림에 대해서는 176.4kBytes/s 의 결과를 얻게 된다.

VoIP 에서는 22 kHz 대역폭은 필요로 하지도 않는데 (16 bit 역시 필요하지 않다) : 다음에서 그러한 코딩 방식을 보게 될 것이다.

4.3. 압축 알고리듬

이제 우리가 가진 것은 빠른 전송을 가능하게 하는 표준형태로 변형해야 할 디지털 데이터이다.

PCM, Pulse Code Modulation, Standard ITU-T G.711

ADPCM, Adaptive differential PCM, Standard ITU-T G.726

4.4. RTP 실시간 전송 프로토콜

이제 우리가 가지고 있는 것은 TCP/IP 스택에 인캡슐레이션 시킬 원형 데이터이다.

  VoIP 데이터 패킷
       RTP
       UDP
       IP
 (하부) I,II 레이어

VoIP 데이터 패킷은 RTP (Real-Time Transport Protocol) 패킷 내부에 존재하며, 한편 RTP 패킷은 UDP-IP 패킷 내부에 존재한다.

첫째, VoIP 는 TCP 를 사용하지 않고 UDP (datagram) 를 사용하는데, 이는 실시간 어플리케이션에서 TCP 가 너무 거추장스럽기 (heavy) 때문이다.

둘째, UDP 는 목적지에 도착한 패킷들의 순서를 제어하지 않고 목적지에 도착하는데 걸린 시간에 대해서도 상관하지 않는다 (datagram 개념). 이 두 특징은 전반적인 음성 품질 (다른사람이 말하는 것을 얼마나 잘 알아들을 수 있는지) 과 대화 품질 (대화를 하기가 얼마나 용이한지) 에 매우 중요하다. RTP 는 이러한 문제를 두 가지 방법으로 해결하는데 : 수신자가 받은 패킷을 올바른 순서로 정리하도록 해주며, 손실된 패킷이나 너무 오래 걸려서 도착하는 패킷을 기다리느라 너무 많은 시간을 대기하도록 하지 않도록 한다. (우리에게 필요한 것은 음성 패킷의 모든 부분이 아니라 그 순서가 제대로 갖춰진 패킷의 연속적인 흐름이다.)

                    Real Time Transport Protocol
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

위에 표시된 것은 :

RTP 프로토콜에 대한 완전한 설명과 그 용용에 대해서는 관련 RFC 1889 와 1890 를 참고하라.

4.5. RSVP

VoIP 에는 RSVP 와 같이 QoS 를 처리할 수 있는 다른 프로토콜도 사용된다.

RSVP is a signaling protocol that requests a certain amount of bandwidth and latency in every network hop that supports it. RSVP 는 그것이 지원되는 모든 네트웍 합 (hop) 에서 특정한 양의 대역폭과 레이턴시 (latency) 를 요구하는 신호 프로토콜이다.

RSVP 에 대한 자세한 정보는 RFC 2205 를 보라.

4.6. Quality of Service (QoS)

사용자는 쌍방 대화식의 음성 교환을 원하기 때문에 VoIP 어플리케이션은 실시간 데이터 스트리밍을 요구한다는 것을 수차례 이야기하였다.

불행하게도 TCP/IP 는 이러한 목적을 보장해 줄 수가 없고, 단지 "힘 닿는대로" 처리해 줄 뿐이다. 따라서 우리는 패킷이 지나가는 모든 라우터에서 패킷을 관리해 줄 수 있도록 하는 책략과 정책을 새울 필요가 있다.

어떻게 하느냐 하면 :

  1. IP 프로토콜의 TOS 필드는 서비스 종류 (type of service) 를 표시하는데 : 이 값이 높으면 별로 긴급하지 않다는 것을, 낮으면 낮을수록 점점 더 실시간의 긴급함을 나타낸다.

  2. 패킷을 큐에 집어넣을 때 :

    1. FIFO (나중에 온 패킷이 가장 먼저 서비스) 는 가장 멍청한 방법으로, 패킷이 도착한 순서대로 서비스하는 것 보다도 나쁘다.

    2. WFQ (가중치를 둔 공정한 대기열) 는 패킷의 공정한 (fair) 서비스를 위해 노력한다. (예를들어 FTP 서비스가 모든 가용 대역폭을 잠식하도록 내버려두지 않는다.) 이는 데이터 흐름의 종류를 판단하여, 통상 UDP 패킷을 하나 처리하고 TCP 패킷을 하나 처리하는 공정한 방법에 의해 이루어진다.

    3. CQ (사용자 정의 대기열) 은 사용자가 우선순위를 결정한다.

    4. PQ (우선순위를 가지는 대기열) 은 몇 개 (통상 4 개) 의 대기열로 이루어지는데 각각은 자신의 우선순위를 가지고 있다 : 패킷은 높은 우선순위의 대기열에서 우선적으로 서비스되며, 높은 우선순위의 대기열이 비면 그 아래의 대기열을 서비스하기 시작한다.

    5. CB-WFQ (단계에 기반해 가중치를 주는 공정한 대기열) 은 WFQ 와 비슷하지만, 추가적으로 64 까지의 단계와 각각에 해당하는 대역폭 값을 가지고 있다.

  3. 쉐이핑 (shaping [2] ) 을 통해 아래와 같은 두 가지 스트림에 자원을 배분할 때 각각에 대한 대역폭 제한을 두는 방법으로

    1. 수신

    2. 송신

  4. RED (Random Early Detection) 와 같이 체증을 회피하는 방법으로 [3]

QoS 에 대한 방대한 정보는 IETF 에서 Differentiated Services 를 참조하라.

4.7. H323 신호 프로토콜

예를들어 MS Netmeeting과 같은 프로그램은 VoIP 를 위해 H323 프로토콜을 사용한다.

이 프로토콜은 상호간 대화를 하도록 여러 요소를 허용하는데 :

  1. VoIP 연결을 초기화하는 클라이언트인 터미널을 제공한다. 비록 터미널들은 다른 요소가 없더라도 상호간 대화할 수 있으나, 확장성의 측면에서 몇 가지 추가적인 요소를 필요로 한다.

  2. Gatekeepers 가 제공된다. 이것의 본질적은 동작은 :

    1. IP 주소 대신에 이름 [4] 을 사용할 수 있도록 주소 변환을 수행한다.

    2. 호스트들과 사용자들에 대해 연결을 허용하고 거부하는 등의 통제를 수행한다.

    3. 대역폭을 관리한다.

  3. 게이트웨이가 제공된다. 이는 TCP/IP 와 PSTN 의 변환 기준점이다.

  4. 회의 기능을 위해 다중점 제어장치 Multipoint Control Units (MCUs) 가 제공된다.

  5. 또한 프락시 서버가 사용된다.

H323 은 VoIP 뿐만 아니라 화상통신, 데이터 통신도 지원한다.

H323 은 VoIP 에 대하여 오디오 코덱인 G.711, G.722, G.723, G.728, G.729 를 전송할 수 있고, 비디오 코덱에 대해서는 H261 과 H263 을 지원한다.

H323 에 대한 더 많은 내용은 OpenH323 Standards 와 H323 에 대한 이 사이트, 그리고 표준을 기술하고 있는 ITU H-series Recommendations 에서 찾아볼 수 있다.

실제적으로 구현된 여러 상용 어플리케이션은 Microsoft Netmeeting, Net2Phone, DialPad ... 등이 있고, 특히 프리웨어로서 개발된 어플리케이션은 OpenH323 Web Site 에서 찾을 수 있다.

주석

[1]

역주 : 전화통화품질에 대한 소비자의 주관적 평가를 평균한 수치

[2]

역주 : traffic shaping 을 이야기하는 것 같습니다.

[3]

역주 : 네트워크 상의 혼잡을 피하기 위하여 사용하는 알고리즘

[4]

역주 : 컴퓨터 이름을 의미합니다. 자세한 내용은 7.2절 을 참고.

이전처음으로다음
개관 요구사항