SIP의 이해 - 12. PUBLISH (RFC 3903)

                                                                                     글 싣는 순서

                                                                                  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) 
                                                                                 13. MESSAGE  (RFC 3428)

 

이번 글에서는 PUBLISH 메쏘드에 대해 살펴보겠습니다. 이 메쏘드는 8장 SUBSCRIBE & NOTIFY를 다룰 때 함께 다루었어야 하는 데 차례를 잘 못 정의한 관계로 뒤에서 다루게 되었습니다. 따라서, 잘 이해가 되지 않는 부분이 있으면, 8장을 다시 한 번 읽어보시는 것이 글을 이해하는 데 도움이 되실 것입니다.

이글은 RFC 3903 SIP Extension for Event State Publication 및 RFC 3856 A Presence Event Package for SIP 글을 참조하였습니다. 처음에는 RFC 3903만 가지고 정리하다 보니 어딘지 모르게 2% 부족한 글이 되었습니다. 2%를 찾아 헤매다 보니 RFC 3856을 발견하게 되었습니다.  두 개의 내용을 함께 정리하는 것이 좀 더 편하게 정리할 수 있다고 생각됩니다. 또한, RFC 3856은 PUBLISH 메쏘드의 존재를 모르는 상황에서 presence의 정보를 업데이트하는 구조로 되어 있기에 RFC 3856의 부족한 2%를 채울 수 있는 것 같습니다.  

개요
구글, 네이트온, MSN 등과 같은메신저에 우리는 쉽게 상대방의 Presence (현재의 상태) 정보를 쉽게 확인할 수 있습니다. Presence는 네트워크 상에서 통신을 위한 사용자의 상태정보 (willingness and ability)라고 정의할 수 있습니다. 이는 단순히 on-line 및 off-line 정보일 수 있으며, 우리가 쓰는 것처럼 회의중 (Meeting), 통화중 (Busy), 자리비움 (Away)등과 같이 다양한 정보로 표현될 수 있습니다. 이러한 Presence 정보를 서로 주고 받기 위해 REGISTER, PUBLISH, SUBSCRIBE, NOTIFY가 유기적으로 동작합니다.

RFC 2778 A Model for Presnece and Instant Messaging 자료를 참조하시면, 기본적인 용어 및 매커니즘을 이해할 수 있습니다. 향후에 SIMPLE (SIP for Instant Messaging and Presence Leveraging Extension)을 꼭 다룰 것이 때문에 여기에서는 생략하도록 하겠습니다. ^^

RFC 3903 SIP Extension for Event State Publication 의 용어 정의를 통해 주요 구성 요소에 대해 살펴보겠습니다. 

• Event State
  자원의 상태 정보
  
• EPA (Event Publication Agent)
  PUBLISH 요청를 발행하는 UAC , 아래 그림에서 Alice의 역할
  RFC 3856의 PUA (Presence User Agent)
  
• ESC (Event State Compositor)
  PUBLISH 요청을 수신받아 처리하는 UAS, 아래그림에서 Compositor의 역할
  RFC 3856의 PA (Presence Agent) 로써, Proxy 및 Register와 공존할 수 있음
  
• Event Hard State
  자원의 default Event State로 AoR에 대한 고정된 상태 정보
  ESC는 Soft State publication이 없을 때 사용
  
• Event Soft State
  PUBLISH 매커니즘을 통해 EPA가 발행하는 Event State, 유효기간을 가지고 있으며, 만료시에 재협상되는 유효기간 내에서만 의미있는 Event State를 나타냄

정리하면, PUBLISH 메쏘드는 AoR (Address-of-Record)과 연관된 Event State를 생성, 변경, 제거하기 위한 메쏘드입니다.  REGISTER와 비슷하지만, REGISTER와 달리 다이얼로그를 생성하지 않습니다. 따라서, 상태의 변화에 즉각적인 퍼블리싱이 가능하며, 기존의 다이얼로그에 영향을 미치지도 않습니다. 또한, REGISTER를 통해 표시할 수 있는 Presence 정보는 제한적일 수 있지만, PUBLISH 메쏘드를 통해 좀 더 다양한 형태의 Presence 정보 교환이 가능합니다. 

 

위의 그림에서 보듯이 Presnece를 수집하고, PUBLISH 요청을 처리하는 UAS를 Compositor 즉 ESC 라고 합니다. Bob은 Compositor에 SUBSCRIBE 메쏘드를 통해 Alice의 Presence 가 변경되면 알려줄 것을 요청하고, Alice가 Logon 하여 Presence 정보를 Compositor에 업데이트하면, Bob에게 Alice의 Presence정보가 NOFITY를 통해 통지 됩니다.

 

호 절차
이미 SUBSCRIBE 및 NOTIFY의 동작에 대해서는 설명했으므로 생략하고, 아래 그림에서 처럼 PUBLISH 메쏘드에 대해 살펴보겠습니다.

Alice는 ESC에 자신의 Presence 정보를 Pulication할 것이며, 이 때의 SIP 헤더는 아래와 같습니다. 생략된 XML 메세지 바디는 8장의 NOTIFY에 전송되는 내용과 동일한 형태를 취합니다. presence에 대한 이벤트 패키지를 사용하므로 Event:presence 로 전달됩니다. REGISTER 메쏘드의 경우 Event:reg 로 되어 있던 것을 기억하시기 바라며, 두 메쏘드 모두 Expires 헤더를 가집니다.  아래 그림을 보시면, 상태정보를 나타내는 헤더가 없습니다. 이 내용은 NOTITY에서와 마찬가지로 XML 메세지 바디에 포함되어 있습니다.

아래 그림은 PUBLISH에 대한 200 OK 응답 메세지입니다. 새롭게 SIP-ETag가 추가된 것을 확인할 수 있습니다.

 마치며..
향후에 이 연재를 마치면, Presence 및 SIMPLE에 대해 좀 더 깊게 다루도록 하겠습니다. 여기에서는 매쏘드 위주로 살펴보는 것으로 만족해야 겠습니다. 연재를 하면서 나중에 다시 다루겠다는 표현을 몇 번 한 것으로 기억하는 데 다 지킬 수 있을 지가 의문입니다. ^^ 제가 하지 않더라도 다른 블로거들이 해주리라 믿으면서, 다음에는  연재의 마지막인 MESSAGE에 대해 아주 간략하게 살펴보겠습니다. 

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