SIP의 이해 - 10. UPDATE (RFC 3311)

                                                                                     글 싣는 순서

                                                                                  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 를 하기 위해 많이 사용되는 사용자 기능입니다.

호 절차

최초 INVITE 요청 시에 Allow 헤더에 UPDATE를 명기하여 UAC가 UPDATE 메쏘드를 지원함을 UAS에게 알려줍니다. UAS 또한 180 Ringing의 Allow 헤더에 UPDATE를 명기하여 UPDATE 메쏘드를 지원함을 UAC에게 알려줍니다. INVITE with OFFER (G.711)에 대해 180 Ringing with Answer (G.711)로 응답했습니다.

 

UPDATE 요청의 내용은 아래와 같습니다. 엘리스는 200 OK전에 코덱을 G.711에서 G.729로 변경할 것을 요청하며, 밥은 200 OK with answer (G.729)로 응답합니다.

 

여기서 기억해야 할 것은 기존의 Offer / Answer 가 완료된 상태에서 UPDATE 메쏘드가 사용되어 세션 파라미터를 변경하는 것입니다. Offer / Answer가 완료되지 않은 상태에서 UPDATE 메쏘드가 생성될 수 없습니다. INVITE without Offer라면, 180 Ringing with Offer가 전송되고, PRACK을 통해 Answer가 완료되어야 UPDATE가 생성될 수 있습니다. 이 부분은 당연한 이야기 인데 RFC 3311 The SIP UPDATE Method에서 하도 길게 적어놔서 저도 한번 언급한 것입니다.

 

RFC 3311 Example Call Flow

백문이 불여일견  RFC 3311에 나타난 호 절차를 보면서 다시 한 번 정리해 보도록 하겠습니다.

엘리스는 초기 INVITE에 Offer를 포함하여 전송하고, 밥은 180 Ringing에 Answer를 포함하여 응답을 합니다. 이 Provisional Response에 신뢰성을 갖기위해, 즉 Reliable Provisional Resopone를 위해 PRACK을 사용합니다. 이미 초기 INVITE에 대해 프로세스가 완료되지 않았지만, 즉 200 OK를 받지는 않았지만, 세션 파라미터 협상이 완료되었습니다. 이때, 엘리스는 Hold 서비스 (잠시 대기)를 호출하였고 이에 UPDATE 메소드가 전송됩니다. 두 번째 Offer에서는 sendrecv 즉, 양방향 스트림을 UPDATE 매쏘드를 이용하여 단방향 스트림으로 전환합니다. 즉, 밥이 스트림을 보내도 엘리스는 현재 듣지를 못하는 상태이기 때문입니다. 밥이 스트림을 양방향으로 다시 전환하기로 결정하고, UPDATE를 통해  3번째 Offer / Answer를 수행합니다. 초기 INVITE에 대한 Final Reponse인 200 OK를 전송하여 세션을 설립합니다.

 

마치며

UPDATE 메쏘드에 대해 충분히 이해하셨으리라 믿습니다.  다음 장에서는 REFER에 대해 살펴보도록 하겠습니다.  개인적으로는 많은 사연이 있는 매쏘드입니다. 이기종 장비간에 Call Transfer를 연동 시에 REFEER를 지원하지 않는 장비 덕에 힘들었던 기억이 있습니다. 표준 프로토콜로 RFC에 많은 부분이 정의되고 있지만, 실제 구현 부분에서는 갈길이 먼 듯합니다. 그래서 Allow 헤더에 직접 명기하여 정확하게 상대방과 지원여부를 확인하는 것이 중요할 것입니다.