SIP: Difference between revisions

From 탱이의 잡동사니
Jump to navigation Jump to search
(Created page with "== Overview == SIP 프로토콜 소개. 원본은 이곳<ref>http://www.nexpert.net/489</ref>에서 확인할 수 있다. == SIP == SIP는 Session Initication Protocol 의...")
 
No edit summary
 
(9 intermediate revisions by the same user not shown)
Line 64: Line 64:
=== Redirect Server ===
=== Redirect Server ===
Proxy Server는 통화 연결을 위한 SIP INVITE ㅁ세지리르 목적지로 직접 전달해주는 것과 달리 Redirect Server는 메시지를 전송한 UAC로 목적지를 3xx redirect 메시지로 알려준다. Redirect 메시지를 받은 UAC는 수신한 목적지 주소를 가지고 새로운 세션을 열어서 통신을 시도한다.
Proxy Server는 통화 연결을 위한 SIP INVITE ㅁ세지리르 목적지로 직접 전달해주는 것과 달리 Redirect Server는 메시지를 전송한 UAC로 목적지를 3xx redirect 메시지로 알려준다. Redirect 메시지를 받은 UAC는 수신한 목적지 주소를 가지고 새로운 세션을 열어서 통신을 시도한다.
통시사와 같은 대규모 VoIP망을 지원하는 IP PBX의 경우에는 Registrar Server, Proxy Server, Redirect Server를 따로 구축하기도 하지만, 일반 기업용 IP PBX는 한 서버에 모두 구현한다. 따라서, VoIP 엔지니어들은 IP PBX 내에서 각 컴포넌트를 따로 구분하지 않는다.
== B2BUA의 이해 ==
SIP는 UA(User Agent)간의 통신으로 클라이언트 서버 기반 프로토콜로 UAC(User Agent Client)와 UAS(User Agent Server)간 통신을 다룬다. SIP Proxy는 옵션 장비로 다수의 UA간의 통신을 편리하게 해주는 역할을 수행하지만, UA가 보내는 SIP 메시지 전체를 수정/변경/삭제할 수 없고, 특정 헤더를 삽입하거나 제한된 수정이 가능하다. 따라서 SIP Proxy는 기업에서 사용되는 수많은 부가 기능을 구현하거나 서로 다른 프로토콜간 연동을 하기 위해서는 부족한 장비이다.
따라서, IP PBX는 SIP Proxy가 제공하는 것보다 더 많은 부가 기능, 직접적인 코덱협상, CAC, VoIP 프로토콜 간 상호연동 등의 기능을 수행하기 위해 B2BUA로 개발된 경우가 많다. B2BUA는 Back-to-Back User Agent의 준말로 UAC 역할과 UAS의 역할을 동시에 수행한다는 의미이다.
B2BUA가 구현된 IP PBX와 SIP Proxy로 구현된 IP PBX의 차이점은 다이얼로그 구성에서 차이가 난다. 같은 Call ID를 가지는 하나의 트랜잭션 단위가 다이얼로그를 형성한다. 아래 그림에서 왼쪽 전화기에서 INVITE를 보내면, 오른쪽 전화기가 200 OK로 응답하는 하나의 트랜잭션 단위이다. SIP Proxy 서버는 SIP 메시지의 헤더와 바디 부분을 변경하지 않고 Via 헤더나 Route 헤더 등을 삽입하거나 제거하는 일을 하면서 실제 다이얼로그에 영향을 미치지 않는다.
[[File:SIP dialog.png]]
B2BUA 로 동작하는 IP PBX는 UAC인 전화기에서 보낸 INVITE를 종단하는 UAS로 동작하여 다이얼로그를 종단하고, 다시 UAC의 역할을 수행하여 착신 전화기에 INVITE 메시지를 새롭게 생성하여 전송한다.
[[File:B2bua dialog.png]]
B2BUA 로 구성된 IP PBX의 장점은 다음과 같이 요약할 수 있다.
* 다양한 부가 서비스 구현이 용이함.
* 이기종 프로토콜간 연동 지원
: 발신 전화기는 SIP로 수신 전화기는 H.323으로 통신이 가능하며, 미디어는 직접 전화기간에 전달된다.
* 코덱 변환 지원
: 하나의 통화에서 LAN 상에서는 G.711로, WAN 상에서는 G.729로 통신할 수 있어 대역폭 관리 및 정책 설정이 용이하다.
== SIP의 친구들 ==
SIP는 시그널링 프로토콜로 와넌한 하나의 호를 생성 및 종료하기 위해서는 SIP를 도와주는 친구 프로토콜이 있다.
* RFC 3550 Real-Time Protocol (RTP) & RTCP : 실제 음성 및 영상 전송.
* RFC 4566 Session Description Protocol (SDP) : 세션 설정을 위한 세부 속성 파라미터 제공.
== 요청과 응답 프로토콜로써의 SIP ==
SIP는 Client/Server 프로토콜이면서 요청과 응답 (Request/Response) 프로토콜이다. SIP는 세션에 대한 처리 요청과 응답으로 트랜잭션을 진행한다.
[[File:Sip request response.png]]
SIP를 이해하는 것은 요청과 응답의 과정을 정확히 아는 것이다.
== 요청을 위한 14개의 SIP 메소드 ==
SIP의 요청(Request) 메시지는 메소드(Method)라고 하고, 정해진 특정 상황에서 발생되므로 용도를 알면 의미를 쉽게 파악할 수 있다.
RFC 3261에 정의된 6개의 기본 메소드는 다음과 같다.
* INVITE
: 멀티미디어 세션에 참가시키기 위한 서비스 또는 사용자를 초대하기 위한 메소드
* ACK
: INVITE 메소드에 대한 최종 응답인 200 OK를 수신했음을 통지하기 위한 메소드. ACK는 별도의 응답을 받지 않는 것이 특징.
* BYE
: 기존의 세션을 종료하기 위한 메소드
* CANCEL
: 최종 응답 200 OK를 받기 전에 기존의 요청을 취소하기 위한 메소드
* OPTION
: 서버의 Capability를 요청하기 위한 메소드
* REGISTER
: User Agent가 Registrar Server에 등록하기 위한 메소드
그 외에 멀티미디어 세션 관리 및 부가 서비스를 위해 추가적으로 8개의 메소드가 IETF에서 발행하는 RFC 문서에 각각 정의되었다.
* INFO(RFC 2976)
: 기존의 설립된 세션 또는 다이얼로그 내에서 추가적인 정보를 전송하기 위한 메소드
* PRACK(RFC 3262)
: UAC (User Agent Client)가 임시적으로 Response를 승인하기 위한 메소드
* SUBSCRIBE(RFC 3265)
: 특정 이벤트를 살펴보기 위해 원격 노드에 요청하기 위한 메소드
* NOTIFY(RFC 3265)
: 특정 이벤트 발생 시 응답하기 위한 메소드
* UPDATE(RFC 3311)
: 세션 설정 파라미터를 업데이트하기 위한 메소드
* MESSAGE(RFC 3428)
: 채팅과 같은 단문 메시지를 (IM, Instant Messaging)을 전달하기 위한 메소드
* REFER(RFC 3515)
: 호전환(Call Transfer)과 같이 UA가 지금 통신 중인 UA 이외의 또 다른 UA와 통신하기 위한 메소드
* PUBLISH(RFC 3903)
: Presence Server에 UA의 상태 정보를 전송하기 위한 메소드
SIP는 RFC 3261에 정의된 기본 6개의 메소드와 추가 8개의 메소드를 합쳐 총 14개의 메소드를 사용한다. SIP 메소드만 이해해도 SIP 호 절차 분석이 쉽다.
== 응답 유형 ==
요청에 대한 응답은 세 가지 유형으로 구분된다.
* Accept(승인)
: 요청의 처리를 승인하고, 결과로 200 OK를 송신
* Reject(거절)
: 요청의 처리를 거절하고, 결과로 원인에 따른 응답을 송신
* Redirect(재송신 요청)
: 요청의 처리를 보류하고, 요청의 처리를 재송신할 다른 주소를 송신
200 OK는 가장 많이 보는 응답이며, Reject는 거절 사유에 따라 응답 유형이 다르다.
== 기본적인 SIP 호 설립 절차 ==
전화 통화 과정을 머리속에 그리면서 아래 그림을 살펴보면 좋다. 엘리스와 밥이 통화하는 과정을 기술적으로 설명하면 다음과 같다.
"엘리스는 수화기를 들고 밥의 전화번호를 다이얼링하는 순간 엘리스의 전화기는 SIP INVITE 메소드로 세션 설립 요청을 밥에게 보낸다. 밥의 전화기는 요청에 대한 처리의 결과로 벨리 울리기 시작하고, 엘리스에게 링백톤(Ringback tone)을 전송한다. 밥이 수화기를 드는 순간 밥의 전화기는 200 OK 를 송신한다. 엘리스의 전화기를 링백톤 생성을 중지한다. 엘리스의 전화기를 200 OK를 수신했음을 확인하기 위해 ACK(Acknowledgement) 메소드를 송신한다."
[[File:Sip call flow.png]]
위의 그림은 기본적인 SIP Call Flow, 호 프로시져 또는 호 절차로 불린다. INVITE 와 ACK는 SIP 메소드이며, 200 OK는 INVITE에 대한 최종 응답이다. 위의 그림에 표시된 절차는 최소한의 SIP 세션 설립 절차이자 호 설정 절차이므로 모든 SIP 세션 설립에 반드시 포함된다.
특히, INVITE, 200 OK, ACK의 교환 과정을 SIP 세션 설정을 위한 "three-way handshake"라고 한다. TCP three-way handshake"가 SYN, SYN/ACK, ACK 를 교환하면서 세션 설립을 완료하듯이 SIP도 INVITE, 200 OK, ACK를 교환하면서 세션 설립을 완료한다.
== 실제 사용되는 SIP 호 설립 절차 ==
앞에서 언급한 대로 SIP 세션을 설립하기 위한 3-way handshake 에 사용되는 INVITE, 200 OK, ACK는 필수 메시지이다. 실제 호 설립 절차에서는 추가적인 옵션 메시지인 100 Trying 응답과 180 Ringing 응답을 함께 사용한다. 100 Trying 응답은 SIP INVITE를 수신하여 처리하는 중임을 나타내며, 180 Ringing 응답은 착신 전화기의 벨리 울리고 있으니 링백톤을 재생하거나 컬러링과 같은 음 수신을 준비하라는 의미를 나타낸다.
[[File:Sip normal call flow.png]]
밥의 전화기가 INVITE를 수신하자마자 100 Trying이 송신되며, INVITE를 정상적으로 처리하여 벨이 울리기 시작하면 180 Ringing을 앨리스의 전화기로 보낸다.
IVR이나 음성사서함등의 SIP 시스템과 시스템간의 연결시에는 180 Ringing 이 필요없으므로 사용하는 경우를 제외하고는 거의 모든 SIP 세션 설립에 필수적으로 포함된다.
== SIP 호 종료 절차 ==
통화중에 참가자 중 한명이 수화기를 내려 놓으면, BYE 요청이 송신되고 200 OK로 응답하면서 세션을 종료한다.
[[File:Sip bye.png]]
== ISDN Q.931 와 SIP 호 절차 비교
요즘은 Voice Gateway와 IP PBX간에 SIP Trunk를 많이 구현하므로 장애처리를 해야할 경우, ISDN E1 PRI의 Q.931 호 절차와 SIP의 호 절차를 비교하는 일이 자주 있다. Q.931 시그널링의 SETUP 메시지는 SIP의 INVITE와 대응되는 것처럼 각 메시지는 상호 대응되는 관계이다.
[[File:Sip to isdn.png]]
UC 엔지니어가 반드시 알아야 하는 세션 설립 및 종료 절차이다. SIP 패킷을 수집하거나 Voice Gateway에서 디버깅을 할 때 위의 절차를 모르면 아무것도 할 수 없다.


== References ==
== References ==
<references />
<references />
[[category:SIP protocol]]

Latest revision as of 13:34, 3 February 2020

Overview

SIP 프로토콜 소개. 원본은 이곳<ref>http://www.nexpert.net/489</ref>에서 확인할 수 있다.

SIP

SIP는 Session Initication Protocol 의 약자로 응용 계층의 시그널링을 담당하는 프로토콜이다. SIP의 이름을 그대로 번역을 하면 "세션 설정 프로토콜"이다. RFC 3261 권고안에 따르면, SIP는 하나 또는 그 이상의 참가자와 멀티미디어 세션의 생성, 변경, 종료에 대한 응용 계층의 프로토콜로 정의한다. SIP에서 정의한 세션은 다음과 같다.

  • Internet multimedia conferences (다자간 회의)
  • Internet telephone calls (음성 전화)
  • Internet video session (영상 전화)
  • Multimedia distribution (멀티미디어 분배)
  • Subscriptions and Notification for Events (이벤트 구독 및 통지)
  • Publications of State (상태정보 배포)

인터넷에서 세션은 폭넓은 의미로 사용되지만, SIP에서는 전화를 걸고 받기 위한 번화번호와 같은 정보를 송수신하는 것을 의미한다.

SIP 패킷 구조

SIP 메시지를 송수신하는 패킷의 구조를 알면 SIP의 특징을 이해할 수 있다. SIP의 패킷 구조는 다음과 같다.

Sip packet.png

SIP 메시지는 텍스트 기반의 가변 길이로 구성되며 크게 SIP 헤더와 메세지 바디로 나뉜다. 헤더는 편지의 봉투와 같은 내용을 담고 있으며 뒤에 올 메시지 바디의 종류를 표시한다. 메시지 바디에는 필요한 구체적인 사항들이 기술되며 옵션 필드이다.

SIP가 사용하는 전송 프로토콜(Transport Layer)은 TCP(Transport Control Protocol) 또는 UDP(User Data Protocol)이다. 위의 그림에서처럼 일반적인 상황에서는 UDP를 주로 사용하지만, 현재는 Secure IPT나 특정 상황에서 TCP를 많이 사용하며, 사용하는 포트는 SIP는 5060과 5061 포트를 주로 이용한다.

SIP 컴포넌트

SIP 프로토콜이 멀티미디어 통신을 위한 호를 생성 및 종료하기 위해서는 다음의 5가지 기능(Functionality)이 필요하다.

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

이 기능들은 SIP 컴포넌트에서 직접 구현된다.

Sip components.png

위의 다이어그램은 SIP 통신을 위한 컴포넌트들을 간단히 표시한 것이다. SIP 주요 컴포넌트들을 하나씩 살펴보자.

UA(User Agent)

UA는 User Agent의 약자로 UAC (UA Client)와 UAS (UA Server)를 합쳐서 부른다. UAC는 세션을 시작하는 역할로 접속을 요청을 하며, UAS는 세션을 종단하며 접속 요청 메시지를 수신한다. UA는 다른 UA와 직접 연결을 설정하거나 Proxy/Redirect Server 들의 도움으로 다른 UA와 연결을 설정한다. 통화중인 호의 상태를 실시간으로 관리한다. 따라서, UA는 UAC와 UAS의 역할을 동시에 가지고 있다.

SIP Proxy

호 별로 SIP 컴포넌트들은 UAC의 역할을 하거나 UAS의 역할을 한다. 그러나 SIP Proxy는 호를 종단하지 않고 릴레이만을 하므로 UAC나 UAS의 역할을 수행하지 않는다.

SIP Gateway

Gateway는 관문이라는 뜻으로 서로 다른 이기종망을 연결하는 장비이다. SIP Gateway는 PSTN 전화망과 IP 네트워크를 서로 연결해주는 역할을 한다.

제 3 의 서버

SIP를 지원하는 UA인 전화기가 두 대가 있다고 가정하자. 전화기가 "전화번호와 IP 주소 매핑 테이블"을 가지고 있다고 가정할 경우에 서로 통화가 가능하다. 만일 사용자가 전화기의 IP 주소를 알고 있다고 할 경우에도 통화를 가능할 것이다. 그런데, 전화기가 두 대가 아닌 수천/수만 대일 경우를 생각해보자.

모든 전화기가 "전화번호와 IP 주소 매핑 테이블"을 가지고 있으면 통화가 가능하다. 그러나, 현실적으로 전화기가 컴퓨터 수준으로 성능이 증가해야 되는 단점과 IP 주소가 바뀔 때마다 다른 전화기에 정보를 업데이트 해주어야 하므로 현실적으로 불가능하다. 이런 관리적인 요소를 해결할 수 있는 방법은 제 3의 서버가 "전화번호 IP 주소 매핑 테이블"을 가지고 있고, 모든 전화기들이 IP 주소가 변경될 때 마다 업데이트를 하고, 통화 시도시에 제3 의 서버에게 IP 주소를 물어보면 된다.

관리적인 요소들로 구분한 제3 의 서버는 다음과 같이 분류된다.

Registrar Server(등록 서버)

일반적으로 전화기들은 부팅 시에 자신이 획득한 IP 주소나 SIP URI 정보를 Registrar Server 에 등록한다. Registrar Server는 전화기로부터 받은 SIP Register 메시지를 기준으로 데이터베이스에 저장한다.

Registrar Server는 저장된 정보를 바탕으로 Proxy Server로 부터 요청에 응답하지만 SIP 메시지를 직접 처리하지는 않는다. Registrar Server의 기능을 이용하여 Presence (상태정보)의 정보를 생성할 수 있다.

Proxy Server

Proxy Server는 전화기(UA)로부터의 수신한 접속 요청 메시지를 추가/변경/삭제할 수 있다. 즉, 전화기가 1001 전화번호로 통화를 시도하는 SIP INVITE 메시지가 도착하면, Proxy Server는 Registrar Server에 1001의 IP 주소를 문의한 후에 1001 전화기로 메시지를 전달한다. 또한 과금(Billing)을 위한 CDR(Call Detail Record)정보 등을 유지한다.

Redirect Server

Proxy Server는 통화 연결을 위한 SIP INVITE ㅁ세지리르 목적지로 직접 전달해주는 것과 달리 Redirect Server는 메시지를 전송한 UAC로 목적지를 3xx redirect 메시지로 알려준다. Redirect 메시지를 받은 UAC는 수신한 목적지 주소를 가지고 새로운 세션을 열어서 통신을 시도한다.

통시사와 같은 대규모 VoIP망을 지원하는 IP PBX의 경우에는 Registrar Server, Proxy Server, Redirect Server를 따로 구축하기도 하지만, 일반 기업용 IP PBX는 한 서버에 모두 구현한다. 따라서, VoIP 엔지니어들은 IP PBX 내에서 각 컴포넌트를 따로 구분하지 않는다.

B2BUA의 이해

SIP는 UA(User Agent)간의 통신으로 클라이언트 서버 기반 프로토콜로 UAC(User Agent Client)와 UAS(User Agent Server)간 통신을 다룬다. SIP Proxy는 옵션 장비로 다수의 UA간의 통신을 편리하게 해주는 역할을 수행하지만, UA가 보내는 SIP 메시지 전체를 수정/변경/삭제할 수 없고, 특정 헤더를 삽입하거나 제한된 수정이 가능하다. 따라서 SIP Proxy는 기업에서 사용되는 수많은 부가 기능을 구현하거나 서로 다른 프로토콜간 연동을 하기 위해서는 부족한 장비이다.

따라서, IP PBX는 SIP Proxy가 제공하는 것보다 더 많은 부가 기능, 직접적인 코덱협상, CAC, VoIP 프로토콜 간 상호연동 등의 기능을 수행하기 위해 B2BUA로 개발된 경우가 많다. B2BUA는 Back-to-Back User Agent의 준말로 UAC 역할과 UAS의 역할을 동시에 수행한다는 의미이다.

B2BUA가 구현된 IP PBX와 SIP Proxy로 구현된 IP PBX의 차이점은 다이얼로그 구성에서 차이가 난다. 같은 Call ID를 가지는 하나의 트랜잭션 단위가 다이얼로그를 형성한다. 아래 그림에서 왼쪽 전화기에서 INVITE를 보내면, 오른쪽 전화기가 200 OK로 응답하는 하나의 트랜잭션 단위이다. SIP Proxy 서버는 SIP 메시지의 헤더와 바디 부분을 변경하지 않고 Via 헤더나 Route 헤더 등을 삽입하거나 제거하는 일을 하면서 실제 다이얼로그에 영향을 미치지 않는다.

SIP dialog.png

B2BUA 로 동작하는 IP PBX는 UAC인 전화기에서 보낸 INVITE를 종단하는 UAS로 동작하여 다이얼로그를 종단하고, 다시 UAC의 역할을 수행하여 착신 전화기에 INVITE 메시지를 새롭게 생성하여 전송한다.

B2bua dialog.png

B2BUA 로 구성된 IP PBX의 장점은 다음과 같이 요약할 수 있다.

  • 다양한 부가 서비스 구현이 용이함.
  • 이기종 프로토콜간 연동 지원
발신 전화기는 SIP로 수신 전화기는 H.323으로 통신이 가능하며, 미디어는 직접 전화기간에 전달된다.
  • 코덱 변환 지원
하나의 통화에서 LAN 상에서는 G.711로, WAN 상에서는 G.729로 통신할 수 있어 대역폭 관리 및 정책 설정이 용이하다.

SIP의 친구들

SIP는 시그널링 프로토콜로 와넌한 하나의 호를 생성 및 종료하기 위해서는 SIP를 도와주는 친구 프로토콜이 있다.

  • RFC 3550 Real-Time Protocol (RTP) & RTCP : 실제 음성 및 영상 전송.
  • RFC 4566 Session Description Protocol (SDP) : 세션 설정을 위한 세부 속성 파라미터 제공.

요청과 응답 프로토콜로써의 SIP

SIP는 Client/Server 프로토콜이면서 요청과 응답 (Request/Response) 프로토콜이다. SIP는 세션에 대한 처리 요청과 응답으로 트랜잭션을 진행한다.

Sip request response.png

SIP를 이해하는 것은 요청과 응답의 과정을 정확히 아는 것이다.

요청을 위한 14개의 SIP 메소드

SIP의 요청(Request) 메시지는 메소드(Method)라고 하고, 정해진 특정 상황에서 발생되므로 용도를 알면 의미를 쉽게 파악할 수 있다.

RFC 3261에 정의된 6개의 기본 메소드는 다음과 같다.

  • INVITE
멀티미디어 세션에 참가시키기 위한 서비스 또는 사용자를 초대하기 위한 메소드
  • ACK
INVITE 메소드에 대한 최종 응답인 200 OK를 수신했음을 통지하기 위한 메소드. ACK는 별도의 응답을 받지 않는 것이 특징.
  • BYE
기존의 세션을 종료하기 위한 메소드
  • CANCEL
최종 응답 200 OK를 받기 전에 기존의 요청을 취소하기 위한 메소드
  • OPTION
서버의 Capability를 요청하기 위한 메소드
  • REGISTER
User Agent가 Registrar Server에 등록하기 위한 메소드

그 외에 멀티미디어 세션 관리 및 부가 서비스를 위해 추가적으로 8개의 메소드가 IETF에서 발행하는 RFC 문서에 각각 정의되었다.

  • INFO(RFC 2976)
기존의 설립된 세션 또는 다이얼로그 내에서 추가적인 정보를 전송하기 위한 메소드
  • PRACK(RFC 3262)
UAC (User Agent Client)가 임시적으로 Response를 승인하기 위한 메소드
  • SUBSCRIBE(RFC 3265)
특정 이벤트를 살펴보기 위해 원격 노드에 요청하기 위한 메소드
  • NOTIFY(RFC 3265)
특정 이벤트 발생 시 응답하기 위한 메소드
  • UPDATE(RFC 3311)
세션 설정 파라미터를 업데이트하기 위한 메소드
  • MESSAGE(RFC 3428)
채팅과 같은 단문 메시지를 (IM, Instant Messaging)을 전달하기 위한 메소드
  • REFER(RFC 3515)
호전환(Call Transfer)과 같이 UA가 지금 통신 중인 UA 이외의 또 다른 UA와 통신하기 위한 메소드
  • PUBLISH(RFC 3903)
Presence Server에 UA의 상태 정보를 전송하기 위한 메소드

SIP는 RFC 3261에 정의된 기본 6개의 메소드와 추가 8개의 메소드를 합쳐 총 14개의 메소드를 사용한다. SIP 메소드만 이해해도 SIP 호 절차 분석이 쉽다.

응답 유형

요청에 대한 응답은 세 가지 유형으로 구분된다.

  • Accept(승인)
요청의 처리를 승인하고, 결과로 200 OK를 송신
  • Reject(거절)
요청의 처리를 거절하고, 결과로 원인에 따른 응답을 송신
  • Redirect(재송신 요청)
요청의 처리를 보류하고, 요청의 처리를 재송신할 다른 주소를 송신

200 OK는 가장 많이 보는 응답이며, Reject는 거절 사유에 따라 응답 유형이 다르다.

기본적인 SIP 호 설립 절차

전화 통화 과정을 머리속에 그리면서 아래 그림을 살펴보면 좋다. 엘리스와 밥이 통화하는 과정을 기술적으로 설명하면 다음과 같다.

"엘리스는 수화기를 들고 밥의 전화번호를 다이얼링하는 순간 엘리스의 전화기는 SIP INVITE 메소드로 세션 설립 요청을 밥에게 보낸다. 밥의 전화기는 요청에 대한 처리의 결과로 벨리 울리기 시작하고, 엘리스에게 링백톤(Ringback tone)을 전송한다. 밥이 수화기를 드는 순간 밥의 전화기는 200 OK 를 송신한다. 엘리스의 전화기를 링백톤 생성을 중지한다. 엘리스의 전화기를 200 OK를 수신했음을 확인하기 위해 ACK(Acknowledgement) 메소드를 송신한다."

Sip call flow.png

위의 그림은 기본적인 SIP Call Flow, 호 프로시져 또는 호 절차로 불린다. INVITE 와 ACK는 SIP 메소드이며, 200 OK는 INVITE에 대한 최종 응답이다. 위의 그림에 표시된 절차는 최소한의 SIP 세션 설립 절차이자 호 설정 절차이므로 모든 SIP 세션 설립에 반드시 포함된다.

특히, INVITE, 200 OK, ACK의 교환 과정을 SIP 세션 설정을 위한 "three-way handshake"라고 한다. TCP three-way handshake"가 SYN, SYN/ACK, ACK 를 교환하면서 세션 설립을 완료하듯이 SIP도 INVITE, 200 OK, ACK를 교환하면서 세션 설립을 완료한다.

실제 사용되는 SIP 호 설립 절차

앞에서 언급한 대로 SIP 세션을 설립하기 위한 3-way handshake 에 사용되는 INVITE, 200 OK, ACK는 필수 메시지이다. 실제 호 설립 절차에서는 추가적인 옵션 메시지인 100 Trying 응답과 180 Ringing 응답을 함께 사용한다. 100 Trying 응답은 SIP INVITE를 수신하여 처리하는 중임을 나타내며, 180 Ringing 응답은 착신 전화기의 벨리 울리고 있으니 링백톤을 재생하거나 컬러링과 같은 음 수신을 준비하라는 의미를 나타낸다.

Sip normal call flow.png

밥의 전화기가 INVITE를 수신하자마자 100 Trying이 송신되며, INVITE를 정상적으로 처리하여 벨이 울리기 시작하면 180 Ringing을 앨리스의 전화기로 보낸다.

IVR이나 음성사서함등의 SIP 시스템과 시스템간의 연결시에는 180 Ringing 이 필요없으므로 사용하는 경우를 제외하고는 거의 모든 SIP 세션 설립에 필수적으로 포함된다.

SIP 호 종료 절차

통화중에 참가자 중 한명이 수화기를 내려 놓으면, BYE 요청이 송신되고 200 OK로 응답하면서 세션을 종료한다.

Sip bye.png

== ISDN Q.931 와 SIP 호 절차 비교 요즘은 Voice Gateway와 IP PBX간에 SIP Trunk를 많이 구현하므로 장애처리를 해야할 경우, ISDN E1 PRI의 Q.931 호 절차와 SIP의 호 절차를 비교하는 일이 자주 있다. Q.931 시그널링의 SETUP 메시지는 SIP의 INVITE와 대응되는 것처럼 각 메시지는 상호 대응되는 관계이다.

Sip to isdn.png

UC 엔지니어가 반드시 알아야 하는 세션 설립 및 종료 절차이다. SIP 패킷을 수집하거나 Voice Gateway에서 디버깅을 할 때 위의 절차를 모르면 아무것도 할 수 없다.

References

<references />