Record-Route in SIP

In this blog, we’ll go through “record-route” header in SIP and also differences from “via” header that is used for responses. Shortly, the most important thing to defer this two header is that one of them is used for subsequent requests, the other one is used only for the response! Let’s have a detailed look:


Record-route:
This header is placed in the first invite by proxies to say: “I want to be in the path for subsequent invites”. Each Proxy that Invite passes add its own record-route header to finally create “Route-Set”. Normally, I mean without record-route, user agents would communicate directly with their information in contact header. Furthermore, we can deduce that only Proxy can trigger this process by putting the “record-route” header in the first request.

Let’s check Invites out with more details;
Invite 1:
INVITE sip:B@proxy-2.com SIP/2.0
From: A<sip:A@proxy-1.com>;tag=tag_A
To: B<sip:B@proxy-2.com>
Call_ID: xxxxxx
CSeq: 1 INVITE
Contact: sip:A@u.proxy-1.com

Invite 2:
INVITE sip:B@proxy_2.com SIP/2.0
Record-Route: <sip:p1.proxy-1.com;lr >
From: A<sip:A@proxy-1.com>;tag=tag_A
To: B<sip:B@proxy-2.com>
Call_ID: xxxxxx
CSeq: 1 INVITE
Contact: <sip:A@u.proxy-1.com>

Invite 3:
INVITE sip:B@proxy-2.com SIP/2.0
Record-Route: <sip:p2.proxy-2.com;lr>
Record-Route: <sip:p1.proxy-1.com;lr>
From: A<sip:A@proxy_1.com>;tag=tag_A
To: B<sip:B@proxy_2.com>
Call_ID: xxxxxx
CSeq: 1 INVITE
Contact: <sip:A@u.proxy_1.com>

As you see, each Proxy added its own record-route header and the recipient got the final Invite message and Route-Set is created. It must mirror all the Record-Route header fields into responses because the originator of the request also needs to know the set of proxies by the recipient.

For the next transactions, because of route-set Request URI may be affected. If the first route URI contains “lr” parameter, that means you do not need to change anything on Request URI. However, If it does not contain “lr” (loose routing), If there are any Route HFs in the message, the function takes the first one, rewrites Request-URI with it's value and removes the first URI from Route HFs. Let me show that;

Because it has “lr” parameter in route-set as shown below;

INVITE sip:B@proxy-2.com SIP/2.0
Route: <sip:p2.proxy-2.com;lr>
Route: <sip:p1.proxy-1.com;lr>
From: A<sip:A@proxy_1.com>;tag=tag_A
To: B<sip:B@proxy_2.com>
Call_ID: xxxxxx
CSeq: 1 INVITE
Contact: <sip:A@u.proxy_1.com>

Invite message in the next request will be like this;

INVITE sip:B@proxy-2.com SIP/2.0

Route: <sip:p1.proxy-1.com;lr>
From: A<sip:A@proxy-1.com>;tag=tag_A
To: B<sip:B@proxy-2.com>
Call_ID: xxxxxx
CSeq: 1 INVITE
Contact: sip:A@u.proxy-1.com

If it does not have “lr” parameter, it would be like this;

INVITE sip:p2.proxy-2.com SIP/2.0              >>>>> the first route

Route: <sip:p1.proxy-1.com;lr>
From: A<sip:A@proxy-1.com>;tag=tag_A
To: B<sip:B@proxy-2.com>
Call_ID: xxxxxx
CSeq: 1 INVITE
Contact: sip:A@u.proxy-1.com

Record-Route header is a mandatory element when your Proxy is stateful. In this way, the Proxy can keep the status of the session as whether it is completed or not. Once it is stateless, it does not matter being in the path for proxies.

If you do not use record-route header in your Proxy; your call flow would be like this;

That means the next requests will connect to another side directly. Proxies would not be in the path.


We will discuss DTMF in the next blog, keep in touch!