Search
Duplicate

컴퓨터 네트워크/ VoIP

VoIP 개요

VoIP란 인터넷 및 네트워크의 표준 프로토콜로 사용되는 IP(Internet Protocol)을 사용하여 개별적인 네트워크로 구성되어 있던 음성과 데이터를 하나의 통신 네트워크로 통합하여 전송하는 방식을 일컫는다.
VoIP(Voice over Internet Protocol)는 1995년 2월 VocalTec Communication Inc라는 이스라엘 회사가 사운드카드, 스피커, 마이크로폰 그리고 모뎀이 장착된 PC에서 동작하도록 설계한 소프트웨어를 소개하면서 처음 구현되었다. 인터넷을 통해 사용자가 공중망으로 음성 패킷을 전송하기 위해 PC를 사용한 것이 VoIP의 유래가 된 것이다.
소프트웨어는 음성신호를 압축하고, IP 패킷으로 변환하여 인터넷을 통해 전송하기 위해 아날로그의 음성 신호를 디지털 형식으로 변환하는 일련의 과정을 수행한다.
초기 VoIP는 소프트웨어로 구현되었으나, 빠른 속도의 기술 발전으로 현재는 인터넷과 PSTN(Public Switched Telephone Network)을 연결해주기 위해 게이트웨이 서버를 이용하여 표준 전화기로 VoIP를 이용할 수 있게끔 발전되었다.

VoIP 구성

VoIP 기본 구조

그림 9-1은 기본적인 VoIP 서비스 구성도를 보여주고 있다.
전화기를 사용하는 수화자에 의해 발생한 음성 신호는 PSTN을 경유하며, 기존의 전화망과 같은 SCN(Switched Circuit Network)과 IP 네트워크 사이에서 VoIP 연동 서비스를 제공하는 장비인 게이트웨이를 통해 인터넷으로 전송되게 된다.
따라서 통신비용이 절약되고 데이터 네트워크와 음성통신 네트워크의 중복 투자를 피할 수 있게 되어 일반적으로 VoIP를 사용할 경우 통신비용은 일반회선을 사용하는 것에 비해 70-80% 정도의 절감효과를 누릴 수 있게 된다.
VoIP 게이트웨이는 전화망에서 사용하는 데이터 형식인 PCM(Pulse Code Modulation)과 인터넷에서 패킷 전달 규약인 IP를 해석하여 상호 연동 서비스를 제공한다. 즉 회선 교환망(전화, PSTN)과 패킷 교환망(컴퓨터, IP 네트워크)을 연결시키는 브리지 역할을 수행한다.
VoIP 게이트웨이는 그림 9-1과 같이 PSTN 상의 전화가 컴퓨터 혹은 또 다른 전화 시스템과 호환성을 가지고 IP 상에서 동작할 수 있도록 해주는 기능을 수행한다.
이는 회선 교환망의 교환기에서 온 신호와 데이터를 받아서 라우터가 이해할 수 있는 형태로 변환하는 과정을 말한다.
이 과정에서 신호전달에 관한 규약에 따라 신호를 받아들여 해석하여 인터넷을 통한 상대편 라우터의 게이트웨이로 전달되고, 상대편의 게이트웨이는 이와 반대되는 과정을 수행한다.
또한 VoIP 게이트웨이는 앞서 설명한 것과 같은 기본기능 이외에 교환기에서 전달되는 음성 신호를 인터넷으로 보내기 전에 특정 알고리즘에 의해 압축하는 기능을 제공하기도 한다.

VoIP 서비스 형태

PC to PC
PC to Phone
Phone to Phone

VoIP에서의 QoS

IP 네트워크에서 음성의 통화 품질에 영향을 주는 중요한 파라미터로는 지연(Delay), 지터(Jitter), 패킷손실(Packet Lost) 등이 있으며, 이들 파라미터에 많은 영향을 미치는 요소로는 무음 억제(Silence Suppression), 에코(Echo) 등이 있다.

지연(Delay)

지연은 신호가 네트워크를 경우하는데 소요되는 시간이다. 즉 송화자의 입에서 생성된 신호가 수화자의 귀까지 도착하는데 필요한 시간이다. 종단간 지연은 모든 네트워크 장치와 스트림 매개체에 의해 발생하는 지연의 총합이다.
VoIP 네트워크에서 종단간 지연은 음성 데이터가 지나가는 경로에 따라 PSTN에서의 전송 지연과 패킷 지연 그리고 VoIP 장비 지연으로 나뉠 수 있다.
PSTN에서는 전송 지연에 의해 주로 결정되며, 네트워크 교환 장비를 통한 지연은 아주 적다.
패킷 지연은 주로 버퍼링, 큐잉, 교환 또는 IP 라우터의 라우팅 지연을 의미한다.
VoIP 장비 지연은 전송로의 송신부와 수신부에서 음성 신호 처리 때문에 발생한 지연을 말한다.
VoIP 게이트웨이나 VoIP 터미널의 지연은 아날로그 신호를 디지털 신호로 인코딩하는데 걸리는 지연과 디지털 음성 신호를 아날로그로 변조하는데 코덱 지연 시간을 포함한다. 또한 코덱 종류에 따라 음성 신호를 압축하는데 추가적인 지연이 발생하기도 한다.

지터(Jitter)

지터란 지연 시간이 일정하지 못하고 시간에 따라 변동되는 것으로서, 음성 패킷들이 도착하는데 있어서의 규칙성을 나타낸다.
즉 네트워크 내의 지연 떄문에 패킷의 도착 간격 시간이 불규칙한 현상을 나타내는데, 예컨대 IP 네트워크에서 패킷 지연이 점점 증가할 경우 지터 또한 점점 커진다고 할 수 있다. 따라서 실시간 멀티미디어 전송 시에는 패킷 지연을 일정하게 하여 지터를 줄이는 방법을 필요로 한다.
네트워크에서 발생하는 패킷 간 지연은 갓 패킷마다 다르고, 수신 압축해제 알고리즘이 도착하는 패킷들 사이에 간격이 일정하기를 요구하기 때문에 이를 위한 해결책으로 게이트웨이와 같은 수신 장치에 지터 버퍼를 사용하기로 한다.

패킷 손실(Packet Lost)

음질의 명확성에 영향을 주는 요소로 패킷 손실이 있다. VoIP와 같이 실시간 응용에서는 미디어 전송시 UDP(User Datagram Protocol)를 사용하므로 재전송이 이루어지지 않고, 일정 시간 내에 도착하지 않은 패킷은 수신부에 의해 폐기된다.
재전송은 패킷의 재구성을 위해 추가적인 시간이 필요하므로, 실시간 통신에서는 사용하기 어렵다.
VoIP 네트워크에서는 이러한 패킷 손실이 연속적으로 빈번하게 발생하는 경우 통화 품질에 영향을 줄 수 있는데, 이를 막기 위해 패킷 손실 은폐방법(PLC; Packet Loss Concealment)을 사용하기도 한다.
이 방법은 패킷 손실 시에 이전에 받은 패킷을 다시 재생하여 수신자가 패킷 손실을 ㅇ라아채지 못하게 하는 방법이다.

무음 억제(Silence Suppression)

패킷의 수를 줄이기 위해 대화 중에 무음이 지속되는 기간을 활용한다. 보통 상호간 대화에서 각 화자는 전형적으로 약 반 정도의 시간은 듣기만 한다. 그러므로 화자가 듣는 시간 동안은 패킷을 전송할 필요가 없다.
이를 위해 VAD(Voice Activity Detector) 같은 무음 처리 기능을 사용하는데, VAD는 통화자가 말을 할 때만 음성 패킷을 전송한다. 이는 VoIP 게이트웨이나 터미널의 한 기능으로, 대화 중에 무음 기간 동안 음성 패킷을 삭제하는 기능이다.
VAD를 사용하면 40-50% 정도의 대역폭 요구를 줄일 수 있다.

에코(Echo)

에코는 송신자의 음성이 수신자측을 거쳐서 다시 송신자에게 들리는 현상을 말한다. 전형적으로 16-20ms의 지연을 가진 에코는 일반적이고 문제가 되지 않으나, 에코지연이 약 32ms를 초과하는 경우에는 문제가 된다.
에코 문제를 해결하기 위해 음성 네트워크 장치인 에코 소거 장치(Echo Canceller)를 사용하여 에코를 제거하거나 감소시킬 수 있다.
에코 소거 장치는 에코의 근원에 가능한 가까운 곳에 배치되기도 하지만, 네트워크 내의 어느 지점에든지 위치할 수 있다.

VoIP 프로토콜

인터넷 폰 서비스를 제공하기 위한 표준에는 ITU-T에서 권고하고 있는 H.323 기반의 패킷 네트워크에서의 멀티미디어 서비스 제공 표준과 IETF(Internet Engineering Task Force)에서 규정한 SIP(Session Initialation Protocol)로 크게 구분할 수 있다.
H.323이나 SIP, RTCP(RTP Control Protocol) 등의 프로토콜들은 모두 RTP(Real-time Transport Protocol)를 기반으로 한 멀티미디어를 위한 전송 프로토콜이다.
이들의 주요한 기능은 비디오, 오디오 등의 멀티미디어 형식에 대한 정보를 포함하고 있으며 패킷의 손실 감지, 각 미디어 데이터들 간의 동기화 등을 제공한다.
특히 RTP는 멀티캐스트 회의에서도 사용될 수 있도록 설계되어 있다. 그리고 RTP는 RTCP라는 제어 프로토콜을 가지고 있어 회의 참여자들에게 추가적인 다양한 정보들을 제공할 수 있도록 하고 있다.
또한 미디어 게이트웨이를 제어하기 위한 프로토콜로는 MGCP가 있다.
그림 9-2는 VoIP에서 사용하는 프로토콜의 스택 구조를 나타내고 있다.

RTP와 RTCP

네트워크 계층의 IP를 기반으로 트랜스포트 계층에서 RTP, RTCP, RSVP 등의 전송 프로토콜을 이용하여 음성패킷을 전달한다.
RTP는 인터넷상에서 음성이나 영상과 같은 실시간 데이터를 전송하기 위한 인터넷 표준 프로토콜이고, 실시간이라는 특성 때문에 지연에 민감하고 다양한 미디어 지원을 위해 RTCP가 필요하게 되었다.
또한 한정된 네트워크 자원을 사용해야 하는 제한을 극복하면서 사용자의 요구에 맞는 서비스를 제공하기 위해 음성신호를 패킷화하여 전송 시 이를 압축함으로써 인터넷 상에 차지하는 대역폭을 줄이고 자원을 효과적으로 사용하기 위해 수신자 주도로 자원예약을 요청할 수 있는 RSVP를 사용한다.
RTP와 RTCP는 실시간 데이터의 특성상 낮은 지연을 유지하기 위해 TCP가 아닌 UDP를 사용한다. UDP는 송신자와 수신자 사이에 확인 메시지를 주고 받지 않으며 재전송도 하지 않는다. 이러한 특성은 신뢰성 보다는 실시간 서비스가 중요시되는 인터넷 전화 같은 멀티미디어 응용에 적합하다.
RTP와 RTCP는 전통적으로 UDP의 서로 달느 포트번호를 갖는다. RTP는 짝수의 포트번호가 할당되며, RTCP는 그 다음의 홀수 번호가 할당된다.

RTP(Real-time Transport Protocol)

RTP는 음성 영상 데이터 등과 같은 실시간 정보를 멀티캐스트나 유니캐스트 서비스를 통해서 전송하는데 적합한 프로토콜이다. 이를 위해 RTP에서는 세그먼트 번호 필드와 타임스탬프 필드를 제공한다.
일반적으로 RTP의 경우 패킷은 인터넷에서 UDP/IP를 통해 전송하며, 특정 전송 프로토콜에 제한되지 않고 다양한 프로토콜 상에서 멀티캐스트 또는 유니캐스트 서비스를 지원한다.
그러나 RTP 자체는 실시간 데이터를 지원하기 위한 QoS나 전송의 신뢰성은 보장하지 않으며, 데이터의 시간 정보와 패킷의 순서 정보만을 포함하여 수신측에서 수신된 데이터의 재조립을 통한 재생에 필요한 정보를 제공한다.
이러한 특성 떄문에 RTP는 QoS와 종단 대 종단 데이터 전송을 감시하는 RTCP를 필요로 한다.
RTP는 전형적으로 체크섬과 포트 개념을 제공하는 UDP 상에서 사용됨으로써 멀티캐스트 IP 패킷들을 전송할 때 한 곳에서 발생한 RTP 스트림이 여러 목적지로 전송될 수도 있다. 그림 9-3은 이와 같은 RTP 프토코로의 위치 및 패킷 구조를 보여준다.
RTP는 IP 네트워크에서 멀티미디어 정보를 전송하기 위한 프토토콜이다.

RTCP(Real-time Transport Control Protocol)

RTCP는 RTP 세션과 다른 UDP 포트를 이용하며, 별개의 프로토콜로 설계되었지만 다른 표준이나 RFC로 정해져 있지 않으며 RTP 표준 내에 포함된다. RTCP 패킷은 세션의 품질에 대한 종단간 정보를 전달한다.
품질 정보는 패킷 지연, 지터, 수신 패킷, 패킷 손실 등이 있으며 이러한 정보를 통해서 실시간으로 네트워크의 상태를 평가할 수 있다.
또한 RTCP를 이용하여 세션을 이루는 두 통신 주체는 주기적인 제어정보를 교환하며 품질에 관련된 피드백 정보를 교환한다.
이러한 과정을 통해 RTCP는 네트워크의 장애가 발생하는 경우 종단점을 위한 RTP 스트림이 손실되고 있는지를 관찰할 수 있으며, RTCP와 IP 멀티캐스트를 이용하여 네트워크 관리자와 같은 제 3 통신수행자가 네트워크 상의 문제점이나 세션 품질을 관찰할 수 있다.
RTCP는 RTP의 QoS를 유지하기 위해 데이터 전송을 감시하고, 세션 관련 정보를 전송하는데 사용되는 프로토콜이다.

RSVP(ReSource reserVation Protocol)

RSVP는 실시간 전송을 위한 자원 예약프로토콜로서 응용서비스와 QoS 요구사항을 보장하기 위해 대역폭을 확보하기 위한 절차를 규정하여 채널들이나 경로들을 예약할 수 있도록 한다. RSVP는 인터넷 QoS를 보장하기 위한 신호 프로토콜로서 다음과 같은 특징을 가지고 있다.
라우터의 경로 상태를 소프트 상태(Soft State)로 유지한다. 소프트 상태라는 것은 특정 경로에 대해 할당된 자원이 시간에 따라 변할 수 있다는 것이다. 예컨대 라우팅 경로가 변경되는 경우 RSVP가 동적으로 새로운 경로상의 자원들을 예약하여 소프트 상태를 유지할 수 있다. 소프트 상태의 유지는 QoS의 보장과도 밀접한 관련이 있으며, RSVP에서는 메시지를 주기적으로 재전송 함으로써 소프트 상태를 유지시킨다.
숫니자가 송신자에게 자우너예약을 요청하며, 수신자는 다른 수신자나 송신자에게 할당된 자원에 영향을 주지 않고 멀티캐스트 그룹에 참여한다.
기본적으로 단방향(simplex) 모드로 동작하며, 양방향 모드를 위해서는 자원예약을 양방향으로 해야 한다.
유니캐스트와 멀티캐스트를 지원하며, 특히 멀티캐스트에 유리하다.
송신지와 수신자의 종단간 QoS를 보장한다. 패킷 전송 경로를 따라 RSVP 프로토콜이 동작하면서 수집한 트래픽 정보가 자원할당의 근거가 된다.
그림 9-4는 호스트와 라우터에서의 RSVP 동작을 섦여하고 있다.
그림에서와 같이 RSVP는 패킷 분류자(Classifier), 정책 제어(Policy Control)와 수락 제어(Admission Control) 그리고 패킷 스케쥴러로 구성된다. 패킷 분류자는 각 패킷들의 QoS 클래스를 결정하며, 패킷 스케쥴러는 특정 패킷이 전송될 시간을 결정한다.
수락 제어는 노드가 요청된 QoS를 제공하기 위해 충분한 가용자원을 갖고 있는지를 결정하며, 정책 제어는 사용자가 요청한 자원을 예약하는데 관리상의 권한을 가지고 있는지를 결정한다.
만약 수락 제어와 정책 제어를 만족하는 경우, 요구하는 QoS를 위해 패킷 분류자와 링크계층 인터페이스에 파라미터들이 설정되고, 성공하지 못하면 요청한 프로세스에 에러를 통지한다.
RSVP의 자원 예약을 위한 신호 처리 과정은 그림 9-5와 같은 과정을 거친다.
먼저 송신자는 PATH 메시지를 통해서 자신의 트래픽 특성을 수신자에게 알려준다. 이때 경로는 IP 유니캐스트 혹은 멀티캐스트 라우팅 프로토콜에 의해 결정된다.
PATH 메시지가 지나가는 경로의 노드들은 경로 상태(path state)를 기록하게 된다. PATH 메시지를 받은 수신자는 송신자가 보내고자 하는 흐름의 특성(Flow-spec)을 보고 자신이 원하는 대역폭을 결정하여, RESV(자원 요청) 메시지를 통해 전달한다.
RESV 메시지에는 수신자가 원하는 서비스 요청 사항이 실리게 된다. RESV 메시지는 PATH 메시지가 전달된 경로를 따라 반대 방향(Upstream)으로 전달된다.
수신자로부터 RESV 메시지를 받은 노드들은 메시지에 기록된 서비스 요구사항을 근거로 서비스가 가능한지를 결정한다. 이것이 연결 수락 제어이다.
만약 요구를 수락한다면, 노드들은 흐름 특성을 링크 계층에 전달하고, 링크 계층은 주어진 흐름특성에 따라 패킷 스케쥴(Packet Scheduler)과 패킷 구분(Classifier)을 수행하게 된다.
네트워크 노드는 자원 요청에 대해 필터특성(Filter-Spec)을 사용하는데, 이것은 할당된 자원이 어느 송신자로부터의 흐름에 해당하는지를 명시하는 것이다. 특정 송신자의 흐름에 별도의 자원을 할당할 수도 있으며, 혹은 여러 송신자의 흐름에 합쳐진 흐름에 자원을 할당할 수도 있다.
이러한 필터특성은 링크 계층에서 패킷 구분에 사용된다. RESV 요청이 거절되면, 요청을 거절한 노드는 거절 이유를 기술한 오류 메시지를 수신자에게 전송하고 신호 과정은 종료된다.
RSVP는 단말이나 서버, 라우터 등이 협동하여 단말 간 응용 시 필요로 하는 대역을 예약/확보하기 위한 프로토콜이다.

H.323

H.323은 QoS가 보장되지 않는 PBN(Packet Based Network) 상에서 화상회의와 같은 멀티미디어 전송시스템에 대한 기술적인 요구사항을 정의하고 이는 ITU-T 권고안으로서 1996년 ITU-T SG(Study Group) 16에서 LAN, 인터넷 패킷 기반의 망을 통해 영상, 음성, 데이터 등 멀티미디어 통신을 위하여 제안한 영상회의 표준이다.
특히 H.323은 ISDN 통신을 위한 음성/비디오 코덱 권장 사양인 H.320을 완벽하게 지원하ㄴ면서 다양한 벤더 장비간의 상호 연동을 지원한느 것을 특징으로 하고 있다.

H.323 구성

H.323은 그림 9-6과 같이 터미널, 게이트웨이, 게이트키퍼, MCU(Multipoint Control Unit)와 같은 장비를 점대점(Point-to-Point)과 점대다중점(Point-to-Multipoint)의 형태로 구성된다.
1.
터미널(Terminal)
터미널은 오디오와 비디오, 또는 데이터 통신을 할 수 있는 능력을 갖고 있는 종단 장치로서 PC 또는 독립된 장치를 말한다.
터미널에 의해 제공되는 기본 서비스가 음성 통신이기 때문에 오디오로 통신할 수 있는 능력은 필수이며, 비디오, 데이터로 통신하는 능력은 선택 사항이다.
터미널은 H.323의 게이트웨이나 게이트키퍼, 다른 터미널 등과 실시간으로 양방향 통신을 할 수 있다.
2.
게이트웨이(Gateway)
게이트웨이는 이종의 네트워크 프로토콜을 사용하는 네트워크 사이에 연결성을 제공한다. 이러한 네트워크 연동기능은 신호를 설정하고 해제하는 기능과 프로토콜들을 변환하는 기능으로 이루어진다.
3.
게이트키퍼(Gatekeeper)
게이트키퍼는 H.323 데이터 네트워크의 통합성을 유지하는데 필요한 많은 기능들을 수행한다. 게이트키퍼는 선택적으로 주소 변환, 인증, 대역폭관리, 과금, 호 경로설정 등과 같은 중요한 서비스를 제공한다.
게이트키퍼가 존재할 경우 다음의 서비스들은 필수적으로 제공해야 한다.
주소 변환(Address Translation)
별명 주소(Alias Address)와 전송 주소(Transport Address)간의 변환을 수행해야 한다.
수락 제어(Admission Control)
H.255.0 ARQ/ACF/ARJ 메시지들을 이용해서 LAN 접근에 대한 허가 여부를 결정하는 인증 작업을 수행해야 한다.
대역폭 제어(Bandwidth Control)
H.255.0 BRQ/BRJ/BCF 메시지들을 사용하여 단말기 대역폭 요구를 관리해야 한다.
지역 관리(Zone Management)
지역 내에 있는 터미널들, MCU들 그리고 게이트웨이들을 관리해야 한다.
선택적으로 호 제어 시그널링(Call Control Signaling), 호 수락(Call Authorization), 대역폭 관리(Bandwidth Management), 호 관리(Call Management) 기능도 제공할 수 있다.
4.
MCU(Multipoint Control Unit)
MCU는 하나의 MC(Multipoint Controller)와 하나 이상의 MP(Multipoint Processor)로 구성된다. 세 개 이상의 터미널 화상회의를 지원할 수 있는데, 회의에 참여하는 모든 터미널들은 MCU로 연결을 설정한다.
MCU는 자원을 관리하고 음성 또는 비디오 코덱을 결정할 목적으로 터미널 사이에 협상하며, 논리적으로 H.323 표준의 분리된 구성요소지만 단일 물맂거 장비로 구현될 수 있다.
MC
다중점 회의에서 3개 이상의 단말들 간의 회의를 지원하기 위한 제어 기능들을 제공한다. MC는 다중점 회의에 참석한 각 단말들과 능력 교환을 수행하고 나중에 이를 변경할 수도 있다.
MP
단말들로부터 오디오, 비디오, 또는 데이터 스트림을 수신하여 각 매체 스트림에 적용된 알고리즘이나 형식의 변경, 같은 매체 스트림들 간의 스위칭이나 믹싱의 처리 과정을 거쳐 그 단말들에게 다시 돌려주는 일을 담당한다.

H.323 프로토콜

H.323 프로토콜 스택은 여러 가지 규약들로 이루어져있기 때문에 매우 복잡하다. H.323 프로토콜은 패킷 네트워크와 전송 프로토콜에 독립적이며, 동작하는 전송 프로토콜을 명시하지 않는다.
H.225 프로토콜은 상호 연결을 위한 규약으로 터미널과 게이트키퍼 사이에 주고 받는 메시지(RAS)와 호 신호에 대한 메시지(Q.931), 실시간 데이터전송에 대한 내용을 기술하고 있다.
또한 H.245 프로토콜은 H.323 프로토콜의 호 제어에 관한 내용을 규정한다.
그림 9-7은 H.323의 프로토콜 스택을 보여주고 있다.
1.
오디오/비디오 코덱
음성 채널은 T1을 통해 전송될 떄 PCM을 사용하는 경우 64Kbps를 사용한다. 압축기술은 음성 품질을 보존하면서, 대역폭을 적게 요구하도록 개발되었다. 대부분의 H.323 장비들은 벤더들 간의 상호 연동성을 위해 ITU-T 같은 표준에서 제정된 코덱을 사용한다.
2.
H.225 RAS(Registration, Admission, Status) 신호
H.225 RAS 신호는 게이트키퍼가 있는 경우에만 사용하는 규약이다. 즉, 단말과 게이트키퍼간의 통신 규약인 것이다. H.225 RAS 신호를 사용하여 터미널이 게이트키퍼에게 호 설정을 요청할 수 있고, 게이트웨이는 터미널의 호 설정 요청을 수락하여 자신의 관리 목록에 등록할 수도 있다.
또한 RAS는 게이트키퍼와 터미널 사이의 상태를 관리하고 대역폭을 변화 시키는 기능도 수행한다.
아래 표는 게이트키퍼와 터미널 사이에 사용되는 RAS 메시지를 나타낸다.
메시지
설명
ARQ(AdmissionReQuest)
호를 설정하기 위해 허락을 요청하는 터미널로부터 게이트키퍼에게 보내지는 메시지
ACF(AdmissionConFirm)
게이트키퍼가 터미널에게 호를 설정하는 것을 허락하는 메시지
DRQ(DisengateReQuest)
터미널이나 게이트키퍼가 호를 해제하기 위하여 보내는 메시지
DCF(DisengageConFirm)
DRQ 메시지에 대한 확인 메시지
3.
H.225 호 신호(Call Signaling)
H.225 호 신호는 Q.931 신호 메시지를 지원하며, H.323 종단 간 연결을 위하여 TCP 포트 1720을 통해서 설정된다. 이 포트는 전화 호 연결, 유지 및 해제를 위해서 Q.931호 제어 메시지를 초기화한다.
Q.931은 호 연결(Call Setup)에 필요한 규약으로써 전화 연결을 위해 ISDN(E1/T1 같은 디지털 회선에서 주로 사용되는 규약)에서도 사용되는 범용적인 규약이다.
아래 표는 보편적으로 사용되는 H.225호 신호 메시지들이다.
메시지
설명
Setup
송신자가 수신자에게 호 설립을 위한 메시지를 보낸다. 이 메시지는 H.225 메시지로 게이트키퍼 TCP 포트 1720으로 보낸다.
Call Proceeding
게이트키퍼가 송신자에게 호 설립 과정이 진행되고 있다는 것을 알리는 메시지를 송신자에게 보낸다.
Alerting
게이트키퍼는 수신자가 ringing을 받고 있다는 것을 알리는 메시지를 송신자에게 보낸다.
Connect
게이트키퍼는 수신자가 응답을 했음을 알리는 메시지를 송신자에게 보낸다.
Release Complete
송신자 또는 수신자가 전화 호의 종료를 시작하는 메시지를 상태편에게 보낸다.
Facility
부가서비스의 요청 및 확인을 보내는 Q.932 메시지이다.
4.
H.245 제어 신호(Control Signaling)
H.245에서는 멀티미디어 데이터를 교환하기 위한 일련의 프로토콜의 동작과 해당 프로토콜에서 주고 받는 메시지의 구문을 정의하고 있다.
H.245 제어 신호는 H.323 터미널 간에 멀티미디어 데이터를 주고 받기 위해 각 터미널의 동작을 제어하거나 통신에 대한 정보를 전달할 수 있는 제어 메시지 교환을 위한 제어 프로토콜이다.
터미널 간에 호 연결이 이루어지면 상호 연결된 터미널은 하나의 채널을 사용하여 음성 및 영상을 전송하는 것이 아니라 여러 개의 채널을 연결한 후 각 채널에 대해 음성 및 영상을 전송하게 된다.

H.323 동작 과정

그림 9-8은 H.323의 호 설정 과정을 나타내는 그림이다.
1.
T1 터미널은 게이트키퍼에게 자신을 등록하기 위해 RAS ARQ(Admission Request) 메시지를 전송하여 호 설정을 요청한다.
2.
게이트키퍼는 T1에게 ACF 메시지를 전송함으로써 호를 사용할 것을 허가한다.
3.
T1 터미널은 게이트키퍼에게 자신을 등록하기 위해 RAS ARQ(Admission Request) 메시지를 전송하여 호 설정을 요청한다. T1은 연결을 요청하는 T2에 H.225호 신호설정(setup) 메시지를 보낸다.
4.
T1 터미널은 게이트키퍼에게 자신을 등록하기 위해 RAS ARQ(Admissoin Request) 메시지를 전송하여 호 설정을 요청한다. T2는 T1에 H.22호 진행(Call Proceeding) 메시지로 응답한다.
5.
T2는 자신이 속해 있는 게이트 키퍼에게 자신을 등록하기 위해서 RAS ARQ 메시지를 전송한다.
6.
T2의 게이트 키퍼는 T2에게 RAS ACF 메시지를 전송함으로써 등록을 알려준다.
7.
T2는 T1에 H.225 경고(Alert) 메시지를 전송하여 연결 설정을 알린다.
8.
T2는 T1에 H.225 연결(Connect) 메시지를 전송하여 연결 설정을 확인한다.
9.
T1과 T2는 H.245 연결 확립을 통하여 미디어 전송을 위한 채널을 설정한다.
10.
T1과 T2와의 미디어 데이터 전송이 이루어진다.
11.
전송이 끝나면 H.245 연결 해제를 통하여 설정된 채널은 해제된다.
12.
T1은 게이트키퍼에게 H.225 호가 해제 되었다는 메시지를 전송한다.
13.
게이트키퍼는 T2에게 H.225 호가 해제 되었다는 메시지를 전송한다.
14.
T1과 T2는 각각 게이트키퍼에게 RAS DRQ(Disengate Request) 메시지를 전송하여 게이트키퍼와의 호 해제를 요청한다.
15.
게이트키퍼는 T1과 T2와의 호를 해제하고 T1과 T2에게 DCF(Disengage Confirm) 메시지를 전송하여 호를 해제시켰음을 알려준다.

SIP(Session Initiation Protocol)

SIP는 인터넷 전화기, PDA, 휴대폰과 같이 음성 통신이 가능한 VoIP 단말기 간의 호를 설정하기 위해 개발된 프로토콜이다.
SIP는 HTTP, SMTP 등 웹에 기반을 두고 모델링하였고, URL, 메일 주소 등의 주소 방식을 사용하고 메시지 구성이 ASCII로 작성된 텍스트 기반의 제어 프로토콜이다.
SIP는 단말간 또는 사용자들 간에 기존의 VoIP 서비스 뿐만 아니라 멀티미디어 컨퍼런스, 인터넷 텔레폰, 원격 교육 등의 세션이나 호를 생성, 변경, 해제하는 기능을 수행한다.

SIP 프로토콜 특징

1.
최소 상태(Minimal State) 유지
하나의 회의나 통화에는 다수의 SIP 메시지가 송수신된다. 이러한 상태를 유지하기 위해서 SIP 서버가 통화 전체에 대한 상태 정보를 저장하고 있을 필요는 없다. SIP 프락시 서버는 요청과 응답이 이루는 하나의 트랜잭션에 대한 상태 정보만을 유지하고 있으면 된다.
또한 SIP 리디렉트(Redirect) 서버는 위치 제공 서버로부터 수신자 주소만을 캐시(Cash)하고 있으면 된다.
2.
하위 계층 프로토콜에 중립
SIP 메시지를 전송하기 위해서는 주로 TCP와 UDP를 사용한다. UDP는 신뢰성은 떨어지지만, TCP보다 구현이 간단하고 호 설정 속도가 빠르다. 또한 멀티캐스트를 이용한 다자간 세션 설정도 용이하기 때문에 일반적으로 SIP는 UDP를 사용하여 메시지를 전송한다.
3.
텍스트 기반 프로토콜
SIP는 HTTP처럼 텍스트 기반 프로토콜이기 때문에 어떤 언어로든 구현이 용이하며 디버깅이 쉽다. 또한 확장성이나 유연성 면에서도 유리한 점을 제공한다.
4.
사용자 이동성(Mobility)
이동성이란 사용자 측면에서는 현재의 위치와 현재 사용 중인 단말 종류와 무관하게 세션에 참가할 수 있다는 것이다. 네트워크 측면에서는 참가자의 위치가 다른 곳으로 옮겨져 있어도 그를 구분하고 확인할 수 있다는 것이기도 하다. 즉 SIP는 인터넷에 접속할 수 있는 곳이라면 간단한 재등록 절차를 거쳐 음성통화를 가능하게 한다.

SIP 구성요소

SIP는 HTTP와 유사한 클라이언트-서버 구조로 되어 있으며 크게 사용자 에이전트(User Agent Client)와 서버(User Agent Server)로 나누어진다.
1.
사용자 에이전트
SIP의 요청관련 메시지를 주느냐 또는 받느냐에 따라 클라이언트도 될 수 있고 서버도 될 수 있다. 다시 말해 SIP의 INVITE 메시지를 보내면 클라이언트(UAC)이고, 그것을 받아 무언가 응답을 보낸다면 서버(UAS)이다.
UAC(User Agent Client)
송신자 쪽에 위치하여 SIP 요청을 초기화하는 클라이언트 응용 프로그램이다.
UAS(User Agent Server)
수신자 쪽에 위치하여 송신자의 요청을 받았을 경우 그 요청을 수락할 것인지, 거부할 것인지 또는 전송할 것인지에 관해 사용자의 의견을 물어 그 결정을 사용자 대신에 송신자에게 응답을 보내는 응용 프로그램이다.
위치(Location) 서버
SIP 서버(Proxy, Redirect)의 요청을 받은 위치 서버는 finger, rwhois, LDAP(Light-weight Directory Access Protocol) 또는 자체 메커니즘 등을 사용하여 연결 가능한 사용자의 위치를 알려준다.
사용자가 여러 곳에 로그인해 있을 수 있기 때문에 서버는 다수의 위치를 알려줄 수 있어야 한다.
2.
서버
SIP 서버는 UAC의 SIP 요청을 처리하는 것으로, 직접 세션에 관여하지는 않고 요청을 어떻게 처리하는가에 따라 다음과 같이 나뉜다.
SIP 프락시(Proxy) 서버
송신자와 수신자 사이에 존재하며 요청과 응답메시지를 자신이 보내는 것처럼 중계한다. 수신자는 프락시 서버로부터 요청을 받는 것이고, 송신자는 프락시 서버로부터 응답을 받는 것이다. 즉 프락시 서버는 UAC와 UAS의 역할을 모두 수행하는 SIP 서버이다.
송신자는 자신에게 등록된 프락시 서버에게 SIP 요청을 하고, 그 요청은 다수의 원격지 프락시 서버를 경유할 수 있다. 그 경우 프락시 서버는 반드시 메시지의 Via 헤더필드에 경로를 첨가해야 한다. 응답은 Via 필드를 참조하면서 역으로 진행되고 하나씩 삭제된다.
그림 9-9는 프락시 서버 구성을 나타내고 있다.
SIP 리디렉션(Redirection) 서버
송신자에게 INVITE 요청을 받으면 수신자에게 현재 위치를 위치 서버로부터 찾아내어 송신자에게 되돌려주어 송신자로 하여금 직접 수신자를 호출할 수 있도록 한다.
그림 9-10은 리디렉션 서버의 동작을 나타내고 있다.

SIP 프로토콜 메시지 형식

SIP의 기본 동작은 클라이언트/서버 모델과 유사하다. 클라이언트에서 서버로 호 설정 요청 시에는 REQUEST 방법을 이용하고, 서버에서 클라이언트의 응답은 숫자로 지정된 상태 코드인 RESPONSE를 전달한다.
그림 9-11의 왼쪽 그림에서 알 수 있듯이 서버에게 요청을 원하는 단말기는 REQUEST 메소드를 보내고, 응답을 하는 단말기는 RESPONSE 메시지를 보낸다.
그림 9-11의 오른쪽은 메시지 헤더필드의 내용으로 콜 서비스, 주소, 프로토콜 정보 등을 나타내며 REQUEST, GENERAL, RESPONSE, ENTITY의 4가지 범주로 분류된다.
GENERAL 헤더에는 REQUEST와 RESPONSE 둘 다사용될 수 있고, 기본적인 내용에는 수신자, 발신자, Call-ID 등이 있다.
REQUEST 헤더에는 클라이언트의 우선 순위와 같은 부가적인 정보가 들어갈 수 있으며, RESPONSE 헤더에는 Unsupported, Retry-After(not now)와 같은 응답에 대한 추가 설명이 들어간다. ENTITY 헤더에는 메시지의 길이, 미디어 타입, 인코딩 방식과 같은 정보가 들어간다.

SIP 프로토콜 주소지정

SIP는 URL을 사용하여 수신자를 찾기 위한 IP 주소, 포트 번호 그리고 메시지의 헤더를 만드는데 필요한 각종 정보를 표현한다. 다음은 SIP URL의 몇 가지 예로서 전자우편 주소와 형식이 비슷하다. 또한 사용자 ID 대신에 VoIP 단말기의 번호를 사용하여 SIP 주소를 나타낼 수도 있다.
SIP: bwyoon@icc.skku.com
SIP: 123456789@icc.skku.com;user=phone

SIP와 H.323의 비교

아래 표는 SIP와 H.323을 비교하고 있다. SIP는 H.323과 같은 복잡한 호 절차를 생략하였고, 구문이 간단하여 구현이 쉽다는 장점을 갖고 있다. 따라서 표에 보이는 바와 같은 다양한 장점으로 최근에는 SIP가 주류를 이루고 있다.
기능
SIP
H.323
표준 제정 기관
IETF
ITU
호 연결시
기본 호 연결 시 채널 연결
H.225와 H.245에 의한 호와 채널의 분리
메시지 형태
HTTP 기반의 텍스트
ASN.1에 의한 코딩 방식
단말 능력 (Capability) 교환
SDP(Session Description Protocol)에 의한 한정적 교환
H.245에 의한 단말의 전체적 능력 교환
신뢰성
아직 장비 장애에 대한 표준화된 처리 규정이 없음
네트워크 개체들의 장애를 다루기 위한 여러 개의 특성이 정의되어 있음
사용되는 채널
UDP 채널 1개
UDP 또는 TCP 채널 2개
메시지 확장성
메시지 헤더에 단지 한 줄만 입력하면 됨
많은 프로토콜들을 결합해야 함
수정 가능성
프로토콜 계층에 독립적
프로토콜 계층에 종속적
모바일
가능
아직 없음
서버
SIP 네트워크 서버
게이트키퍼

MGCP(Media Gateway Control Protocol)

인터넷과 기존 PSTN 사이에는 게이트웨이를 사용하여 VoIP 서비스를 제공한다. 즉 게이트웨이는 회선교환 네트워크로부터 신호와 미디어를 받아들여서 IP 네트워크가 사용하는 패킷 형식으로 변환해야 한다.
이를 위해 미디어 게이트웨이 제어기와 미디어 게이트웨이 사이에 표준화된 제어 프로토콜이 필요하게 되었고, MGCP와 MEGACO/H.248이 표준화 되었다.
이와 같이 분리된 게이트웨이 모델은 큰 확장성을 가지므로 다양한 서비스의 지원이 가능하고 미디어 게이트웨이를 통한 네트워크 구성은 좀 더 용이해질 수 있다.

MGCP 개요

현재 음성데이터 서비스는 예전의 음성전화망의 기반 기술이었던 회선 교환방식을 이용하지 않고서도 ATM, IP 등의 비회선 교환방식의 네트워크를 이용하여 서비스를 할 수 있게 되었다.
이에 따라 기존의 PSTN과 새로운 패킷교환 네트워크 사이에서 서로 다른 호 신호를 사용하기 위한 프로토콜의 연동과 다양한 종류의 미디어 스트림 형식변환이나 전송 등의 새로운 기능을 담당해야 할 게이트웨이가 필요하게 되었다.
그림 9-12는 MGCP의 망 구성도를 나타내는 그림으로 크게 데이터 스트림 전송을 위한 게이트웨이와 제어를 담당하는 CA(Call Agent)로 나뉜다. 즉, MGCP는 게이트웨이를 제어하기 위한 시그널링 프로토콜로서 CA라고도 불리며, IETF에서 개발되었다.
CA는 호 제어 정보와 관련된 호 신호를 처리하는 반면에 미디어 게이트웨이는 CA로부터 명령을 받고 기본적으로 CA가 명령하는 것을 수행한다. CA는 일반적으로 연결설정 및 게이트웨이의 한쪽에서 다른 쪽으로부터 연결을 해제하는 기능을 수행한다.

RGW(Residential Gateway)

RGW의 가장 기본적인 기능은 PSTN 회선과 연결설정을 위한 MGCP, RTP 등을 지원하는 것이다. 예컨대 RGW에 물려있는 사용자가 A가 수화기를 들면 RGW는 사용자 A가 전화기를 들었다는 on-hook 이벤트를 감지하고 MGCP를 이용해서 CA에게 알려준다.

TGW(Trunking Gateway)

Trunking Gateway는 인터넷 망과 PSTN 망을 연결하는 역할을 수행한다. 만약 사용자 D가 연결설정을 시도하면 TDM(Time Division Multiplexing) 형식으로 TGW에게 음성데이터를 전송한다. TGW는 이 음성데이터를 받아서 RTP 패킷으로 변환하며 IP 망으로 내보낸다.
반대로 IP 망에서 TGW에게 RTP 패킷 형식으로 데이터가 들어오면 TDM 형식으로 변환하여 PSTN 망으로 전송한다. TGW는 MGCP를 이용해서 CA와 통신하며 수신한 호에 대한 보고를 하고 음성 데이터를 어떻게 처리해야 하는지를 CA로부터 지시 받는다.
TGW는 이와 같이 다른 종류의 망 사이에 위치하기 때문에 다양한 인터페이스를 지원할 수 있어야 한다. 그림 9-12에서와 같이 CA는 PSTN과의 연동에서 STP와 연결되므로 SS7 시그널링을 지원할 수 있어야 한다. SS7은 PSTN 망에서 제어를 담당하는 패킷기반의 시그널링 프로토콜이다.

CA(Call Agent)

CA는 RGW와 TGW를 제어하며 이를 위한 시그널링 프로토콜로 MGCP를 이용하낟. 기본적으로 게이트웨이들은 CA에서 지시한 이벤트들에 대한 감시를 하고, 발생한 이벤트에 대해 CA에게 보고하고 이벤트에 대한 처리절차를 지시 받는다.