SIP의 이해 - 11.REFER (RFC 3515)

                                                                                     글 싣는 순서

                                                                                  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)

 

"CUCM 6.1  데이타 시트의 이해" 를 약 1년에 걸쳐서 연재를 하였지만, "SIP의 이해"는 약 두 달 정도 만에 10장까지 연재하였습니다. SIP를 전체적으로 한 번 정리를 해야겠다는 생각에 빠르게 쓸 수 있었던 듯합니다.  이 연재가 저에게도 여러분들에게도 SIP를 이해하는 데 도움이 되었으면 하는 바램입니다.

시작하기 전에
SIP를 정리하면서 느끼는 점을 간단히 적어보면, SIP는 이제 더이상 간단한 프로토콜이 아니라고 생각됩니다. 다양한 서비스를 SIP 프로토콜 하나로 해결할려다 보니 매쏘드가 많아지고 있으며, 앞으로 더 많은 서비스가 SIP로 구현될 것입니다. 지금 SIP는 그 자체만으로도 매우 방대해졌으며, 단순히 VoIP 프로토콜로써 뿐만아니라 UC의 핵심 프로토콜로 성장하면서, SIP도 여러 워킹 그룹에서 다루고 있습니다. 따라서, 더욱더 복잡해지고 있으며, 이는 이기종 장비간 상호 연동성에 많은 장애가 됩니다. SIP처럼 상호 연동에 어려움을 겪는 프로토콜이 없을 것입니다. 복잡성 외에도 SIP의 유연성도 이기종 장비간에 연동이 쉽지 않게합니다. 유연성이라 한다면, 하나의 기능 구현에 있어서 이렇게 해도 되고, 저렇게 해도 되는 것이 아닌가 합니다. 대표적인 것이 Call Forward 일 것입니다.  302 Moved Temporarily로 또는 181 Call Forwarded 로 응답을 하는 UA에 대해 착신전환이 발생하는 것입니다. 어떤 장비는 302 Response를 무시하여 호를 종료하기도 합니다. 
 
제 생각에는 H.323처럼 좀 더 엄격하게 표준이 정의 되어야 하는 데, 유연성의 장점을 버리지 못해 - 쉽게 버릴 수도 없는 - 이런 문제들이 발생합니다. 그러나, SIP가 향후 VoIP 프로토콜을 주도할 것이므로 시간이 지나면 이런 문제들이 하나 둘씩 극복되지 않을 까 합니다.

개요
REFER 는 SIP 메쏘드로써, REFER 를 받는 수신측은 Request에 제시되는 리소스를 참조하도록 합니다. 많은 어플리케이션에서 사용될 수 있으며, Call Transfer와 같은 서비스가 대표적인 사용예입니다. 쉽게, 하나의 UA가 다른 UA에게 직접 INVITE를 요청하도록 하는 것입니다. REFER 메쏘드를 받는 수신측은 INVITE /200 OK / ACK를 제 삼자와 통신한 후 NOTIFY 메쏘드를 통해 REFER 전송자에게 보고하도록 되어 있습니다.  또한, REFER에 대한 응답 202 Accepted를 사용합니다.

호 절차 (Call Transfer)

 

위의 그림은 보시겠습니다. 엘리와 밥이 항상 통화를 했었는 데 캐롤이 새로 등장합니다. 밥에게 새로운 애인이 생긴 모양입니다. ^^  이제는 기본적인 INVITE요청에서 ACK까지는 설명드리지 않아도 엘리스와 밥간에 호가 성립되어 통화중임을 알 수 있을 것입니다. 통화중에 밥은 엘리스를 캐롤과 통화하도록 연결해 주고자 합니다. 밥은 엘리스에게 "잠시만, 캐롤과 통화하도록 해줄께"라고 말하고 Hold 버튼을 선택할 것입니다.

Hold (통화중 대기) 는 엘리스가 잠시 대기하도록 하는 것입니다. 이미 앞에서도 Hold에 대해 말씀을 드렸었는 데 간단하게 정리하겠습니다.  reINVITE  with SDP가 엘리스에게 전달되고, SDP 에는 a=sendonly , c=0.0.0.0 라고 표시가 됩니다. 200 OK with SDP가 밥에게 전달되고, SDP에는 a=recvonly 라고 표시가 됩니다.  만일 MoH (Music on Hold)가 사용된다면, c=0.0.0.0이 특정 서버의 IP address를 가리킬 것입니다.  

 

위의 그림을 보면, Hold를 한 후 Carol의 정보를 REFER를 통해 보내게 됩니다. REFER을 수신한 엘리스는 INVITE를 직접 Carol에 요청합니다. 엘리스와 캐롤간에 통화로가 설정되고 나서 엘리스는 밥에게 현재의 상황을 NOTIFY 매쏘드를 통해 Bob에게 보고합니다. 동시에 BYE 매쏘드를 밥에게 전송하여 엘리스와 밥간의 호는 종료되고, 엘리스와 캐롤간에 통화 후 종료하게 됩니다. 위의 상황을 본다면, Blind Transfer가 되겠습니다.

밥이 엘리스에게 보낸 REFER 메세지는 아래와 같습니다. 

 

여기서 Refer-To 헤더를 짚고 넘어가겠습니다. REFER 메세지에 반드시 포함되어야 하며, 엘리스가 INVITE를 생성한 후 보낼 정확한 목적지가 명기됩니다. REFER의 다양한 응용을 위해서는 Refer-To 헤더에 다양한 양식의 URI 입력이 가능해야 할 것입니다. 아래는 RFC 3515에 나타난 예제입니다.

Refer-To: sip:alice@atlanta.example.com

Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.

       biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>

Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B

          to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>

Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>

Refer-To: http://www.ietf.org

 

또한, NOTIFY 메세지는 아래와 같습니다. Event : refer를 통해 이 NOTIFY는 REFER에 이벤트에 의해 생성됨을 확인할 수 있습니다. (아래 NOTIFY 메세지는 RFC 3515를 참조하여 제가 직접 호 절차에 맞게 대충 내용을 맞추다 보니 틀릴 수 있는 부분이 있습니다. 이런 흐름이다라는 것으로 이해해 주시면 될듯합니다. )

 

To, From, Call ID가 정확하게 REFER와 매치가 되어야 되는 것은 당연한 것일 것입니다.  또한 메세지 바디에 message/sipfrag가 명시되어야 하며, 이는 REFER에 의한 이벤트의 상태를 나타냅니다.  여기에서는 SIP/2.0 100 Trying이라고 되어있습니다. 이는 다음과 같은 의미입니다.

• SIP/2.0 100 Trying
  현재 REFER에 의해 요청된 이벤트가 처리중임
  
• SIP/2.0 200 OK
  현재 REFER에 의해 요청된 이벤트가 성공적으로 처리되었음
  
• SIP/2.0 503 Service Unavailable
  현재 REFER에 의해 요청된 이벤트가 실패했음
  
  
• SIP/2.0 603 Declined
  현재 REFER에 의해 요청된 이벤트를 수신했지만, 거절되었음

Subscription-State 헤더를 통해 Carol이 Active임을 통지합니다. 이 헤더를 통해 나타냅니다. 그리고, 마지막 NOTIFY가 전송될 때는 Subscription-State:terminatd;reason=noresource가 반드시 명기되어야 합니다.

자 그럼 Call Transfer with consultantive 는 어떻게 될지 생각해 보겠습니다. 이는 밥이 캐롤과 통화 후 캐롤에게 "잠시만 엘리스 전화 돌려줄께" 하고 Transfer 버튼을 누르게 될 것입니다. 이의 절차는 아래과 같습니다. 저는 항상 답을 금방 주는 편입니다. ^^

 

엘리스와 밥이 통화 후 밥은 엘리스를 Hold 시킨 후, 밥이 캐롤과 통화합니다. 그리고, 밥은 앨리스에게 REFER를 전송하여 엘리스가 캐롤에게 직접 INVITE를 전송하도록 합니다. 엘리스는 캐롤과 세션이 연결되자마자 NOTIFY로 밥에게 보고합니다. 이 상태에서 밥은 엘리스와의 통화와 캐롤과의 통화 모두를 종료하게 되는 것입니다.

 

호 절차 (3-way Conference)

REFER를 이용한 또 다른 응용서비스로 아래 그림과 같이 삼자 통화를 들 수 있겠습니다.

 

Call Transfer와 3자 통화의 차이라면, 엘리스가 캐롤과 호를 설립하고 나서, NOTIFY를 밥에게 전송합니다. 밥은 엘리스에게 reINVITE를 전송하여 기존의 Hold 상태의 세션을 양방향 통신 상태로 전환합니다. 즉, Call Transfer에서는 BYE로 기존 세션을 종료한 것과 달리 엘리스가 호를 유지하게 되고, 엘리스는 밥과 캐롤의 목소리를 믹싱하여 밥과 엘리스에게 전송하여야 합니다. 따라서, DSP가 바쁘게 움직일 것입니다. 이 것은 엘리스에 의해 삼자 통화가 되는 것입니다.

일반적인 삼자 통화는 아래 그림과 같을 것입니다.

 

밥이 엘리스와 통화 중에 엘리스를 통화중 대기 시킨 후 다시 캐롤과 통화하게 되고 두개의 호를 밥이 Join하여 Ad-hoc Conference를 하게 되는 것입니다. 삼자 통화는 Refer를 이용할 수 도 이용하지 않을 수도 있다는 것을 이해하시면 될 듯합니다.

 

호절차 (3-way conference with MCU)
삼자 통화를 살펴보는 참에 MCU 또는 DSPFram을 이용한 Conference를 살펴보겠습니다. 만일, 통화자가 서로 다른 코덱을 사용하게 되면, 어쩔 수 없이 외부 리소스를 사용해야 합니다. 이를 사용하는 경우에 대한 호 절차를 살펴보겠습니다.

 

위의 호 절차를 보시면, 외부 리소스를 사용하여, 삼자 통화를 하는 것을 나타냅니다. 아마도 호 절차는 이해가 되는 데 RTP가 어떻게 Conference Resource로 묶이게 되는 지를 이해하지 못하시겠다면, 지금까지의 SIP 연재를 상기해 보시기 바랍니다.

 

결론 
처음 이 메쏘드를 정리할 때 RFC 3515 The SIP REFER Method의 예제를 가지고 정리할려고 했는 데 예제가 구체적인 상황을 명시하지 않아 이해하기가 난해하리라 생각되어 다른 예제를 찾아보다 삼자 통화 호 절차까지 다루게 되었습니다.

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