Analysis of Two SIP route instances

In the previous article, we used the description of the SIP Routing Mechanism to understand the definition and concept of the SIP routing mechanism. Next, let's explain these abstract concepts to help you understand them. Next, we will use two SIP routing instances to help you understand these concepts.

SIP route 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 the external dial Proxy Server whose P1P1 is U1 ):

 
 

  
  
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 callee@domain.com through location service

The corresponding device address is the callee@u2.domain.com, in the SIP routing mechanism, so the request-URI is rewritten 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 200OK 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: caller@u1.example.com in the Contact in invite, then the request message called in the session is sent to this URI. Similarly, the called in the 200 OK response also carries their own contact address, the caller will receive the response message will also set the remote destination address of this session to: callee@u2.domain.com, 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 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 its own domain 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 
 
 

# P #

SIP route Example 2:

If the above example focuses on the SIP 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 provide 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. In the SIP routing mechanism, 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. The URI in the first Route is not its own, so the message is forwarded to the 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.

At this point, the two SIP route instances have been explained, and you do not know whether you understand this knowledge. I hope this article will give you some reference.