本帖最后由 yyh19820713 于 2022-11-9 14:02 编辑
协议关于CANCEL和487 Request Terminated讲得很清晰:
//CANCEL用于取消Client发送的一个请求,比如发送INVITE请求后,又发送CANCEL取消这个INVITE请求 //尤其用于UAC要求UAS终止该请求并且针对该请求产生一个error response,比如主叫发送一个CANCEL给被叫,被叫会针对INVITE Request(务必注意,不是针对CANCEL回response)回复一个487Request Terminated //对于已经收到UAS已经回复final response的请求没有任何影响 //CANCEL对于需要server很长时间响应的请求很有用。 //因此CANCEL对于INVITE请求最合适,因为INVITE需要很长时间才能得到响应。 The CANCEL request, as the name implies, isused to cancel a previous request sent by a client. Specifically, it asks the UAS to ceaseprocessing the request and to generate an error response to that request. CANCEL has no effect on a request to whicha UAS has already given a final response. Because of this, it is most useful toCANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITErequests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCELrequest for an INVITE, but has not yet sent a final response, would "stopringing", and then respond to the INVITE with a specific error response (a487).
//两个transaction独立 //UAC - User Agent Client - 发起请求的一方,比如发INVITE请求 //UAS - User Agent Server - 收到请求的一方 //对于原始请求比如INVITE请求的transaction和CANCEL transaction,二者是独立的。 //但是UAC并不依赖于487来取消一个请求,因为对于基于RFC2543的UAS并不产生487这样的响应。 //如果在64*T1秒内未收到最终响应,UAS应该考虑取消原始请求的transaction并销毁用于处理原始请求的client transaction. Note that both the transactioncorresponding to the original request and the CANCEL transaction will completeindependently. However, a UAC canceling a request cannotrely on receiving a 487 (Request Terminated) response for the original request,as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for theoriginal request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), theclient SHOULD then consider the original transaction cancelled and SHOULDdestroy the client transaction handling the original request.
|