SIP Protocol Resolution and implementation (C and C use Osip) 5

Chapter 5 General User Agent Behavior

A user agent represents a terminal system. It contains a user proxy client (UAC) and a user Proxy Server (UAs ). UAC creates a request and UAS responds to the request. UAC can create external event-based requests (for example, a user presses a button and a signal in the PSTN line) and process a response. UAS can receive requests and construct response messages to requests based on user input, external excitation, program running results, or other mechanisms.

When a UAC sends a request, the request may be transmitted through multiple proxy servers, and the proxy server transmits the request to UAS. When the UAS creates a response, the response is sent to the UAC in reverse direction.

The processing of UAC and UAS depends on two main factors. First, it depends on whether the request and response are in or out of the conversation, and second on the Request Method. The complete description of the dialog in Chapter rfc3261. A dialog indicates the relationship between two UA terminals. It is established by a specific sip method such as invite.

This chapter describes the processing rules of UAC and UAS for non-dialog request methods.

For security-related questions about requests and responses, see section rfc3261 26th. This includes the mechanism for mutual verification between UAC and UAS.

Section 1 UAC Behavior

Request Creation

This section describes the non-dialog behaviors of UAC.

A valid SIP request must contain at least the following header fields: to, from, CSeq, call-ID, Max-forwards, and. These header fields are mandatory in the SIP request. They provide support for many message routing services. These services include: Message locating, response routing, restricted message propagation, message order, and unique identifier of a transaction. Request lines containing methods, request Uris, and SIP versions are also mandatory.

An invite request outside a session is used to create a meeting (rfc3261 section 13th), and an options request is used to query the ability (rfc3261 section 11th ).

Request-Uri

The initial request-URI must be set to the same value as the to header field. A notable exception is the register method. Rfc3261 section 10th describes how to set the request-Uri of the register method.

For some special reasons, some pre-existing routing settings will affect the request-Uri of a message. The pre-existing route settings are used to identify the order of a series of servers. The non-Session requests sent by UAC are transmitted by the server in this order. Generally, the user or service provider sets the UA or processes it by a non-Sip mechanism. If the provider wants to set an external proxy for UA, it is strongly recommended to use pre-existing routing settings and provide a URI for this proxy. In the method that contains the pre-existing route settings and contains multiple route header fields, the request-Uri setting method is described in Chapter 12.2.1.1 of rfc3261.

To header domain

The to header field first specifies the expected logical receiver of the request, the address reported by the user, or the resource of the Request target. This may or may not be the final receiver of the request. The to header domain may contain the SIP or sips uri. However, it can also use other URI modes (for example, tel URL (RFC 2806 [9]). All sip implementations must support the sip uri mode. The to header field also allows a display name ).

A uac has many methods to set the to header domain of a special request. Generally, you can manually enter the user interface or select a URI in the address book to set the to header domain. Generally, users do not enter a complete Uri, but only a string of numbers or letters (such as "Bob "). UA can interpret these inputs, and UA processes the names entered by the user with information such as domain names to form a sip uri (e.g.: SIP: bob@example.com ). Sips uri indicates that the user needs to communicate securely. "@" Is usually followed by the Domain Name of the requester. This domain name is used to process external requests. Tel URI is used when the UA does not want to specify a domain name and the User specifies a phone number.

The to header field of an external request cannot contain the to tag ). The label in the to header field indicates one end of the conversation.

See section 20.39 of rfc3261 for more information about to header fields. The following is an example of a valid to header field:
To: Carol <SIP: carol@chicago.com>

From header field

The From header field identifies the logic ID of the Request initiator, which may be the address registered by the user. Like the to header field, it contains a URI and an optional display name. It is determined by the SIP element how to handle this request (for example, for some senders, the operation is automatically rejected ). Therefore, it is very important that the From header domain does not contain the local IP address and the local domain name that UA runs, because these are unreasonable names.

The From header field can contain a display name. If the sender hides its own identifier, UAC should use a URI (like: SIP: thisis@anonymous.invalid) that has an anonymous meaning but has a valid syntax ).

In a request, the From header field value is usually pre-specified by the UA user or the local domain name administrator. If this UA has multiple users, it will be able to automatically switch the configuration according to the user's identification. The request recipient can identify the sending source of a request through the From header to determine who sent the request (rfc3261 section 22nd details about the verification ).

The From header must contain a new "tag" parameter, which is generated by UAC. Section 19.3 of rfc3261 describes how to determine the "tag" parameter.

For more information about the From header field, see section 20.20 of rfc3261. The following are some examples of the From header field:
From: "Bob" <sips: bob@biloxi.com>; tag = a48s
From: SIP: + 12125551212@phone2net.com; tag = 887 s
From: anonymous <SIP: c8oqz84zk7z@privacy.org>; tag = hyh8

Call-ID header field

The call-ID header uniquely identifies a sequence of messages. The UA must ensure that the value of the call-ID header is the same for all requests and responses in a dialog.

Unless otherwise specified, the UAC must be assigned a globally unique identifier for the call-ID header field of the new non-Session Request created by UAC. All sip ua instances must have a way to ensure that their generated call-ID header fields are not generated by other UA instances. Note: When a failed response is received and the response request needs to be modified, the resend request is not considered as a new request, therefore, you do not need to re-construct the call-ID header field. See section 8.1.3.5 of rfc3261.

We recommend that you use the cryptographically random identifier (rfc1750) to generate the call-ID header field. You can use the "local ID @ domain name" format. The call-ID header is case sensitive. For more information about call-ID, see section 20.8 of rfc3261. The following is an example of the call-ID header field:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

CSeq Header domain

The CSeq Header field is used to identify and sort transactions. It consists of a serial number and a method name. The method name must be the same as the method in the request. The serial numbers in non-register requests outside the dialog are arbitrary. The serial number must be a 32-bit unsigned integer and must be less than 2 ** 31. Rfc3261 section 12.2.1.1 discusses in detail how to construct a CSeq Header field outside the dialog. The following is an example of the CSeq Header field:
CSeq: 4711 invite

Max-forwards header field

The max-forwards header field is used to limit the number of forwarding nodes (also known as hop) that a request passes during the process of sending a request to the destination address )). This header field is composed of an integer. This integer is decreased by every hop. If the value of the Max-forwards header field is reduced to 0 before a request is sent to the destination, the request will be rejected and the request sender will receive 483 (too many hops).

A uac must insert the max-forwards header to each request and the initial value is 70. This value is large enough to ensure that requests are not discarded by non-cyclic SIP networks. However, in a cyclic SIP network, this value is not enough to consume Proxy Server resources. Be careful when using a small value, and use it only when the network environment where the UA is located is good.

Via header domain

The via header field is used to identify the transmission of a transaction and the location where the response will be replied. A value is inserted into a via header field only when the current hop is selected and can receive messages.

When a UAC creates a request, it must insert the via header domain to the request. The protocol name and Protocol version must be sip and 2.0 respectively. The via header must contain a branch (shunting) parameter. This parameter is used to identify the transaction created in this request. It is used on both the server side and the client side.

The value of the branch parameter must be unique in space and time in the request sent by the UA. Cancel is an exception to ack messages that are not 2XX responses. The cancel request carries the same branch parameter value as the request to be canceled. In rfc3261 section 17.1.1.3, we will discuss that ack for a non-2XX response will contain the same branch parameter value as the invite request for this non-2XX response.

The branch parameter must start with "z9hg4bk". The seven letters are used as the modulus. Therefore, when the server receives this request, it can be determined that the result of branch ID is in line with this manual.

When the request is processed by the transport layer (rfc3261 section 18th), the values of the maddr, TTL, and sent-by components of the Via header domain are set. The proxy server processes information about the via header domain in rfc3261 section 16.6 and section 8th.

Contact Header domain

The contact header supports the sip uri or sips uri. Subsequent requests can use these URIs to precisely access the UA instance. The contact header must contain a sip URI or sips uri in any request that can create a conversation. In this manual, requests that can create a dialog only contain INVITE requests. For these requests, the contact header field is global. That is to say, the URI contained in the contact header field value is the URI that UA wants to receive the request. This URI must be valid even for concurrent non-Session requests.

If the request URI or the top value of the Route Header field contains a sips uri, the contact header field must also contain the sips uri.

For more details about the contact header field, see section 20.10 of rfc3261.

Supported header and require Header

If the UAC supports SIP Extension and the extension can be responded by the server, the UAC must list the optional tags in the request for containing a supported header field (rfc3261 section 19.2 ).

The optional tags must only contain the standard extensions defined in RFC. This is to prevent servers from providing services for customers with non-standard and custom features.

If UAC wants to send an extension that is understandable to UAS, UAC must insert the require header field into the request to list the optional tags for this extension. If the UAC wants to use an extension in the request and any forwarding proxy knows this extension, it must insert the proxy-require header field into the request to list the optional tags for this extension.

Like the supported header field, the require header field and the proxy-require header field must only contain standard extensions.

Additional Message Components

After the header fields described above in a new request have been properly created, you can insert some optional header fields specified by this method.

A sip request may contain a mime-encoded message body. Regardless of the type of the message body contained in the request, some header fields must explicitly express the content of the message body. For more information about header fields, see section 20.11 to section 20.15 of rfc3261.