There are two types of SIP proxy servers:
1) Stateless proxy server: A simple forwarding function that selects the destination and route of forwarding by requesting information. Messages are discarded as soon as they are forwarded.
2) Stateful proxy server: records incoming requests and sent request information (especially transaction status) and uses this to control future message processing. It also has a fork function for messages.
1 stateful proxy server
A stateful proxy server is a pure transaction processing engine.
As shown in Figure 1, a stateful proxy server contains a server-side transaction and one or more client transactions associated with it. The two are the higher-level proxy processing module: the proxy kernel.
When a request arrives, a server-side transaction is first established to process the request, and then the kernel determines the requested route and selects one or more next hop locations, so multiple client transactions are built to send the request.
When a request arrives, the proxy must process the request:
1, verification request
2, pre-processing routing information
3. Determine the purpose of the request (targets)
4, forward the request to each destination
5, handle all responses
2 verification request
Before the proxy forwards the request, it must check the legitimacy of the message. A legitimate message must be checked as follows:
1), legal grammar
2), URI scheme
3), the maximum number of forwards
4), (optional) loop detection
5), proxy-require
6), proxy-authorization
(1) Legal grammar
Any part of the request that is relevant to the inspection or that is related to the request forwarding section must be grammatically correct. During the inspection, the rigor of other parts is ignored in the inspection and remains unchanged during the forwarding of the message.
(3) Maximum number of forwards
If the request contains a Max-Forwards header field and the header field is 0, the proxy cannot forward the request. However, if the request is an OPTIONS request, the proxy can respond to the request as the final responder.
(5) proxy-require check
Future extensions to this protocol may require additional proxy features. So the terminal will include a Proxy-Require header field in the request to indicate which features will be used, so the proxy can determine if it can support these features based on Proxy-Require.
If the request contains a Proxy-Require header field (20.29) and there are one or more option-tags that the proxy cannot understand. Then the proxy must return a 420 (BadExtension) error, and this error response must include an Unsupported (20.40) header field listing those option-tags that the proxy cannot support.
3 Pre-processing routing information
The proxy must check the Request-URI part of the request. If the Request-URI contains a value that the proxy was previously placed in the Record-Route header field, the proxy MUST replace the Request-URI with the last value in the Route header field and remove the value from the Route header field. The proxy must then be processed according to a modified request.
If the first value of the Route header field is the proxy, then the proxy must remove it from the request.
3 determine the purpose of the request
1) If the area of the Request-URI is not the area that the proxy is responsible for, then the Request-URI must be placed in the target collection and as the only target URI.
2) If the proxy is responsible for the area specified by the Request-URI, the proxy can use any mechanism to decide where to send the request. The proxy can add a destination when the request is forwarded. He can use the information available to determine a new destination during the process. For example, the proxy may choose to merge the contact address contained in a forwarding response (3xx) into the destination set.
4 request forwarding
For each destination identified in the previous step, the proxy forwarding request follows the following steps:
1), copy a received request
2), update the Request-URI
3), update the Max-Forwards header field
4), optionally add a Record-Route header field
5), optional add additional header fields
6), routing information post processing
7), determine the next node address, port, communication protocol.
8), increase a Via header field value
9), if necessary, add a Content-Length header field
10), forward this new request
11), set the timer C
(2) Update Request-URI
The Request-URI in the copied request must be replaced with the destination URI.
(3) Max-Forwards
If the header field of the copy contains a Max-Forwards, the proxy must decrement the value of this field by one.
If the copied header field does not contain a Max-Forwards header field, the proxy must add a header field by itself. The default value is 70. Some UAs now do not fill in the Max-Forwards header field in the request.
(4) Record-Route
When establishing a dialog request, if you want to keep the dialog created by this request, the subsequent request is still going through this proxy, then the proxy must add a Record-Route header field value in this copy, and add this header. The field value should be before other existing Record-Route header fields.
In the request after the dialogue is established, even if the Record-Route is no longer added, the request in the conversation will pass through the proxy server unless the terminal UA re-establishes a conversation.
The URI prevented in the Record-Route header field must be a SIP or SIPS URI. This URI must contain an lr parameter.
When the proxy needs to view the messages in all the conversations, we need Record-routeing, which generally includes the Record-Route header field in the request INVITE that establishes the dialog.
(6) Processing routing information
If the requested copy contains a Route header field, the proxy must check the first value of the Route header field. If the URI does not contain the lr parameter, then the proxy must modify the request according to the following steps:
- The proxy must place the Request-URI in the last value in the Route header field.
-proxy must put the value of the first Route header field in the Request-URI and remove it from the Route header field.
(7) Determine the address, port and communication protocol of the next node.
The proxy can have its own policy to decide to send the request to a specific IP address, port and transport, regardless of the value of the Route or the value of the Request-URI.
The proxy can also apply the steps of RFC 3263 to determine where the request should be sent.
(8) Add a Via header field value.
The proxy MUST add a Via header field value to the requested copy and increment it before the other Via header field values. The proxy needs to calculate its own branch parameters and should be globally unique and contain the necessary magiccookies.
On the value of the proxy construction branch parameter, there is an additional constraint for loop detection. A proxy to detect loops should create a two-part branch parameter. The second part is used for loop detection, and it is determined from the spiral whether there is a loop.
(8) Set timer C.
In order to be able to handle the case where the INVITE request does not generate a final response, the TU uses a timer.
5 response processing
When the proxy receives a response, it first attempts to locate a client transaction that matches the response. If there is no match, the proxy must handle the response as a stateless proxy (even if the response is an informational response). If a client transaction matching the response is found, then the response is forwarded to the client transaction for processing.
When the client transaction hands the response to the proxy layer, the following steps are performed:
1) Find the appropriate response context.
2), update the timer C with a temporary response
3), remove Via from the top
4), increase the response in the response context
5), check if this response needs to be sent immediately
6) If necessary, select the best final response from the response context.
7), need to merge the authentication header, , , , , , , , , , , , , , , fiel, , d value.
8), optional rewrite of the Record-Route header field value
9), forward response
10), generate the appropriate CANCEL request.
(3) Remove Via from the top
If there is no such Via header field value in this response, then the meaning of the response means that the response should not be forwarded by this proxy.
(4) Increase the response in the response context
The received final response is saved in the context of the reply until a final response to the context is generated by the server transaction. This response is a candidate for receiving the best final response from that server transaction. Even if this response is not selected as the best response, the information of this response needs to be constructed to be the best response.
(5) Check if this response needs to be sent immediately
When the final response arrives at the server transaction, the following response packets must be forwarded immediately.
- any non-100 (trying) temporary response
- Any 2xx response.
If you receive a 6xx response, then it will not be forwarded immediately. If it is a stateful proxy, you need to cancel all clients that depend on this transaction (as described in Section 10), and cannot be created in context. New branch.
After the final response is sent on the server transaction, the following response should be sent immediately:
- Any 2xx response to the INVITE request.
A stateful proxy must not forward other replies immediately. In particular, a stateful poxy must not forward any 100 (Trying) responses. These responses are candidates for subsequent "best" responses to be forwarded, added to the response context by the above "add a response in context" step.
(6) Choose the best response (omitted)
(8)Record-Route
If the response sent in the final response contains the Record-Route header field value and is the value originally provided by the proxy, the proxy may need to override this value before sending this response.
(9) Forwarding the response
When the "Merge Authentication Header Field" and "Record-Route" steps are completed, the proxy can perform additional processing on this response. However, this proxy cannot add, modify, or delete message bodies. And unless otherwise indicated, the proxy cannot delete any header field values except for the Via header field value.
The proxy must pass the response to the server transaction associated with this reply context. This causes the response to be sent to the top of the Via header field value.
Summary of 6Proxy Route processing
In the absence of a local policy, the proxy handles the request containing the Route header field can be attributed to the following steps:
1. The proxy will check the Request-URI. If it points to the area the proxy is responsible for, the proxy will replace the URI with the result of the location service. Otherwise, the proxy does not change this URI.
2. The proxy will check the top URI of the Route header field. If the URI points to this proxy, the proxy is removed from the Route header field (this routing node has arrived).
3. The proxy forwards the request to the URI identified by the top Route header value, or the Request-URI (if there is no Route header field). The proxy uses the steps of RFC3263 to generate the parameters necessary for the address, port, communication protocol, etc. to forward the request.
If there is no strict routing node in the requested path, the Request-URI will always mark the destination of the request.
7 stateless Proxy
When used as stateless, proxy is a simple message forwarder. Many stateless processing steps are similar to when there is a state. Different places are described below.
A stateless proxy does not have the concept of a transaction, or a response context that describes the behavior of a stateful proxy. Conversely, stateless proxy processing messages, whether they are requests or responses, are handled directly from the communication layer. Of course, the stateless proxy does not resend these messages by itself. They simply forward any resent messages they receive (they themselves have no ability to distinguish between those messages that are resent and those that are original). Further, when a request is processed statelessly, the node does not generate its own 100 (Trying) or other temporary response.
KNPL-700Plus
KNPL-800
KNPL-700
KNTD-300
Thank you for reading, if you have any questions or needs, please contact us!
EMAIL: marketing@koontech.com, we will reply you immediately
Previous：Phone systems all the best providers