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