(SIP) Server Transaction

Network 2020. 3. 17. 16:39 Posted by Vispera

수신한 요청을 TU로 전달하고 신뢰성 있는 응답의 전송을 담당한다.

요청을 받을 때 Core에 의해서 생성된다.

INVITE와 Non-INVITE 요청에 따라 state machine이 달라진다.

 

1] INVITE Server Transaction

요청에 의해 Server Transaction이 생성되면, "Proceeding" state로 시작한다.

이 때, TU가 200ms 이내에 Provisional 또는 최종 응답을 발행할 것을 Server Transaction이 아는 상태가 아니라면 

100 Trying 응답을 발행해야 한다.

-> Provisional 응답은 네트워크 혼잡(트래픽 증가)를 피하기 위해서 빠르게 재전송 요청을 막는 용도로 사용된다.

-> 100 Trying 응답은 To Header의 tag parameter가 추가되지 않는다.

요청은 반드시 TU로 전달되어야 한다.

 

TU는 모든 Provisional 응답을 Server Transaction으로 보낸다.

이 응답은 Transaction layer에 의해 재전송되지 않는다. 신뢰성이 없다.

Server Transaction의 상태를 바꾸지 않는다.

만약 "Proceeding" state에서 요청의 재전송을 수신하면,

TU로 부터 받았었던 가장 최근의 Provisional 응답이 Transport layer로 전송된다.

 

"Proceeding" state가 계속될 때, 만약 TU가 2xx 응답을 Server Transaction으로 보낸다면, 

Server Transaction은 이 응답을 Transport layer로 반드시 보내야 한다.

2xx 응답을 재전송 해야 한다면 Server Transaction에서 진행하지 않는다.

-> 이전에 2xx 응답을 보냈으니까 "Terminated" state로 전이된다. -> Transaction이 소멸된다.

-> 그래서 TU에서 처리된다.

 

"Proceeding" state에서 TU가 300~699 응답을 Server Transaction으로 보내면, 

Server Transaction은 Transport layer로 반드시 보내야 한다.

그리고 "Completed" state로 전이된다.

 

"Completed" state에서 Transport layer로 UDP를 사용한다면, 

T1 값을 가지는 Timer G이 같이 시작된다. 재전송을 제어한다.

Client Transaction의 Timer E와 같이 동작한다. ( (SIP) Client Transaction (규격 분석)글 참조)

 

Timer H도 같이 동작하는데 이 타이머는 Client Transaction의 Timer B처럼 모든 Transport에 적용된다.

타이머 기본 값은 64 * T1 이다.

Server Transaction이 언제 응답 재전송을 그만 둘 것인지를 결정하게 한다.

-> ACK 수신을 기다린다. -> ACK timeout 결정

 

"Completed" state에서 ACK를 받았을 때 "Confirmed" state로 전이된다.

이 상태에서는 Timer G가 무시되므로 모든 응답의 재전송은 중단된다.

Timer H가 "Completed" state에서 종료되면, 'ACK가 아직 수신되지 않았다'라는 뜻이다.

그래서 Server Transaction은 "Terminated" state로 전이된다.

그리고 TU한테 Transaction 실패와 함께 timeout을 알려야 한다.

 

* State Machine 정리

1. Proceeding

1) INVITE 요청 수신 -> TU로 전달하고 상태 시작

100 Trying 응답을 Transport layer로 전송(TU가 200ms 이내로 반응이 없다면)

2) TU로 부터 101~199 응답(Provisional)이 오면 Transport layer로 전달하고 상태 유지

3) TU로 부터 2xx 응답이 오면 Transport layer로 전달하고  "Terminated" state로 전이

4) TU로 부터 300~699 응답이 오면 Transport layer로 전달하고 "Completed" state로 전이

5) Transport error가 발생하면 "Terminated" state로 전이

 

2. Completed

1) Timer G가 종료되면 응답을 재전송하고 상태 유지

2) Timer H가 종료되거나(timeout) Transport error가 발생하면 TU한테 timeout 또는 error 알리고 "Terminated" state로 전이

3) ACK 받으면 "Confirmed" state로 전이

4) Completed 상태에서 UAC로부터 INVITE 를 재수신 가능

- Client가 INVITE 요청에 대한 provisional response를 수신하지 못한 경우

- Timer가 만료되어 INVITE를 재전송한 이후에 reponse를 수신한 경우

3. Confirmed

- Timer I이 종료되면 "Terminated" state로 전이

Timer I은 T4를 사용(default 5s, in UDP)

 

4. Terminated

- Transaction 소멸

 

 

2] Non-INVITE Server Transaction

이 state machine은 "Trying" state에서 생성되고

INVITE 또는 ACK 이외의 요청들을 받아들인다. 이 요청들을 TU로 바로 전달한다.

"Trying" state가 되면 다른 요청의 재전송은 무시된다.

 

"Trying" state에서 TU가 Provisional 응답을 Server Transaction으로 보내면, 

Server Transaction은 "Proceeding" state로 전이된다.

해당 응답은 Transport layer를 통해 전송된다.

 

만약 "Proceeding" state에서 TU로부터 요청 재전송을 수신하면, 

가장 최근의 Provisional 응답을 Transport layer로 재전송해야 한다.

 

만약 TU가 최종 응답(200~699)을 Server Transaction으로 보내면, 

Server Transaction는 "Completed" state로 전이되고, 

그대로 Transaction layer를 통해 Transport layer로 전송된다.

 

Server Transaction가 "Completed" state로 전이되면, 

Timer J가 시작된다. 64 * T1의 값을 가지며, timeout을 제어한다. (in UDP)

요청의 재전송이 발생하더라도 Server Transaction는 최종 응답을 Transport layer로 전송한다.

Server Transaction는 다른 요청의 최종 응답이 TU로부터 오면 무시한다.

 

* Matching requests to Server Transactions

Magic Cookie 라 불리는 "z9hG4bK"로 시작되는 Branch ID parameter는 unique 하다.

-> Transaction ID로 사용

1. 요청의 Branch Parameter 비교

2. 요청의 최상위 Via의 sent-by value 비교

3. 요청의 method가 일치하는지 비교(ACK 제외)

4. Header 체크 : Request-URI, To tag, From tag, Call-ID, CSeq, Top Via

-> sent-by value : 우발적으로 또는 악의적으로 복제될 수 있는 Branch Parameter를 구분하기 위해 사용

ex) Via header의 pc33.atlanta.com:5060

 

* State Machine 정리

1. Trying

1) 요청을 받아서 TU로 전송하면서 상태 시작

2) TU로 부터 1xx 응답을 받으면 Transport layer로 전송하고 "Proceeding" state로 전이

3) TU로 부터 200~699 응답을 받으면 Transport layer로 전송하고 "Completed" state로 전이

 

2. Proceeding

1) TU로 부터 1xx 응답을 받으면 Transport layer로 전송하고 상태 유지

2) TU로 부터 200~699 응답을 받으면 Transport layer로 전송하고 "Completed" state로 전이

3) 재전송된 요청을 수신하면, 최근에 Client로 전달한 Provisional 응답을 재전송

4) Transport error가 발생하면 TU한테 알리고 "Terminated" state로 전이

 

3. Completed

1) Timer J가 종료되면 "Terminated" state로 전이

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

3) Client로부터 재전송된 요청을 수신하면 이 요청에 대한 최종 응답을 Client로 전송

- TU가 Server Transaction으로 최종 응답을 보내면 처리하지 않음

 

4. Terminated

- Transaction 소멸

 

 

'Network' 카테고리의 다른 글

(SIP) Transport  (0) 2020.03.18
(SIP) Timer C  (0) 2020.03.18
(SIP) Client Transaction의 응답 매칭 방법  (0) 2020.03.17
(SIP) Client Transaction  (0) 2020.03.17
ARP Spoofing  (0) 2019.11.26