Transferred from: blog.csdn.net/boy8239/article/details/1799542
Author: boy8239 has already introduced sip-related knowledge about important SIP header domains, registration processes, and session processes. Now let's 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 RoutingStrict 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.
Loose Routing(Louse routing, LR): This routing mechanism is flexible and is also the soul of the SIP routing mechanism, which is defined in RFC 3261 of the SIP basic code. 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 also
Possible(Purely voluntary, if it wants to receive a subsequent request message from this session) it will add a record-Route Header domain, 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 following headers irrelevant to the routing mechanism 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 the domain domain.com, so it gets the device address corresponding to the callee@domain.com through the location service is the callee@u2.domain.com, so it overwrites the request-Uri with the new 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 you are called, you will also have your own route set: (<SIP: p2.domain.com; LR>, <SIP: p1.example.com; LR>) in addition, the remote destination address of this session is set to the URI in the invite contact:, and then the request message 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 :, then the request message from the host in this session is 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 main call first, then the main call issued 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, so delete it and forward the message 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. The called 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 where P3 is strictly routed, and other proxies are loose routed, and the four proxies are happy to add the record-Route Header domain. Message stream: We directly gave the invite message: 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>
Other messages in the middle of this we just asked, directly look at the called last bye message is probably what it looks 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> the bye message is sent to P4 because p4 is in the first route. 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 converts 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>
P2 received the message, found that the request-URI in the message is their own, so in the further processing first of all to the message to do the following Transformation: 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 goes like the following: 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.
