9 Canceling a Request
在前面的章节中，我们已经讨论了关于标准UA的处理流程，包括method的请求所产生的请求和处理响应流程。在这个章节，我们讨论CANCEL，它是一个目的性比较强的method。
CANCEL请求和它的名字一样，它是用来取消前面由客户端发送的请求。具体来说，它要求UAS退出前面的请求，并且针对那个请求生成一个错误响应。如果UAS已经针对一个请求生成了最终响应回复，这时，CANCEL再次针对这个请求发送取消的话是无效的。因为这个原因，大部分的CANCEL请求都需要服务器端耗费比较长的时间做出响应回复。因此，对于INVITE来说，使用CANCEL是最好的办法，这样就可以通过一个比较长的时间生成响应回复。 在以上使用环境中，接收CANCEL请求的UAS，在还没有发送最终响应时，UAS将会处理一个“stop ringing”，然后再针对这个INVITE发送一个特别错误响应码（一个487）。
代理服务器和用户代理客户端都可以创建和发送CANCEL响应。Section 15 讨论了UAC取消INVITE请求的条件，Section 16.10 讨论了代理使用CANCEL的细节。
有状态代理响应一个CANCEL请求，而不是简单前转一个从下游要素中收到的响应。因为那个原因，CANCEL被看作是一个“hop-by-hop”请求，因为它被回复是在每个有状态代理hop的节点上的。
9.1 Client Behavior
一个CANCEL请求只能用来取消一个INVITE请求，不应该发送去取消其他的请求。
因为除了INVITE请求以外，其他请求会马上响应这个请求，因此，发送一个CANCEL请求到一个非INVITE请求总会创建一个互相竞争的条件。
以下流程用来构建一个CANCEL请求。在CANCEL请求中的Request-URI，Call-ID， To，CSeq的数字部分，和From头域值必须是确认的，这些参数，包括标签是在被取消的请求中。通过客户端构建的CANCEL中必须只有一个Via头值匹配被取消的请求中的最顶部的Via头域值。使用这些头域中同样的值允许此CANCEL匹配它将要取消的请求。（Section 9.2 说明了匹配是如何发生的）。但是，此CSeq头域中的method部分必须含有一个CANCEL的值。通过这样的处理流程，作为一个事务，在它的具有权限范围内，CANCEL才可以被完整确认和处理。 （参考 Section 17）。
如果这个被正在取消的请求中包含了一个Route头域值，此CANCEL请求必须包括那个 Route头域的值。
这个要求是一个必须条件，通过这样的处理要求，无状态代理才能正确地路由此CANCEL请求。
CANCEL请求中一定不能包含任何Require或Proxy-Require头。
一旦CANCEL被创建以后，客户端应该检查针对正在被取消的请求，它这里是否收到任何响应消息（临时响应或最终响应）（因此，这里的请求是一个原始请求）。
如果客户端没有收到任何临时响应，CANCEL一定不能被发送；相反，客户端必须在发送请求之前等待临时响应到达。如果初始的请求已经生成了一个最终响应，这个请求就不应该被发送出去了，这是一个无效操作，因为这个CANCEL请求已经对这个初始请求没有任何作用，这个请求已经生成了最终响应。当客户端决定发送CANCEL时，它针对这个CANCEL创建一个客户端事务，然后传输这个事务，包括这个CANCEL请求关联的目的地地址，端口和传输方式内容。针对这个CANCEL请求定义的目的地地址，端口和传输方式必须和发送初始请求的互相确认。
在接收前一个请求的响应之前，如果被允许发送CANCEL，在初始请求之前，服务器 可以接收这个CANCEL。
注意，两种事务-相对于初始请求的事务和CANCEL事务，它们都是独立完成的。但是，一个正在处理取消请求的UAC不能依赖于针对初始请求的响应-487（请求结束），因为需要保持和RFC 2543的一致性，UAS将不会生成一个这样的响应。如果在64*T1秒内，针对初始请求没有收到最终响应的话，
这个客户端应该可以认为这个初始事务可以被取消，并且应该销毁这个正在负责初始请求的客户端事务。
9.2 Server Behavior
CANCEL method要求在服务器端的事务用户（TU）取消待处理的事务。TU通过执行CANCEL请求决定事务是否取消，而且假设请求method是任何一种method，但是 CANCEL或者ACK可以应用事务匹配流程，具体匹配流程在Section 17.2.3有所讨论。这个匹配的事务是其中一个将被取消的事务。
在服务器端关于执行CANCEL请求的流程完全取决于服务器类型。一个无状态代理会前转这个取消请求，一个有状态代理可能会有响应消息，生成它自己的一些CANCEL请求，然后UAS回复这些响应。查阅Section 16.10 获得关于CANCEL的代理处理方式。
根据标准UAS的处理方式，UAS首先处理CANCEL请求，具体的处理方式描述在Section 8.2有更多介绍。但是，因为CANCEL请求是hop-by-hop的处理方式，因此它不能被重新提交。服务器端也不会验证其在Authorization头中获得安全验证消息。注意，CANCEL 请求也不包含Require头域。
根据以上所说的处理流程，如果UAS没有发现一个针对CANCEL的匹配事务的话，它应该对这个CANCEL响应一个481错误码（Call Leg/Transaction Does Not Exist）。如果关联初始请求的事务仍然存在的话，收到CANCEL请求的UAC的执行方式取决于这个UAC是否已经针对关联的初始请求已经发送了最终响应。如果已经发送了最终响应，那么这个CANCEL请求对初始请求处理没有任何影响，对任何会话状态没有任何影响，对初始请求生成的响应没有任何影响。如果这个UAS没有发送最终响应的话，这个UAS的处理流程则取决于初始请求的method。进一步说，如果初始请求是一个INVITE method，这个UAS应该对这个INVITE马上回复一个487错误码（Request Terminated）。CANCEL请求不会对本规范中所定义的其他method所产生的事务有影响，仅对自己的method所产生的事务有影响。
无论初始请求的method是何种method，只要CANCEL匹配了一个现存的事务，这个UAS应该自己应答这个CANCEL，并且返回一个200（OK）响应。这个响应消息是通过以下处理流程来创建的，具体创建流程查阅Section 8.2.6，这里需要注意，对于CANCEL来说，这个响应中的这个To标签和初始请求中的响应中的To标签应该相同。这个CANCEL的回复响应被传递到这个服务器的事务处理进行传输。
继续发布……
关注微信公众号：asterisk-cn，获得有价值的Asterisk行业分享
Asterisk freepbx，FreeSBC技术文档：www.freepbx.org.cn
融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com
Asterisk / FreePBX / FreeSBC中国合作伙伴，官方qq技术分享群（3000人）：589995817
