글 싣는 순서

                                                                                  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 버튼을 선택할 것입니다.

더보기

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

신고
Posted by 라인하트

댓글을 달아 주세요

  1. Jyoung 2009.03.19 11:23 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 연재 계속 잘 보고 있읍니다. 감사합니다.

  2. 쏠라구구 2009.04.19 22:41 신고  댓글주소  수정/삭제  댓글쓰기

    제목이 REFFER 이 아니라 REFER 이 아닌가요? ㅎㅎ~

    방문자의 관심 테스트로 알겠습니다...

    오늘에서야 자세하게 sip 문서를 정독해보고 테스트 중이네요.

    역시나 좋은 문서 감사~~.. 아참 sip pdf 파일에도 수정요..~~

  3. 라인하트 2009.04.20 07:58 신고  댓글주소  수정/삭제  댓글쓰기

    역시 예리한 감각입니다. 독자들에 대한 관심 테스트였다고 우기고 싶습니다. -,-:?

  4. Lyan 2012.09.25 12:50 신고  댓글주소  수정/삭제  댓글쓰기

    블루투스 일을 하다가 SIP 관련 업무로 옮기면서 어제부터 읽고 있습니다.^^ 처음에는 어려웠는대 정리가 잘 되어 있어 많은 도움 받고있습니다. 아직은 잘 이해가 안되지만 몇 번 더 읽으면 잘 되겠죠.^^?ㅋ

    • 라인하트 2012.09.26 14:36 신고  댓글주소  수정/삭제

      네 도움이 되나니 다행입니다.
      처음 공부하는 것이 어렵지 벽을 넘으면 쉽다고 합니다.

  5. nine 2012.11.17 17:17 신고  댓글주소  수정/삭제  댓글쓰기

    SIP 를 처음 접하면서, 많은 도움을 받고 있습니다.

    의문되는 부분이 있어서 질문드립니다. (단순 오타 같지만 초보자라서 확인 하고 싶은 마음입니다.)

    NOTIFY 메시지 설명하신 부분에서

    "여기에서는 SIP/2.0 100 Trying이라고 되어있습니다. 이는 다음과 같은 의미입니다"

    ==> "여기에서는 SIP/2.0 200 OK이라고 되어있습니다. 이는 다음과 같은 의미입니다"
    (메시지 예시의 바디와 일치 하지 않는 설명)

    위와 같이 수정되는 것이 맞는 것이 아닌지 질분드립니다.

  6. 방랑자 2014.12.22 14:24 신고  댓글주소  수정/삭제  댓글쓰기

    즉, Call Transfer에서는 BYE로 기존 세션을 종료한 것과 달리 엘리스가 호를 유지하게 되고, 엘리스는 밥과 캐롤의 목소리를 믹싱하여 밥과 엘리스에게 전송하여야 합니다. 따라서, DSP가 바쁘게 움직일 것입니다. 이 것은 엘리스에 의해 삼자 통화가 되는 것입니다.

    이 부분에서 에리스는 밥과 캐롤의 목소리를 믹싱하여 밥과 캐롤에게 전송한다.가 맞지않나여 ..?

    헷갈려서 질문드립니다 ..ㅎㅎ



티스토리 툴바