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

Send request

At this time, determine the target of the request to be sent. Unless specified by the local policy, unless the Sending target must be determined according to the DNS mentioned below. If the first element in the route set is a strict route, the routing process must be set in the request-Uri header domain of the request. Otherwise, the route is set to the value of the first Route Header field in the request (if a route header field exists, or, if the Route Header does not exist, the routing process is set in the request-Uri header domain. These routing processes generate a series of IP addresses, ports, and transmission protocols. During transmission, you will try to transmit the data to the addresses and ports in the series. No matter which URI is used as the input of the routing process, if request-Uri specifies a sips resource, UAC must treat the subsequent routing process as a sips uri.

The local policy may try to specify other addresses of a request target. If request-Uri contains a sips uri, TLS must be used for other addresses of any request target. In addition, there are no other restrictions on requests that do not contain the Route Header domain. A simple and selectable method is provided to set the route table in advance, just like specifying an external proxy. However, it is not recommended to configure an external route. A URI should specify a pre-existing route set. If a request contains a route header field, it should be sent to the position indicated by the value at the top of the Route Header field, however, it may be sent to any server specified by the routing and request-Uri specified in this document, and the server is confirmed by UA. In particular, if UAC is configured to use an external proxy, the request should be sent to the position indicated by the first value in the Route Header domain, rather than the external proxy policy used to send all messages. This means that the external proxy does not add the record-route header to the request, so that subsequent requests do not include this external proxy path. It also allows terminals that cannot process the first route URI to delegate this task to an external proxy.

UAC should implement stateful elements according to the processing process mentioned in [4], and try each address until it is connected to the server. Each connection attempt starts a new transaction. Therefore, the values at the top of the Via header domain for each connection attempt are different, and a new branch parameter is added. In addition, the transport value in the via header domain is set to the value of the target server of the request.

Process Response

The response is first processed by the transport layer and then transmitted to the Transaction layer. After processing, the transaction layer sends the response to the Tu. Most of the responses processed by the Tu are method-related. Despite this, tu still has some common methods.

Transaction layer error

Sometimes the response returned by the Transaction layer is not a SIP message, but a Transaction layer error. When a timeout error is received from the Transaction layer, the error must be considered as a 408 (request timeout) response. If the transport layer reports a fatal transmission error (which is usually a fatal imcp error in UDP or a connection failure in TCP ), the response must be considered as a 503 Status Code (which cannot be obtained by the service.

Unknown response

A uac must regard all unknown final responses as a response whose status code is x00. And it must be able to process the x00 response in all classes. For example, if a UAC receives an unknown response whose response code is 431, it can know that the request sent has encountered a problem and regard the response as a 400 response code (error request). UAC must treat non-100 temporary responses as 183 (in session processing) for processing. In addition, the UAC must be able to process 100 and 183 responses.

Multiple

If more than one via header field appears in the response, UAC should discard the message. The redundant vias header indicates that the message is damaged by the wrong route or message.

Handle 3xx responses

After receiving a redirection response (for example, if the status code is 301), the user should receive a redirection response based on the request, use one or more URIs in the contact header to generate one or more new requests. This process is similar to how the agent processes 3xx requests in rfc3261 sections 16.5 and 16.6. When a user initiates a request, only the URI of the target address set is the request-Uri of the original request. If you want to construct a new request based on the 3xx response, you should place the possible URI in the target set. The customer can choose which URI can be connected to the target and place it in the target set on the premise of following the restrictions in this description. Just as the proxy server will recursion, the user must not add any existing Uris when handling responses of the 3xx class. If the request-URI in the original request is a sips uri, you can select a non-sips uri, but you should be notified that the request will be sent to an insecure Uri. Any request may receive a 3xx response. The response's contact header contains the original Uri. The two addresses may be set to mutual redirection. Any URI only appears once in the target set to place an infinite redirect loop.

As the number of entries in the target set increases, users may create new requests to these target addresses in any order. A general method is to use the Q Parameter Value in the contact header field to determine the order of the target address. Messages requested from these Uris may be serialized or concurrently generated. One way to achieve this is to sort each group in descending order based on the Q value, perform serial processing on each group, and perform parallel processing on the URIs in each group. Another method is to sort the values in descending order. The URI with the same Q values is ordered and then processed in order.

If you fail to communicate with an address in the target set, continue to try the next address in the target set until all attempts are completed. If all attempts are completed, the request fails. Request failure should be detected by the failure response code (response code greater than 399 ). For Network errors, the customer transaction reports the transport layer failure to the transaction user. Note that some response codes (detailed descriptions in section 8.1.3.5 of rfc3261) indicate that the request can be retried. Retry requests are not considered as failed requests.

If a transaction fails to be sent to an address in the contact, the user should try the next contact address, which will create a new transaction for transmitting the new request.

To create a request based on a 3xx response Contact Header domain, UAC must copy the "method-Param" and "Header" parameters from the target set (rfc3261 section 19.1.1) complete Uri. The value of "Header" is used to create and override the values of some header fields in the new request according to the method in section 19.1.5 of rfc3261.

Note: In some cases, the contact header domain used for communication is appended to the redirected original request header domain. As a general rule, if the header field can accept multiple values separated by commas, the new value will be appended to the original redirect request header field. If the header domain cannot accept multiple values, the original request header domain to be redirected will be overwritten. For example, the returned contact header field is the following value:
SIP: user @ host? Subject = Foo & call-Info = The main header fields in the original request for any redirection will be overwritten. The http url is only appended to the value of the existing call-Info header field.

We recommend that UAC use the to, from, and call-ID header fields of the original request. However, UAC may choose to update the value of the call-ID header field for the new request.

Finally, once a new request is created, it will be sent by a new customer firm. Therefore, it must have a new branch ID at the top of the Via header field (rfc3261 discussed in section 8.1.1.7 ).

In other respects, the header domain and Message Body of the original request should be reused based on the request that receives a redirection response.

Sometimes, the value of the contact header field may be temporarily or permanently cached by UAC, depending on the response status code and timeout parameter. See rfc3261 section 21.3.2 and 21.3.3.