글 싣는 순서

                                                                                  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)


블로그의 UC 포럼 게시판에 벌써 60여명이 가입하였습니다. UC에 대해 정보를 교환하고자 하는 의지는 뜨거운 듯합니다만, 의지와 달리 게시판에 글을 올리는 것에 주저하시는 것 같습니다. 가입 인사나 UC에 대한 의견을 나누면서 서로에게 도움이 되면, 향후에 오프라인 미팅도 같이 할 수 있지 않을까 합니다.

블로그의 솔민아빠님을 중심으로 오프라인 세미나를 모 교육 기관과 준비하고 있습니다. UC 및 CCIE Voice에 대해 서로 이야기 나눌 예정입니다. 이번 오프라인 세미나는 UC 포럼 분들에게 공지가 되지도 못했는 데 신청자가 넘쳐 조기에 마감되었습니다. 향후에 진행되는 오프라인 세미나는 UC 포럼 회원님을 중심으로 준비하도록 하겠습니다.  

개요
이미 협상된 세션 파라미터를 변경하기 위한 re-INVITE가 있는 데 왜 UPDATE 메쏘드가 정의되었는 지 생각해 볼 필요가 있습니다. 아래 그림과 같이 엘리스가 INVITE를 전송한 후 Ringback tone을 듣고 있다가  밥이 수화기를 들기 전에 (200 OK가 전송되기 전에) Hold 서비스를 호출했다고 가정해 봅시다. 즉, 기존의 다이얼로그가 그대로 유지되면서 Hold 서비스가 되어야 합니다. re-INVITE를 통해 Hold 서비스를 호출할 수 있지만, 기존의 다이얼로그를 유지할 수 없으며, 별도의 세션이 설립되는 것입니다. 따라서, UPDATE 메쏘드를 이용하여 INVITE 메쏘드에 대한 Final Response (200 OK) 이전에 세션 파라미터를 업데이트하는 것입니다.

 

UPDATE 메쏘드는 기존에 협상된 미디어 스트림이나 코덱과 같은 세션 파라미터를 변경하기 위해 사용되지만,  기존의 다이얼로그를 그대로 유지 합니다.  re-INVITE는 마찬가지로 세션 파라미터를 변경하는 것은 같지만, 세션이 설립된 후에 사용되며 기존의 다이얼로그에 영향을 주게 되는 것이 차이점입니다. 

여기서 Hold 서비스에 대해 잠깐 짚고 넘어 가겠습니다. 사용자가 전화기의 Hold 버튼을 누를 때, 단방향  a=sendonly 스트림으로 변경할 것을 요구하는 Offer가 생성되고, 사용자의 전화기는 Mute (묵음) 상태가 되며, 상대측으로 미디어가 전송되지도, 로컬에서 미디어가 재생되지도 않습니다.  이 Offer에 Media에 대한 주소는 0.0.0.0으로 설정합니다.  Hold는 RFC 3264 An Offer Answer Model with the SDP에 자세히 나와 있습니다. 양방향 스트림을 단방향 스트림으로 전환하면서 상대방을 대기 상태로 만드는 것입니다.  Hold 서비스는 Call Transfer 또는 Ad hoc Conference 를 하기 위해 많이 사용되는 사용자 기능입니다.


더보기

 

신고
Posted by 라인하트
TAG , , , ,

댓글을 달아 주세요

  1. simon 2009.12.12 16:02 신고  댓글주소  수정/삭제  댓글쓰기

    SDP offer/answer, early media, RTP payload에 대해 한번 정리중인데 고민의 흔적이 느껴집니다.
    좋은 자료 감사합니다.



티스토리 툴바