[RFC 3261] CHAPTER 9. Canceling a Request

CHAPTER 9. Canceling a Request

 

• CANCEL request은 클라이언트가 보낸 기존 request을 취소할 때 사용한다.
• UAS가 이미 final response(200 OK, 486 Busy Here, 404 Not Found 등)을 보냈다면, 그 이후에 CANCEL request이 와도 아무 효과가 없다.

INVITE에 대해 CANCEL을 받으면 → 벨소리(호 연결 시도)를 멈추고 → INVITE에 대해 487(Request Terminated) response을 보낸다.

 

(9.1) Client Behavior

• INVITE request을 취소할 때만 request해야 한다.
  • 다른 request은 response이 빠르기 때문에 race condition이 발생할 수 있다.

CANCEL sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP 10.1.3.33;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 2 CANCEL
Contact: <sip:alice@atlanta.com>
Content-Length: 0

 

CANCEL 구성

• Request-URI, Call-ID, To, From, via, Route, CSeq number 는 기존 request(=INVITE)과 동일.
  • 기존 request의 최상단 Via 값 하나만 있어야 한다.
  • 단, CSeq 메소드는 CANCEL 이어야 한다.
• Require, Proxy-Require 헤더는 금지

클라이언트는 기존 request에 대한 (provisional 또는 final) response를 받았는지 확인해야 한다.

 

 

CANCEL 규칙

• 1xx(provisional response)을 받은 후에만 전송이 가능하다.
• CANCEL은 원래 INVITE와는 별개의 새 트랜잭션으로 처리된다.
• UAC는 CANCEL request에 대한 response(200 OK, 487 등)을 반드시 기다려야 한다.
• 64*T1 (타이머 값) 동안 최종 response이 없으면 클라이언트는 request가 취소된 것으로 간주하고, 클라이언트 트랜잭션을 종료해야 한다.

 

(9.2) Server 동작

CANCEL 메소드는 서버 측의 TU에게 현재 처리 중인 트랜잭션을 취소하라는 request이다.
CANCEL은 자체 트랜잭션을 가지며, 서버는 CANCEL request에 대해 200 OK response을 준다.

 

서버의 종류에 따라 CANCEL request 처리 방식이 다르다.

• stateless 프록시의 경우, CANCEL을 그대로 전달
• stateful 프록시/UAS의 경우, 직접 처리
  • CANCEL request는 hop-by-hop이며, 재전송 될 수 없기 때문에 authorization 헤더로 인증을 요구할 수 없다.

• 트랜잭션이 없는 경우 → 481(Call/Transaction Does Not Exist) response
• 트랜잭션이 있는 경우 → 무조건 200 OK response
  • final response를 보냈는지 여부에 따라 처리 방식이 다르다.
  • 보낸 경우 → 아무 영향이 없다.
  • 보내지 않은 경우(INVITE 진행 중)→ 487(Request Terminated) response