글 싣는 순서

                                                                                  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를 나타냄

더보기

-------------------
라인하트 (CCIEV #18487)
linecard@naver.com
신고
Posted by 라인하트

댓글을 달아 주세요

  1. 양군 2010.12.07 14:56 신고  댓글주소  수정/삭제  댓글쓰기

    정말 대단합니다.
    SIP 프로토콜의 전문가이십니다.

    매우 유용했습니다.
    감사합니다~

    혹시, pjsip 라는 프레임워크에 대해서도 연재하실 생각은 없으신가요? ㅠㅠ ^^

    • 라인하트 2010.12.07 20:50 신고  댓글주소  수정/삭제

      양군님.. 너무 무리한 부탁이십니다. SIP의 이해도 겨우 했는 데 다시 시작하라는 것은... ^^



티스토리 툴바