(SIP) Client Transaction

1] INVITE Client Transaction

Transaction 설명에 앞서 INVITE가 다른 요청들과는 다른 이유 : Extended Duration

-> Callee가 전화를 받기 전에(요청에 응답하기 전에)는 언제 응답을 받을지 모른다.

-> 3-way handshake가 필요 -> INVITE >> 200 OK >> ACK

-> 여기서 ACK는 TU에서 바로 Transport layer로 전송, Transation layer에서 처리하지 않는다.

-> ACK를 보내는 이유 : Unreliable Transport를 통해 재전송 그만하라는 의미

 

< 재전송 >

Transaction layer에서 Transport layer에 보낸 이전 메시지를 가지고 있다가

해당 Transport layer로 한 번 더 보내는 것을 말한다.

 

Unreliable Transport 에는 UDP 존재 -> 비연결 지향, 재전송 O -> 이 글에서 UDP로 축약해서 지칭함

Reliable Transport 에는 TCP, SCTP 존재 -> 연결 지향, 재전송 X -> 이 글에서 TCP로 축약해서 지칭함

 

UDP에서는 재전송이 일어나는데 Timer A로 제어 -> 이 재전송 간격 시간을 T1 값으로 지정

T1은 RTT(Round Trip Time)이고 기본 500ms로 지정한다.

T1은 Exponential Backoff(지수 백오프)로 관리 -> 지연 시간을 지수적으로 진행

첫번째 재전송 간격은 T1, 두번째는 2 * T1, 세번째는 4 * T1, ...

충돌 방지를 위함

 

또한 INVITE를 보내고 timeout을 설정해야 하는데 Timer B로 제어 -> 64 * T1 값으로 지정

64 * T1 = 일곱 개의 요청을 보내는데 필요한 예상 시간 (in UDP)

-> INVITE Transaction의 timeout

 

"Calling" state가 지속되면 Timer B가 종료된다.

-> Client Transaction은 TU한테 timeout을 알린다.

-> Client Transaction은 ACK를 생성하면 안된다. -> 요청이 처리되지 않았기 때문이다.

 

"Calling" state에서 Provisional response를 받으면 "Proceeding" state로 전이된다.

바뀌게 되면 더 이상 재전송할 필요가 없다. 이 응답은 TU로 전달된다.

 

"Calling"과 "Provisional" state에서 300~699 응답을 받으면 바로 "Completed" state로 전이된다.

Client Transaction 이 응답들을 TU로 보낸다.

UDP든 TCP든 ACK를 생성하게 되고 original request(INVITE)를 보냈던 Transport layer로 보낸다.

 

"Completed" state로 되면 Timer D가 시작된다.

UDP : 적어도 32초

TCP : 0초

 

Timer D는 UDP가 사용되는 경우에, Server Transaction의 "Completed" state가 유지될 수 있는 예상 시간을 설정한다.

Server transaction 에서의 Timer H의 시간(64 * T1)과 동일하다. (64 * 0.5s = 32s)

 

하지만 Client Transaction은 Server Transaction의 T1 값을 모른다.

그래서 64 * T1으로 설정하는게 아니라 32s 라는 절대 최소값을 사용한다.

 

"Completed" state에서 수신되는 최종 응답에 대한 재전송은

ACK 재전송을 위해 TU로 전달해야 하지만

새로 수신된 응답(최종 응답 이외의 응답)은 TU에 전달해서는 안된다.

 

* State Machine 정리

1. Calling

1) Client Transaction이 초기화 되어 시작되고, TU가 보내는 INVITE 전송

2) TImer A가 끝나면 2 * T1 으로 초기화 후 INVITE 다시 보냄(지수 백오프 적용)

3) Timer B가 끝나거나 Transport error 발생 시 TU한테 알리고 "Terminated" state로 전이

4) 2xx 응답을 받으면 TU로 전달하고 "Terminated" state로 전이

5) 1xx 응답을 받으면 TU로 전달하고 "Proceeding" state로 전이

6) 300~699 응답을 받으면 ACK를 보내고 TU로 전달하고 "Completed" state로 전이

 

2. Proceeding

1) 1xx 응답을 받으면 TU로 전달하고 상태 유지

2) 2xx 응답을 받으면 TU로 전달하고 "Terminated" state로 전이

3) 300~699 응답을 받으면 ACK 보내고 TU로 전달하고 "Completed" state로 전이

 

3. Completed

1) 300~699 응답을 받으면 ACK 보내고 상태 유지

2) Transport error 발생 시 TU한테 알리고 "Terminated" state로 전이

3) Timer D가 끝나면 "Terminated" state로 전이

 

4. Terminated

- Transaction instant 소멸

 

 

* 2xx 응답 처리는 TU가 Proxy Core 또는 UAC Core 일 때 각각 다르다.

이유 : 2xx 응답 처리는 Transaction layer 에서 발생하지 않는다.

-> Client Transaction의 instance가 소멸되면서 해당 코어로 2xx 응답이 전달된다.

- UAC Core는 2xx 응답에 대한 ACK 생성

- Proxy Core는 2xx 응답을 포워딩

 

Client Transaction은 "Terminated" state로 전이되면

Transaction의 instant 가 소멸된다. -> 정확하고 올바른 명령을 보장하기 위해 필수적이다.

 

Transport layer가 응답을 받고 이 응답에 매칭되는 Client Transaction이 없다면

이 응답은 현재 TU의 Core로 직접 전달된다.

 

2xx 응답이 수신되면 instance는 소멸된다.

다음 2xx 응답(재전송)은 계속해서 Transaction layer를 거치지 않고 TU로 전달된다.

 

* Client Transaction에서 전송되는 ACK 요청의 구조 분석

- Call-ID / from / Request-URI 는 original request와 같아야 한다.

- To 는 이전에 받은 응답의 To 와 같아야 한다. Tag 가 붙어 있어서 original request와 다르다.

- Via 는 무조건 하나로 시작하고, original request의 Top Via 와 일치해야한다.

- CSeq 는 seq #는 original request와 같아야 하고, method는 ACK로 설정한다.

 

 

2] Non-INVITE Client Transaction

"Trying" state는 새로운 요청이 들어오면 시작되는 상태

Timer F를 사용 -> 64 * T1 값을 사용 -> Non-INVITE Transaction timeout

UDP를 사용하면 Timer E도 사용되고 T1 값을 가진다.

 

Timer E에서 UDP 환경에서 재전송 시, 시간 종료되면 다시 초기화하는데

T1 -> MIN( 2 * T1, T2) -> MIN( 4 * T1, T2) -> MIN( 8 * T1, T2) -> ...

(INVITE Client Transaction과 동일하게 Exponential Backoff 사용)

 

T2의 deafult 값은 4s -> Server Transaction이 요청에 응답하는데 걸리는 예상 시간

그래서 default 값으로 본다면, (T1 : 500ms / T2 : 4s)

500ms -> 1s -> 2s -> 4s -> 4s -> ...

 

* State Machine 정리

1. Trying

1) Timer E가 종료되면 요청이 Transport layer를 통해 재전송된다.

2) Timer F가 종료되면 TU한테 timeout을 알리고 "Terminated" state로 전이

3) Provisional 응답을 받으면 TU로 전달되고 "Proceeding" state로 전이

4) 최종 응답(200~699)을 받으면 TU로 전달되고 "Completed" state로 전이

 

2. Proceeding

1) Timer E가 종료되면 요청이 Transport layer를 통해 재전송된다.

2) Timer F가 종료되면 TU한테 timeout을 알리고 "Terminated" state로 전이

3) Provisional 응답을 받으면 TU로 전달되고 상태 유지

4) 최종 응답을 받으면 TU로 전달되고 "Completed" state로 전이

 

3. Completed

1) Timer K가 T4를 가지며 시작 (UDP에서는 default 5s, TCP에서는 0)

-> T4 : 네트워크가 Client와 Server Transaction 사이의 메시지들을 클리어하는데 걸리는 예상 시간

2) 재전송되는 응답을 담을 버퍼 존재

3) Timer K가 종료되면 "Terminated" state로 전이

 

4. Terminated

- Trasnsaction 소멸