SIP의 이해와 Call Flow 분석

SIP(Session Initiation Protocol)의 개요

SIP의 등장 배경
- H.323의 단점을 극복 하기 위해
- H.323은 제약이 많음

SIP는 세션 설정 프로토콜이며 크게 5개의 세션이 있음
1. 다자간 회의
2. 음성 전화 
3. 영상 전화
4. 이벤트 신청 및 통지
5. 상태 정보 배포

SIP는 TCP, UDP를 사용할 수 있지만 현재는 TCP를 더 많이 사용

SIP 메세지는 SIP 헤더(메세지 바디의 종류)와 메시지 바디(옵션 필드)로 구성

 

SIP컴포넌트

 

 

SIP컴포넌트들은 통신에서 호를 생성/종료하기 위한 기능들은 직접 구현한다.

 

UA

- UAC(세션 시작)

- UAS(호를 종단)

- UA끼리 직접 연결하거나 리다이렉트 서버, 프록시를 통해 연결한다.

- 호의 상태를 실시간으로 관리한다.

 

SIP Proxy 

- 호를 종단하지 않고 릴레이해준다.

 

SIP Gateway

- PSTN전화망과 IP 네트워크를 연결해준다.

 

SIP에서는 별도의 서버가 IP 주소 매핑 테이블을 가지고 전화기의 정보들을 업데이트한다.

 

서버를 기능에 따라 3가지로 분류할 수 있다.

1. Registrar Server

    - 전화기로부터 SIP REGISTER 메세지를 받아 상태 정보를 생성/업데이트한다.

2. Proxy

    - 전화기로부터 수신한 접속 요청 메세지를 추가/변경 

    - 메세지 전달 , 과금 정보 등을 생성

3. Redirect Server

    - 메세지를 전송한 UAC에게 3xx redirect 메세지를 보냄으로써 목적지를 알려준다.

 

B2BUA

- SIP PROXY 로 구성된 IP PBX는 대용량 처리를 하는데는 유용하지만 부가 기능과 서로 다른 프로토콜을 연동하기에는 부족하다

  (SIP는 UA가 보낸 메세지 전체를  수정할 순 없고 일부만 수정 가능함)   

  따라서 기업에서는 이러한 단점들 때문에 B2BUA로 IP 프록시를 구현하는 경우가 많다.

 

B2BUA의 구성

- B2BUA는 착신 전화기와 발신 전화기의 IP PBX를 각각 만들어주고 두 개의 다이얼로그를 생성한다.

  이렇게하면 메세지의 헤더와 바디 부분을 변경할 수 있고, 프로토콜간 연동도 용이해진다.

 

일반적인 기업 : B2BUA 사용 (부가 기능 개발)

통신사업자 : SIP PROXY 사용 (대용량 처리)

 

기본적인 SIP CALL FLOW의 이해

SIP는  요청/응답 기반의 프로토콜이기 때문에 세션에 대한 제어 요청과 응답으로 트랜잭션을 진행한다.요청에는 14개(기본 6개,부가 기능 8개)의 메서드가 정의되어있고 , 응답에는 3개의 응답이 있다.

 

1. SIP Proxy 가 없는 경우

     - 앨리스가 밥의 IP를 안다고 가정한다.

 

 

 

 

만약 앨리스가 밥에게 전화를 거는 상황을 예로 들어보면 , 크게 3가지의 필수 과정이 포함된다.

 

 

호(CALL) 설립 절차

 

1. INVITE : 세션에 참가를 요청

INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP 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

 

from ,to 헤더를 통해 앨리스가 밥에게 통화를 시도했다는 것을 알 수 있다.

Via 헤더를 통해 응답을 받는 주소를 명시하고 있다.

CSeq는 314159번이며 , 같은 다이얼로그 내에서 이 번호는 유지된다.

 

 

2. 200 OK : 참가 요청 승인 

SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131

 

같은 다이얼로그 이므로 CSeq는 그대로 유지된다.

여기서 주목해야할 점은 From , to 헤더가 바뀌지 않고 그대로 유지된다는 것인데, 이것을 통해 From , to 헤더는 출발지 목적지가 아닌 방향성을 나타낸다고 볼 수 있다.

Via 헤더의 received 필드를 추가하여 메시지를 받은 정보(앨리스)를 명시하고 있다.

 

3. ACK : 승인 확인 (ACK는 따로 ACK가 나가지 않는다.)

ACK sip:bob@192.168.10.20 SIP/2.0 
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 ACK
Content-Length: 0

 

Received 필드는 지워졌으며 CSeq 를 통해 200 OK에 대한 ACK임을 확인할 수 있다.

 

하지만 실제 통신에서는 두 가지 프로시저가 추가된다.

 

4. 100 TRYING : INVITE 를 받고 요청을 정상적으로 수신했음을 알림 

5. 180 RINGING : 송신 측에게 링백톤을 전송

 

호 종료 절차

 

1. BYE : 상대방이 전화기를 내려놓는다.

BYE sip:alice@10.1.3.33 SIP/2.0 
Via: SIP/2.0/TCP 192.168.10.20;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Alice <sip:alice@atlanta.com>;tag=1928301774
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 231 BYE
Content-Length: 0

 

밥이 앨리스에게 요청을 상황이므로 새로운 다이얼로그이다. 그렇기 때문에 CSeq는 새로운 값을 받는다.

 

2. 200 OK : BYE 요청에 대한 응답

SIP/2.0 200 OK 
Via: SIP/2.0/TCP 192.168.10.20 
To: Alice <sip:alice@atlanta.com>;tag=1928301774
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf 
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 231 BYE
Content-Length: 0

 

CSeq를 통해 BYE 요청에 대한 응답임을 알 수 있다.

 

2. SIP Proxy 를 경유하는 경우

     - 앨리스는 밥의 IP를 모르고 SIP Proxy를 경유한다고 가정한다.

 

 

1. INVITE (앨리스 -> 프록시)

INVITE sip:bob@biloxi.com/TCP SIP/2.0 
Via: SIP/2.0/TCP 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

 

앨리스는 INVITE 메세지를 프록시 서버로 전송한다.

 

2. INVITE (프록시 -> 밥)

INVITE sip:bob@192.168.10.20/TCP       SIP/2.0
Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds;received=10.1.3.33
Max-Forwards: 69
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

 

프록시 서버는 밥의 URI로 메세지를 전송하는데 Via 헤더가 추가된 것을 볼 수 있다.

이것은 밥의 응답이 서버를 경유하기 위함이며 이렇게 함으로써 호의 진행 상황을 알 수 있다.

서버를 하나 경우했으므로 Max-Fowards 는 70에서 69로 감소되었다.

 

3. 200OK (밥 -> 프록시)

SIP/2.0 200 OK
Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1        
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131

 

Via헤더에는 각각 서버의 주소와 앨리스의 주소가 Received 필드에 추가되있다.

 

 

4. 200OK (프록시 -> 앨리스)

SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131

 

프록시는 자신이 추가했던 Via 헤더를 지운 후 다시 앨리스에게 메세지를 전달한다.

 

5. ACK

ACK 이후 부터는 프록시를 거치지 않고 메세지를 전달하는데 이렇게 되면 프록시는 호의 진행 상황을 알 수 없고 

부가 기능 또한 개발이 불가능하다.

따라서 모든 메세지가 프록시 서버를 경유하도록 하는 방법이 필요한데 후에 기술할 Record - Route 헤더와 Route 헤더를

사용한다.