RFC3261 sip协议------cancel请求

 Cancel请求

Cancel请求是用来取消一个之前已经发送过得请求的，如果这个请求已经得到了应答，那么Cancel请求是失效的。所以Cancel请求一般都用是用来取消invite请求的，因为invite的请求得到最终应答的时间比较长。对于一个有状态的UAS来说，Cancel请求是点对点的，就是Cancel请求需要每个proxy服务器进行处理和应答。而无状态服务器只是转发这个cancel请求。

UAC behavior

UAC端只能发送invite请求的cancel请求，这是应为其他的请求在UAS端处理过快，cancel请求不会起作用。为了匹配要取消的invite请求，构建cancel请求时，要把要取消的invite请求的request-uri、call-id、to、cseq以及from头域都要复制到cancel请求中去。cancel请求构建的时候via头域的值，只能是invite请求的第一个via头域。如果invite请求中包含了route头域，那么cancel请求也要包含这个头域，这是为了能让无状态服务器能够路由cancel消息。

在cancel请求构造成功之后，UAC准备发送之前，需要检查是否收到了临时或者是最终的应答，如果未收到临时应答，UAC不能发送cancel请求，直到有一个临时应答发送回来才能发送。这是因为，如果在未收到临时应答就发送cancel请求，那么cancel请求就可能要比它要取消的invite请求先一步到达。

UAS behavior

在UAS这边，如果收到了一个cancel请求，如果是无状态服务器，那么就会直接转发。如果是有状态服务器，那么这个服务器会处理这个请求，并产生一些自己的cancel请求，发送出去。

在有状态服务器中，首先要对这个cancel进行匹配，如果没有匹配到这个cancel请求要取消的原始请求，那么服务器发送481状态（Call Leg/Transaction Does Not Exist）应答给客户端。如果匹配到了这个cancel请求的原始请求，那么是否取消这个原始请求，取决于是否已经发送了最终应答，如果已经发送了最终应答，那么cancel请求失效。如果未发送最终应答，如果最终应答是一个invite请求，那么服务器发送一个487应答给客户端。无论原始请求是什么方法，如果原始请求与cancel请求已经匹配，那么服务器就会发送一个200ok的应答给客户端。