SIP의 이해 - 7. PRACK (RFC 3262)

                                                                                글 싣는 순서

                                                                                  1. SIP의 개요 (RFC 3261)
                                                                                  2. SDP의 개요 (RFC 4566 & RFC 3264)
                                                                                  3. Early Media in SDP (RFC 3959, RFC 3960)
                                                                                  4. RFC 3261의 주요 매쏘드 (I)             
                                                                                  5. RFC 3261의 주요 매쏘드 (II) 
                                                                                  6. RFC 3261의 Response의 이해
                                                                                  7. PRACK (RFC 3262) 
                                                                                  8. SUBSCRIBE & NOTIFY (RFC 3265, RFC 3680)  
                                                                                  9. INFO  (RFC 2976) 
                                                                                 10. UPDATE (RFC 3311)
                                                                                 11. REFER (RFC 3515)
                                                                                 12. PUBLSIH (RFC 3903)

SIP의 이해를 연재하면서 정말 6장까지 진행되었는 데 댓글이 없기는 처음입니다.  -,- 그래도 방문객들이 부끄러움이 많아서 댓글을 달지 않는다고 믿고 꾸준히 업글하도록 하겠습니다. 설마, SIP는 모두 다 알고 있는 내용이여서 별로 특별할 것이 없다고 많은 분들이 생각한다고 믿고 싶지 않습니다. 흑흑..

이글은 RFC 3262 Reliability of Provisional Responses in the SIP와 Cisco Networkers의 SIP 관련 자료를 참조하여 작성된 것입니다.

PRACK 개요
PRACK는 Provisional Response ACKnowledgement의 약어로써, 아직 설립되지 않은 세션에 대한 신뢰할 수 있는  Provisional ACK를 제공하는 것입니다. 이미 제 3장 Early Media in SDP에서 잠시 다루었던 메쏘드입니다. UAC가 INVITE Request를 보내면, UAS는 100 Trying 또는 183 Session Progress 와 같은 메세지를 200 OK Response 이전에 보내므로 여기에 필요한 정보를 실어 보냅니다. 그러나, UAC의 입장에서는  유일하게 INVITE에 대한 200 OK를 받으면, ACK를 통해 응답이 가능합니다. 즉, 200 OK이전에 신뢰할 수 있는 응답을 제공하기 위한 방안이 없습니다.  따라서,  PRACK을 통해 응답을 수행하게 됩니다.  

 

잘 이해가 않가실 것입니다. 다시한번 위의 그림을 보면서 설명드리겠습니다. PRACK은 INVITE에 대한 200 OK Final Response 전에 UAC에 의해 생성되는 것이며, 183 Session Progress 라는 Provisional Resopse에 대한 응답이 PRACK에 포함되는 것입니다. 따라서, Provisional Resopnse가 신뢰할 수 있도록 되는 것입니다. PRACK이 없다면, 183 Session Progress 에 대해 UAC는 신뢰할 수 있는 응답을 제공할 수 없습니다. 

즉, RFC 3261상의 Response는 Final 과 Provisional 두가지 타입으로 정의합니다. Final Response는 Request에 대한 처리 결과로써 생성되어 신뢰할 수 있도록 전송됩니다. 예를 들면, INVITE에 대한 200 OK가 주어지는 것이며, 또한 200 OK에 대한 ACK가 주어지는 것입니다. Provisional Response 는 Request에 대한 처리 중에 정보를 제공하기 위해 생성되지만, 신뢰할 수 있는 방안을 제공하지 못합니다. 이 Provisional Response에 대한 신뢰할 수 있는 전송 방안을 제공하는 것이 PRACK입니다. PRACK는 일반적인 Request와 똑같이 동작하여 200 OK Response를 받습니다.

PARCK은 INVITE에 대한 100 Trying 이외의 101 부터 199 Response에 대해서만 제공됩니다. 사실 100 Trying은 hop-by-hop으로 이루어지는 것으로 end-to-end 매커니즘이 아니기 때문입니다. 밥과 엘리스 사이에 SIP Proxy가 2개가 있다고 생각해보시길 바랍니다. 100 Trying은 밥으로 부터 전달되는 것이 아니라, INVITE를 받은 SIP Proxy에 의해 생성됩니다. 지금까지 주욱 연재를 읽어오신 분들에겐 당연한 얘기입니다.

 

PRACK 관련 헤더 분석
위의 그림의 호 절차대로 각 SIP 헤더를 살펴보도록 하겠습니다. 아래 그림처럼 INVITE with SDP를 전송할 때, UAC는 Requires 헤더에 100rel 메세지를 포함합니다. 100rel은 Provisonal Response에 대한 신뢰성을 제공하기 위한 Option Tag로써, UA는 신뢰할 수 있는 Provisional Response 주고 받을 수 있음을 의미합니다. 

아래 그림은 183 Session Progress로써 Provisional Response입니다. 각 Provisional Response에는 Rseq 헤더를 통하여 squence number를 제공합니다.  이때 UAS가 100rel을 지원하지 않는다면, 420 Bad Extension 을 통해 거절하며, Unsupported 헤더에 사유를 명기합니다.

아래 그림은 PRACK SIP 헤더입니다.  Rack 헤더를 통해 Rseq의 sequence number를  포함하여 ACK함을 나타냅니다.

아래 그림은 PRACK에 대한 ACK입니다. PRACK은 Request이므로 이에 대한 처리 결과로써 200 OK가 전송됩니다.  만일 여기서 UAS가 200 OK 를 보내지 못하거나 전송간에 손실이 되었다면, 어떻게 될까요. PRACK은 일반 Request와 동일하므로 재전송이 발생합니다. ^^ 당연한 얘길 것입니다.

Offer / Answer Model and PARCK
이미 제 3장에서 다루었던 내용으로 early-session과  session에 대한 협상 시에 PRACK을 통해 early-session에 대한 응답을 수행했던 것을 상기하시바랍니다. 이 부분에 대해 RFC 3262에 나와 있는 좀 더 다양한 상황에 대해 정리하도록 하겠습니다.

일반적으로는 UAC가 INVITE with Offer를 제공하면, UAS는 provisional reponse (예를 들면, 183 Session Progress) with Answer 로 응답하여 Fianl Response이전에 세션 파라미터에 대한 협상이 진행됩니다. 만일  UAS가 provisional reponse with Offer를 한다고 가정한다면, 즉, UAC가 INVITE without Offer를 한 경우가 될 것입니다. 이때는 반드시 PRACK with Answer가 되어야합니다. 또한, PRACK with Offer라면, PRACK에 대한 200 OK에 Answer가 포함되어야 합니다.  이것은 기본적인 Offer / Answer Model에 기초한 것으로 PRACK을 통해 다양한 상황에서 세션파라미터 협상이 가능함을 확인할 수 있는 부분입니다. 

마치며
이번 글은 짧게 만들었습니다. 사실 이글에서 PRACK을 사용하는 SIP Preconditions를 함께 설명할까 생각했지만, 저도 아직 자세하게 공부하지 못했기에 나중에 별도의 장으로 나누거나 다른 곳에 포함시켜 설명드리도록 하겠습니다. 사실 SIP Preconditions는 RSVP를 사용하는 QoS 부분입니다. 

-----------------
라인하트
CCIEV #18487
linecard@naver.com