SIP Protocol Resolution and implementation (C and C ++ use Osip) 7

Handling 4xx responses

A specific 4xx response requires the processing of a specific UA instead of the Request Method.

If a 401 (unauthorized) or 407 (proxy authentication required) response is received, UAC should carry the credential to retry the request according to the authorization process (rfc3261 Section 22.2 and section 22.3.

If you receive a 413 (Request Entity too long) Response (rfc3261 section 21.4.11), the request contains an entity that is longer than the UAS limit. If possible, UAC should ignore the message body or use a shorter entity to retry the request.

If you receive a 415 (unsupported media type) Response (rfc3261 section 21.4.13), the request contains a media type not supported by UAS. UAC should only use the type listed in the accept header field of the response, the encoding used is listed in the accept-encoding header field of the response, and the language is listed in the Accept-Language header field of the response.

If a 416 (unsupported URI mode) Response (rfc3261 section 21.4.14) is received, request-Uri uses a URI mode not supported by the server. The client should try again in the sip uri mode.

If you receive a 420 (incorrect extension) Response (rfc3261 section 21.4.15 ), the request lists an extension option not supported by the proxy or uas in the require or proxy-require header domain. UAC should ignore the extensions listed in the response's unsupported header and try again.

In all the above cases, the request is modified accordingly and a new request is created. This new request creates a new transaction. The call-ID, to, and from header fields are consistent with the previous request, the CSeq Header field should contain a sequence number greater than the original sequence number.

For other 4xx responses, whether to try to resend new requests depends on the request methods and use cases.

Section 2 UAS Behavior

When an external request is processed by a UAS, there are a series of rules irrelevant to the request method to be followed. Rfc3261 section 12th provides guidance on how a UAS responds to requests within or outside a dialog.

Note that request processing is performed automatically. If a request is accepted, all States related to it must be changed to accepted. If a request is rejected, all the statuses related to it must be changed to rejected.

All UAS requests must be processed according to the steps described in this section (that is, starting with verification, and then checking methods, headers, and all other content mentioned in this section ).

Method check

Once a request is verified (or does not require verification), UAS must check the request method. If UAS knows but does not support this method, it must create a 405 response (the method is not allowed ). The method for creating a response is described in Section 8.2.6 of rfc3261. UAS must add an allow header field to the 405 response. The allow header field must list the methods supported by UAS. The allow header field is described in Section 20.5 of rfc3261.

If the request method is supported by the server, the process continues.

Header domain check

If UAS cannot understand a header field in the request (this indicates that this header field is not defined in this manual or other extensions), the server must ignore this header field and continue to process this request. UAS should ignore any header fields not required to process the request.

To header and request-Uri Header

The to header field contains the original receiver of the request sent by the sender identified by the From header field. The original receiver may or may not be the UAS to process the request because of call transfer or other proxy operations. When the to header domain of a request is different from that of UAs, UAS may use any policy to determine whether to accept the request. Even though UAS does not know the URI mode (for example, the uri of a Tel) or the to header does not identify a user recognized or valid by this UAS, however, we recommend that you accept this request. If the UAS decides to reject the request, it should construct a response with a status code of 403 (Forbidden) and send the response to the Transaction Layer of the server for transmission. Although the request-Uri header field identifies the UAS that processes the request. If request-Uri uses a mode not supported by UAS, it should use 416 (unsupported URI scheme) to reject the request. If request-Uri identifies an address that UAS does not want to accept, it should use 404 (not found) to respond. A UA binds its address-of-record to a specific contact address using the register method, and will be able to receive requests whose record-Uri is equal to the contact address. Other potential resources that can receive the request-Uri include the Contact Header domain used by the UA to establish or refresh the request or response.

Merge requests

If the to header field of a request does not contain tags, UAS must check the requests in the current transaction. If the tag flag, call-ID, and CSeq of the request from header domain exactly match those items of the transaction to be requested, however, the request does not match this transaction (the Basic matching rules are described in section 17.2.3 of rfc3261 ). The UAS kernel should construct a 482 (loop detected) response and deliver the transaction to the server.

A single request is sent to UAS multiple times from different paths, most of which are due to the presence of branches. UAS processes the first received request and sends a 482 (loop detected) Response to eliminate them.

Require header domain

Assume that UAs is an element suitable for processing this request. If so, check the require header field.

The require header domain is used by UAC to tell UAS about sip extensions that UAC wants UAS to support in order to process requests correctly. The format is described in Section 20.32 of rfc3261. If UAS does not recognize an optional flag listed in the require header domain, it will create and send a response with a status code of 420 (Bad extension. This UAS must add an unsupported header field and list the options it does not recognize in the require header field.

Note that the require header and proxy-require header cannot be used in a sip cancel request or an ACK corresponding to a non-2XX response. If these header fields appear in these requests, they must be ignored.

An ACK corresponding to the 2XX response must only contain the value of the require header field and proxy-require that appear in the initial request.

For example:

UAC-> UAS: Invite SIP: watson@bell-telephone.com Sip/2.0
Require: 100rel

UAs-> UAC: SIP/2.0 420 bad Extension
Unsupported: 100rel

This action ensures that the client server can interact without delay when all options are recognized by both parties. Interaction slows down when not all options are recognized by both parties (for example, the preceding example. For a pair of matching client server pairs, interaction is fast because the round-trip negotiation process is saved. In addition, this eliminates the Ambiguity Caused by server ignorance of client extensions. Some features are only applicable to specific terminals, such as call management domains.

Content Processing

If UAS recognizes any extensions requested by the client, UAS checks the message body and header fields of the message. If there is any message body type (identified by Content-Type), the language (identified by content-language) or encoding (identified by content-encoding) is not recognized, the message body is not optional (identified by the content-Disposition Header). UAS must use a 415 (unsupported media type) Response to reject the request. When a request contains a message body type that is not recognized by UAS, the response must contain an accept header and list all the message body types it recognizes. If the message body encoding is not recognized by UAS, the response must contain an Accept-encoding header domain to list all encodings that can be recognized by UAS. If the language of the message body contained in the request cannot be recognized by UAS, the response must contain an Accept-Language Header domain to indicate the language recognized by UAS. In addition to these checks, message body processing also depends on methods and types. For information on processing content-specific header fields, see section 7.4 OF rfc3261 and section 20.11 to section 20.15.

Application Extension

UAS that can be expanded cannot use extensions when a response is generated, unless the supported header field of the request supports this extension. If the extension is not supported, the server must rely only on the standard sip or the extension supported by the client to construct the response. In some special environments, if the server cannot process requests without using extensions, the server should send a 421 (extension required) response. This response indicates that a correct response cannot be constructed without a specific extension server. The extension to be used must be specified in the require header domain of the 421 response. This process is not recommended because it will destroy the interaction between the client and the server.

Any extension applied to a non-421 response must be listed in the require header domain of the response. Of course, the server cannot use extensions that are not listed in the requested supported header field. Therefore, the require header field in the response is only included in the standard RFC extension.

Process requests

If all the checks described in the previous sections are passed, the UAS processing will vary according to different methods. Rfc3261 section 10th describes register requests, section 11th describes options requests, section 13th describes INVITE requests, and section 15th describes bye requests.

Create response

When UAS constructs a response for a request, it will follow the general creation process described in the following sections. Specific behaviors are also required according to the specific response status code, but it is not described in this chapter.

Send a temporary response

A primary method-independent policy for creating a response is that UAS cannot send a temporary response to a non-invite request. Instead, UAS should immediately send a final response to a non-invite request.

When a 100 (trying) response is created, any timestamp header field that appears in the request must be copied to this 100 (trying) response. If the constructed response has a latency, UAS should add this latency in the timestamp header domain of the response. The latency must include the difference between sending and receiving requests, in seconds.

Header field and tag

The returned from header must be the same as the request's From header. The response's call-ID header must be the same as the request's call-ID header. The returned CSeq Header must be the same as the requested CSeq Header. The requested via header must be the same as the requested via header and must be in the same order.

If the requested to header field has a tag, the to header field in the response must be equal to the to header field in the request. However, if the to header field in the request does not contain tag tags, The uri of the to header field in the response must be equal to the uri of the to header field in the request. In addition, UAS must Add Tag tags to the to header of the response (100 (trying) is an exception, and it may already have tag tags ). The server uses this as the identifier of the UAS response. It is also part of the dialog ID. All responses to a request, including the final response and temporary response (except 100 (trying), must use the same tag. Create a tag in rfc3261 section 19.3.

Stateless UAS Behavior

A stateless UAs is a UAS that does not maintain the transaction state. It usually replies to the request, but after the final response is sent, it will discard all the statuses reserved in UAS. If a stateless UAS receives a resend request, it will re-create the response and send it, just like replying to a request sent for the first time. Unless the same request always receives the same response for the request method, UAS cannot be stateless. This rule prevents the registration service from being stateless. Stateless UAS does not use the Transaction layer; it directly receives requests from the transport layer and sends the responses directly to the transport layer.

Stateless UAS processes requests that do not require verification and the response to this request is predictable. If a request that does not need to be verified is processed by a stateful UAS, a large number of requests that do not need to be verified will slow down the creation of a large number of transactions or stop the UAS processing completely. This forms a denial of service environment. For more information, see section 26.1.5 of rfc3261.

The main behavior of stateless UAs is:

O A stateless UAS must not send a temporary (1xx) response.

O A stateless UAS must not transmit the response repeatedly.

O A stateless UAS must ignore ack requests.

O A stateless UAS must ignore the cancel request.

O The to header field tag of the response must be constructed as stateless-This method constructs the same tag for the same request. For more information about constructing tags, see section 19.3 of rfc3261.

In all other aspects, the behavior of a stateless UAs is the same as that of a stateful UAS. A uas can operate each new request in stateful and stateless modes.