Analysis of SIP route and record_route/SIP routing mechanisms

 

Analysis of SIP route and record_route/SIP Routing Mechanism from: [url] Routing

Analysis of SIP Routing Mechanism (zz)

We have already introduced sip-related knowledge about important SIP header domains, registration processes, and session processes. Now we will introduce the Routing Mechanism in SIP.

In general, there are two routing scenarios in SIP:
1. Request message routing
2. Response message routing

Among them, the routing of response messages is very simple, that is, it relies entirely on Via. For details, see my analysis on the session process in rfc3261.
Next we will only talk about the route of the SIP request message.

First, we need to figure out what strict routing and loose routing are.

Strict routing ):
It can be understood as a "rigid" reason mechanism. This routing mechanism is defined in RFC 2534, the predecessor of the SIP protocol, and its mechanism is very simple.
The request-Uri of the received message must be its own Uri, and then it will "pop up" the first Route Header domain, and use the URI as the new request-Rui, and then route the message to the URI.

Louse routing (LR ):
This routing mechanism is flexible and is also the soul of the SIP routing mechanism, which is defined in RFC 3261.
The following describes the route decision-making process of a loose routing Proxy:

1. The proxy first checks whether the request-Uri of the message belongs to the domain in which it is responsible. If yes, it will "translate" the address into a specific contact address through the positioning service and replace it with the original request-Uri; otherwise, it will not change the request-Uri.

2. the proxy checks whether the URI in the first Route Header field is its own. If yes, remove it.

3. The first two items are preparations. Now we need to perform the real routing. If there is a Route Header domain, the proxy routes the message to the URI in the header domain, otherwise it routes the message to request-Uri. How to determine the IP address, port, and transmission protocol from the next hop URI is another thing.

For the preceding three rules, we can simply conclude that the priority of route is higher than that of request-Uri.

Well, we have learned about the two routing mechanisms. Let's take a look at route and record-route.
If the via is to leave a back path for the response message of a request message, the record-route is to leave a back path for the request message after the request message.
[Note] each time a SIP message passes through a proxy (including the caller), a via header domain is added. When the message arrives at the called, the via header field records the complete path of the request message. The called party copies the original via header fields to the Response Message (including the parameters of each via and the order of each via), and then delivers them to the URI in the first, each proxy will delete the first via (that is, the via it added) before forwarding the response message, and then forward the message to the URI in the new first via until the message arrives at the main call.

During the transmission of a request message, the proxy may also add a record-Route Header domain if it wishes to receive the subsequent request message from this session, in this way, when a message arrives at the call, there will be 0 or several record-route header fields. The called will merge these record-route header fields into the routing set and their own routing set. Then the called will use this routing set to construct a series of Route header fields when sending request messages, to route messages.
Then, the called object will copy all the record-route header fields to the response message and return them to the caller just like the via header field.
After receiving the response message, the caller will also merge the record-route header fields into the route set, but it will reverse it. The Route Header domain of the subsequent request message in this session is constructed through the routing set.
[Note] the record-Route Header does not need to be routed, but only serves to transmit information.
The record-Route Header field is not the only source of the route set. You can also obtain the route set through manual configuration.

The description is still abstract. The following describes two instances in RFC 3261.

Routing Example 1:

Scenario:
There are two proxies between two ue, u1-> P1-> P2-> u2, and both proxies are willing to add record-route header fields.

Message stream:
[Note] because we only care about the SIP routing mechanism here, the headers irrelevant to the routing mechanism in the following messages are omitted.

U1 sends an invite request to p1 (P1 is the U1 outbound Proxy Server ):
Invite SIP: callee@domain.com Sip/2.0
Contact: SIP: caller@u1.example.com

P1 is not responsible for the domain domain.com, and there is no Route Header domain in the message. Therefore, the proxy address responsible for the domain is obtained through DNS query and the message is forwarded. Here, P1 adds a record-Route Header domain before forwarding, which contains an LR parameter, indicating that P1 is a loose router and follows the Routing Mechanism in rfc3261.
Invite SIP: callee@domain.com Sip/2.0
Contact: SIP: caller@u1.example.com
Record-route: <SIP: p1.example.com; LR>
P2 is responsible for domain domain.com, so it gets [email] callee@domain.com [/Email] Through location service the corresponding device address is [email] callee@u2.domain.com [/Email], therefore, use a new URI to overwrite the request-Uri. The message does not have a route header field, so it forwards the message to the URI in request-Uri. before forwarding, It also adds a record-Route Header field and also has the LR parameter.
Invite SIP: callee@u2.domain.com Sip/2.0
Contact: SIP: caller@u1.example.com
Record-route: <SIP: p2.domain.com; LR>
Record-route: <SIP: p1.example.com; LR>
The called at u2.domain.com receives the invite message and returns a 200 OK response. This includes the record-Route Header field in invite.
Sip/2.0 200 OK
Contact: SIP: callee@u2.domain.com
Record-route: <SIP: p2.domain.com; LR>
Record-route: <SIP: p1.example.com; LR>
When called, you will have your own route set:
(<SIP: p2.domain.com; LR>, <SIP: p1.example.com; LR>)

And the remote destination address of this session is set to the URI in contact in invite: [email] caller@u1.example.com [/Email], then the request message called in this session is sent to this URI. Similarly, the called contact address is also carried in the 200 OK response. After receiving the response message, the caller sets the remote destination address of the session: [email] callee@u2.domain.com [/Email], after which request messages from the host in this session are sent to this URI.
Similarly, the caller also has his own route set, but it is in reverse order with the called:
(<SIP: p1.example.com; LR>, <SIP: p2.domain.com; LR>)

After the call is complete, we set up the caller to first hook up, then the caller sends a bye request:
Bye SIP: callee@u2.domain.com Sip/2.0
Route: <SIP: p1.example.com; LR>, <SIP: p2.domain.com; LR>
We can see that the bye Route Header domain is constructed by the host's route set.
Because P1 is in the first route, bye is sent to P1 first.

After receiving the message, P1 finds that the URI in the request-Uri does not belong to its own domain, and the message has a Route Header domain, and the URI in the first Route Header domain is exactly the same as itself, therefore, the message is deleted and forwarded to the URI in the new first Route Header domain, that is, P2:
Bye SIP: callee@u2.domain.com Sip/2.0
Route: <SIP: p2.domain.com; LR>
After receiving the message, P2 finds that the URI in the request-Uri does not belong to the domain in which it is responsible (P2 is responsible for domain.com rather than u2.domain.com). The URI in the first Route Header domain is exactly the same as itself, therefore, the Route Header domain is no longer available, and therefore is forwarded to the URI in request-Uri.

When you are called, you will receive the bye message:
Bye SIP: callee@u2.domain.com Sip/2.0

Routing Example 2:
If the preceding example focuses on the routing process, this example focuses on the difference between strict routing and loose routing.

Scenario:
U1-> P1-> P2-> P3-> P4-> u2
Among them, P3 is strictly routed, and other proxies are loose routed, and the four proxies are happy to add record-route header fields.

Message stream:
We directly provided the invite message to be called:
Invite SIP: callee@u2.domain.com Sip/2.0
Contact: SIP: caller@u1.example.com
Record-route: <SIP: p4.domain.com; LR>
Record-route: <SIP: p3.middle.com>
Record-route: <SIP: p2.example.com; LR>
Record-route: <SIP: p1.example.com; LR>

The other messages in the middle are left blank. Let's take a look at what the bye message is like:
Bye SIP: caller@u1.example.com Sip/2.0
Route: <SIP: p4.domain.com; LR>
Route: <SIP: p3.middle.com>
Route: <SIP: p2.example.com; LR>
Route: <SIP: p1.example.com; LR>

Because p4 is in the first route, it is called to send the bye message to P4.

After receiving the message, P4 finds that it is not responsible for the u1.example.com domain, but the URI in the first Route Header domain is itself, so it is deleted. P4 also finds that the URI in the new first Route Header domain is a strict router, so it adds the URI in request-URI to the last route location, in addition, the first route will pop up and overwrite the original request-Uri. Then, the message is forwarded to the current request-Uri, that is, P3.
Bye SIP: p3.middle.com Sip/2.0
Route: <SIP: p2.example.com; LR>
Route: <SIP: p1.example.com; LR>
Route: <SIP: caller@u1.example.com>

After receiving the message, P3 directly transforms the message and sends it to p2:
Bye SIP: p2.example.com; LR Sip/2.0
Route: <SIP: p1.example.com; LR>
Route: <SIP: caller@u1.example.com>
After P2 receives the message, it finds that the request-URI in the message is its own. Therefore, before further processing, it first converts the message as follows:
Bye SIP: caller@u1.example.com Sip/2.0
Route: <SIP: p1.example.com; LR>
Then P2 finds that it is not responsible for the u1.example.com domain, and the URI in the first route is not its own. Therefore, the message is forwarded to this URI, that is, P1.

After receiving the message, P1 finds that it is not responsible for the u1.example.com domain, but the URI in the first Route Header domain is itself, so it is deleted. The message is as follows:
Bye SIP: caller@u1.example.com Sip/2.0
Since the Route Header field is already empty, P1 sends the message to u1.example.com.