Chapter 6. SIP Method
1. 왜 아직 설립되지 않은 세션에 신뢰할 수 있는 응답을 제공해야 하는가
일반적인 SIP Call Flow는 아래와 같습니다. UAS(밥의 전화기)는 100 Trying 또는 183 Session Progress 와 같은 메세지를 200 OK Response 이전에 보내므로 필요한 정보를 전달할 수 있지만, UAC (앨리스의 전화기)는 INVITE 요청을 송신한 후에 200 OK에 대한 ACK를 통해서만이 나머지 정보를 전달합니다. 즉, UAC는 200 OK 이전에 신뢰할 수 있는 응답을 제공하기 위해서는 기본적인 SIP호 프로시져와 다른 방법이 필요합니다.
신뢰할 수 있는 응답과 신뢰할 수 없는 응답을 이해하기 위해 PRFC 3261에 설명된 두 가지 응답 유형에 대해 살펴보겠습니다.
- Final Response
Request에 대한 처리의 결과로써 생성되며, 반드시 요청에 대한 응답으로 동작하여 신뢰성을 제공합니다. 예를 들면, INVITE에 대한 200 OK와 200 OK에 대한 ACK가 Final Response입니다. - Provisional Response
Request에 대한 처리중에 관한 정보를 제공하며, 전달 후에 응답을 기다리지 않으므로 신뢰할 수 있는 방안을 제공하지 못합니다. 예를 들면 100 Trying과 183 Session Progress 가 Provisional Response 입니다.
그렇다면 왜 200 OK 이전에 신뢰할 수 있는 응답을 제공해야 할까요?
일례로, 앞 장에서 잠깐 언급했던 것처럼 200 OK 전에 Early Media Session을 위한 Offer & Answer 교환을 완료하기 위해 필요합니다. UAS가 100 Trying 에 SDP Offer를 싣을 경우에 UAC의 즉각적인 응답을 기대할 수 없습니다. UAC는 상대방이 수화기를 들고 200 OK를 보내주어야만 ACK에 SDP Answer를 싣을 수 있습니다. 여기서 200 OK이전에 언제든지 SDP Offer에 즉각적인 SDP Answer를 제공할 수 있는 방안이 필요합니다.
2. PRACK의 이해
PRACK은 Provisional Response ACKnowledgement의 약어로 RFC 3262 Reliability of Provisional Responses in the SIP 에 정의되었습니다. PRACK은 아직 설립되지 않은 세션에 대한 신뢰할 수 있는 Provisional ACK를 제공합니다.
PRACK은 INVITE에 대한 200 OK 최종 응답(Final Response) 전에 UAC에 의해 생성되는 것이며, 183 Session Progress 라는 Provisional Resopse에 대한 응답이 PRACK에 포함되는 것입니다. 따라서, Provisional Resopnse가 신뢰할 수 있도록 되는 것입니다. 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에 의해 생성되므로 hop-hy-hop입니다.
메세지를 자세히 분석해 보겠습니다.
- INVITE
UAC는 Requires 헤더에 100rel 메세지를 포함합니다. 100rel은 Provisonal 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
(Alice's SDP not shown)
- 183 Session Progress
183 Session Progress는 Provisional Response입니다. 각 Provisional Response에는 Rseq 헤더를 통하여 squence number를 제공합니다. 이때 UAS가 100rel을 지원하지 않는다면, 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>
Content-Type: application/sdp
Content-Length: 235
(Bob’s (different) SDP not shown)
- PRACK
PRAck 헤더는 Rseq의 sequence number를 표시하여 183 Session Progress를 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
- 200 OK [PRACK]
PRACK에 대해 신뢰할 수 있는 응답을 제공하는 200 OK입니다. PRACK은 Request이므로 이에 대한 처리 결과로써 200 OK가 전송됩니다.
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
지금까지 Early Offer 하에 Fianl Response(200 OK) 이전에 세션 파라미터에 대한 협상을 진행하기 위해 PRACK를 사용하는 것을 설명하였습니다.
Delayed Offer로 Early Media Session을 협상할 경우에 UAS는 provisional reponse (183 Session Progress) 에서 Offer를 시작한다면, UAC는 반드시 PRACK을 이용하여 Answer해야 합니다. 이것은 기본적인 Offer / Answer Model에 기초한 것으로 PRACK을 통해 다양한 상황에서 세션파라미터 협상이 가능합니다.
마치며
지금까지 PRACK의 쓰임새에 대해 살펴보았습니다. 만일 200 OK 이후에 잘 통화하다가 세션 파라미터를 변경해야 하는 경우에는 어떻게 할까요? PRACK은 200 OK 이전에 사용한다고 하였는 데 그 이후에 세션 파라미터 교환을 하기 위해 다시 용도를 변경해야 하나요? 아니면 새로운 매쏘드를 만드는 것이 나을까요?
"다시쓰는 SIP의 이해" 연재의 다른 글
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method
2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method
2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method
2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method
2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method
2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method
2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method
2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method
2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP
2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP
2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP
2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response
2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261
2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261
2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261
2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview
2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview
2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)
2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)
2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)
라인하트 유씨누스 (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________
