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를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________



저작자 표시 비영리
신고
Posted by 라인하트
TAG ,

댓글을 달아 주세요

  1. X 2015.05.06 18:22 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 항상 잘 보고 공부하고 있습니다.

    질문이 있어 또 다시 이렇게 글을 남기게 됩니다.

    INVITE의 Seq가 314159로 되어있는데 PRACK의 Cseq의 헤더 역시 31459로 되어 있습니다.

    또한 PRACK 의 200OK의 Cseq역시 INVITE의 Cseq와 같은 31459라는 숫자를 사용하고 있어 궁금해서 이

    렇게 글을 적어봅니다. PRACK도 ACK와 마찬가지로 같은 INVITE와 같은 Cseq 넘버를 가지는 건가요;;?

    다른 곳에는 INVITE와는 별도로 PRACK의 Cseq를 쓴다고 적혀있어 여쭙니다.

    감사합니다.

    • Favicon of http://www.nexpert.net BlogIcon 라인하트 2015.05.07 06:41 신고  댓글주소  수정/삭제

      제가 참조한 자료에서 CSeq가 위의 자료처럼 되어 있지만, CSeq는 새로운 요청이 생성될 때마다 1씩 증가시키는 것이 정상입니다. 따라서, 314159가 PRACK요청시에는 314160으로 변경되어야 합니다. ^^

      점점 존경스러워지네요.. X님

  2. X 2015.05.07 11:35 신고  댓글주소  수정/삭제  댓글쓰기

    궁금증이 확실히 풀렸습니다.

    빠른답변 감사드리고 좋은 하루 되세요.!

  3. 예전에 같이 한잔했던 사람 2015.05.07 16:11 신고  댓글주소  수정/삭제  댓글쓰기

    PRACK의 CSeq와 INVITE의 CSeq는 다른것입니다.
    INVITE를 보낼때 CSeq가 증가하는 것은 이전 INVITE 메시지와 구별하기 위한것이기 때문입니다.
    그렇기때문에 CSeq는 각각의 메쏘드별로 처리된다고 보시면 됩니다.
    RAck: 813520 314159 INVITE
    이 부분이 있는 이유가 그것때문입니다. 현재 보낸 PRACK은 314159 INVITE가 유효한지 체크하는 것으로 다른 INVITE와 구별하기 위해서 INVITE의 CSeq를 함께 보내는 것입니다.



티스토리 툴바