SIP protocol parsing and implementation (C and C ++ use Osip) 9

Chapter 6 cancel a request

The previous chapter describes the general behavior of UA to create requests for all methods and process requests to generate responses. This chapter discusses a purposeful method called cancel.

The cancel request, like its name implies, is used to cancel a previous request sent by a client. In details, it causes UAS to terminate the processing of this request and construct an error response for this request. The cancel request is invalid for the request that has sent the final response. Therefore, it is often used for requests that require the server to process for a long time. Therefore, for invite requests that require a long response time, It is very suitable to use the cancel request to cancel it. A uas that has received a cancel request to cancel the invite and has not yet sent a final response will "stop logging" and immediately send a response with a specific error code (487) to this invite request.

Cancel requests can be created and sent by the proxy or UAC. Section 15th of rfc3261 discusses under what circumstances UAC will cancel an invite request. Rfc3261 section 16.1 discusses the cancel requests of the proxy server.

A stateful proxy server must respond to cancel, instead of simply forwarding the response received from the next element in the network stream. Therefore, cancel is a "Hop-by-Hop" request, that is, every stateful proxy needs to respond to it.

Section 1 client Behavior

A cancel request should not be used to cancel a non-invite request.

Because non-invite requests are responded immediately, sending cancel for non-invite requests will cause competition (non-invite and cancel who are first processed ).

The following process is used to construct a cancel request. The request-Uri, call-ID, to, CSeq numeric parts of the cancel request must be the same as the From header fields and the tags in these header fields. A cancel request constructed by a client must contain only one via header Domain value, which is consistent with the value at the top of the Via header domain of the request to be canceled. Make the value of these header fields in cancel consistent with the value of the header field of the request to be canceled to match the request to be canceled (rfc3261 section 9.2 describes how to match ). However, the method name part of the CSeq Header must be cancel to correctly identify and process cancel requests as a transaction (rfc3261 section 17th ).

If the request to be canceled contains the Route Header domain. Cancel must also contain the Route Header field and ensure that the value is consistent.

This is to allow the stateless proxy server to properly route cancel requests.
 
The cancel request must not contain any require or proxy-require header fields.

Once the cancel request is constructed, the client should check whether it has received a response to the message to be canceled (temporary response and final response) (the request to be canceled will be the original request later ).

If no temporary response is received, the cancel request cannot be sent. Before sending a cancel request, the client must wait for receiving a temporary response. If a final response is received, the cancel request cannot be sent. It is invalid to send a cancel request to an original request that has sent the final response. When the client decides to send a cancel request, it creates a client transaction for the cancel request along with the target address and port for transmission. The destination address, port, and transmission mode must be consistent with the original request.
 
If you allow sending a cancel request before receiving a temporary response, the server may receive the cancel request before receiving the original request.
 
Note that the transactions in the cancel request and those in the original request must be completely independent. In any case, a UAC cannot cancel the original request by receiving a 487 (request terminated) response to the original request, because UAS in RFC 2543 will never create such a response. If the final response is not received within 64 * T1 seconds (defined in rfc3261 section 17.1.1.1), the client should cancel the original transaction and delete the transaction processing the original request.

Section 2 server Behavior

The request of the cancel method cancels an unselected transaction in the server tu. When receiving a cancel request, tu indicates that a transaction is to be canceled, and the method of this transaction cannot be cancel or Ack. Then, the transaction that the TU finds Based on the transaction matching method described in rfc3261 section 17.2.3 is the transaction to be canceled.

The process of processing a cancel request on the server depends on the server type. The stateless proxy server will forward the cancel request. The stateful proxy server responds to the cancel request and creates some of its own cancel requests, which are responded by UAS. Rfc3261 section 16.10 describes how the proxy server processes cancel requests.

A uas processes the cancel request according to the general process described in section 8.2 of rfc3261. However, although the cancel request is one-hop and cannot be submitted multiple times, the server cannot challenge it in the Authorization Header domain to obtain the appropriate creden. Note that the cancel request cannot contain the require header domain.

If the UAS cannot find the transaction to be canceled by the cancel request based on the above processing process, it should send a 481 (call LEG/transaction does not exist) response to the cancel request. If the transaction of the original request exists, the behavior of UAs after receiving the cancel request depends on whether it sends the final response. If a final response has been sent, the cancel request will not affect the processing of the original request, the session status, and the structure of the original request response. If UAS does not send a final response, its behavior depends on the method of the original request. If the original request is an invite method, UAS should immediately send a 487 (request terminated) response to this invite request ). This Manual does not define how to handle transactions of other methods after receiving the cancel request.

Regardless of the method of the original request to be canceled, UAS sends a 200 (OK) response as long as the cancel request matches an existing transaction. The structure of this response follows the process described in section 8.2.6 of rfc3261. It is worth noting that the tag of the to header field in the response to the cancel request should be consistent with the tag of the to header field in the response to the original request. The response to the cancel request is sent to the server transaction for transmission.