Chapter 6. SIP Method
3. 세션 설립 후 세션 파리미터 재협상하기 - re-INVITE
전화 통화중 호 보류 등의 서비스를 구현하기 위해 미디어 스트림의 IP 주소나 코덱 변경해야 합니다. 즉, 통화중 SDP Offer/Answer 협상을 진행해야 합니다. SIP 세션 설립 후에 주고 받을 수 있는 SIP 메세지는 BYE 메쏘드뿐이며, BYE 메쏘드는 세션을 종료하기 위해 사용하므로 기존 세션 설정을 협상할 수는 없습니다.
BYE 메쏘드 이전에 세션 파라미터를 재협상하기 위해 SIP는 re-INVITE 와 UPDATE 메쏘드를 사용합니다. re-INVITE는 아래 그림과 같이 Call Hold(호 보류)와 같은 서비스를 구동할 때 많이 사용합니다. re-INVITE는 세션을 설립하기 위해 이용되는 기본 호 프로시져인 INVITE / 200 OK / ACK 절차를 다시 진행하는 것입니다. 통화중에 밥이 부가서비스 호출을 위해 Hold 버튼을 누르게 되면 아래와 같이 re-INVITE가 발송됩니다.
IP Telephony에서는 200 OK 이후 삼자통화와 같은 부가 서비스를 구동하기 위해 호 보류 서비스를 함께 사용합니다. re-INVITE를 이용하는 호 보류 서비스에 대해 간단히 살펴보겠습니다.
- 미디어 스트림의 방향 변경에 의한 호 보류
일반적으로 사용자가 Hold 버튼을 누르는 순간 “a=sendonly” 세션 파라미터를 변경하면서 사용자의 전화기는 묵음(Mute)가 되어 상대방에게 미디어를 전달하지 않습니다.
미디어 스트림은 “a=recvonly” 상태에서 다른 UA가 Hold 서비스를 시작하기 위해서는 “a=inactive”로 세션 파라미터를 변경한다 - 0.0.0.0 으로 미디어의 접속 주소 변경에 의한 호 보류
RFC 3261및 RFC 2543에 명시된 방법으로 “c=0.0.0.0”으로 연결될 IP 주소를 설정하는 것이 있지만, RFC 3264에서 추천하지 않습니다. 원래의 미디어 세션을 단절할 뿐만 아니라 IPv6에서는 동작하지 않습니다.
호 보류를 구현할 경우에 미디어의 주소 변경을 이용한 방법은 보안상 취약하므로 거의 사용하지 않습니다.
4. UPDATE의 이해
re-INVITE 메쏘드를 사용하여 기존 협상된 세션 파라미터를 재협상할 수 있습니다. 전화 통화 시도 시에 발생하는 상황을 가정해서 생각해 보겠습니다.
엘리스가 INVITE를 전송한 후 링백톤을 듣고 있다가 밥이 수화기를 들기 전에 - 180 Ringing은 전달되었지만 200 OK가 전송되기 전인 상황 - 호보류(Hold) 서비스를 호출했다고 가정해 봅시다. 즉, 기존의 다이얼로그가 그대로 유지되면서 호 보류(Hold)서비스가 호출되어야 합니다.
re-INVITE는 기존 다이얼로그 (INVITE/ 200 OK / ACK)가 완료된 후에 발행이 가능하므로 위의 상황에서는 사용할 수 없습니다. 즉, 기존의 다이얼로그를 유지하면서 세션 파라미터를 재협상하는 절차가 필요합니다.
UPDATE는 RFC 3311 The SIP UPDATE Method에 정의된 메쏘드로, 세션 파라미터를 재협상하기 위해 사용합니다. re-INVITE와 달리 UPDATE 메쏘드는 다이얼로그를 유지하면서 세션 파라미터를 재협상합니다.
UPDATE 메쏘드를 이용하여 세션 설립이전에 G.711 코덱에서 G.729 코덱으로 변환하는 과정을 살펴보겠습니다.
- INVITE (SDP1)
INVITE의 Allow 헤더에 UPDATE를 명기하여 UAC가 UPDATE 메쏘드를 지원함을 UAS에게 통보하면서 G.711 코덱을 Offer 합니다.
INVITE sip:bob@biloxi.com/TCP SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928
Call-ID: a84b4c76e66710@pc33.atlanta.com
Allow: UPDATE
CSeq: 22756 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Requires: 100rel
Content-Type: application/sdpContent-Length: 142
(Alice's SDP not shown)
(but calls for the codec G.711)
- 180 Ringing (SDP1)
180 Ringing의 Allow 헤더에 UPDATE를 명기하여 UPDATE 메쏘드를 지원함을 UAC에게 알려주면서 G.711 코덱을 Answer합니다.
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928
Call-ID: a84b4c76e66710@pc33.atlanta.com
Allow: UPDATE
CSeq: 22756 INVITE
RSeq: 813520
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Bob's SDP not shown)
(suitable response with the codec G.711)
- UPDATE
엘리스는 200 OK 이전에 코덱을 G.711에서 G.729로 변경할 것을 요청합니다.
UPDATE sip:bob@biloxi.com/TCP SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 10197 UPDATE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's new SDP not shown)
(but calls for the codec G.729)
나머지 과정은 생략합니다. 200 OK (UPDATE)로 G.729를 Answer한 후에 나머지 과정을 진행합니다.
UPDATE 와 re-INVITE 관계를 정리하면, UPDATE는 INVITE/200 OK/ACK 이전에 세션 협상 완료된 상황에서 세션 파라미터를 변경하기 위해 사용하고, re-INVITE는INVITE/200 OK/ACK 이후에 세션 파라미터를 변경하기 위해 사용합니다. 세션 협상 완료된 후에도 기존 다이얼로그를 그대로 유지하기 위해 UPDATE를 사용할 수 있겠지만, re-INVITE를 추천합니다.
5. PRACK과 UPDATE에 대한 이해
PRACK과 UPDATE에 대한 이해를 돕기 위해 RFC 3311 The SIP UPDATE Method 에 나타난 예시를 다시 한번 살펴보겠습니다.
- 1차 세션 파라미터 협상
최초 SDP Offer / Answer 협상은 엘리스의 INVITE와 밥의180 Ringing 메세지로 이루어집니다. 앨리스는 180 Ringing 메세지와 SDP Answer를 정확히 수신했음을 통지하기 위해 PRACK을 사용합니다. PRACK을 통해 INVITE에 대한 200 OK 이전에 신뢰할만한 응답을 제공합니다. - 2차 세션 파라미터 협상
엘리스는 180 Ringing 이후에 링백톤을 듣다가 부가 서비스 (호보류)를 호출합니다. 즉, 1차 세션 파라미터 협상을 완료하자 마자 부가 서비스 호출을기 위해 세션 파라미터 재협상이 필요합니다. 2차 세션 파라미터 협상은 앨리스의 UPDATE와 200 OK (UPDATE) 메세지로 이루어집니다.
- 3차 세션 파라미터 협상
밥은 다시 세션 파라미터를 재협상하기 위해 UPDATE 메쏘드를 이용합니다.
지금까지 3차에 걸린 세션 파라미터 협상과정에서 기존의 다이얼로그는 바뀌지 않았습니다. PRACK과 UPDATE는 INVITE / 200 OK / ACK 이전에 진행됩니다.
마치며
UPDATE 메쏘드를 살펴보았고, 다음에는 DTMF와 SIP INFO에 대해 살펴보겠습니다.
"다시쓰는 SIP의 이해" 연재의 다른 글
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method
2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method
2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method
2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method
2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method
2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method
2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method
2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method
2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP
2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP
2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP
2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response
2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261
2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261
2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261
2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview
2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview
2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)
2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)
2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)
라인하트 유씨누스 (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________
