transaction 종류 및 정의

이전 여러 레터들을 통해 SIP 개념 및 메시지 종류등에 대해 살펴보았다. 본 레터 이후로는 SIP에 대해 좀더 깊이 있는 논의를 해보도록하자. 이에 그 첫번째 주제로 SIP Transaction을 잡았다.

그럼 시작해 보자.

 

ㅁ SIP Tracsaction 개념

 

SIP Transaction은 하나의 request와 해당 request에 대한 response들(0 또는 여러 개의 Provisional responses와 하나 이상의 Final responses)로 구성된다. Provisional response와 Final response에 대한 설명은 이전 레터를 참고하기 바란다.

 

 

ㅁ SIP Transaction 특징

 
- INVITE request 이고 final response 가 2xx 가 아닌 경우의 transaction은 ACK를 포함한다.

 

- 2xx response를 수신한 경우는 ACK는 해당 transaction에 포함되지 않는다.

 
- SIP Transaction은 Server/Client, INVITE/non-INVITE 요소에 따라서 각기 다른 state 를 갖는다.

 

- SIP Transaction 관점에서 볼때 각각의 요청과 응답은 Client 측 transaction과  Server 측 transaction을 갖는다. 다음은 SIP Transaction 관계(relationships)를 그림으로 표현한 것이다.

 

 

 

ㅁ Transaction Matching 방식

 

가. Server Transaction과 request의 matching 

 
  if (top Via header의 branch parameter 값이 동일하고 &&
           top Via header의 URI 값이 동일하고 &&
               method가 동일)
       수신한 request는 기존에 존재하는 transaction이 있음
     
단,  INVITE 수신, 2xx를 제외한 final response 전송, ACK 수신인 경우에는 method가 일치하지 않으나  transaction일치하는 것으로 본다.  수신한 request가 기존에 존재하는 transaction과 일치되면 non-INVITE 인 경우에는 request의 재전송이다.

   

나. Client Transaction과 response의 matching

Client의 transport layer가 response를 수신할 때, 어느 client transaction이 response를 처리할지 결정해야 한다.

 
    if (top Via header의 branch parameter 값이 동일하고 &&
         CSeq header의 method가 동일)
        수신한 response matching
  

 

ㅁ INVITE Client transaction

INVITE Transaction은 three-way handshake로 구성된다. Client transaction은 INVITE를 전송하고, server transaction은 provisional response(예: 100,180)를 전송하고, client transaction은 ACK를 보낸다. 

 

 

  

상기 그림의 절차를 단계별로 기술하면 다음과 같다. 

 

(1) Client transaction이 초기화 될 때 Calling 상태로 천이되며, TU로부터 INVITE request를 수신 가능하다. TU가 전송하는 INVITE request는 반드시 client transaction의 Calling 상태에서 수신해야 한다. 

 

(2) Client transaction이 단말로부터 INVITE request를 수신한 후, 이를 UAS에게 전송한다. 이때 만약 전송 프로토콜이 UDP인 경우에는 Timer A를 설정된 T1 값으로 구동(fire)/리셋한다. 만약 전송 프로토콜가 TCP 또는 SCTP인 경우 client transaction은 Timer A를 사용해서는 안된다.

 

Timer A는 비신뢰성을 지닌 UDP 전송 프로토콜을 사용하는 경우 INVITE request를 재전송하기 위해 사용되는 타이머이다.

 

(3) Transaction timeout을 체크하기 위한 Timer B를 구동한다. 만약 Timer B 구동시에 Client transaction이 여전히 Calling 상태일 경우, client transaction은 TU 쪽으로 timeout이 발생했음을 알려준다.

 

Timer B 값으로 설정된 64*T1 값은 UDP와 같은 비신뢰성 전송 프로토콜을 사용하였을 경우, 7개의 request를 전송하기 위해 필요한 총 시간을 의미한다는데, 규격상에 이렇게 정의되어 있으므로 왜 이렇게 정의했는지는 만든 애들한테 따지시기 바람.ㅋ

 

(4-1) Client transaction이 UAS로부터 INVITE request에 대한 1xx provisional response를 Calling 상태에서 수신한다. 이때 State Machine은 Proceeding 상태로 천이된다.

 

(4-2) Calling 상태에서 UAS로부터 300-699 response를 수신하였을 경우, client transaction의 State Machine이 Completed 상태로 천이된다. 이때 client transaction은 UAS로부터 수신한 response를 TU 쪽으로 전달하고, ACK 메시지를 생성한다.

 

(4-3) 만약 client transaction이 Calling 상태일때 2xx response를 수신하였다면, client transaction은 Terminated 상태로 전이되고, 해당 response를 TU 쪽으로 전달한다.

 

(5-1) Proceeding 상태의 client transaction은 TU 쪽으로 수신한 1xx provisional response를 전달한다. Proceeding 상태에서는 request 재전송 절차를 더이상 수행할 필요가 없다.

 

(5-2) Proceeding 상태에서 UAS로부터 300-699 response를 수신하였을 경우, client transaction의 State Machine이 Completed 상태로 천이된다. 이때 client transaction은 UAS로부터 수신한 response를 TU 쪽으로 전달하고, ACK 메시지를 생성한다.

 

(5-3) 만약 client transaction이 Proceeding 상태일때 2xx response를 수신하였다면, client transaction은 Terminated 상태로 전이되고, 해당 response를 TU 쪽으로 전달한다.

 

(6) ACK 메시지를 이전에 전송했던 UAS 주소 정보(address, port, transport 등)를 참조하여 동일한 UAS 쪽으로 전송한다.

 

(7) Client transaction이 Completed 상태로 천이될 때, Timer D를 구동한다. Client transaction이 Completed 상태일때 Timer D가 구동된다면, client transaction은 Terminated 상태로 천이된다. Timer D는 UDP와 같은 비신뢰성 전송 프로토콜을 사용할 경우에는 32초 정도 설정하고, TCP 또는 SCTP와 같은 신뢰성 전송 프로토콜을 사용할 경우에는 0초로 설정한다.  

 

Timer D는 UDP를 사용하였을 때 server transaction이 Completed 상태로 머무를 수 있는 총 시간을 체크한다. 다시 말해, Timer D는 client transaction이 정해진 시간내에 Completed 상태에서 Terminated 상태로의 상태 천이 시간을 체크하는 타이머이다.

 

규격에서는 마지막 메시지를 송수신한 후에 일정시간 동안 커넥션을 유지하는 것을 권고하고 있다.

이때 유지되는 시간은 client transaction의 상태가 Terminated 상태로 변경되는데 필요한 최소한의 시간 이상이어야 한다.  

   

(8) Client transaction이 Terminated 상태로 천이되었다면, client transaction은 해당 instant를 파기(destory)한다.

 

참고로 UAC 에서 response를 수신하였을 경우 이 수신된 response를 어떤 client transaction이 처리할 지를 결정해야 한다. 이러한 목적으로 최상위 Via 헤더 필드내의 branch 파라미터를 사용하여 수신된 response와 처리할 client transaction을 매칭한다. 매칭 관련 자세한 사항은 앞서 기술하였다.

   

 

ㅁ Non-INVITE Client transaction

 
Non-INVITE transaction은 ACK를 사용하지 않는 단순한 request/response들의 상호 작용이다. 이 트랜잭션은 INVITE transaction과 유사한 State Machine으로 상태를 관리한다.

 

 

상기 그림의 절차를 단계별로 기술하면 다음과 같다. 

 

(1) TU가 client transaction으로 request를 생성하여 전송한다. 

 

(2) TU로부터 request가 수신하여 client transaction을 초기화한다. Client transaction은 Trying 상태로 천이되며, 이때 client transaction은 Transaction timeout을 체크하기 위해 Timer F를 64* T1 초로 설정하여 구동한다.

 

만약 Timer F 구동시에 Client transaction이 여전히 Trying 상태일 경우, client transaction은 TU 쪽으로 timeout이 발생했음을 알려준다. 이때 client transaction은 Terminated 상태로 천이된다.

 

(3) 만일 UDP와 같은 비신뢰성 전송 프로토콜을 사용할 경우, client transaction은 Timer E를 T1초로 설정하여 구동한다. Timer E가 Trying 상태에서 구동되었다면, 해당 Timer E가 리셋된다. Timer E는 비신뢰성을 지닌 UDP 전송 프로토콜을 사용하는 경우 request를 재전송하기 위해 사용되는 타이머이다. 
 

(4-1) Client transaction이 Trying 상태에서 1xx provisional response를 수신하였다면, 수신된 response를 TU 쪽으로 전달한다. 이때 client transaction은 Proceeding 상태로 천이된다.

 

(4-2) Trying 상태에서 UAS로부터 200-699 final response를 수신하였을 경우, 수신된 response를 TU 쪽으로 전달한다. client transaction의 State Machine이 Completed 상태로 천이된다.

 

(5) 만약 Timer E가 Proceeding 상태에서 구동된다면, request가 재전송되고, Proceeding 상태에서 Timer E는 T2초로 리셋된다.

 

(6) 만약 Timer F가 Proceeding 상태에서 구동된다면, client transaction 에러에 따른 timeout이 발생했음을 TU에게 알려줘야 한다.

 

(7-1) Client transaction이 Proceeding 상태에서 1xx provisional response를 수신하였다면, 수신된 response를 TU 쪽으로 전달한다. 참고로 1xx provisional response는 client transaction의 중단과는 무관한 서버의 현재 상태 정보를 제공하는 메시지이다.

 

(7-2) Client transaction이 Proceeding 상태에서 200-699 final response를 수신할 경우, 수신된 response는 TU 쪽으로 전달되고, client transaction 상태는 Completed 상태로 천이된다.

 

(8) 일단 client transaction이 Completed 상태가 되면 즉시 Timer K가 비신뢰성 전송 프로토콜인 UDP일 경우 T4초로 설정되어 구동되고, 신뢰성 프로토콜인 TCP/SCTP를 사용할 경우 0초로 설정되어 구동된다. 이후 client transaction 상태는 Terminated 상태로 천이된다.

 

Completed 상태에서 client transaction은 이전에 추가로 재전송했던 request에 대한 response가 수신될 수도 있기 때문에 최소한 T4초 정도 버퍼링하며 대기한다. T4초로 설정한 이유는 client transaction과 server transaction 사이에서 메시지를 클리어(clear)하기 위해 필요한 네트워크상에서 소요되는 총 시간이다. T4 기본값은 5초이다.

 

(9) Client transaction이 Terminated 상태가 되는 즉시 파기(destroy)된다. 이때  INVITE client transaction과 Non-INVITE client transaction의 차이점은 파기되는 대상이다. 앞서 살펴보았듯이 INVITE client transaction은 파기되는 대상이 transaction의 instant인 반면에, Non-INVITE client transaction은 해당 transaction을 파기한다.

 

참고로 UAC 에서 response를 수신하였을 경우 이 수신된 response를 어떤 client transaction이 처리할 지를 결정해야 한다. 이러한 목적으로 최상위 Via 헤더 필드내의 branch 파라미터를 사용하여 수신된 response와 처리할 client transaction을 매칭한다. 매칭 관련 자세한 사항은 앞서 기술하였다.

 

 

ㅁ Server INVITE transaction

 

INVITE Transaction은 three-way handshake로 구성된다. Client transaction은 INVITE를 전송하고, server transaction은 provisional response(예: 100,180)를 전송하고, client transaction은 ACK를 보낸다. 먼저 Server INVITE transaction을 살펴보면 다음과 같다.

 

 

상기 그림의 절차를 단계별로 기술하면 다음과 같다. 

 

(1) 일단 server transaction은 UAC로부터 request를 처리하기 위해 생성된다. 이때 server transaction은 Proceeding 상태로 천이된다. 이 상태에서 INVITE request를 수신하면 TU 쪽으로 전달한다.

 

Server transaction은 TU가 200ms 내에 provisional resopnse를 생성해야 할지 final response를 생성해야 할지를 모를 경우 100 (Trying) response를 생성해야 한다. Server transaction이 100 Trying response를 전송하는 경우는 일반적으로 proxy에서 발생한다고 볼 수 있다.

 

(2-1) TU로부터 100-199 provisional response를 수신하면 수신한 response를 UAC 쪽으로 전송한다. 이경우 server transaction이 상태 변화없이 Proceeding 상태로 유지된다.

 

(2-2) TU로부터 300-699 response를 수신하면 수신한 response를 UAC 쪽으로 전송한다. 이경우 server transaction이 Completed 상태로 천이된다.

 

(2-3) TU로부터 2xx response를 수신하면 수신한 response를 UAC 쪽으로 전송한다. 이경우 server transaction이 Terminated 상태로 천이된다. 2xx response의 재전송은 server transaction이 아닌 TU가 생성하기 때문에 server transaction이 재전송할 response를 생성할 필요가 없다.

 

(2-4) 만약 전송 에러가 발생한 경우, server transaction은 TU 쪽으로 전송 에러가 발생하였음을 알려주고 server transaction는 Terminated 상태로 천이된다.

 

(3) Server transaction이 Completed 상태로 천이되면, 비신뢰성 전송 프로토콜인 UDP를 사용할 경우 Timer G가 T1초로 설정되어 구동되지만, 신뢰성 프로토콜인 TCP/SCTP를 사용할 경우 Timer G를 설정하지 않는다.

 

(4) Server transaction이 Completed 상태로 천이되면, Timer H도 전송 프로토콜에 상관없이 64*T1 초로 설정하여 구동(fire)한다. 이때 설정한 Timer H는 언제 server transaction이 response 재전송을 포기할 지에 대한 시점을 결정한다. 설정된 시간이 지난후 Timer H가 만료되면 해당 response 재전송을 포기한다.

 

 Timer B와 마찬가지로 설정된 Timer H 설정값 64*T1초는 UDP와 같은 비신뢰성 전송 프로토콜을 사용하였을 경우, 7개의 request를 전송하기 위해 필요한 총 시간을 의미한다.

 

만 약 server transaction이 Completed 상태에서 Timer H가 구동되면, server transaction이 ACK를 결코 수신할 수 없음을 의미한다. 이 경우에는 server transaction가 Terminated 상태로 천이되고, transaction 에러가 발생했음을 TU 쪽으로 알려줘야 한다.

 

(5) Completed 상태에서 UAC로부터 INVITE 를 재수신할 수 있다. 이는 client가 INVITE에 대한 provisional response를 수신하지 못했거나, 재전송 timer가 expire되어 INVITE를 재전송한 이후에 reponse를 수신한  경우로 볼 수 있다.
  

이 경우 재수신된 INVITE 메시지를 실패 처리하지 않고, 이전에 전송한 provisional response를 다시 보내고 상태는 그대로 유지된다.
 

(6) Server transaction이 Completed 상태에서 ACK 를 수신하였다면, server transaction은 Confirmed 상태로 천이된다. 참고로 이때 response 재전송이 모두 중지되기 때문에 Timer G는 무시된다.

 

(7) Server transaction의 Confirmed 상태는 재전송된 final response에 대한 추가적인 ACK를 처리한다.

 

(8) Server transaction이 Confirmed 상태로 천이되면, Timer I를 구동한다. 이때 Timer I는 비신뢰성 전송 프로토콜인 UDP를 사용할 경우 T4초로 설정하고, 신뢰성 전송 프로토콜인 TCP/SCTP를 사용할 경우 0초로 설정한다.

 

Timer I가 구동되고 나면 server transaction은 반드시 Terminated 상태로 천이되야 한다.

 

(9) 일단 server transaction이 Terminated 상태로 천이되면, 해당 transaction은 즉시 파기된다.

 

 

ㅁ Non-INVITE Server transaction

 

Non-INVITE transaction은 ACK를 사용하지 않는 단순한 request/response들의 상호 작용이다. 이 트랜잭션은 INVITE transaction과 유사한 State Machine으로 상태를 관리한다.

 

 

상기의 그림에서 언급된 Timer의 용법에 대해 간략히 정리하면 다음과 같다. 

 

(1) State Machine이 Trying 상태로 초기화된다. UAC가 전송한 request 를 수신하여 이를 TU 쪽으로 넘겨준다. Server transaction이 Trying 상태에서 재전송된 request는 모두 버린다(discard).

 

(2-1) Server transaction이 Trying 상태에서 TU로부터 1xx provisional response를 수신하였을 경우, server transaction이 Proceeding 상태로 천이되고, 수신한 response를 UAC 쪽으로 전송한다.

 

(2-2) Server transaction이 Trying 상태에서 TU로부터 200-699 final response를 수신하였을 경우, server transaction이 Completed 상태로 천이되고, 수신한 response를 UAC 쪽으로 전송한다.

 

(3) Server Transaction이 Proceeding 상태에서 재전송된 request를 수신할 경우, server transactino은 가장 최근에 UAC쪽으로 전송한 provisional response를 다시 UAC로 재전송한다.

 

(4-1) Server transaction이 Proceeding 상태에서 TU로부터 1xx provisional response를 수신하였을 경우, server transaction이 Proceeding 상태로 유지되고, 수신한 response를 UAC 쪽으로 전송한다.

 

(4-2) Server transaction이 Proceeding 상태에서 TU로부터 200-699 final response를 수신하였을 경우, server transaction이 Completed 상태로 천이되고, 수신한 response를 UAC 쪽으로 전송한다.

 

(4-3) Server transaction이 Proceeding 상태에서 전송 에러가 발생한 경우, server transaction은 TU 쪽으로 전송 에러가 발생하였음을 알려주고 server transaction는 Terminated 상태로 천이된다.

 

(5) Server transaction이 Completed 상태에서 UAC로부터 재전송된 request를 수신할때마다, server transaction은 수신된 request에 대한 final response를 UAC로 전송한다.

 

유념할 점은 Server transaction이 Completed 상태에서 TU가 Server transaction으로 final response를 전달해 올 경우 이를 처리하지 않고 바로 버린다(discard).

 

(6) Server transaction이 Completed 상태에서 전송 에러가 발생한 경우, server transaction은 TU 쪽으로 전송 에러가 발생하였음을 알려주고 server transaction는 Terminated 상태로 천이된다.

 

(7) Server Transaction이 Completed 상태로 천이되면, Timer J가 UDP인 경우 64*T1 초로 설정되어 구동되고, TCP/SCTP인 경우 0 초로 설정되어 구동된다.

 

(8) 일단 server transaction이 Terminated 상태로 천이되면, 해당 transaction은 즉시 파기된다.

 

 

ㅁ Transaction 상태 천이

 

지금까지 설명한 내용들을 기초로 Client와 Server 측의 Transaction 상태 및 Dialog 상태 천이를 SIP INVITE request가 성공인 경우와 실패인 경우에 대해 각각 Call Flow를 그려보자. 먼저 INVITE request가 성공인 경우의 Call Flow는 다음과 같다.

 

 

   

다음은 INVITE request가 실패인 경우의 Call Flow는 다음과 같다.

 

 

 

상기의 그림에서와 같이 INVITE에 대한 300~699 reponse에 대한 ACK는 client transaction에서 생성하고 전송한다. non-2xx response에 대한 ACK는 hop-by-hop 으로 처리하며, ACK를 수신하지 못할 경우 failure response 재전송은 server transaction이 제어한다.

[출처] SIP Client/Server Transaction 개념잡기|작성자 몽키몽키