SIP PRACK: Difference between revisions

From 탱이의 잡동사니
Jump to navigation Jump to search
No edit summary
 
Line 87: Line 87:
<references />
<references />


[[Category:telephony]]
[[category:SIP protocol]]

Latest revision as of 13:46, 3 February 2020

Overview

원문은 이곳<ref>http://www.nexpert.net/146</ref> 에서 확인할 수 있다.

PRACK

PRACK 는 Provisional Response ACKnowledgement 의 약어로써, 아직 설립되지 않은 세션에 대한 신뢰할 수 있는 Provisional ACK 를 제공하는 것이다.

UAC가 INVITE Request를 보내면, UAS는 100 Trying 또는 183 Session Progress 와 같은 메시지를 200 OK Response 이전에 보내므로 여기에 필요한 정보를 실어 보낸다. 그러나, UAC의 입장에서는 유일하게 INVITE 에 대한 200 OK를 받으면, ACK를 통해 응답이 가능하다. 즉, 200 OK 이전에 신뢰할 수 있는 응답을 제공하기 위한 방법이 없다. 따라서 PRACK 을 통해 응답을 수행하게 된다.

Dialog

Sip prack dialog.png

위의 그림을 보면서 이해해보자.

PRACK은 INVITE에 대한 200 OK Final Response 전에 UAC에 의해 생성되는 것이며, 183 Session Progress 라는 Provisional Response 에 대한 응답이 PRACK 에 포함되는 것이다. 따라서, Provisional Response 가 신뢰할 수 있도록 하는 것이다. 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 를 받는다.

PRACK은 INVITE에 대한 100 Trying 이외의 101 부터 199 Response 에 대해서만 제공된다. 사실 100 Trying 은 Hop-by-hop 으로 이루어지는 것으로 end-to-end 매커니즘이 아니기 때문이다.

밥과 앨리스 사이에 SIP Proxy 2개가 있다고 생각해보자. 100 Trying은 밥으로부터 전달되는 것이 아니라, INVITE를 받은 SIP Proxy에 의해 생성된다.

PRACK 관련 헤더 분석

아래 내용처럼 INVITE with SDP를 전송할 때, UAC는 Requires 헤더에 100 rel 메시지를 포함한다. 100 rel은 Provisional Response에 대한 신뢰성을 제공하기 위한 Option Tag로써, UA는 신뢰할 수 있는 Provisional Response 를 주고 받을 수 있음을 의미한다.

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>
Requires: 100rel
Content-Type: application/sdp
Content-Length: 142

아래 내용은 183 Session Progress 로써 Provisional Response 이다. 각 Provisional Response 에는 Req 헤더를 통하여 Sequence Number 를 제공한다. 이때 UAS가 100 rel을 지원하지 않는다면, 420 Bad Extension 을 통해 거정하며, Unsupported 헤더에 사유를 명기한다.

SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
RSeq: 813520
Contact: <sip:alice@pc33.atlanta.com>
Contant-Type: application/sdp
Content-Length: 235

아래 내용은 PRACK SIP 헤더이다. PRACK 헤더를 통해 RSeq의 Sequence Number 를 포함하여 ACK 함을 나타낸다.

PRACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asi98JK
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
RAck: 813520 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Length: 0

아래 내용은 PRACK에 대한 ACK이다. PRACK은 Request 이므로 이에 대한 처리 결과로써 200 OK가 전송된다. 말일 여기서 UAS가 200 OK를 보내지 못하거나 전송간에 손실이 되었다면, PRACK은 일반 Request와 동일하므로 재전송이 발생한다.

SIP/2.0 200 OK sip:bob@192.168.10.20
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asi98JK ; received=10.1.3.33
To: Bob <sip:bob@biloxi.com>; tag=a6c85e3
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 PRACK
Contact: <sip:alice@pc33.atlanta.com>
Content-Length: 0

Offer/Answer Model and PRACK

일반적으로는 UAC가 INVITE with Offer를 제공하면, UAS는 Provisional Response (에를 들면, 183 Session Progress) with Answer 로 응답하여 Final Response 이전에 세션 파라미터에 대한 협상이 진행된다.

만일 UAS가 Provisional Response with Offer 를 한다고 가정한다면, 즉 UAC가 INVITE without Offer를 한 경우가 될 것이다. 이 때는 반드시 PRACK with Answer가 되어야 한다. 또한, PRACK with Offer 라면, PRACK에 대한 200 OK에 Answer가 포함되어야 한다. 이것은 기본적인 Offer/Answer Model 에 기초한 것으로 PRACK 을 통해 다양한 상황에서 세션 파라미터 협상이 가능함을 확인할 수 있는 부분이다.

References

<references />