overview sip

이번 글에서는 SIP에 대해서 살펴볼까 합니다 . SIP라고 하면 차세대 VoIP 표준 프로토콜이며, 현재 H.323 표준에서 SIP로
이전하고 있는 중입니다. 대부분의 VOIP 장비는 H.323 표준을 지원하고 있으며, 가장 호환성이 뛰어나서 대부분의 H.323 장비들간의
연동은 잘 이루어지고 있습니다. 그러나, 현재 VoIP 시장의 화두는 Unified Communications이며, 이는 단순한 전화 또는 영상
전달만으로 국한 되는 것이 아니라 기존의 모든 통신 수단을 하나로 묶고자 하는 진화방향입니다. 이 목표를 달성하기 위해 H.323은 그 한계점이
있습니다.  따라서, 처음부터 IP 관련 표준을 선도해 온 IETF에서 표준화된 SIP는 최상의 조건을 가지고 있다고 볼수
있습니다.  이러한 SIP에 대해 자세히 살펴보기 위해서는 RFC 3261를 확인할 필요가 있습니다. RFC 3261는 하나 또는 그
이상의 참가자와 세션의 생성, 변경, 종료에 대한 applicaton layer 프로토콜인 SIP에 대해 설명한 권고안입니다.

RFC 3261를 보다가 Overview of Operation 색션이 SIP를 쉽게 이해할 수 있도록 되어 있어 이부분을 정리를
하였습니다. 블로그의 "폴리콤 PVX와 HDX간의 SIP 화상 패킷 분석" 이 너무 어렵게 되어 있다는 말씀이 있어서, 이글을 먼저 읽고 그
글을 참조하는 것이 이해하는 데 도움이 되시리라 생각됩니다.

Overview of SIP Functionality

SIP는 멀티미디어 통신을 생성하고 종료하기 위한 5가지 요소를 살펴보면 다음과 같습니다.

• User Location : 통신에 참가할 단말을 결정
  
• User Availiability : 통신에 참여할 착신측의 통화 가능여부 결정
  
• User Capabilities : 통신간에 사용될 미디어 및 미디어 파라미터 결정
  
• Session Setup : 착신측 및 송신측에 세션 파라미터 생성
  
• Session Management : 세션의 종료 및 전환, 세션 파라미터 변경, 부가 서비스 연동

SIP는 위와 같은 5가지 요소 및 기능을 통해 멀티미디어 통신을 가능하게 하며, SIP은 UA(User Agent), Proxy
Server, Redirect Server, Registrar 등의 개체들로 이루어져 있습니다.

• UA (User Agent)
  접속요청 메시지를 송신할 때에는 클라이언트 형식(UAC, User Agent Client)으로
  동작하고, 접속요청 메시지를 수신하여 처리할 때에는 서버 형식(UAS, User Agent Server)으로 동작합니다. UA는 다른 UA와
  직접 연결을 설정하거나 Proxy/Redirect Server들의 도움으로 다른 UA와 연결을 설정하며, 호(呼, call) 상태를 저장하고
  관리합니다.
  
  
• Proxy Server
  UA로부터의 수신한 접속 요청 메시지를, 다른 도메인(domain)의 Proxy 혹은 Redirect
  Server로 전달하거나, 해당 도메인 내의 UA로 전달하는 기능을 수행하고 과금(billing)을 위한 정보들을 유지합니다.
  
  
• Redirect Server
  수신한 접속 요청 메시지를 다른 UA나 Proxy Server에게 직접 전달하지 않고, 접속 요청
  메시지를 보내 온 해당 UA나 Proxy Server에게 그들이 접속 요청 메시지를 재전송해야 할 UA나 Proxy Server의 주소를 알려
  주는 역할을 합니다.
  
  
• Registrar
  UA로부터 등록 요청 메시지를 수신하고 이를 SIP이 아닌 다른 별도의 프로토콜을 이용하여 Location
  Service를 제공하는 시스템에 저장합니다. (Location Service는 이 정보를 Proxy 혹은 Redirect Server에
  제공하여 접속 요청이 잘 전달될 수 있도록 합니다.)
  

SIP는 완벽한 멀티미디어 아키텍쳐를 구성하기 위해 다른 IETF 프로토콜과 함께 사용되는 컴포넌트라고 볼수 있습니다. 멀티미디어
아키택쳐는 다음과 같은 프로토콜을 포함하고 있습니다.

• RFC 1889 Real-Time Protocol (RTP)
  실시간 데이터 전송 및 QoS에 대한 피드백 제공
  
• RFC 2326 Real-Time Streaming Protocol (RTSP)
  스트리밍 미디어 전송을 제어
  
• RFC 3015 Media Gateway Control Protocl (MEGACO)
  Public Switched
  Telephone Network(PSTN)과 IP 네트워크간의 연동을 위한 게이트웨이 제어
  
• RFC 2327 Session Description Protocol (SDP)
  멀티미디어 세션 파라미터 정의

위와 같이, SIP는 IETF의 멀티미디어 아키택쳐 가운데 하나로 사용자에게 완벽한 서비스를 제공하기위해서는 다른 프로토콜과 결합하여
사용되어야 합니다.


SIP는 서비스를 제공하지 않고, 서비스를 구현하기 위해 사용될 Primitives (매개 변수)를
제공합니다. 예를 들면, "발신자 정보 표시 서비스"가 구현될 때, SIP가 서비스를 제공하는 것이 아니라 Primitives에 의해 
단순히 SDP에 의해 세션 정보를 전송할 뿐입니다. 따라서, 이 서비스가 이 값을 이용하여 구현하는 것입니다. 따라서, 이 Primitives는
여러 다른 서비스에 의해 사용될 것입니다.

onclick="toggleMoreLess(this, '85_0',' more.. ',' less.. '); return false;">more..

Overview of Operation - Basic Call Flow

다음의 간단한 예를 통해 살펴보겠습니다. 엘리스는 소프트폰을 가지고 있으며, 밥은 SIP 전화기를 가지고 있습니다. 엘리스가 밥에게 전화를
거는 상황입니다.  또한 최소한의 파라미터만을 가지고 교환하는 것으로 합니다.

href="http://cfs4.tistory.com/upload_control/download.blog?fhandle=YmxvZzExNDAzOUBmczQudGlzdG9yeS5jb206L2F0dGFjaC8wLzE4MDAwMDAwMDAwMS5wbmc="> height=873
src="http://cfs5.tistory.com/upload_control/download.blog?fhandle=YmxvZzExNDAzOUBmczUudGlzdG9yeS5jb206L2F0dGFjaC8wLzE4MDAwMDAwMDAwMy5wbmc=">

엘리스는 atlanta.com의 Proxy Server로 INVITE 메세지를 아래와 같이 전송합니다 .첫줄은 INVITE 매쏘드와 URI
(Uniform Resource Identifier)를 나타내고 있으며, 메일 주소 체계와 비슷합니다.

href="http://cfs5.tistory.com/upload_control/download.blog?fhandle=YmxvZzExNDAzOUBmczUudGlzdG9yeS5jb206L2F0dGFjaC8wLzE4MDAwMDAwMDAwNC5wbmc="> height=364
src="http://cfs4.tistory.com/upload_control/download.blog?fhandle=YmxvZzExNDAzOUBmczQudGlzdG9yeS5jb206L2F0dGFjaC8wLzE4MDAwMDAwMDAwMi5wbmc=">

• Via
  엘리스가 INVITE 요청에 대한 응답을 받고자하는 주소를 나타냅니다.
  
• To
  Display Name인 "Bob"과 실제 연결되어야 할 SIP URI를 나타냅니다.
  
• From
  Display Name인 "Alice"와 실제 요청한 SIP URI를 나타냅니다.
  
• Call-ID
  이 호를 위한 global unique identifier 를사용하며, 일반적으로 호스트 네임 또는 IP
  address와 랜덤 스트링을 결합하여 생성됩니다. 따라서, To/ From/ Call-ID가 결합으로 엘리스와 밥간의 Pee-to-peer
  SIP 관계를 정의합니다.
  
• Cseq
  Commnad Sequence는 정수와 메쏘드 이름을 포함합니다. 새로운 요청마다 증가합니다.
  
• Contact
  SIP URI를 포함하며, 엘리스에게 접근할 수 있는 직접적인 경로를 나타냅니다. 일반적으로 FQDN (Fully
  qualified domain name)을 사용합니다. 그러나 많은 경우 도메인 네임으로 등록하지 않기 때문에 IP address가 선호됩니다.
  Via 헤더 필드가 요청에 대한 응답 경로를 나타내고, Contact 헤더 필드는 미래의 요청을 보낼 경로를 말합니다. 조금 어렵게 되어 있는
  데요. 요청에 대한 응답은 Via 헤더 필드를 참조하며, 신규 요청을 생성할 경우는 Contact 헤더 필드를 참조한다는 것입니다.
  

미디어 타입, 코덱, 샘플링 속도 등은 SDP를 통해 전송되므로 여기에서는 설명하지 않습니다. 이에 대해서는 RFC 2327 SDP를
참조하시거나, 블로그의 "폴리콤 PVX와 HDX 간의 SIP 화상 통신 패킷 분석"이라는 글을 참조하시기 바랍니다.

INVITE 메소드는 atlanta.com의 SIP Proxy Server로 전송됩니다. 실제 엘리스는 밥의 위치를 알수가 없습니다.
Proxy Server는 요청을 받은 후에 100 Trying 메세지를 엘리스에게 전송하며, 이 메세지의 의미는 정확하게 엘리스의 INVITE
메소드를 수신했으며, 이 메세지를 밥에게 보내기위해 처리중임을 나타냅니다.  atlanta.com의 SIP Proxy Server가
biloxi.com SIP Proxy Server로 메세지를 전송하기 전에 INVITE 메세지내의 Via 헤더 필드에 자신의 주소를 추가합니다.

biloxi.com의 SIP Proxy Server는 INVITE 메세지를 수신 후 100 Trying 을 전송하고, 밥의 IP
address를 확인한 후 Via 헤더 필드에 자신의 주소를 추가에게 밥에게 전송합니다.

INVITE 메세지를 수신 후 밥의 전화기는 링을 울리게 되고, 180 Ringing을 biloxy.com의 SIP Proxy
Server로 전송하여 역방향으로 메세지가 엘리스에게 전송되며, 엘리스는 Ringback tone을 듣게 됩니다.

밥이 수화기를 들게 되면, 200 OK with SDP 메세지가 엘리스에게 전송됩니다.

href="http://cfs4.tistory.com/upload_control/download.blog?fhandle=YmxvZzExNDAzOUBmczQudGlzdG9yeS5jb206L2F0dGFjaC8wLzE4MDAwMDAwMDAwMy5wbmc="> height=500
src="http://cfs6.tistory.com/upload_control/download.blog?fhandle=YmxvZzExNDAzOUBmczYudGlzdG9yeS5jb206L2F0dGFjaC8wLzE4MDAwMDAwMDAxNC5wbmc=">

200 OK 메세지를 살펴보면, Via, To, ,From, Call-ID, CSeq 헤더 필드는 INVITE메세지로 부터 복사합니다.
Contact 필드는 밥에 의해 변경되어 미래의 요청에 사용될 것입니다.

엘리스의 전화기는 200 OK를 수신 후 Ringback tone 생성을 중지하고, 밥이 수화기를 들었음을 알립니다. 엘리스의 전화기는
ACK (acknowledgement) 메세지를 송신합니다. 위의 Call Flow를 다시 보시면, 엘리스 전화기의 200 OK 메세지가 직접
밥의 전화기로 전송되는 것을 알수 있습니다. 엘리스와 밥의 전화기는 Contact 헤더 필드를 통해 서로 상대방의 주소을 교환하였기에
발생합니다. 두개의 SIP Proxy Server는 더이상 호를 추적할 필요가 없으므로, Call Flow에서 제외되는 것입니다. 이것이 SIP
세션 설정을 위한 "three-way handshake"입니다.

이제 엘리스와 밥은 SDP에 의해 협상된 파라미터를 통해 미디어 세션이 시작될 것입니다. 일반적으로 이또한 엘리스와 밥간의 직접 교환되며,
Proxy Server는 제외됩니다.

만일, 미디어 세션에 대한 파라미터 변경이 필요할 경우 re-INVITE 메세지가 전송되고, 상대방은 200 OK를 전송하여 새로운 협상에
동의함을 표시하고, 동의하지 못할 경우 488 (not acceptable here) 에러를 전송합니다. 그러나, re-INVITE의 fail은
기존에 연결된 호에 대해서는 영향을 미치지 않습니다.

만일, biloxi.com Proxy Server가 단말간의 SIP Signaling 메세지를 모두 확인하고 싶어할 경우, 즉, 메세지가
SIP Proxy Server를 경유하도록 하고 싶다면, INVITE 메세지내의 Record-Route 라우팅 헤더 필드를 추가할 수 있습니다.
mid-call feature를 제공하는 SIP Proxy Server에 유용하게 사용됩니다.

Overview of Operation - Registration

SIP에 있어서 등록과정은 필수적인 요소이다. 기본적으로 Peer-to-peer Protocol이므로 SIP Proxy Server는
옵션이지만, 단말의 숫자가 증가할 경우 모든 경로에 대한 정보를 단말이 보유하는 것은 불가능하므로 일반적으로 SIP Proxy Server
(일반적으로, Registra Server와 함께 구현됨)를 사용하며, 단말들은 등록과정을 진행합니다. 등록과정을 통해 SIP Proxy
Server는 단말의 현재 위치를 확인할 수 있습니다. 즉, address-of-record URI와 Contact address를 바인딩하는
것입니다.

단말은 REGISTRATION 메세지를 SIP Proxy Server에 전송하여 200 OK를 수신하는 것으로 등록 과정이 진행됩니다.
등록 시 밥은 집전화와 사무실 전화를 동시에 등록할 수 있으며, 한 명 이상의 사용자가 동시에 하나의 전화기에 등록될 수 있습니다.

Registration 메세지에는 다음과 같은 헤더 필드를 포함합니다.

• Request-URI
  등록시에 사용되는 위치서비스의 도메인으로 "sip:chicago.com" 으로 표시된다. SIP URI의
  @이나 userinfo가 표시되어서는 않됩니다.
  
• To:
  address-of-record는 SIP URI로 표시되어야 하며, 등록 신청,변경, 의뢰에 대한
  address-of-record를 포함합니다.
  
• From:
  등록에 대한 응답되는 address-of-record를 포함하며, 일반적으로 To 헤더 필드와 내용이 동일하다.
  
• Call-ID
  하나의 UAC로 부터의 모든 등록 메세지는 같은 Call-ID를 가집니다.

Capability Negotiation

Capability Negotiation는 SDP를 통해 이루어집니다. INVITE with SDP 로 밥이 엘리스에게 전송하면, 엘리스는
밥에게 200 OK with SDP로 응답하여 two-phase 협상이 이루어 집니다. 이 과정을 통해 기본적인 협상이 성립됩니다. 즉,
엘리스가 제시하고, 밥이 응답하는 형식을 취하는 것입니다.

마치며...

지금까지 간단하게 나마 RFC 3261를 살펴보았습니다. 이외에도 다수의 내용이 있으나, 제가 Overview of Operation
부분과 Registration 부분에서만 주요 내용을 발췌하여 정리하였습니다.

2008/02/01 - [UC Solutions] - 폴리콤 PVX
와 HDX 간의 SIP 화상 통신 패킷 분석

-------------------------
라인하트
CCIEV
#18487
href="mailto:linecard@naver.com">linecard@naver.com

id=callbacknestwwwnexpertnet85538
style="FLOAT: left; WIDTH: 226px; HEIGHT: 196px">

Posted by 라인하트