설립된 세션에 대한 세션 파라미터를 재협상하기 위해서는 INVITE 메쏘드를 이용하여 새로운 다이얼로그를 만듭니다. 하지만, 호보류 상황에서 re-INVITE 메쏘드를 사용할 수 없는 상황이 있습니다.
엘리스의 전화기는 INVITE를 전송한 후 180 Ringing을 받아 링백톤을 재생합니다. 밥은 벨소리를 듣고 수화기를 들기 전에 호전환을 위해 호보류 버튼을 누릅니다. 즉, 200 OK가 전송되기 전에 호보류 서비스를 호출합니다.
re-INVITE는 INVITE / 200 OK / ACK 이후 세션 설립이 완료된 후에 사용하는 메쏘드입니다. 200 OK 이전에 새로운 다이얼로그를 생성할 수 없으므로 기존 다이얼로그를 유지하면서 세션 파라미터를 재협상해야 합니다. re-INVITE 메쏘드를 사용할 수 없는 상황을 위한 새로운 메쏘드가 필요합니다.
UPDATE 메쏘드는 RFC 3311 The SIP UPDATE Method에서 정의합니다. re-INVITE와 달리 UPDATE 메쏘드는 다이얼로그를 유지하면서 세션 파라미터를 재협상합니다.
UPDATE는 INVITE/200 OK/ACK 이전에 세션 협상이 완료된 상황에서 세션 파라미터를 변경하기 위해 사용하고, re-INVITE는 INVITE/200 OK/ACK 이후에 세션 파라미터를 변경하기 위해 사용합니다. 세션 협상 완료된 후 통화 중에 기존 다이얼로그를 유지하기 위해 UPDATE를 사용할 수 있지만, re-INVITE를 이용하여 새로운 다이얼로그를 생성하는 것이 일반적입니다.
UPDATE 메쏘드를 이용하여 세션 설립 이전에 G.711 코덱에서 G.729 코덱으로 변환하는 과정을 정리합니다.
1) 앨리스의 'INVITE (SDP1 : G.711 Offer)'
앨리스는 INVITE와 함께 G.711 코덱을 사용하는 미디어 세션에 대해 SDP 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
(SDP 정보는 생략, G711 코덱을 Offer)
Allow 헤더는 사용 가능한 메쏘드를 명기합니다. UAC인 앨리스는 'Allow:UPDATE'를 선언하여 UPDATE 메쏘드 사용이 가능합니다. 또한, 'Requires:100rel' 이므로 임의 응답(Provisional Response)에 대한 신뢰할 수 있는 응답을 제공할 수 있습니다.
2) 밥의 '180 Ringing (SDP1 : G.711 Answer)'
밥은 180 Ringing과 함께 G.711 코덱을 사용하는 미디어 세션에 대해 SDP 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
(SDP 정보는 생략, G.711 코덱을 Answer)
UAS인 밥은 'Allow :UPDATE'를 선언하여 UPDATE 메쏘드 사용이 가능합니다. RSeq가 주어져 신뢰할 수 있는 응답이 필요할 경우 사용할 수 있습니다.
3) 앨리스의 'UPDATE (SDP2 : G.729 Offer)
엘리스는 200 OK 이전에 UPDATE 메쏘드로 코덱을 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
(SDP 정보는 생략, G.729 코덱을 Offer)
4) 정리
나머지 과정은 생략합니다. UPDATE에 대한 200 OK 응답은 G.729 Answer를 합니다.
PRACK과 UPDATE에 대한 이해를 돕기 위해 RFC 3311 The SIP UPDATE Method의 예시를 살펴보겠습니다.
1) 1차 세션 파라미터 협상 (SDP 1)
1차 SDP 제안과 수락 (Offer & Answer) 협상은 엘리스의 INVITE 요청과 밥의 180 Ringing 응답으로 이루어졌습니다. 앨리스는 180 Ringing 응답을 정확히 수신했음을 통지하기 위해 PRACK을 발행합니다. 여기서, PRACK은 INVITE에 대한 200 OK 이전에 신뢰할만한 응답을 제공합니다.
2) 2차 세션 파라미터 협상 (SDP 2)
엘리스가 180 Ringing 이후에 링백톤을 듣다가 호보류 버튼을 누릅니다. 2차 SDP 제안과 수락 (Offer & Answer) 협상은 앨리스의 UPDATE 요청과 200 OK (UPDATE) 응답으로 이루어졌습니다.
3) 3차 세션 파라미터 협상 (SDP 3)
앨리스는 호보류를 해제합니다. 3차 SDP 제안과 수락 (Offer & Answer) 협상은 앨리스의 UPDATE 요청과 200 OK (UPDATE) 응답으로 이루어졌습니다.
PRACK과 UPDATE는 기존의 다이얼로그를 변경하지 않으면서 세션 설립 이전에 사용됩니다. 기본적으로 PRACK과 UPDATE는 용도가 전혀 다릅니다. PRACK은 100 Trying을 제외한 1xx 응답에 대한 신뢰할 수 있는 응답을 주기 위해 사용하고, UPDATE는 기존 다이얼로그 내에 세션 파라미터를 변경하기 위해서 사용합니다. re-INVITE는 세션 설립이 완료된 후에 새로운 다이얼로그로 세션 파라미터를 변경하기 위해 사용합니다.
https://brunch.co.kr/@linecard/188