SIP의 이해 - 8. SUBSCRIBE 및 NOTIFY (RFC 3265,RFC 3680)

글 싣는 순서

                                                                                  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)

이제 8장까지 왔습니다. 점점 봐야할 RFC 문서도 많아지고, 제대로 요점을 정리하고 있는 지도 의심이 들기 시작합니다. 허클베리피님이 가끔씩 조언도 해주시고, 틀린 부분을 바로잡아 주셔서 다행입니다. 블로그를 방문하시는 분들도 의문 사항을 댓글에 남겨 주시면 아마도 많은 분들께서 좋은 답변을 해 주시지 않을까 기대합니다.

요즘 NExpert 블로그에서 Google Groups를 이용한 UC 포럼 게시판을 만들었습니다. 관심있으신 분들은 오른쪽 상단의 공지사항을 확인하시고, UC 포럼에 가입해 보시기 바랍니다. 아직 활성화되지 않은 포럼이라 서로 질문하거나 글을 올리는 것을 상당히 주저하고 있지만, 서로 가입인사도 나누면서 UC 전반에 걸친 질문과 답변이 오고 가길 기대합니다. 그럼 시작하겠습니다.

개요
이벤트에 대한 통지 요청을 하고, 이에 대한 응답을 받는 다는 것은 다양한 SIP 응용 서비스에서 유용합니다. RFC 3265 SIP-Specitif Event Notification에 다음과 같은 SIP 응용 서비스를 예를 들고 있습니다.

Automatic Callback Service (자동 콜백 서비스)
특정 단말의 상태정보를 알 수 있도록 호가 종료되었을 때, 상태 정보가 SIP 서비스로 통지(Notification)된다면, 바로 콜백이 이루어질 것입니다. 콜백 서비스는 상대방이 부재중이거나 통화중일 때 송신자가 콜백 서비스를 신청해 놓으면, 상대방의 상태 변화가 감지되자마자 자동으로 통화가 되도록 하는 것입니다.
Buddy Lists (친구 목록)
버디 리스트에 등록된 친구 또는 동료의 상태정보가 실시간으로 통지되어 메신저와 같은 서비스를 편리하게 사용합니다.
MWI (Message Waiting Indication)
음성사서함의 상태 변화 이벤트가 실시간으로 전화 또는 메신저에 통지되어 음성 사서함의 저장된 음성을 들을 수 있습니다.
PINT (PSTN and Internet Internetworking)
PINT에서도 호 상태 정보를 통한 서비스가 가능합니다. PINT는 저도 처음듣는 용어입니다. ^^ 인터넷에 찾아보니, "인터넷 응용을 요청하고 PSTN 전화서비스를 향상시키는 작업을 한다" 라고 합니다. 간단하게 유추해 보면, 인터넷 상의 응용 서비스가 PSTN과 원활하게 호를 처리할 수 있도록 지능망과 연동하는 것이 아닌가 합니다.

이러한 SIP 응용 서비스는 SUBSCRIBE와 NOTIFY 메쏘드를 활용합니다. 아래 그림은 호 또는 자원 (단말 등)의 상태를 Subscription하고 상태의 변화를 통지하는 일반적인 절차입니다.

Subscriber는 메신저 서버, UA 등 다양한 형태가 될 것이며, Notifier는 Registrar 서버 또는 UA 입니다. 여기서 SUBSCRIBE와 NOTIFY가 언제 생성되는 지 알아 보겠습니다. SUBSCRIBE 메쏘드는 Subscriber가 특정 사용자의 현재의 상태와 상태 정보 업데이트를 요청하여 향후의 이벤트 발생 시에 통지해 줄 것을 요청하는 것입니다. 또한, NOTIFY는 SUBWCRIBE 의해 요청된 이벤트 발생시 통지하거나, Subscription (신청)된 단말의 상태 변화를 Subscriber에게 통지합니다.

SUBSCRIBE 메세지 분석
위의 호 절차에 따라 패킷을 분석해 보도록 하겠습니다. 최초 Subscriber가 Notifier에게 SUBSCRIBE 요청을 합니다.

위의 SUBSCRIBE 요청에서 관심있게 보아야 할 것은 다음과 같습니다.

Event:reg
SUBSCIBE 요청에 이벤트가 포함되어야 합니다. 이벤트는 엘리스의 등록 상태 정보를 요청하는 것입니다.
Expires:21600
SUBSCRIBE 요청에 이 헤더가 포함되어야 하며, 이 요청의 유효 기간을 명시합니다. 유효 기간 만료 전에 같은 다이얼로그( 같은 Call-ID) 로 SUBSCRIBE를 주기적으로 생성해야 합니다. 만일 Expires:0 로 설정한다면, Unsubscribe를 요청하는 것입니다.

위의 SUBSCRIBE는 정리하면, app_IM.atlanta.com (IM 서버)은 alice@atlata.com의 등록 상태 및 21600 초 동안 발생되는 등록 상태 변화 이벤트 시에 통지해 줄것을 요청하는 것입니다.

위의 SUBSCRIBE 메세지가 SIP Registrar 서버에 요청이 된 후 아래와 같이 200 OK 메세지가 전송됩니다.

200 OK에서 Expires:3600 으로 보내졌습니다. 기존의 요청된 유효기간 보다 매우 짧은 3600초 동안만 Registration 상태 정보에 대해 통지하겠다는 의미입니다. 이제 Notifier에 의해 Accept 되었으므로 엘리스의 등록 상태 정보의 변화는 Subscriber에게 한 시간 동안 통지될 것입니다. 엘리스가 등록되어 있음을 NOTIFY 매쏘드를 이용하여 보냅니다.

reginfo+xml 메세지에서 (노란색 부분) 엘리스의 등록 상태가 init 라고 표기하고 있습니다. 여기서 Subscription-State 헤더를 살펴보도록 하겠습니다. 이름에서 알 수 있듯이 Subscription에 대한 상태 정보를 나타냅니다.

Active
Subscription은 Accepted 및 Authorized 되었음을 의미
Pending
Notifier가 Subscription을 수령했지만, 불충분한 정책정보로 인해 승인 또는 거절 여부를 아직 결정하지 못함을 의미
Terminated
Subsription이 종료되었음을 의미
Expires 유효기간이 만료되었을 수도 있으며, 사유가 명기됨

Registration State Machine
RFC 3680 SIP Event Package for Registrations에 따른 등록 상태의 변화에 대해 살펴보겠습니다. 아래 그림은 등록 상태 변화를 도식화한 것입니다.

이 과정을 이해하기 위해서 다시한번 SIP Registration을 짚어보겠습니다. SIP에서 Registration이란 Contact Address와 Address-of-record를 바인딩하는 것입니다. 여기서 Contact Address는 AoR에 의한 식별된 사용자에게 연결되기 위한 실제 단말의 주소라고 할 수 있습니다. 이러한 일련의 과정을 위해 User Agent가 SIP REGISTER 메쏘드를 이용합니다. 다음은 등록 상태 변화를 나타낸 것입니다.

Init
Address-of-record에 등록된 contact 이 없는 상태 즉, 도메인에 등록된 사용자이나 통화하기 위한 Contact 주소가 확보되지 않았음을 의미합니다.
Active
하나 이상의 Contact address가 바인딩된 상태입니다.
Terminated
더 이상의 Contact address가 존재하지 않는 상태로 바로 Init 상태로 전환됩니다.

User Presence & Registration State
등록 상태 정보는 사용자 상태 정보 (Presence)와는 틀린 것입니다. 사용자 상태 정보는 사용자가 지금 망에서 다른 사용자와 통화할 수 있는지를 의미하며, 사용자와 연결하기 위한 다양한 통신 수단를 나타내는 Contact address의 집합을 나타냅니다. 등록 상태 정보는 사용자와 연결하기 위한 Contact address가 존재하는 지를 나타내는 것입니다. 즉, 사용자 상태 정보를 알기 위해서는 등록 상태 정보라는 Raw 데이타가 필요하게 되는 것입니다. 어렵게 설명된 듯합니다만, 찬찬히 읽어보시면 이해가 되실 것입니다.

"Welcome Notice "서비스 예제
RFC 3680 SIP Event Package for Registration에는 등록 상태 정보를 이용한 몇가지 시나리오가 있습니다. 이 중에서 RFC 3680의 Welcome Notice서비스 예제를 살펴보도록 하겠습니다. Welcome Notice는 현재 일반적으로 사용되는 것으로 사용자가 로밍폰으로 외국에서 전화기를 켜면, 사용자의 단말이 Welcome to the contry 메세지를 받게됩니다. 이의 호절차는 다음과 같습니다.

Application은 특정 사용자 (Joe)의 등록 상태 정보를 요청하기 위해 Notifier로 동작하는 Registrar 서버에 SUBSCRIBE를 아래와 같이 전달합니다.

Registrar는 아래와 같이 200 OK를 통해 3600초 동안 Joe의 등록 상태 정보를 보내겠다고 합니다.

Registrar는 200 OK를 전송한 후 Joe의 현재 등록 상태를 Application에 NOTIFY 메쏘드를 통해 아래와 같이 전달합니다. reginfo+xml 포맷으로 된 Joe의 등록 상태는 init 입니다. 즉, 사용자의 등록 정보는 있으되, Contact Address가 아직 업데이트 되어 있지 않다는 것입니다.