VoIP 전화기용 표준, ‘이제는 SIP’ (퍼옴)

VoIP 전화기용 표준, ‘이제는 SIP’

등록일 : 2003.06.16
출   처 : NETWORK TIMES 2003년 06월호
작성자 : Network Computing  



아직 IP 네트워크에 음성을 추가하지 않았다 하더라도 SIP(Session Initiation Protocol), 즉 세션 초기화 프로토콜을 만나기까지 그리 오래 걸리진 않을 것이다. SIP는 하나의 IP 네트워크에서 세션을 수립하고 해체하는 신호 프로토콜로, 엔드유저를 다집단 음성 및 화상회의로 로케이팅 및 연결해주는 VoIP 전화기용 표준으로 가장 잘 알려져 있다.
SIP가 아직 현실적이지 않다는 생각은 잘못이다. SIP는 현재 존재하고 있으며 잘 사용되고 있다. 이 글을 쓰는 동안, 필자는 본에이지(Vonage)의 소비자 SIP 서비스와 어댑터를 테스트해 보았으며, 이것은 고품질의 지역, 국내 및 국제 전화 서비스를 저렴한 가격에 제공해주었다. 그리고 하이엔드 쪽에서는 브로드소프트(BroadSoft)가 표준 기반 VoIP, 참석, 음성 메일 및 통합 메시징(SIP가 의도하는 모든 것)을 제공할 수 있도록 서비스 사업자들에게 서버와 애플리케이션 패키지를 판매하고 있다.


SIP는 다재다능

HTTP와 마찬가지로, SIP는 다재다능하며 사용이 간편하다. 이것은 협업 멀티미디어 회의 및 음성 지원 전자상거래를 수립할 수 있다. 지금은 비록 거의 모든 기업용 VoIP 업체들이 자신들의 전용 시그널링 솔루션에 포함시키는 수준이지만 SIP는 2년 안에 VoIP 이행에서 일반화될 것이다. IETF는 1999년 SIP의 첫 버전인 RFC 2543을 발표했으며, 가장 최근에는 지난 6월 RFC 3261을 내놓았다.

SIP는 레거시 네트워크에 있던 전통적인 음성용 종단간 회선을 인터넷 상의 세션이 대체하게 되는 VoIP용으로 이상적이다. ITU의 H.323 멀티미디어 표준뿐만 아니라 일부 업체 전용 VoIP 전화기들도 이런 기능이 있다. SIP가 등장하기 이전에 제품을 만들었던 VoIP 업체들은 H.323을 채택했다. 하지만 SIP는 H.323보다 이행이 간단하며, 오버헤드가 더 작고 가벼운 프로토콜이다.

하지만 SIP는 기존의 전화기 접속을 보다 표준에 가깝게 대체해 주기 때문에, 참석(presence)과 같은 진보된 멀티미디어 서비스를 이행하기가 더 쉽다. 이것은 사용자가 특정 전화기뿐만 아니라 비디오나 인스턴트 메시징(IM) 세션에서 호출을 받을 수 있는지, 그리고 받기를 원하는지 여부를 즉시 파악할 수 있게 해준다. 또한 VoIP 호출에서 여러 개의 목적지로 호출을 보낼 수 있다.

그리고 SIP는 상용화의 길을 개척하고 있다. XO OS에 함께 포함된 마이크로소프트의 윈메신저(WinMessenger) IM 프로그램은 SIP를 기반으로 하고 있다. 윈메신저는 또한 SIP를 이용해 인터넷 전화 호출을 하고 있다. 향후 3G 무선랜 또한 호출의 설정 및 해제용으로 SIP를 사용할 것이다.

하지만 SIP가 실제로 할 수 있는 일에 대해서는 여러 가지 오해가 많다. 예를 들어 SIP는 디지털 음성을 전송하지 않으며, 이 일은 RTP(Real-Time Transport Protocol)의 몫이다. RTP는 SIP가 호출을 수립한 다음 음성을 전송해준다. 그리고 SIP가 다양한 코덱과 기술을 이용해 음성, 텍스트 메시징, 혹은 비디오 세션을 수립할 수 있으려면 그 전에 세션에 있는 장비가 어떤 기능을 지원하는지를 파악해 두어야 한다. 여기서 바로 세션 디스크립션 프로토콜(Session Description Protocol: SDP)이 개입되는데, SIP는 이 SDP를 이용해서 잠재적 대화의 두 종단지점들 사이의 능력을 협상한다.


‘초대받으셨습니다’

SIP는 전송 수단으로 UDP(User Datagram Protocol)나 TCP를 사용할 수 있지만, 포트 5060에 있는 UDP를 기본값으로 사용한다. UDP와 같이 믿을 수 없는 프로토콜에 의해 SIP 패킷이 유실되면, SIP는 일단 응답을 충분히 기다렸는지 결정한 후 명령어를 재전송한다.

SIP가 다른 종단지점으로 보내는 가장 일반적인 명령어는 ‘인바이트(invite)’다. SIP 전화기는 UA(User Agent)가 다른 SIP 전화기나 UA로 접속하고 싶을 때 이 초대 명령어를 보낸다. 초대가 성공하면 보냈던 곳(originator)으로 ‘200’이란 응답이 오는데, 이것은 모든 것이 OK며 세션이 수립됐음을 의미한다.

HTTP나 SMTP와 마찬가지로, SIP는 평문이기 때문에 명령어를 파싱(parsing)하기가 더 쉽다. 그리고 어떠한 프로토콜 분석기든 간단한 ASICC 번역으로 실제 명령어와 응답을 보여줄 수 있다.

SIP 헤더에는 인바이트와 함께, e메일 메시지와 유사하게 ‘투(to)’와 ‘프롬(from)’ 주소가 포함돼 있다. 이런 주소들은 URI(Uniform Resource Identifier)로 불리며, 다음 예처럼 e메일 주소와 비슷한 모습이다:


sip:peter@nwc.com

URI에서 ‘투(to)’필드에는 표준 전화번호가 들어갈 수 있다. SIP 헤더에는 또한 ‘콜 ID(call ID)’가 포함되는데 이는 SIP 트랜잭션을 구분해주는 고유의 숫자며, ‘비아(via)’ 필드는 UA에게 초기 접속을 협상할 때 응답을 보내기 위해 어떤 IP 주소를 사용할지를 말해준다.

일단 세션이 수립되면, ‘컨택트(contact)’ 필드가 사용되는데 이것은 수신 UA가 송신 UA와 대화할 때 사용하는 목적지를 뜻한다. NAT(Network Address Translation)가 배치되면 종단지점에서는 SIP 계층에 삽입된 라우팅이 불가능한 NAT 주소를 회신 주소로 사용한다. 하지만 SIP 업체들은 다양한 것들을 이용할 수 있다. 즉 예를 들어 SIP 장비는 SIP 헤더에 있는 IP 주소를 바꾸기 위해 IP 패킷의 목적지 주소를 사용할 수 있다. SIP 지각 방화벽은 NAT를 이용해 SIP 헤더에 있는 IP 주소를 바꿀 수 있다.

인바이트 요청은 SDP 신택스를 이용해 UA에게 호출자의 매체 능력(media capabilities)을 알려준다. 호출된 집단이 대답을 하면 이것은 OK 메시지로 응수하며, 여기에는 또한 지원되는 매체 능력이 포함돼 있다.

필요한 서버들

일부 SIP 전화기들은 서로 직접적으로 호출을 할 수 있지만, 확장성을 원한다면 서버가 필요하다. SIP 서버는 디렉토리 정보와 호출된 집단의 위치를 지속적으로 추적해준다. 몇몇 SIP 서버가 있으며, 이들은 모두 같은 서버나 자체 하드웨어 플랫폼에서 가동될 수 있다.

SIP 프록시 서버는 SIP 전화기나 UA의 요청을 처리한다. 이것은 발신자 대신 수신자에게 접속을 초기화하며 이것이 200 OK 응답을 받을 때까지 루프 안에 머문다. 프록시 서버는 ‘비아’ 필드에 자신의 IP 어드레스를 두기 때문에, 목적지 클라이언트는 응답을 어디로 보내야할지를 알게 된다. 그러면 프록시는 응답을 다시 발신자에게 보내준다. ‘컨택트’ 필드의 주소는 UA들간의 직접적 통신에 사용된다.

프록시 서버가 인바이트 요청을 전달하면, 이것은 즉시 ‘100’이나 ‘트라잉(trying)’이라는 상황 메시지를 돌려보낸다. 이것은 호출자에게 자신이 인바이트 요청에 의해 작업 중임을 통보해 주는 메시지다. 프록시 서버는 목적지 UA를 로케이팅해서 여기로 인바이트를 보내고 나면 송신자에게 180 ‘링잉(ringing)’을 보낸다. 수신자는 대답을 하면서 프록시 서버로 200 응답을 보내며, 그러면 프록시 서버는 원래의 UA로 메시지를 전송한다.

발신자는 그러면 ‘ask’ 응답을 목적지 클라이언트로 보냄으로써 자신이 200을 받았다는 사실을 클라이언트가 알게 해준다. 그 이후의 모든 통신은 클라이언트들간에 일어나며 RTP가 UA들간의 디지털화된 오디오 전송을 책임진다. 호출이 완료되면 ‘바이(bye)’메시지가 다른 UA로 전송되며, 여기서는 다른 200로 응답한다.

프록시 서버는 호출이 완료되면 루프에서 벗어나오는 게 기본이지만, 주변에 그대로 있게 구성될 수도 있는데, 그 방법은 프록시 서버가 UA와 통신을 할 때 ‘컨택트’ 필드에 자신의 주소를 삽입시킴으로써 UA로 하여금 발원 UA 대신 프록시 서버로 나머지 응답을 돌려보내도록 UA에게 강요하는 것이다. 호출 동안 프록시가 포함되도록 유지함으로써 호출 기간 동안 추적이 가능한 곳에서 세부사항 보고서를 만들 수 있다. 이것은 또한 보안을 목적으로 종단지점에 대한 네트워크 세부사항들을 숨길 수 있게도 해준다.

요청과 호출 설정은 또한 여러 프록시 서버들을 통과할 수 있다. 예를 들어 하나의 프록시 서버가 목적지 UA로 접속할 수 없으면 다른 프록시 서버로 요청을 보내며, 이 프록시 서버에서는 그러면 UA를 로케이팅하거나 로케이팅 시도를 한다.

방향조정(redirect) 서버도 또한 있는데, 이 서버는 UA나 프록시 서버로부터 요청을 수신할 수 있다. 방향조정 서버는 자체적으로 접속을 만들지는 못하며, 원래 요청을 재시도할 곳에 대한 정보로 응답을 해줄 뿐이다. 이것은 프록시 서버에 큰 부담을 추가하지 않으면서 필요로 하는 정보를 UA에게 신속하게 줄 수 있는 방법이기도 하다.


어렵지 않게 보장

SIP 게이트웨이 서버는 VOIP 세계와 PSTN 사이를 번역해주기 때문에, 조직 외부에서 호출을 반들 수 있다. 예를 들어 게이트웨이는 내부 PBX로 레거시 접속을 제공하거나, 혹은 PSTN으로 곧장 간다. 이것은 SIP 신호를 레거시 전화기가 이해할 수 있는 어떤 것으로 바꿔주며, RTP 트래픽을 전환하는 코덱을 갖고 있기 때문에 레거시 회선에서, 혹은 이 회선으로 전송될 수 있다.

조직들간에 호출을 하는 대부분의 VoIP는 PSTN을 통해 갈 것인데, 그 이유는 인터넷용의 글로벌 디렉토리 서비스가 없기 때문이다. 향후에는 ENUM(E.164 넘버 RFC 2916)이란 프로토콜이 DNS를 이용해 인터넷 기반 디렉토리 서비스를 제공하게 될 것이며, 이것은 서로 다른 조직이나 회사들 사이에서 호출을 할 수 있게 전화번호를 추적해줄 것이다.

프록시 서버를 사용하고 있다면 레지스터 서버(register server)가 필요하다. 예를 들어 재택근무자가 VoIP 전화기를 꽂으면 이 장비는 레지스터 서버에 상대방의 로케이션을 말한다. 호출이 이루어질 때 사용 가능한 SIP 게이트웨이가 있는 한 레지스터 서버로 여러 전화기를 등록할 수 있다.

SIP의 이동성 지원은 가장 약한 부분 중 하나다. 예를 들어 SIP 프록시 서버는 인바이트 요청을 받으면 각각의 장비에 순차적으로 접속할 수도 있고 모든 장비에 동시에 접속할 수도 있다. 레지스터 서버는 등록된 사용자의 로케이션 정보를 로케이션 서버에 저장해두며, 이것은 물리적으로 동일한 서버에 상주할 수 있다. SIP 프록시 서버는 UA를 찾기 위해 로케이션 서버에 자문을 구한다.

두려움을 떨치고 SIP를 잡으라. 그리 어렵지는 않으리라 보장한다.



SIP 해부

헤더

To: 목적지 UA(User Agent)나 종단지점의 URI(Uniform Resource Identifier) 포함
From: 디스플레이 이름과 요청을 보내는 UA의 URI 포함
Contact: 일단 호출이 수립되고 난 후 목적지 UA가 요청 UA로 접속하는 데 필요한 정보
Via: 사용될 전송 프로토콜과 SIP 버전 포함. 송신자가 그 요청에 대한 응답을 받을 수 있게 보장하는 IP 주소도 또한 포함. 호출시 각 프록시 서버는 비아 필드에 자신의 IP 주소를 넣음으로써 응답이 이 곳을 통해 가도록 한다.

명령어

INVITE: SIP가 다른 종단지점으로 호출을 만들어내는 데 사용하는 주요 명령어
REGISTER: SIP 종단지점이 그 현재 로케이션의 등록 서버를 알리는 데 사용하는 명령어

서버

프록시 서버: 요청을 만들고 UA를 대신해 접속을 수립한다.
리다이렉트 서버: 요청에 응답해 UA로 대체 로케이션 정보를 제공하지만, 접속 설정에는 관여하지 않는다.
레지스트레이션 서버: 전화기와 같은 SIP 장비에 의해 현재 로케이션 등록에 사용된다.
로케이션 서버: 로케이션 정보를 데이터베이스에 저장. 보통 레지스트레이션 서버와 같은 물리적 서버에 상주한다.

[출처] VoIP 전화기용 표준, ‘이제는 SIP’ |작성자 까미유