SIP CANCEL 取消請求

SIP CANCEL 取消請求：

• 要取消的那個關聯請求，稱為原始請求。
• 只是嘗試針對原始請求的 Transaction 進行取消，沿用原始請求的 Via branch 找原始請求的 Transaction：
• 找不到 Transaction 回 481 Call Leg/Transaction Does Not Exist。
• 已送成功回應算找不到 Transaction？
• 已送失敗回應算找不到 Transaction？(也就是 Transaction 狀態不是 Proceeding)
• 否則回 200 OK。
• 原始請求：
• 已最後回應則忽略。
• 取消動作並回應 487 Request Terminated。
• 可能一下子還不會有最後回應的請求才需要，通常會先有暫時回應。馬上 (200ms 以內) 就最後回應的請求不需要暫時回應，送 CANCEL 到對方收到可能已經發出最後回應而造成 race condition。
• CANCEL 不是 INVITE 專用，但目前只有 RFC3261 的 INVITE 符合，Client 只對 INVITE 發 CANCEL。Server 設計應當對所有請求通用 (除了 CANCEL 和 ACK 以外)，以後或許有別的請求可 CANCEL。
• CANEL 不屬於 Regular Transaction

CANCEL INVITE 讓 UAS 停止處理 (如「停止振鈴」)。re-INVITE 可以 CANCEL 嗎？

註：RFC3261 限制 CANCEL 收到任何回應之後才能發，確保 Server 收到 CANCEL 前收到原始請求。RFC2543 沒此規定，所以 CANCEL 有可能比原始請求先到。

CANCEL 可由 UAC 或 Proxy 產生。CANCEL 屬於「點對點」請求，Stateful Proxy 不是只是轉送，需回應 CANCEL，並對所有關聯 branch 進行 CANCEL。另外，也不能加上 Authorization 要求重送來盤問取得適當的憑證。

 在 RFC2543，CANCEL 和 INVITE 的 Transaction 是混在一起的，UAS 收到 CANCEL 後就不回應原始請求，不會回 487。

Client 行為

建立 CANCEL 請求：

• 沿用原始請求的 Request-URI、Call-ID、CSeq 的序號、From (含 tag)、和 To (含 tag)。CSeq 的 Method 是 CANCEL。
• 註：To tag 未必有，含 To tag 也似乎不必要。
  
• 只有一個 Via，和原始請求的頂頭 Via 一致，好讓 Server 比對出要取消的 Transaction。
• 須包含原始請求的 Route，讓 Stateless Proxy 能夠適當地繞 CANCEL。(在 RFC2543 沒清楚定義)
• 不能有 Require 或 Proxy-Require。(應該被忽略。都要取消了，額外要求也就沒意義。)

傳送 CANCEL

• 已收到最後回應，送了也沒用，所以不該送。
• 等到收到任何暫時回應才能送，否則 Server 有可能比原始請求還早收到 CANCEL。但 RFC2543 不用等到收到任何暫時回應。此時可能有 To tag，也可能沒有。
• 如同一般 Transaction 建立 Client Transaction 附上和原始請求仝款的目的位址、port 和 transport 傳送請求。

處理 CANCEL 回應 (不用理會結果如何)

• 481 Call Leg/Transaction Does Not Exist：要取消的 Transaction 不存在。(不用取消了？)
  
• 200 OK：要取消的 Transaction 存在，但未必表示取消成功。
  
• 逾時：
  

收原始請求的回應 (就跟原本的處置一樣，都會移除原始請求的 Client Transaction)

• 200 OK：原始請求成功，取消失敗。
• 487 Request Terminated：取消成功。(註：RFC2543 UAS 不會送 487，只能等逾時)
• 其它錯誤：原始請求失敗也就不用取消了。
• 逾時 ( 64*T1 秒)：視為已經取消。

註：就 INVITE 而言，UAC 發出 CANCEL 後 dialog 仍 confirmed，只能先 ACK 再 BYE 結束 dialog。early dialog 可嘗試用 CANCEL 結束，也可以用 BYE 結束。被叫端只能收到 ACK 後 BYE。

Proxy 轉送最後回應時，必須取消進行中的所有相關 Client Transaction。這之前或當下，原始請求仍可能收到其它 branch 產生的 200 OK。

如果 Proxy 的 Client Transaction (Timer C) 逾時，此時可基於目前狀況 (如使用率) 重設 Timer 動態延長 Transaction 生存時間。或者結束 Client Transaction，此時如果有收到暫時回應，Proxy 必須產生 Transaction 的 CANCEL (等多久？)。
如果沒收到暫時回應，則視為收到 408 Request Timeout。

Server 行為

CANCEL 要求 Server 端 TU，取消符合的 Transaction。註：CANCEL 和 ACK 不能取消。

不同 Server 類型有不同 CANCEL 處理方式：

• UAS：
• 如同通用 UAS 方式處理，但由於 CANCEL 是 hop-by-hop 請求，不能加上 Authorization 要求重送來盤問取得適當的憑證。
• 找不到參照的 Transaction，回  481 Call Leg/Transaction Does Not Exist。
• 回 200 OK。
• 原始請求已回最後回應，忽略。
• 如果原始請求是 INVITE，INVITE 回 487 Request Terminated。
  
• Stateless UAS：忽略 CANCEL。因為沒紀錄 Transaction，無法針對 Transaction 取消。
  
• Stateless Proxy：轉送。
• Stateful Proxy：
• 找不到參照的 Transaction，轉送。
• 回 200 OK，並對所有進行中 branch 產生 CANCEL。
• INVITE Expire 逾時
  
• Redirect Server：回 2xx 並結束參照的 Transaction，自己不產生任何請求。
  

參考

1. RFC3261 §9 Canceling a Request、§16 Proxy Behavior、§8.2.7 Stateless UAS Behavior、§8.3 Redirect Servers、。