2001.10.24 차세대 VoIP 서비스를 위한 IETF SIP의 기술 동향 분석 유현경* 성정식** 강태규*** 김도영**** 인터넷을 이용하여 저렴한 비용으로 음성을 전송할 수 있는 VoIP 서비스의 발전으로 머지않아 VoIP서비스가 현재의 회선 교환 전화 서비스를 대치할 것으로 보인다. VoIP에 mobility, universal number, multiparty conferencing, voice mail, automatic call distribution과 같은 진보된 서비스를 제공하기 위해서는 시그널링이 가능한 표준화된 프로토콜이 필요하다. 이러한 조건을 만족시키는 시그널링 프로토콜에는 ITU-T의H.323과 IETF의 SIP가 있다. 본 문서에서는 단말간에 콜을 생성, 변경, 종료할 때 쓰이는 SIP가 어떠한 특성을 가지며 동작하는지 살펴본다. 또한 IETF의 SIP 표준화 동향으로는 표준으로 제안된 RFC2543을 기반으로 개발을 하고 있는 SIP, 인터넷 teleconference session을 지원하기 위한 MMUSIC, 인터넷 텔레포니를 위한 IPTEL에 대해 설명한다. 또한 SIP가 H.323과 비교해서 어떠한 장점이 있는지 서술하였고, SIP의 장점을 활용하여 IMT2000, 3GPP, ETSI 등에서 어떻게 발전시키고 있는지 설명한다. ▧  I. 서 론 인터넷을 통해 영상, 음성 및 팩스 메시지를 전달하는 서비스인 VoIP(Voice over Internet Protocol)는 인터넷을 이용하고자 하는 사용자가 PC에서 인터넷에 접속하거나, 인터넷 프로토콜이 적용된 독립적인 디바이스를 이용하여 접속하거나, 기존의 PSTN 단말기에서 게이트웨이로 전화를 걸어 접속할 때와 같이 여러 경우에 음성과 비디오와 같은 실시간 미디어를 전송한다[1]. VoIP서비스를 할 때에 통신하고자 하는 상대방을 찾아 시그널링하는 수단이 필요하며 이러한 VoIP 시그널링 종류는 ITU-T(International Telecommu-nication Standardization Sector)의H.323과 IETF (Internet Engineering Task Force)의SIP(Session Initiation Protocol)가 있다. 지금까지는 H.323 기반의 VoIP 서비스 개발이 많이 이루어졌으나 최근에 대두되는 SIP는 파싱과 컴파일이 쉽고 확장성이 뛰어나며 text-based 이기 때문에 H.323에 비해 구현이 용이한 장점이 있다. 따라서 본 고에서는 VoIP의 시그널링 방법 중에SIP에 관해서 살펴본다. 인터넷 프로토콜 기반 네트워크에서 하나 이상의 단말 간에 멀티미디어 세션이나 콜을 생성, 변경, 종료할 때 쓰이는 SIP는 응용계층 제어 프로토콜로 이러한 세션에는 멀티미디어 컨퍼런스, 인터넷 텔레폰 콜, 원격 교육 등이 포함된다. SIP는 SMTP(simple mail transfer protocol), e-mail, HTTP(hypertext transfer protocol), 웹에 기반을 두고 모델링되었다. 이러한 SIP는 클라이언트가 request를 보내면 서버가 response를 보내는 클라이언트-서버 프로토콜이라고 할 수 있다. SIP는 response code architecture, message header, 전체 오퍼레이션 과정을 포함한 많은 부분에서 HTTP의 syntax와 semantics를 재사용하며 HTTP와 유사한 트랜잭션을 한다. 또한 HTTP, SMTP와 달리 SIP는 TCP나 UDP 상위에서 실행될 수 있다. SIP는 reliability를 보장하기 위한 메커니즘을 제공하며 UDP는 SIP 메시지를 멀티캐스트할 수 있다. 멀티캐스트를 함으로써 group invitation과 기본적인 ACD(automatic call distribution)이 가능하다. II. SIP의 특성 1. SIP의 메시지 SIP 메시지는 클라이언트에서 서버로 보내는 request와 서버에서 클라이언트로 보내는 response가 있다. (그림 1)에서 보듯이 SIP 메시지는 start line, header fields, message body로 구성되는데 다양한 header field는 콜 서비스, 주소, 프로토콜 특성에 관한 정보를 갖고 있다. SIP request는 INVITE, ACK, BYE, CANCEL, REGISTER, OPTION의 6가지 메쏘드로 구성이 된다[6-7].  INVITE는 클라이언트와 서버간에 콜을 개시하는 가장 기본이 되는 메쏘드로 사용자와 서비스가 세션에 참가하도록 하며, 발신자와 수신자의 주소, 콜의 주제, 콜의 priority, 콜 라우팅 request, 바람직한 response 특성을 포함한다. request의 body는 유니캐스트와 멀티캐스트 멀티미디어 세션을 기술하는 textual syntax인 SDP(Session Description Protocol)로 기술이 된다. SIP 서버로 location 정보를 전달하는 REGISTER는 SIP 서버가 incoming address를 outgoing address로 어떻게 매핑하는 지를 사용자에게 알려준다. BYE는 컨퍼런스에 참가한 사람들 간의 연결을 종료하고, OPTIONS은 착신자의 capability에 대한 정보를 가지고 있으며, ACK는 메시지 교환을 확인하고, CANCEL은 전송되지 않은 request를 종료한다. 수신자는 request 메시지를 받고 나면 SIP response 메시지로 응답을 한다. Response 상태 코드는 HTTP/1.1 response code와 유사하나 확장된 형태이며, 또한 모든 HTTP/1.1 response code가 그대로 적용되는 것은 아니다. Response 상태 코드는 1xx, 2xx, 3xx, 4xx, 5xx, 6xx 형태로 표현되는데, 1xx(Informational)는 request를 받고 그 request에 대한 처리를 계속하고 있음을 나타내고, 2xx(Success)는 action이 성공적으로 받아들여져 이해되었음을 의미한다. 3xx(Redirection)는 request를 완료하기 위해서는 또 다른 action이 필요하며, 4xx (Client Error)는 request가 bad syntax를 포함하거나 이 서버에서 수행될 수 없다는 것을 나타내고, 5xx(Server Error)은 서버가 명백히 유효한 request를 처리하지 못했음을, 6xx(Global Error)는 request가 어떤 서버에서도 수행되지 못했음을 나타낸다. 2. SIP, SDP, SAP간의 관계 SIP, SDP, SAP간의 관계는 IETF Transport Area의 MMUSIC 워킹 그룹에서 정의되었는데 SAP(Session Announcement Protocol)는 사용자에게 세션을 알리고 사용자가 세션에 참가할 수 있도록 하고, SIP는 사용자를 세션에 참가하도록 INVITE를 한다. 이 SIP 메시지는 header와 body로 구성되는데 이 SIP 메시지의 body는 SDP로 기술이 된다. SIP는 사용자가 멀티미디어 세션에 참가할 수 있도록 INVITE를 보내고, SAP는 SAP 헤더와 SDP로 구성된 announcement 패킷을 일정한 주소와 포트로 주기적으로 멀티캐스트해야 한다. SDP는 MMUSIC 워킹 그룹에서 정의된 RFC 2327[8]에 기술이 되어 있으며 세션 정보를 기술하는 포맷이라 할 수 있다. 멀티미디어 세션에서 미디어 스트림에 대한 정보를 전송하며  3. SIP의 네트워크 구성 요소 SIP 네트워크는 User Agent, Network Server, Registrar로 구성되는데, UA(User Agent)는 INVITE request를 보내서 콜을 개시하는 UAC(User Agent Client)와 SIP request를 받았을 때 사용자를 contact하는 어플리케이션인 UAS(User Agent Server)로 구성된다. 이 UAS는 콜을 accept하거나, redirect하거나 refuse한다. Network 서버는 proxy 서버와 redirect 서버로 구성되는데 proxy 서버는 다른 클라이언트를 대신해서 request를 하기 위해 클라이언트와 서버처럼 행동하는 매개 프로그램이다. proxy 서버는 request를 interpret하고, 필요하다면 request 메시지를 포워딩하기 전에 rewrite한다. redirect 서버는 콜을 새로운 location으로 redirect하는데, proxy 서버와 달리 SIP request를 개시하지 않고, user agent 서버와 달리 redirect 서버는 콜을 accept하지 않는다. Registrar는 REGISTER request를 받아들이는 서버로 대개 proxy 서버나 redirect 서버와 함께 위치하며 location 서비스를 제공할 수도 있다. 4. SIP의 오퍼레이션 SIP 오퍼레이션에서 SIP 서버는 incoming request를 처리하는 방법에 있어서 Proxy mode와 Redirect mode로 나눌 수 있다. 먼저 (그림 3)의 Proxy mode에서의 SIP 오퍼레이션을 살펴보면, proxy 서버는 INVITE request를 받아 그 request의 어드레스를 보고 location 서버를 contact하여 수신자의 정확한 location 정보를 얻는다. 그리고 proxy 서버는 location 서버에서 받은 어드레스로 SIP request를 보내고, request를 받은 UAS는 수신자에게 INVITE 메시지가 왔음을 알리고 proxy 서버에게 메시지를 잘 받았다는 응답을 보낸다. 그러면 proxy 서버는 UAC에게 OK 응답을 보내고, UAC는 proxy 서버에게 ACK 메시지를 보내며 proxy 서버는 UAS에게 ACK를 포워딩함으로써 메시지 전송이 성공적으로 이루어졌음을 확인한다. 여기서 ACK는 proxy 서버를 거치지 않고 수신자에게 직접 보내질 수도 있다.  redirect mode에서 SIP 오퍼레이션은 (그림 4)와 같이 이루어지는데 redirect 서버는 INVITE request를 받아 proxy 서버처럼 request의 어드레스를 보고 location 서버를 contact하여 수신자의 정확한 location 정보를 얻는다. redirect 서버는 새로 얻어진 어드레스로 수신자와 연결을 시도하지 않고 UAC에게 그 어드레스를 되돌려 주면, UAC가 서버에게서 되돌려 받은 어드레스로 새로운 request를 보낸다. 그리고 콜이 성공적으로 이루어지면 UAC와 UAS는 ACK를 주고 받는다.  III. IETF SIP 표준화 분석 1. IETF SIP 관련 워킹 그룹 구성 IETF는 2001년 6월 현재 9개의 표준화 영역(Applications Area, General Area, Internet Area, Operations and Management Area, Routing Area, Security Area, Sub-IP Area, Transport Area, User Services Area)으로 구성되어 있다. 이 중에서 SIP가 속해있는 표준화 영역은 Transport Area이며, Transport Area의 24개의 워킹 그룹 중에서 SIP와 관련이 있는 워킹 그룹은 Session Initiation Protocol(SIP), Multiparty Multimedia Session Control MMUSIC), IP Telephony(IPTEL), 그리고 지금은 종료된 PSTN and Internet Internetworking (PINT)가 있다[3, 9]. 가.Session Initiation Protocol(SIP) SIP 워킹 그룹은 현재 표준으로 제안된 RFC2543을 기반으로 SIP를 개발하고 있다. SIP는 사용자간에 상호 통신 세션을 개시할 때 HTTP와 SMTP와 유사하게 동작하는 텍스트 기반의 프로토콜이다. 이러한 세션에는 음성, 비디오, 채팅, 인터넷 게임, 가상현실 등을 포함한다. 이 그룹은 requirement가 있는 제안을 구체화하고 발전시킬 뿐만 아니라 SIP에 대한 제안을 draft standard로 향상시키고 SIP specification을 정의하고 확장하는 데 전념하고 있다. 또한 SIPPING 워킹 그룹을 포함한 다른 워킹 그룹에서 SIP의 일반적인 경향에 대한 requirement가 있을 때 SIP의 범주 안에 든다면 변화를 받아들일 것으로 보인다. SIP 워킹 그룹에서는 SIP에 의해 정의된 기본적인 모델과 아키텍처를 유지하기 위해 노력하고 있는데 특히 아래의 4가지에 중점을 두고 있다. - service와 feature는 가능하면 end-to-end로 제공된다. - extension과 새로운 feature는 특정 세션 타입에만 적용되는 것이 아니라 일반적으로 적용 가능해야 한다. - simplicity가 관건이다. - 기존의 IP 프로토콜과 아키텍처의 재사용, 다른 IP 어플리케이션과의 통합이 매우 중요하다. SIP는 MMUSIC 워킹 그룹에서 연구를 시작하여 SIP 워킹 그룹에서 MMUSIC과의 상호 커뮤니케이션으로 발전하고 있다. MMUSIC 워킹 그룹에서 1999년 3월에 RFC2543을 발표하였고 SIP 워킹 그룹이 MMUSIC 워킹 그룹에서 분리되어 2000년 6월에 RFC2543bis와 9월에 RFC2543bis-02를 발표하였다. SIP 워킹 그룹은 IPTEL 워킹 그룹의 Call Processing Language(CPL)를 수용하고 있으며, 분산 전화 서비스를 위해 Distributed Call Signaling Group(DCS)과의 협력을 고려하고 있다. 나. Multiparty Multimedia Session Control(MMUSIC) MMUSIC 워킹 그룹은 인터넷 teleconferencing session을 지원하기 위한 인터넷 표준 프로토콜을 개발하였다. MMUSIC은 오늘날 M-Bone에 퍼져있는 loosely-controlled 컨퍼런스를 지원하는 데 초점을 맞추고 있으나 tightly-controlled session을 운용하는 데 사용되는 일반적인 프로토콜 또한 지원한다. 여기에서 추진하고 있는 프로토콜은 다음과 같다. - distributing session descriptions: Session Description Protocol(SDP) and Session Announcement Protocol(SAP) - providing security for session announcements: SAP security - controlling on-demand delivery of real-time data: Real-Time Stream Protocol(RTSP) - Initiating sessions and inviting users: Session Initiation Protocol(SIP) - managing tightly-controlled sessions: Simple Conference Control Protocol(SCCP) MMUSIC 워킹 그룹은 MMUSIC의 architectural framework을 기술하고 ITU의 interoper-ability scenario와 인터넷 기반 teleconferencing system에 대한 초안 작성을 하고 있다. 또한, MMUSIC 워킹 그룹은 멀티미디어 컨퍼런스에 관련된 IETF의 다른 그룹들과의 협력뿐 아니라 ITU와의 상호운용 표준을 진행하고 있다. 이 워킹 그룹은 두 가지 목적을 가지고 있는데 단기적으로는 여러 프로토콜을 SDP, RTSP와 같이 Proposed Standard나 SAP와 같은 Experi-mental RFC status를 포함하여 이들에 대한 RFC를 작성하는 데 있고, 장기적으로는 기존의 프로토콜을 차세대 SDP를 위한 요구사항을 조사하여 SIP, SAP Security, SAP 와 같은 Proposed Standard status로 진보시키고, SCCP를 지속적으로 발전시키고자 하는 데 있다. 다. IP Telephony(IPTEL) 인터넷 텔레포니가 광범위한 서비스가 되기 전에 많은 프로토콜이 적절하게 사용되어야 하며, 이것은 시그널링과 capability exchange와 관련된 서비스를 제공하기 위한 많은 주변 프로토콜을 포함해야 한다. IP Telephony(IPTEL) 워킹 그룹의 주요 목적은 아래 내용의 프로토콜과 문서를 개발하는 것이다. - 콜 처리 syntax: 두 단말간의 콜이 셋업될 때 시그널링은 시그널링 메시지를 forwarding, redirect, proxying하는 H.323 게이트키퍼와 같은 여러 서버를 통해 처리된다. 예를 들면, 사용자가 특정 회사에 전화를 걸 때 콜을 개시하는 시그널링 메시지는 회사의 특정 서버에 도달한다. 이 서버는 발신자에게 수신자가 통화중이라는 사실을 알리고 사용자와 가까운 다른 서버에 콜 개시를 포워딩하거나 콜을 완전히 삭제한다. 따라서 개인의 이동성과 콜 에이전트 서비스가 가능해진다. - 이 그룹은 콜 처리 syntax에 의해 가능한 서비스를 서술하고 그 syntax가 어떻게 사용되는지에 대한 서비스 모델 문서화를 할 것이다. - Gateway Attribute Distribution Protocol : IP 호스트와 PSTN 사용자간에 콜이 성립될 때 텔레포니 게이트웨이가 필요하다. 이 게이트웨이는 해당 전화 번호 뿐 아니라 클라이언트 특성, 서비스 제공 특성, 게이트웨이의 유용성 등을 포함해야 한다. (호스트의 관리 도메인 밖에 있는 게이트웨이가 사용되면 프로토콜은 remote 도메인에 있는 게이트웨이가 PSTN connectivity, 제공되는 코덱 등의 어트리뷰트를 게이트웨이를 선택하는 다른 도메인에 있는 entitiy로 분배하도록 요구된다.) 이 프로토콜은 효과적인 대역폭, 안전한 전송을 보장하도록 디자인되어야 한다. 2. 워킹 그룹간의 관계 SIP는 MMUSIC 워킹 그룹에서 처음으로 연구를 시작하다가 MMUSIC 워킹 그룹에서 분리된 SIP 워킹 그룹이 그 활동을 이어왔다. SIP 메시지의 body를 기술하는 SDP가 MMUSIC워킹 그룹에서 개발되었고 또한 IPTEL 워킹 그룹의 Call Processing Language(CPL)은 SIP의 특징과 연관이 있다. 이처럼 SIP, MMUSIC, IPTEL 워킹 그룹은 상호 보완적으로 작용하고 있다. IV. SIP의 필요성 및 전망 1. Reliability 제공 메커니즘 클라이언트가 request를 재전송할 필요가 없는 Reliable Transport Protocol과 달리 Unreliable Transport Protocols은 Reliability를 위해 일정한 시간 간격으로 request를 재전송할 필요가 있다. INVITE, ACK, 그 외의 메쏘드에서 Reliability를 지원하기 위한 재전송 방법을 살펴본다. 가. Reliability for Request Other than INVITE UDP와 같은 Unreliable Transport Protocol을 사용하는 SIP 클라이언트는 첫번째 패킷을 전송한 후에 두번째는 T1초 후에, 다음 패킷은 2*T1초 후에, interval이 T2초에 도달할 때까지 INVITE나 ACK 이외의 request를 재전송해야 하며 다음 재전송은 T2초 간격으로 이루어진다. 이 때 클라이언트는 11개의 패킷을 모두 전송하거나 최종 response를 받으면 재전송을 중단한다. T1과 T2의 디폴트(default) 값은 각각 500ms와 4s인데 클라이언트는 디폴트보다 더 큰 값을 사용할 수 있으나 작은 값을 사용하면 안 된다. 나. Reliability for INVITE Requests SIP 클라이언트는 T1초로 시작하여 각 패킷을 전송한 후에 2배의 간격으로 INVITE request를 재전송해야 하며, 클라이언트는 최종 response를 받거나 7개의 request 패킷을 모두 전송하고 나면 재전송을 중단한다. UAC(User Agent Client)는 7번째 패킷을 재전송한 후에 BYE나 CANCEL request를 보낸다. 다. Reliability for ACK Requests ACK request는 response를 발생시키지 않고 INVITE에 대한 response가 도착할 때만 생성되며 transport protocol에 독립적으로 동작한다. 또한 ACK request는 original INVITE request와 다른 경로를 거칠 수 있다. 라. UDP 전송 메커니즘 비교 INVITE, ACK, 그 외의 메쏘드에서 Reliability를 지원하기 위한 재전송 메커니즘을 T1, T2의 디폴트 값인 T1 = 0.5, T2 = 4을 써서 표로 만들어 비교해 보았다. - 메커니즘 1(M1) 패킷 전송 : first 패킷 / 0.5 / 1 / 2 / 4 / 8 / 16 = 31.5초 (7번 전송) - 메커니즘 2(M2) 패킷 전송 : first 패킷 / 0.5 / 1 / 2 / 4 / 4 / 4 = 15.5초 (7번 전송) - 메커니즘 3(M3) 패킷 전송 : first 패킷 / 0.5 / 1 / 2 / 4 / 4 / 4 / 4 / 4 / 4 / 4 = 31.5초 (11번 전송) - 메커니즘 4(M4) 패킷 전송 : INVITE에 대한 response를 받을 때마다 ACK를 전송  2. SIP와 H.323과의 비교 ITU-T의 H.323과 IETF의 SIP는 RTP를 사용하여 Conference call과 Click-for-dial과 같은 인터넷 전화를 할 수 있다는 특징을 갖는 면에서 유사한 기능을 갖고 있으나 직접적인 연동은 불가능하다. 또한, H.323v2이상의 버전과 SIP에서는 Call Holding, Call transfer, Call forwarding, Call waiting 등을 제공하는데 H.323 버전과 SIP 기술을 <표 1>에 비교하였다[2].  H.323은 ASN.1(Abstraction Syntax Notation No. 1)을 사용하고, E.164번호 체계를 따르는 반면, SIP는 텍스트 기반의 인코딩 방식을 채택하였고, SIP URL(Uniform Resource Locator)과 E.164 모두를 사용한 번호 체계를 갖는다. SIPrfc2543bis는 SIPrfc2543에 비하여 Alert information, Caller/callee information, In-reply-to-caller등의 서비스를 추가로 제공하며, E.164번호 체계도 제공한다. Third Party Control은 콜에 참여하지 않고, 양측간에 호를 설정할 수 있는 기능으로 H.323 버전 3이상 및 SIP에는 제공하고 있다. Third Party Control 기능을 이용하여, 비서가 관리자에게 전화를 연결하거나, 상담원 연결, 오퍼레이터 서비스를 제공할 수 있다. Alert information은 일반 전화에서 사용되는 소리에 의한 전화 요청 이외에도 문자에 의한 전화 요청 사실을 알릴 수 있는 서비스이며 Caller/callee information은 발신 및 착신 가입자 정보(예: 발신가입자 번호 등)를 제공할 수 있는 서비스이다. In-reply-to-caller는 e-mail에서 응답e-mail을 보내는 것과 같이 호를 발신한 사람에게 응답해 줄 수 있는 서비스이다. SIP는 ASN.1을 사용하는 H.323과 달리 Text based http-like 프로토콜을 사용함으로써, 파싱 및 컴파일이 쉽기 때문에 복잡성이 적고, 확장성이 뛰어난 장점이 있다[11-13]. H.323 버전 2는 Fast Connect와 H.245 메시지 인캡슐레이션을 추가한 것이 특징으로, 이 2가지 추가한 기능으로 인하여 호 설정 시간이 단축되는 효과를 가져왔다. H.323 버전 3은 Third Party Call Control을 개선하였으며, H.323 버전 4는 Real-time facsimile T.38을 추가한 것이 특징이다. H.323 버전 5는 터미널 이동성(user mobility)과 서비스 이동성(service mobility)을 제공할 예정이다. 3. SIP의 전망 제 3세대 통신 시장을 주도하는 IMT-2000, 3GPP(Third Generation Partnership Project), ITU-T 지능망, ETSI 등에서 경쟁적으로 SIP를 도입하고 있다. 이처럼 SIP는 차세대 네트워크에서도 채택이 되고 있으며, H.323과의 Interworking으로 더욱 발전할 것으로 보인다. IMT-2000은 기본적으로 회선 교환 방식과 패킷 교환 방식을 모두 제공하며, 음성과 같이 실시간이 요구되는 서비스는 회선 교환 방식을 통해 제공하고, 데이터와 같이 실시간이 요구되지 않는 서비스는 패킷 교환 방식을 이용하여 제공한다. 그러나 패킷 교환망과 회선 교환망을 모두 갖는 IMT-2000망에 대한 비효율성과 회선 교환에서의 무선 자원 이용의 비효율성으로 인하여 차세대 이동통신의 망을 패킷 기반인 All-IP 망으로 통합하려는 움직임이 3GPP와 3GPP2와 같은 표준화 기관에서 진행되고 있다. 따라서 회선 교환 방식으로 연결하던 호 제어 부분을 대체할 프로토콜이 필요하며, 현재 관련 표준화 단체에서는 SIP를 표준으로 정하는 방향으로 진행되고 있다[5]. 3GPP 네트워크는 패킷 교환 도메인, 회선 교환 도메인, IP 멀티미디어 도메인으로 구성된다. 이 중에서 IP 멀티미디어 도메인에서 콜 시그널링은 SIP로 이루어지는데, 단말과 네트워크를 연결할 때와 네트워크 서비스 노드간 연결을 할 때 SIP를 사용한다. 3GPP에서 SIP를 채택함으로써 무선 단말과 인터넷의 통합이 가능하고 무선 단말기를 이용하여 개인의 컴퓨터를 사용하듯이 정보를 이용할 수 있게 된다[17]. ETSI(European Telecommunications Standards Institute)에서는 H.323과 SIP간의 inter-operability를 제공하기 위한 연구를 하는 TIPHON(Telecommunications and Internet Protocol Harmonization Over Networks)이 있다. 여기에서는 각각의 콜 시그널링 프로토콜에 독립적으로 동작하는 인터넷 프로토콜을 이용한 전화 서비스 구조를 채택했는데, 그 구조는 인터넷에 기반을 둔 네트워크 사용자가 PSTN, ISDN, GSM, SS7과 같은 네트워크에 있는 사용자와 통신이 가능하도록 하며, 이러한 VoIP 서비스는 ITU의 H.323과 IETF의 SIP에 기본을 두고 시스템이 구성될 것이다. TIPHON의 H.323과 SIP간의 interoperability 활동은 ITU와 IETF의 scalability, reliability, performance requirements에 초점을 맞춘 표준화 과정에서의 상호 협력뿐만 아니라 IMTC(International Multimedia Teleconferencing Consortium)와 같은 다른 그룹과의 협조로 발전할 것으로 보인다. V. 결 론 SIP는 인터넷 이용자들에게 친숙한 HTTP와 유사한 text-based 프로토콜로 H.323에 비해 파싱과 컴파일이 쉽기 때문에 확장성이 용이한 장점이 있다. 그러므로 H.323은 VoIP 사업자 위주의 ITSP(Internet Telephony Service Provider)용 프로토콜이라고 한다면, SIP는 이용한 인터넷 폰의 응용 영역과 사업 주체가 다양해 짐으로써 ITSP 사업자뿐만 아니라 Intra-VPN(Virtual Private network) 및 Extra-VPN 사용자, 콜센터, 인터넷 사용중 통화 시도 확인(Internet Call Waiting: ICW) 서비스, 개인별 홈페이지 전화 연결 서비스 등의 다양한 부가서비스를 제공할 것으로 예상된다. 또한 SIP를 차세대 네트워크에서 시그널링 프로토콜로 채택하여 발전시키고 있으며, VoIP 서비스의 발전을 위해서는 SIP와 H.323간의 interworking이 중요한 관건이 될 것이다. <참 고 문 헌> [1] 한국전자통신연구원, 정보통신기술경영연구소 기술경영연구시리즈 00-01 “인터넷 텔레포니 현황 및 전망,” 2000. 7, pp.5-6. [2] 김도영, 강태규, 김대웅, “VoIP 국내외 기술동향 및 발전전망,” 전자공학회지 제28권 제6호, 2001. 6, pp.73-79. [3] IETF, “Architectural Framework for Signaling Transport,” RFC 2719, 1999. 10. [4] 강태규, 김도영, “차세대 인터넷 서비스 고도화를 위한 IETF의 인터넷 지능망 표준화 동향 분석,” 한국전자통신연구원 주간기술동향 제 953호, 2000. 7. 4, pp.1-17. [5]
|
