RFC3261: SIP:9.2服务器行为

9.2 Server Behavior
9.2服务器行为

   The CANCEL method requests that the TU at the server side cancel a pending transaction.  The TU determines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request method is anything but CANCEL or ACK and applying the transaction matching procedures of Section 17.2.3.  The matching transaction is the one to be cancelled.

​CANCEL方法请求服务器端的TU取消挂起的事务。TU通过接受CANCEL请求，然后假设请求方法不是CANCEL或ACK，并应用第17.2.3节的事务匹配程序来确定要取消的事务。匹配的事务是要取消的事务。

   The processing of a CANCEL request at a server depends on the type of server.  A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it.  See Section 16.10 for proxy treatment of CANCEL.

​服务器上对CANCEL请求的处理取决于服务器的类型。无状态代理将转发它，有状态代理可能会响应它并生成自己的一些CANCEL请求，UAS将响应它。有关CANCEL的代理处理，请参阅第16.10节。

   A UAS first processes the CANCEL request according to the general UAS processing described in Section 8.2.  However, since CANCEL requests are hop-by-hop and cannot be resubmitted, they cannot be challenged by the server in order to get proper credentials in an Authorization header field.  Note also that CANCEL requests do not contain a Require header field.

​UAS首先根据第8.2节中描述的通用UAS处理来处理CANCEL请求。但是，由于CANCEL请求是逐跳的，无法重新提交，因此服务器不能为了在Authorization报头字段中获得正确的凭据而对其提出质疑。还要注意，CANCEL请求不包含Require报头字段。

   If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist).  If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request.  If it has, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request.  If the UAS has not issued a final response for the original request, its behavior depends on the method of the original request.  If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated).  A CANCEL request has no impact on the processing of transactions with any other method defined in this specification.

如果UAS没有根据上面的过程找到CANCEL的匹配事务，它应该用481（呼叫支路/事务不存在）来响应CANCEL。如果原始请求的事务仍然存在，则UAS在接收CANCEL请求时的行为取决于它是否已经发送了原始请求的最终响应。如果有，CANCEL请求对原始请求的处理没有影响，对任何会话状态都没有影响，也对为原始请求生成的响应没有影响。如果UAS没有对原始请求发出最终响应，其行为取决于原始请求的方法。如果原始请求是INVITE，UAS应立即用487（请求终止）响应INVITE。CANCEL请求对使用本规范中定义的任何其他方法处理事务没有影响。

   Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response.  This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same.  The response to CANCEL is passed to the server transaction for transmission.

​无论原始请求的方法如何，只要CANCEL与现有事务匹配，UAS就会用200（OK）响应来回答CANCEL请求本身。该响应按照第8.2.6节中描述的程序构建，注意CANCEL响应的To标签和原始请求响应中的To标签应相同。对CANCEL的响应被传递给服务器事务以进行传输。