9 Canceling a Request
在前面的章節(jié)中，我們已經(jīng)討論了關于標準UA的處理流程，包括method的請求所產(chǎn)生的請求和處理響應流程。在這個章節(jié)，我們討論CANCEL，它是一個目的性比較強的method。
CANCEL請求和它的名字一樣，它是用來取消前面由客戶端發(fā)送的請求。具體來說，它要求UAS退出前面的請求，并且針對那個請求生成一個錯誤響應。如果UAS已經(jīng)針對一個請求生成了最終響應回復，這時，CANCEL再次針對這個請求發(fā)送取消的話是無效的。因為這個原因，大部分的CANCEL請求都需要服務器端耗費比較長的時間做出響應回復。因此，對于INVITE來說，使用CANCEL是最好的辦法，這樣就可以通過一個比較長的時間生成響應回復。 在以上使用環(huán)境中，接收CANCEL請求的UAS，在還沒有發(fā)送最終響應時，UAS將會處理一個“stop ringing”，然后再針對這個INVITE發(fā)送一個特別錯誤響應碼（一個487）。
代理服務器和用戶代理客戶端都可以創(chuàng)建和發(fā)送CANCEL響應。Section 15 討論了UAC取消INVITE請求的條件，Section 16.10 討論了代理使用CANCEL的細節(jié)。
有狀態(tài)代理響應一個CANCEL請求，而不是簡單前轉一個從下游要素中收到的響應。因為那個原因，CANCEL被看作是一個“hop-by-hop”請求，因為它被回復是在每個有狀態(tài)代理hop的節(jié)點上的。
9.1 Client Behavior
一個CANCEL請求只能用來取消一個INVITE請求，不應該發(fā)送去取消其他的請求。
因為除了INVITE請求以外，其他請求會馬上響應這個請求，因此，發(fā)送一個CANCEL請求到一個非INVITE請求總會創(chuàng)建一個互相競爭的條件。
以下流程用來構建一個CANCEL請求。在CANCEL請求中的Request-URI，Call-ID， To，CSeq的數(shù)字部分，和From頭域值必須是確認的，這些參數(shù)，包括標簽是在被取消的請求中。通過客戶端構建的CANCEL中必須只有一個Via頭值匹配被取消的請求中的最頂部的Via頭域值。使用這些頭域中同樣的值允許此CANCEL匹配它將要取消的請求。（Section 9.2 說明了匹配是如何發(fā)生的）。但是，此CSeq頭域中的method部分必須含有一個CANCEL的值。通過這樣的處理流程，作為一個事務，在它的具有權限范圍內，CANCEL才可以被完整確認和處理。 （參考 Section 17）。
如果這個被正在取消的請求中包含了一個Route頭域值，此CANCEL請求必須包括那個 Route頭域的值。
這個要求是一個必須條件，通過這樣的處理要求，無狀態(tài)代理才能正確地路由此CANCEL請求。
CANCEL請求中一定不能包含任何Require或Proxy-Require頭。
一旦CANCEL被創(chuàng)建以后，客戶端應該檢查針對正在被取消的請求，它這里是否收到任何響應消息（臨時響應或最終響應）（因此，這里的請求是一個原始請求）。
如果客戶端沒有收到任何臨時響應，CANCEL一定不能被發(fā)送；相反，客戶端必須在發(fā)送請求之前等待臨時響應到達。如果初始的請求已經(jīng)生成了一個最終響應，這個請求就不應該被發(fā)送出去了，這是一個無效操作，因為這個CANCEL請求已經(jīng)對這個初始請求沒有任何作用，這個請求已經(jīng)生成了最終響應。當客戶端決定發(fā)送CANCEL時，它針對這個CANCEL創(chuàng)建一個客戶端事務，然后傳輸這個事務，包括這個CANCEL請求關聯(lián)的目的地地址，端口和傳輸方式內容。針對這個CANCEL請求定義的目的地地址，端口和傳輸方式必須和發(fā)送初始請求的互相確認。
在接收前一個請求的響應之前，如果被允許發(fā)送CANCEL，在初始請求之前，服務器 可以接收這個CANCEL。
注意，兩種事務-相對于初始請求的事務和CANCEL事務，它們都是獨立完成的。但是，一個正在處理取消請求的UAC不能依賴于針對初始請求的響應-487（請求結束），因為需要保持和RFC 2543的一致性，UAS將不會生成一個這樣的響應。如果在64*T1秒內，針對初始請求沒有收到最終響應的話，
這個客戶端應該可以認為這個初始事務可以被取消，并且應該銷毀這個正在負責初始請求的客戶端事務。
9.2 Server Behavior
CANCEL method要求在服務器端的事務用戶（TU）取消待處理的事務。TU通過執(zhí)行CANCEL請求決定事務是否取消，而且假設請求method是任何一種method，但是 CANCEL或者ACK可以應用事務匹配流程，具體匹配流程在Section 17.2.3有所討論。這個匹配的事務是其中一個將被取消的事務。
在服務器端關于執(zhí)行CANCEL請求的流程完全取決于服務器類型。一個無狀態(tài)代理會前轉這個取消請求，一個有狀態(tài)代理可能會有響應消息，生成它自己的一些CANCEL請求，然后UAS回復這些響應。查閱Section 16.10 獲得關于CANCEL的代理處理方式。
根據(jù)標準UAS的處理方式，UAS首先處理CANCEL請求，具體的處理方式描述在Section 8.2有更多介紹。但是，因為CANCEL請求是hop-by-hop的處理方式，因此它不能被重新提交。服務器端也不會驗證其在Authorization頭中獲得安全驗證消息。注意，CANCEL 請求也不包含Require頭域。
根據(jù)以上所說的處理流程，如果UAS沒有發(fā)現(xiàn)一個針對CANCEL的匹配事務的話，它應該對這個CANCEL響應一個481錯誤碼（Call Leg/Transaction Does Not Exist）。如果關聯(lián)初始請求的事務仍然存在的話，收到CANCEL請求的UAC的執(zhí)行方式取決于這個UAC是否已經(jīng)針對關聯(lián)的初始請求已經(jīng)發(fā)送了最終響應。如果已經(jīng)發(fā)送了最終響應，那么這個CANCEL請求對初始請求處理沒有任何影響，對任何會話狀態(tài)沒有任何影響，對初始請求生成的響應沒有任何影響。如果這個UAS沒有發(fā)送最終響應的話，這個UAS的處理流程則取決于初始請求的method。進一步說，如果初始請求是一個INVITE method，這個UAS應該對這個INVITE馬上回復一個487錯誤碼（Request Terminated）。CANCEL請求不會對本規(guī)范中所定義的其他method所產(chǎn)生的事務有影響，僅對自己的method所產(chǎn)生的事務有影響。
無論初始請求的method是何種method，只要CANCEL匹配了一個現(xiàn)存的事務，這個UAS應該自己應答這個CANCEL，并且返回一個200（OK）響應。這個響應消息是通過以下處理流程來創(chuàng)建的，具體創(chuàng)建流程查閱Section 8.2.6，這里需要注意，對于CANCEL來說，這個響應中的這個To標簽和初始請求中的響應中的To標簽應該相同。這個CANCEL的回復響應被傳遞到這個服務器的事務處理進行傳輸。
繼續(xù)發(fā)布……
關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享
Asterisk freepbx，F(xiàn)reeSBC技術文檔：www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
Asterisk / FreePBX / FreeSBC中國合作伙伴，官方qq技術分享群（3000人）：589995817
