Chapter 1. VoIP의 이해
8. 시그널링의 이해
시그널링 (Signaling, 신호교환)은 전화망에서 호의 접속과 해제 또는 호의 제어 및 관리에 관련된 정보의 교환으로 정의됩니다. 예를 들면, 011-1234-5678라는 전화번호를 다이얼을 하면 발신자는 링백톤을 듣게 되고, 수신자는 링이 울리는 전화기의 수화기를 들면 서로 연결된 후 "여보세요"라는 말을 하면서 통화가 시작됩니다. 수신자가 수화기를 드는 바로 전까지의 과정과 수화기를 내려놓는 이후의 과정이 시그널링입니다.
IP 네트워크 상에서 시그널링으로 수행되는 역할은 세가지입니다.
- 주소번역 (Address Translation)
IP 네트워크에서는 IP 주소(32bit)를 이용하여 상대방을 찾지만, 사람들은 E.164 주소 체계 (전화번호)를 이용하여 상대방을 찾습니다. 서로 다른 주소체계인 전화번호와 IP 주소간의 번역을 위한 매핑 테이블이 필요합니다. 즉, 시그널링 과정에서 발신 전화기가 수신 전화기의 IP 주소를 획득하게 됩니다. - 코덱협상 (Capability Negotiation)
시그널링 과정에서 실제 전달할 음성을 어떤 방식으로 압축해서 보낼지를 결정합니다. G.711, G.729, G.723, G.722 등의 코덱 가운데 적당한 코덱을 선택하는 작업입니다. 기존의 PSTN 전화망은 회선 교환 이므로 한 채널은 64Kbps가 확보되어 G.711 코덱만을 사용하지만, IP 네트워크는 패킷 교환이므로 네트워크의 대역폭의 상황에 따라 다양한 코덱을 사용합니다. - 정책 결정 (Call Admission Control)
전화번호를 누른다고 무조건 전화를 연결하는 것이 아니라 허가받은 사용자인지 또는 상대방은 전화를 받을 수 있는 권한이 있는 지 등에 대한 정책을 결정합니다. 예를 들면, 일반 방문객들이 사용하는 전화기는 사내의 사무실로만 전화할 수 있도록 하거나 해외업무 파트가 아닌 직원들의 전화기는 국제통화를 하지 못하게 설정할 수 있습니다.
IP 네트워크에서 시그널링이 완료된 후에 실제 음성을 전달하기 위한 프로토콜은 RTP (Real time Protocol)입니다. RTP는 실시간으로 음성을 송수신하기 위한 전송 계층 통신 규약으로 IETF의 RFC 1889로 정의되었나 2003년 RFC 3550으로 변경되었습니다. 또한, RTP의 원활한 소통을 위해 RTCP (Real-Time Control Protocol)와 함께 사용될 수 있습니다. RTCP는 송신측은 타임 스탬프를 근거로 재생간에 동기를 취해 지연이 생기지 않도록 하며 수신측에서는 전송 지연이나 대역폭을 등을 점검, RTCP를 사용해서 송신측의 어플리케이션에 통지할 수 있습니다.
10. VoIP 프로토콜의 역사
IP 네트워크에서 시그널링을 위해 사용하는 프로토콜은 H.323, SIP, MGCP, Megaco/H.248, Sigtran, SCCP (Skinny Call Control Protocol) 등이지만, 일반 기업에서 사용하는 프로토콜을 중심으로 정리해 봅니다.
1990년대 초에 음성과 데이터 네트워크 통합을 위한 VoIP는 인터넷 또는 기업 내부의 인트라넷에서 IP를 이용해 음성과 비디오를 전송하기 위한 필요성이 대두되기 시작했습니다. VoIP 초창기에 가장 많이 사용한 시그널링 프로토콜은 H.323으로 QoS(품질 보장, Quality of Service)가 지원되지 않는 LAN 환경에서 멀티미디어 통신을 지원하기 위해 개발되었습니다. H.323은 급하게 표준화되면서 몇가지 문제점을 드러냈습니다.
- 대규모의 사용자 지원의 어려움
- 대형 VoIP 네트워크 구성의 한계점
- 기존의 아날로그 PBX가 지원하던 전화 부가 기능의 미흡
- 프로토콜 자체의 복잡성으로 인한 부가 서비스 개발의 어려움
H.323 표준을 제정한 ITU (국제 전기 통신 연합, International Telecommunication Union)는 주로 물리 및 데이타링크 계층에 관련된 표준을 주로 제정하는 기구입니다. H.323 프로토콜의 단점을 보다보면, ITU가 IP 계층에 대한 이해가 부족한 기관이기에 기존 PSTN 네트워크의 아키택쳐를 그대로 수용한 느낌입니다. H.323의 시그널링 과정과 메세지는 ISDN Q,931과 거의 유사합니다.
ITU는 H.323 프로토콜의 초기 버전에 문제점들을 보완하기 위해 1998년 H.323 Version 2를 표준화하면서 복잡한 시그널링 과정을 단순화한 Fast Connection (Fast start) 프로시져와 부가서비스를 추가하였습니다.
ITU와 달리 IETF (인터넷 국제 표준화 기구, Internet Enginnering Task Force)는 IP 네트워크를 다루는 기구로 H.323의 문제점을 극복하기 위해 SIP를 1999년 급하게 표준화합니다. SIP는 클라이언트/서버 기반 프로토콜로 뛰어난 확장성과 유연성, 그리고 단순한 시그널링을 내세웠습니다. H.323 version 1이 문제가 많았던 것처럼 SIP도 마찬가지였으며, 2002년 RFC 3261가 발표되면서 정리가 되었습니다. 이때 많은 사람들이 SIP가 금방 H.323을 갈아치우고 인터넷 전화 시장을 잠식할 것으로 기대하였지만, 시장의 움직임은 더디기만 했습니다.
SIP의 뛰어난 확장성과 유연성은 장점이지만 단점이기도 합니다. 서로 다른 제조사의 장비 연동은 언제나 프로토콜 초창기에는 문제가 있기 마련이지만, SIP는 부가서비스 연동은 고사하고 기본 서비스 연동에도 다양한 문제를 일으켰습니다. H.323은 엄격히 규격화된 표준 덕분에 개발은 복잡하여도 이기종 장비간 상호 연동이 비교적 쉽게 되었습니다. SIP는 표준으로 명확히 규정되지 않은 부분이 많아 구멍이 많은 프로토콜로 제조사마다 개별적으로 처리하는 부분이 많았습니다. 결국 이기종 장비간에 주로 연동하는 트렁크는 SIP 발표이후에도 오랫동안 H.323이 차지하게 됩니다.
H.323과 SIP간의 경쟁은 2000년대 후반까지 계속 되었으나 각 프로토콜의 장단점을 활용하는 방안으로 귀결되었습니다. H.323은 엄격한 규정 덕에 이기종 장비간 상호연동이 필요한 부분에 주로 사용되었습니다. SIP는 부가 서비스가 많이 필요한 전화기와 IP PBX간 연동에 주로 사용하였습니다.
SIP가 초창기 이기종 장비간 연동에 관한 문제는 느슨한 규정때문입니다. 그러나, 느슨한 규정은 기업이 요구하는 부가서비스의 개발을 용이하게 하였습니다. 제조사마다 방식은 틀리지만 원하는 부가서비스를 빠르게 구현할 수 있었으므로 초기 SIP 개발의 목적은 사라지면서 IP PBX와 IP Phone이 제조사에 귀속되는 현상이 발생했습니다. 기업용 IP Telephony 시장은 IP PBX와 IP Phone을 같은 제조사 제품을 사용해충분한 부가서비스를 사용할 수 있도록 하였고, 일반 가정용 IP Telephony 시장은 많은 부가서비스가 필요없으므로 IP Phone과 IP Telephony 제조사가 달라도 상관없게 진화하였습니다.
결국 RFC 3261에서 시작한 SIP이지만, 부가 서비스 영역으로 들어가면 각 제조사별로 상이한 SIP가 됩니다. 제조사만의 특별한 필드를 사용하는 경우도 있습니다.
현재는 SIP가 시장에서 광범위하게 사용되다보니 자연스럽게 트렁크 영역에서도 엔지니어의 관성에 따라 H.323을 선택하지 않는 이상 SIP를 사용합니다. SIP는 이미 VoIP 시장을 지배하는 프로토콜입니다. 그러나 SIP 프로토콜은 만능이 아니므로 IP Telephony나 UC 구축시에는 전화기, IP PBX, Voice Gateway는 동일 제조사의 제품을 사용해야 합니다. SIP가 표준이므로 다 되어야 된다고 아무리 주장을 하여도 느슨한 부분과 부가 서비스는 제조사 별로 구현 방식이 모두 틀립니다.
지금까지 H.323과 SIP의 경쟁에 대해 다루었습니다. MGCP의 역사에 대해서도 간략하게 살펴보겠습니다. 기본적으로 H.323이나 SIP는 Peer to Peer 방식이며, MGCP는 Master/Slave 방식입니다.
- Master/slave
MGCP, Megaco/H.248 등의 프로토콜로 게이트웨이 및 단말은 지능적인 기능을 수행하지 않고 MGC (Media Gateway Controller) 혹은 CA (Call Agent)라는 호제어 장비가 수행합니다. Gateway는 단순히 음성을 패킷으로, 패킷을 음성으로 변환하는 DSP (Digital Signal Processor) 칩과 PSTN과 IP 망의 연동 인터페이스만을 가지는 더미(dummy)가 됩니다. 게이트웨이나 단말은 단독으로 호 제어를 수행할 수 없는 중앙 집중식 구조입니다. - Peer to peer
SIP 및 H.323 등의 프로토콜로 게이트웨이 및 단말이 지능적인 기능을 수행합니다. 게이트웨이 및 단말이 단독으로 호 라우팅 및 다양한 부가 서비스를 수행합니다. SIP의 Proxy Server 나 H.323의 Gatekeeper는 옵션장비 입니다.
Master/Slave 방식의 MGCP는 1999년 10년 RFC 2705 MGCP (Media Gateway Control Protocol version 1.0)으로 발표되었으며, 2003년 RFC 3545가 나오면서 본격적으로 사용되기 시작했습니다. 이름에서 보듯이 PSTN 연동을 위한 Voice Gateway를 중앙집중식으로 효과적으로 관리하기 위해 개발된 프로토콜로 H.323과 SIP은 망이 거대해질수록 관리가 복잡해지고 과금이나 호 정책의 설정 등의 어려움을 극복하기 위해서 입니다.
MGCP도 SIP와 마찬가지로 IETF에 제정하였으므로 프로토콜 구조가 SIP와 매우 흡사합니다. Voice Gateway가 많은 대기업 및 다국적 기업이나 통신사업자에서 선호하는 프로토콜입니다. MGCP 아키택쳐의 장점은 MEGACO (MEdia GEteway COntrol Protocol, RFC 3015)로 이어지면서 ITU와 IETF가 함께 표준화합니다. IETF는 MEGACO라 명명하였고, ITU는 H.248로 명명합니다. MGCP가 음성 중심으로 설계되었지만, MEGACO/ H.248는 음성, 영상 및 데이타까지 포함하여 설계되었습니다.
11. H.323은 왜 복잡한가?
현재 업계에서 가장 많이 사용하는 VoIP 프로토콜은 SIP입니다. SIP가 선택된 이유는 지속적으로 설명하겠지만, H.323이 복잡하고 개발이 어렵다는 이유를 간략히 살펴보겠습니다.
H.323이 급하게 표준화되었다는 이유 중에 하나는 ISDN Q.931의 호 프로세스를 그대로 차용한 것입니다.
H.323은 Protocol Suites 라고 불리듯이 여러 프로토콜의 조합으로 이루어져 있습니다. 호 제어 및 시그널링을 위한 H.225 Call Control, 단말 등록 및 호 정책을 설정을 위한 H.225 RAS(Registration, Admission, Status), 그리고 부가 서비스 및 Capability Negotiation (코덱협상)을 위한 H.245, 보안 통신을 위한 H.235로 구성되어 있습니다. H.323 통신을 위해서는 H.225 채널과 H.245 채널을 각각 협상하는 복잡한 프로토콜입니다.
H.323은 ASN 코드를 이용하므로 설계나 디버깅도 어렵습니다. 아래는 H.323 Setup 메세지의 예입니다. SIP 이나 MGCP 메세지를 보신 분들은 H.225 Setup 메세지가 더 복잡하고 한눈에 들어오지 않을 것입니다.
Router# debug h225 asn1
H.225 ASN1 Messages debugging is on
Router#
value H323-UserInformation ::= { h323-uu-pdu { h323-message-body setup : { protocolIdentifier { 0 0 8 2250 0 1 }, sourceAddress { h323-ID : "ptel213" }, sourceInfo { terminal { }, mc FALSE, undefinedNode FALSE }, destinationAddress { h323-ID : "ptel23@zone2.com" }, activeMC FALSE, conferenceID '5FC8490FB4B9D111BFAF0060B000E945'H, conferenceGoal create : NULL, callType pointToPoint : NULL, sourceCallSignalAddress ipAddress : { ip '3200000C'H, port 1720 } } } }
12. VoIP 프로토콜 초간단 비교
지금까지 살펴본 H.323, SIP, MGCP를 아래표로 간단하게 비교해 보겠습니다.
구분 |
H.323 |
SIP |
MGCP |
표준기관 | ITU-T | IETF | IETF |
Architecture | 분산 | 분산 | 중앙집중식 |
최신버전 | H.323 v5 | SIP 2.0 (RFC 3261) | MGCP 1.0 (RFC 3015) |
전송 프로토콜 | TCP | TCP or UDP | UDP |
Encoding | ASN.1 | 텍스트 | 텍스트 |
확장성 | 뛰어남 | 매우 뛰어남 | 뛰어남 |
코덱협상 | H.245 | SDP | SDP |
방화벽 투과 | 다수 프로토콜로 복잡 | 단순 | 단순 |
보안 프로토콜 | TLS | H.235 IPSEC, TLS |
|
호 제어 장비 |
GateKeeper |
Proxy Server |
Call Agent |
단말 |
Gateway |
Gateway IP Phone |
Gateway |
현재 기업용 IP PBX 중에 MGCP를 지원하는 장비는 시스코의 CUCM이 유일할 것입니다. 통신사에서 주로 사용한느 소프트스위치나 IMS는 기본으로 제공하는 프로토콜입니다.
VoIP프로토콜을 무엇으로 선택하느냐에 따라 망구조가 많이 달라집니다. 기업에서 사용하는 IP PBX는 Line Side는 SIP로 구성하며, Trunk Side는 H.323 이나 SIP를 사용합니다. 특히 Secure IP Telephony를 사용하는 경우에는 SIP Trunk가 편리하므로 많이 사용합니다.
마치며
이미 포스팅했던 내용들을 다시 정리할려니 어렵네요..^^
"다시쓰는 SIP의 이해" 연재의 다른 글
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method
2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method
2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method
2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method
2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method
2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method
2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method
2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method
2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP
2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP
2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP
2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response
2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261
2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261
2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261
2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview
2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview
2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)
2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)
2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)
라인하트 유씨누스 (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________
