SIP 기본 통신 - 첫번째 이야기

SIP (Session Initation Protocol)

 

인터넷에서 많은 어플리케이션들이 사용되고 있는데, 그 중에는 상대방과 세션을 형성하고 데이터를 주고 받아야 하는 어플리케이션이 있다. 음성, video 등의 멀티미디어 데이터를 실시간으로 전송하기 위해서 다양한 프로토콜들이 개발되었다. SIP(Session Initation Protocol)은 이러한 실시간 멀티미디어 전송 프로토콜들과 함께 사용되어 엔드 유저들이 세션을 형성하여 데이터를 주고 받을 수 있도록 해 준다.

 

SIP는 인터넷 전화와 같은 멀티미디어 세션을 수립하고, 수정하며 종료하는 어플리케이션 계층 제어 프로토콜이다.

또한 SIP는 다른 사람(participants)을 이미 형성되어 있는 세션에 초대(invite)하는 기능도 있다. (multicast conferences)

 

SIP는 멀티미디어 통신 수립 및 종료 등을 지원하는데, 이를 위한 5가지 요소는 다음과 같다.

 

User location : 통신에 사용될 단말을 결정

User availability : 통신 참여 의사를 (통화 가능 여부) 결정

User capabilities : 통신에서 사용될 미디어나 미디어 파라메터를 결정

Session setup : "ringing", 수신측 및 송신측에 세션 파라메터 생성

Session management : 세션의 종료, 전환, 세션 파라메터 수정, 서비스 로딩, 부가 서비스 연동

SIP는 이 5가지 요소의 기능을 통해 멀티미디어 통신을 가능하게 한다.

다음은 RFC 3261에 나오는 앨리스-밥의 SIP 통신 내용이다.

 

일단 앨리스는 PC의 SIP 프로그램을 이용하여 밥에게 전화를 하고, 밥은 SIP 전화기를 이용하여 전화를 받는다.

앨리스가 밥에게 전화를 걸 때는 밥의 SIP 식별자, 즉 SIP URI를 사용한다. SIP URI는 email 주소와 비슷한데, 일반적으로 사용자 이름과 호스트명으로 구성되어 있다. 지금의 경우 밥의 SIP URI는 sip:bob@biloxi.com 이다. 여기서 biloxi.com은 밥의 SIP 서비스 공급자 도메인을 나타낸다. (이메일 주소와 정말 동일하다!)

전화를 거는 앨리스의 경우에는 sip:alice@atlanta.com 이라는 SIP URI를 가지고 있다.

아, SIP 는 Secure URI, 즉 SIPS URI도 제공한다.!! 이때는 주소가 sips:bob@bioxi.com 과 같은 형식이 된다. 이 경우에는 TLS 를 사용하여 암호화 된 패킷을 전달하게 되는 것이다. (웹에서 HTTP 프로토콜 대신 HTTPS프로토콜을 사용하는 것과 동일한 원리이다.)

 

이처럼 HTTP 와 비슷하게 생긴 SIP는, 말그대로 HTTP 통신처럼 request/response를 주고 받는다. 이때, 한 개의 요청에 따른 서버의 응답은 최소한 1개가 된다.(넘을 수도 있다.)

지금 앨리스-밥의 경우를 보면, 앨리스는 먼저 INVITE 요청을 Bob의 SIP URI로 전송한다. 여기서 INVITE라는 메세지는 SIP method중 하나인데, 밥이 전화를 받도록 하기 위해 전화를 거는 요청을 말한다. 이 INVITE 요청은 메시지에 몇가지 정보를 더하기 위해 몇개의 헤더를 포함한다. (HTTP에 있는 그런 헤더 필드이다!) 물론 다른 메소드에도 상황에 맞는 헤더 필드들이 존재한다.

INVITE 요청 헤더에 포함되는 내용은 Unique한 콜 ID, 목적지 주소(밥의 주소), 송신자의 주소(앨리스의 주소), 앨리스가 밥과 수립하기 위한 세션 타입에 대한 정보 등이다. INVITE메세지를 실제로 보면 다음과 같다.

 

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

 

(Alice’s SDP not shown)

 

첫번째 줄에는 "INVITE"라는 메소드 이름이 우선 표시된다. (HTTP에선 GET/POST 같은 것들이 들어간다.)

메소드 옆에는 받는 사람(밥)의 주소와 SIP 프로토콜 버전이 들어간다. 앨리스는 2.0을 쓰고있다 ㅎㅎ

Via 헤더는 엘리스가 이 요청에 대해 받고자 하는 응답이 들어오는 주소를 알려준다. 밥이 응답을 하면 Via 헤더에 있는 주소를 거쳐 앨리스에게 응답이 들어오게 된다.

To 헤더는 밥의주소, 즉 받는 사람의 주소가 들어간다.

From 헤더는 보내는 사람의 주소가 들어간다. 여기서 tag필드에 소프트 폰에 의해 무작위로  생성된 문자열이 들어가게 된다.

Call-ID필드에는 이 콜에 대한 유일한(unique) ID가 입력된다.

CSeq (Command Sequence) 에서는 정수와 메소드명이 들어간다. 새로운 요청이 발생될 때마다 숫자는 증가된다.

Contact 는 앨리스의 SIP (또는 SIPS) URI가 기록된다. 이 주소는 앨리스에게 접근할 수 있는 직접적인 주소이며, 일반적으로 FQDN(Fully qualified domain name)을 사용한다. 도메인이 DNS에 등록되지 않은 경우에는 IP주소가 사용되기도 한다.

마지막으로 Content-Type 헤더는 메시지 Body의 타입을 기술하며, Content-Length는 body의 길이를 나타낸다.

 

그런데 여기서, 전화 통신에 사용되는 media, codec, 샘플링 간격 등은 SIP에 기술되지 않는다. 이때 사용되는 프로토콜은 SDP(Session Description Protocol)이다.

 

 

다시 본론으로 돌아와서,

앨리스가 보낸 INVITE 요청은, Bob의 주소로 도착을 해야 하는데, 이 주소를 찾기 위해 일단 앨리스의 도메인 서버인 atlanta.com으로 먼저 보내진다. 여기서 SIP 서버인 atlanta.com은 proxy server인데, 이 proxy server는 SIP의 요청을 받아 그 요청을  목적지로 forwarding 한다.(이때 프록시 서버가 요청하는 것 처럼 보인다.)

이 예제에서, proxy 서버는 INVITE요청을 받고, 앨리스에게 100(Trying)응답을 보낸다. 100 응답은 받은 INVITE요청이 전송중이라는 것을 의미한다. 그리고 밥의 도메인인 biloxi.com 서버를 찾아 그 서버에게 INVITE 요청을 한다.

그런데 이 때, proxy server는 자신의 주소를 VIA 헤더에 붙이고 전송한다.(올때 거쳐서 와야 하기 때문에) 밥의 서버인 biloxi.com 서버는 INVITE 요청을 받고  앨리스의 서버인 atlanta.com proxy server에게 100 응답을 전송한 뒤, 밥에게 INVITE요청을 한다. (물론 이 서버의 DB에는 Bob의 IP주소가 있을 것이다.) 이 때에도 역시 밥의 서버인 biloxi.com 서버는 자신의 주소를 VIA 헤더에 붙여 밥에게 INVITE요청을 전송한다.

 

이때서야 비로소 밥의 전화기가 울린다~~ 따릉따릉~~

밥의 응답에 대해서는 다음 편에 기술해야 겠다. ㅎㅎㅎ