SIP session initiation protocol

SIP 개념잡기

 

참조: RFC3261 - SIP : Session Iniation Protocol

작성: 몽키몽키(cache798@naver.com)

 

SIP란 놈이 뭔놈인지 개념한번 잡아보자. SIP 개념정의부터 특징, 메시지 포맷 그리고 어떻게 써먹는지에 대해 개괄적으로 간단히 요약해보려 한다. SIP 관련 규격으로는 RFC3261~3265 까지 있는듯 한데, 우선은 RFC3261을 중심으로 살펴보자.

 

ㅁ SIP 정의

 

SIP는 Session Iniation Protocol의 약자이다. SIP는 한마디로 말해 인터넷 전화 호와 같은 멀티미디어 세션(예, conference)을 설정, 수정, 종료할 수 있는 응용 계층의 시그널링(signaling) 프로토콜이다.
 

여기서 Session의 의미에 대해 짚고 넘어가 보자면, Session이라 함은 Session 참여자들의 association 간의 교환되는 데이터를 의미한다. 예를 들면, voice, video, interactive game, chat, virtual reality session 등이 있다.

 

시그널링 프로토콜은 메시지 교환을 위한 주체들 간에 메시지 Session을 제어하기 위해서는 어떠한 정보들을 교환하는 역할을 한다. 예를 들어, 일반 전화망에서 통화를 하기 위해 다이얼 번호를 누르고, 상대가 전화 수화기를 들기 전까지 대기음을 듣고, 통화가 끝난 뒤 회선 자원을 반납하는 과정들이 시그널링을 통한 제어 메세지 전달등이 있다.

 

SIP는 이와 비슷하게 인터넷을 기반으로 하는 Internet Telephony Service, 원격 화상회의, 음성 메일 등에 사용될 수 있는 시그널링 프로토콜 중에 하나가 바로 IETF(Internet Engineering Task Force)의 MMUSIC(Multiparty Multimedia Session Control)에 의해 제안되었다.

 

 

ㅁ SIP 등장배경

 

앞서 정리한 바와 같이 SIP는 H.323 과 마찬가지로 IP 네트워크상에서 다수의 이용자들간에 멀티미디어 세션을 생성하고 종료시키는 역할을 수행하는 프로토콜이다. ITU-T 에서 발표한 H.323 이 이미 사용되고 있음에도 불구하고 굳이 IETF 에서 SIP 를 발표한 이유는 H.323 프로토콜이 가지고 있는 취약점 떄문이다.

 

그럼 H.323 에 어떤 취약점이 있을까?

 

일단 H.323은 상당히 복잡한 프로토콜이다. 일례로 H.323 프로토콜은 관련된 다수의 프로토콜이 존재하고 그러한 프로토콜에 관련된 RFC 문서 역시 방대하다. 하지만 1999년도에 발표된 SIP 의 RFC 2543 문서는 153 쪽에 불과하다. 즉, H.323 과 비교하면 상당히 단순한 프로토콜이다.

 

또한 H.323은 ISDN 의 Q.931 프로토콜을 모토로 만들어 졌다(Q.931 프로토콜은 역시 ITU-T 의 전신인 CCITT 에서 만든 프로토콜이다.). 때문에 ISDN 네트워크에서 이미 널리 사용되어지고 있는 H.320 기반의 화상회의 장비들과 자연스럽게 호환되고 그로 인해 많은 기업들의 기존 투자를 보호해준다는 측면이 있는 것은 사실이지만 이로 인해서 H.323 프로토콜은 IP 프로토콜 보다는 ISDN 프로토콜에 접근하는 디자인이 되었다.

 

이에 반해 SIP 는 디자인 목적 자체가 IP 네트워크를 위해 만들어 졌다. 태생부터가 틀리다. SIP는 HTTP 프로토콜을 모토로 만들어 졌다. 차후에 SIP 를 보다 자세히 다룰 텐데 보시면 SIP 구문이 HTTP와 아주 흡사하다는 것을 보게 될 것이다.

 

SIP가 ASCII 텍스트 기반 이기 때문에 SIP 기반의 어플리케이션을 구현하거나 디버깅 작업이 훨씬 용이하고,  콜을 이용할 때 E.164 어드레스 외에도 이메일 어드레스 및 DNS URL 도 어드레스로 활용할 수 있다는 장점이 있다.

 

 

ㅁ SIP 특징

 

SIP의 개념은 대략 앞서 설명한 바와 같고, 이제 이러한 SIP가 어떠한 특징을 가지고 있는지 살펴보자. SIP는 IETF의 Toolkit 개념에 충실히 부합되게 설계되었다. 그래서 인터넷에서 사용되는 다른 많은 프로토콜과 결합하여 다양한 서비스들을 만들 수 있는 유연성과 확장성을 제공한다.

 

SIP가 실제로 할 수 있는 일에 대해서는 여러 가지 오해가 많다. 예를 들어 SIP는 디지털 음성을 전송하지 않으며, 이 일은 RTP(Real-Time Transport Protocol)의 몫이다. RTP는 SIP가 호출을 수립한 다음 음성을 전송해준다.

 

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

 

일반적인 예로서 SAP(Session Advertise Protocol)로 세션에 대한 정보를 관심있는 그룹에 제공하고, SIP를 통해 대화를 원하는 상대가 세션에 참가하도록 INVITE 하며, SDP(Session Description Protocol)를 통해 열고자 하는 media type에 대한 정보를 교환한다. 또한 SDP에 기술된 RTP등을 이용해서 실시간 Multimedia 서비스를 제공할 수 있게 한다.
 

이거 이거 분위기가 SIP를 이해할려면 SAP, SDP, RTP 규격도 분석해야 하는거 같은데...-.-

 

SIP는 응용계층 프로토콜로서 TCP와 UDP 모두 사용할 수 있으며 Request/Response 구조이다. 또한 HTTP와 SMTP의 상당수의 구문들을 그대로 사용하며 HTTP와 유사한 트랜잭션을 을 가지며, 텍스트 기반이기 때문에 H.323에 비해 구현이 용이한 장점도 있다. 

 

 

ㅁ SIP 구성

 

다음은 SIP 구성 노드 중심의 메시지 처리 절차를 나타낸 그림이다.

 

상기의 그림에서 언급된 각각의 노드들에 대해 상세히 기술하면 다음과 같다.

 

User Agent (UA)

UA는 제 사용자와 동작하는 노드를 의미하며, Request하는 UAC(client)와 Response하는 UAS(Server)로 구분될 수 있지만 실제적으로 두 부분 모두가 하나의 프로그램에 포함된다.

 

User Agent Client (UAC)
UAC는 UA중 새로운 SIP request 를 생성하는 논리적 엔티티(entity)를 말한다. 

 

User Agent Server (UAS)
UAS는 SIP request를 수신하여 response를 생성하는 논리적 엔티티를 말한다. 
 

Provisional Response
Provisional Response는 1xx response로 transaction을 종료시키지 않는 response를 의미한다. 
 

Final Response
Final Resonse는 모든 2xx ~ 6xx response들을 지칭한다.
 

Dialog
Dialog는 일정 시간 동안 유지되는 두 UA 간의 peer-to-peer  SIP 관계를 말한다.
 

Transaction
Transaction은 client에서 server로 보내진 첫번째 request로 부터 server에서 client로 보내진 마지막 response 까지의 모든 메시지로 구성된 논리적 개념이다.
 

Proxy Server

Proxy Server는 주로 라우팅 역할 수행한다. 다시 말해, 요청 메시지를 실제 메시지가 전달되어야 할 곳으로 forwarding하는 역할을 한다.  Proxy Server는 요청을 만들고 UA를 대신해 접속을 수립한다. 이 서버는 다른 클라이언트를 대신하여 request를 만들 목적으로 서버와 클라이언트로서 동작하는 중간 단계의 엔티티를 의미하며, request 메시지의 header 값을 변경/추가하여 전달하는 경우도 있다. 다음은 Proxy Server를 구성하였을 경우 구성도이다. Proxy Server에 대한 상세 동작 과정은 별도의 레터를 통해 설명하겠다. 우선 이정도만 파악하고 넘어가자.

 

 

 

Redirect Server
Redirect Server는 수신하는 request에 다른 URI set을 contact하도록 client에게 지시하면서, 3xx response를 생성하는 User Agent Server이다. 이 서버는 요청에 응답해 UA로 대체 로케이션 정보를 제공하지만, 접속 설정에는 관여하지 않는다.

 

Proxy Server는 이후 연속되는 메시지들을 계속 전달받고 포워딩(forwarding)하지만 Redirect Server에서는 자신을 거치지 않고 바로 요청할 수 있는 SIP-URI를 client에게 전달한다. 또한 이 서버는 UA나 프록시 서버로부터 요청을 수신할 수 있다. 

 

이 서버는 자체적으로 접속을 만들지는 못하며, 원래 요청을 재시도할 곳에 대한 정보로 응답을 해줄 뿐이다. 이 서버의 가장 큰 장점은 프록시 서버에 큰 부담을 추가하지 않으면서 필요로 하는 정보를 UA에게 신속하게 줄 수 있다.

 

Registration Server

Registration Server는  전화기와 같은 SIP 장비에 의해 현재 로케이션 등록에 사용된다.

 

Location Server

Location Server는 사용자(SIP UA)의 위치를 등록해 놓은 DB라고 볼 수 있다. 이 서버와 다른 SIP 구성원간에는 SIP가 아닌 다른 방법으로 정보가 교환된다.  보통 Registration Server와 같은 물리적 서버에 상주한다. 다음은 SIP Location Server를 구성하였을 경우의 구성도이다. 우선 대략적으로만 파악해보자. Location Server에 대해서는 별도의 레터를 통해 설명할 예정이다.

 

ㅁ SIP 메시지 종류

 

SIP 메시지는 TEXT 기반이다. 좀더 정확히 말하자면 HTTP 언어를 사용한다. 따라서 SIP 메시지를 스니핑해서 보고 있자면 마치 웹브라우저에서 발생되는 메시지와 똑같아 보인다.

 

SIP 프로토콜에서 사용되는 메시지는 크게 두 가지로 나눌 수 있다. 하나는 주로 클라이언트에서 발생시키는 Request 메시지이고, 다른 하나는 서버 측 에서 발생시키는 Response 메시지이다.

 

SIP Request 메시지

 

우선 SIP Request 메시지부터 살펴보자면 아래와 같다.

 

1. INVITE

SIP 세션을 시작할 때 즉, 콜을 만들 때 클라이언트(UAC)가 서버 쪽으로 전송하는 메시지이다. 경우에 따라서는 상대 클라이언트(UAS) 쪽으로 바로 전송 할 수도 있다. H.323 프로토콜과 비교해 보면 Call Setup 메시지와 비슷한 용도로 사용되는 메시지이다.

 

2. ACK

UAC(콜을 만드는 클라이언트) 는 Invite 메시지에 대한 최종 Response 메시지를 받고 그 Response 에 대해 ACK 를 회신한다. Response 가 Success 이든 Fail 이든 자기의 Invite 에 대한 최종 Response 에 대해 ACK 로 회신한다.

 

3. BYE

BYE는 클라이언트가 콜을 종료할 때 서버에서 해당 콜이 종료 되었음을 알릴 때 사용한다.

 

4. CANCLE

CANCLE은 앞서 요청되어 아직 완료되지 않은 Request 를 취소할 때 사용한다. 만약 서버로부터 Response 메시지를 받았다면 해당 Request 메시지는 취소될 수 없다.

 

5. OPTION

OPTION은 콜 셋업과 관계없이 서버에 대한 정보를 요구할 때 사용되는 Request 메시지이다. 예로써 서버가 Proxy 인지 Redirect 인지등…

 

6. REGISTER

SIP 클라이언트들은 반드시 Registrar 서버에 자신의 위치 정보를 제공해야 한다. 즉, 자신의 SIP 어드레스와 IP 어드레스 정보 등을 등록해야 한다. REGISTER는 이때 사용되는 메시지이다.
 

SIP Response 메시지

 

앞서 언급한 SIP Request 메시지에 대한 서버의 SIP Response 메시지를 살펴보면 다음과 같다.

Response 메시지는 HTTP 메시지의 타입과 일치한다.

 

1. 1XX

100번대 메시지는 Information 메시지이다. 클라이언트가 요청한 정보에 대한 응답으로 사용된다. 예를 들면 다음과 같다.

-  180 : Ringing 메시지 입니다. H.323 메시지로는 Alerting 메시지와 동일하다.

-  182 : 콜이 Queued  되었음을 알려준다. 이는 SIP 디바이스가 Busy일 경우 바로 처리되지 못하고 일단 대기하고 있음을 의미한다.

 

2. 2XX

Successful 메시지 입니다. 예를 들면 다음과 같다. 

- 200 : OK 메시지이다. H.323 으로 보자면 Connect 메시지이다.

 

3. 3XX

Redirect 메시지이다. SIP Redirect 서버를 사용시 발생된다. 서버는 클라이언트의 INVITE 메시지에 대해 Redirect 메시지를 통해 목적지 클라이언트의 세션정보를 제공해 준다. 예를 들면 다음과 같다.

- 301 : redirect

 

4. 4XX

400번대 메시지는 클라이언트의 Request 메시지에 문제가 있음을 표시한다. 웹서버도 클라이언트의 요구에 문제가 있으면 400번대 메시지를 사용하는데 이들 웹서버의 메시지와 동일한 메시지가 사용된다. 예를 들면 다음과 같다.

-  400 : Bad Request 클라이언트의 Request 가 형식에 어긋났음을 의미한다.

-  404 : Not Found 클라이언트가 요구한 SIP 주소(URL 정보)를 찾을수 없다는 의미한다.

-  이외에도 인증되지 않은 클라이언트의 요구등 클라이언트의 여러 가지 잘못에 대해 서버는 400번대 메시지로 응답한다.

 

5. 5XX

500번대 메시지는 서버의 문제를 나타낸다. 서버가 동작하지 못할 때 또는 응답이 없을 때  사용된다. 예를 들면 다음과 같다.

- 505 : Internal Server Error 서버가 응답하지 않음을 의미한다.

 

6. 6XX

600 번대 메시지는 그 외 나머지 일반적인 에러를 표현한다.

 

앞서 살펴본 바와같이 SIP 메시가 HTTP 메시지와 동일하므로 HTTP 에 익숙하다면 쉽게 이해할 수 있을 것이다. 이제 SIP 메시지 구조에 대해 좀더 자세히 알아보자.

 

 

ㅁ SIP 메시지 구조

 

SIP는 각 사용자들을 구분하기 위해 이메일 주소와 비슷한 다음과 같은 SIP URL을 사용하여 사용자는 IP 주소에 종속되지 않고 서비스를 제공받을 수 있다. 참고로 REGISTER 메시지인 경우에는 “@”이 없는 domain name 으로 설정한다.

 
sip:alice@atlanta.com
sips:alice@atlanta.com?subject=project%20x&priority=urgent
sip:+1-212-555-1212:1234@gateway.com;user=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com

 

대략적인 SIP 처리 과정을 살펴보면 다음 그림과 같다.

 

 

상기의 그림을 간략히 설명하자면, 먼저 Alice는 Bob과 통화하기 위해서 INVITE 메시지(F1, F2, F4))를 Bob에게 전송한다. 이때 Alice의 media type에 대한 정보가 Body에 실려 전달된다(아래의 SIP 요청 메시지 예시 참고). INVITE 메시지가 Bod의 단말에 전달되면 전화벨이 울리고(F6, F7, F8), 그 상태를 다시 Alice에게 알려준다(F9, F10, F11).

 

전화벨이 울린후, Bob이 전화를 받으면 통화를 할려고 한다는 메시지를 Bob의 media type 정보와 함께 Alice에게 전해주고, Alice는 ACK 메시지(F12)를 Bob에게 전송함으로써 통화를 시도하는 Alice와 Bob이 media type이 일치함을 알리고, 실제 통화를 위해 Media Session이 오픈된다.

 

통화가 끝난뒤 Bob이 통화를 종료하면 BYE 메시지(F13)가 Alice에게 전달되고, Alice는 Bob에게 Media Session을 종료하는 BYE 메시지가 정상적으로 처리되었음을 알리는 200 OK 메시지를 전송(F14)함으로써 통화(Media Session)가 종료되게 된다.  

 

상기의 SIP 동작 절차중 F1 INVITE 메시지 구조는 다음과 같다. 

 

상기의 SIP 동작 절차중 F9 200 OK 메시지 구조는 다음과 같다.
 

 

상기와 같이 제시된 SIP 메시지를 요소별로 살펴보면 START LINE에는 요청할 Method 종류와 SIP URI를 기술하고, HEADER에는 Session을 제어하기 위한 값들이 설정된다. BODY에는 Content-Type에 설정된 타입의 내용이 들어가게 된다. 상기에서 제시된 SIP 메시지 예제에서는 Content-Type 값이 application/sdp로 설정되어 있으므로 BODY에는 SDP를 이용한 media type에 대해 기술한다. 참고로 HEADER와 BODY 사이는 반드시 공백라인(CR/LF)를 두어 이를 구분해야 한다.  

 

제시된 SIP 메시지 예제에서 보는바와 같이 SIP 메시지는 크게 Header와 Body로 구분된다. 구럼 우선 SIP Header 요소들에 대해 살펴보자. SIP Header 요소중 필수 요소는 다음과 같다.
 

Request-URI
- 메시지의 첫째줄에 들어가는 값으로  To header의 URI와 동일한 값으로 설정. 
- REGISTER 인 경우에는 “@”이 없는 domain name 으로 설정.
- Request-URI 예시
    sip:alice@atlanta.com
    sips:alice@atlanta.com?subject=project%20x&priority=urgent
    sip:+1-212-555-1212:1234@gateway.com;user=phone
    sips:1212@gateway.com
    sip:alice@192.0.2.4
    sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com

 

To
- Request의 논리적인 수신자.

- 목적지 UA(User Agent)나 종단지점의 URI(Uniform Resource Identifier) 포함

- tag parameter는 UAS가 response 생성시 포함.

- To 예시

   To: Bob <sip:bob@biloxi.com>
 
From
- Request 메시지 전송자의 식별 정보. 

- 디스플레이 이름과 요청을 보내는 UA의 URI 포함

- tag parameter를 반드시 포함해야 한다.
- From 예시

   From: “Bob” <sips:bob@biloxi.com> ;tag=a48s            

- tag parameter는 Call-ID 와 함께 dialog를 식별하기 위한 정보로써, 세계적으로  유일하고 암호화된 값이어야 한다.

 

 

Call-ID
- 일련의 메시지들을 group하기 위한 unique identifier.
- Dialog에서 UA가 보낸 모든 request와 response에 대해 같아야 하고 UA로부터의 각 registration에서 같아야 함.
- SIP UA는 Call-ID 헤더 필드가 다른 UA에 의해 중복 생성되지 않음을 보장하는 수단을 가져야 함.
- 암호화된 random ID 사용을 권고함. (RFC 1750)

- Authentication을 위해 request를 재전송하는 경우에도 Call-ID를 새로 할당하면 안된다.

- Call-ID 예시

   Call-ID: a84b4c76e66710@pc33.atlanta.com

 

CSeq 
- transaction을  식별하고  정렬하는 방법으로서의 역할을 함.
- Sequence no와 method로 구성, method는 request의 것과 같아야 함.
- CSeq 예시

   CSeq: 4711 INVITE

 

Max-Forwards
- destination까지 가면서 transit할 수 있는 hop의 수를 제한
- 각 hop에서 1씩 감소, request가 목적지에 도착하기 전에 0이 되면 483(Too Many Hops) error response를 보냄.

- Max-Forwards 예시

    Max-Forwards: 70

 

Via
- 사용될 전송 프로토콜과 SIP 버전 포함.

- 송신자가 그 요청에 대한 응답을 받을 수 있게 보장하는 IP 주소도 또한 포함.

- 호출시 각 프록시 서버는 이 필드에 자신의 IP 주소를 넣음으로써 응답이 이 곳을 통해 가도록 한다.

- transaction에 사용될 transport 이름과 version 정보,  response가 보내질 location을 표시
- branch parameter가 포함되어야 하며, 그 request가 생성한 transaction을 identify한다.
- branch는 “z9hG4bK”로 시작(magic cookie로 사용됨)
- Via 예시

   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

 

SIP Header 요소중 선택 요소는 다음과 같다.

 

Contact
- SIP 요청 메시지 구성시 반드시 필요한 요소를 구성한 다음에는 SIP 요청 메시지를 보내는 UAC 자신의 주소 정보를 Contact 값으로 지정하여 구성한다.

- 추후 UAS가 SIP 응답 메시지를 전송할때 이전에 수신한 SIP 요청 메시지의 Contact 정보를 참조하여 해당 주소로 전송한다.

- 일단 호출이 수립되고 난 후 목적지 UA가 요청 UA로 접속하는 데 필요한 정보

- UA가 이후의 request를 위해 사용할 SIP 또는 SIPS URI. INVITE 전송 시에는 필수 header 임.
- Contact 예시

    Contact: <sip:alice@pc33.atlanta.com>

 

Require
- UAC가 해당 request를 처리하기 위해 필요한 extension을 명시하기 위해 사용. 이를 수신한 UAS가  자신이 처리할 수 있는 extension을  열거하여 response를 전송함.

- Require 예시

   UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
                  Require: 100rel

   UAS->UAC:   SIP/2.0 420 Bad Extension
                  Unsupported: 100rel

- 상기의 예시는 UAS가 이를 수신하면 모든 Provisional Response를 신뢰성 있게 전송해야 한다는 의미이다. 즉, "RFC3262 - Reliability of Provisional Responses in the SIP" 규격을 지원함을 말한다.

그런데 UAS는 UAC한테 난 그렇게 못해라고 응답하고 있다.

 

  

ㅁ 관련 규격

 

- RFC 3261( SIP: Session Initiation Protocol )
- RFC 3262 ( Reliability of Provisional Responses in Session Initiation Protocol )
- RFC 3263 ( Locating SIP Servers )
- RFC 3264 ( An offer/Answer Model with Session Description Protocol )
- RFC 3265 ( Specific Event Notification )
- RFC 2327 ( SDP: Session Description Protocol )
- RFC 1889 ( RTP: A Transport Protocol for Real-Time Applications )
 

출처 : Tong - 눈팅의 생활화님의 ☆˚。Web/Internet통