What The F-Heck Are Route and Record-Route SIP Headers??

02.06.2020
| No Comments
What The F-Heck Are Route and Record-Route SIP Headers??

Everyone is familiar with the basic SIP headers like CSeq and Call-ID (I’m not gonna mention From and To :)). Some might even know Remote-Party-ID or Contact headers. What I’ve noticed throughout the years though, is that not many are familiar with the Record-Route and Route SIP headers. Not sure why as they’re pretty useful to know. Let’s have a look!

The Concept

A picture is worth a thousand words or whatever the saying goes so I’ll explain the concept on the most basic call flow diagram. It involves me (Maciej) communicating with tipsycollab.com via 2 proxies – P1 and P2.

Route and Record-Route SIP Headers

Just in case you’re not familiar with the Via header, it specifies the path for response messages to the Invite request. They’re added in the request by each proxy along the path and by the UAC (User Agent Client – in this case, Maciej).
As the response travels back, the corresponding Via header is removed at each hop.

Now since we got the Via headers out of the way, let’s have a look at the main topic of this article.
Record-Route headers are added to the request only by proxies that wish to remain in the call signaling path. In the example above, only P2 shows that interest.
What’s important to note is that the Record-Route headers are not modified in the reply.

When Maciej receives the reply (200 OK) containing the Record-Route headers, it will reverse their order and change it to Route headers on the next request (ACK).
Yes, you’re right – there is nothing to reverse here as there is only one Record-Route header above, the real-world example that follows has more so keep an eye on the reversed order.
In essence, the Route headers specify the path a request should take.
It’s going directly from Maciej to P2, bypassing P1.

The Real World

How does it look like in the real world?
Let’s say P2 in the diagram above is Expressway-E while tipsycollab.com is webex.com. There will be slight differences comparing to the diagram as Expressway is acting as a B2BUA, not a Proxy in this scenario.
Showing only relevant parts of the messages as a lot is going on, especially in the Via headers, on Expressway.

As you can see, the Invite contains Expressway’s public IP (20.20.20.20) and external NIC IP (192.168.20.20) in the Record-Route SIP headers thus making sure it remains in the call path.

INVITE sip:999888777@tipsycollab.webex.com SIP/2.0
 Via: SIP/2.0/TLS 20.20.20.20:5061     // Public IP of Exp-E
 Via: SIP/2.0/TLS 192.168.20.20:5073   // External Exp-E IP
 Via: SIP/2.0/TLS 192.168.10.10:5061   // Internal Exp-E IP
 Via: SIP/2.0/TLS 10.10.10.20:5061     // Exp-C IP
 Via: SIP/2.0/TLS 10.10.10.20:5073     // Exp-C IP
 Via: SIP/2.0/TLS 10.10.10.20:5061     // Exp-C IP
 Via: SIP/2.0/TLS 10.10.10.10:5065     // CUCM IP
 Record-Route: <sip:proxy-call-id=8f09a8f7-dd5a-4fca-91ea-fd4b6119ae8d@20.20.20.20:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=8f09a8f7-dd5a-4fca-91ea-fd4b6119ae8d@192.168.20.20:5061;transport=tls;lr>

When the 200 OK comes in, in addition to the above Record-Route headers, three more are added making sure each of the Webex servers remains in the call path.

SIP/2.0 200 OK
 Via: SIP/2.0/TLS 20.20.20.20:5061     // Public IP of Exp-E
 Via: SIP/2.0/TLS 192.168.20.20:5073   // External Exp-E IP
 Via: SIP/2.0/TLS 192.168.10.10:5061   // Internal Exp-E IP
 Via: SIP/2.0/TLS 10.10.10.20:5061     // Exp-C IP
 Via: SIP/2.0/TLS 10.10.10.20:5073     // Exp-C IP
 Via: SIP/2.0/TLS 10.10.10.20:5061     // Exp-C IP
 Via: SIP/2.0/TLS 10.10.10.10:5065     // CUCM IP
 Record-Route: <sip:l2sip-afra-02.wbx2.com:5062;transport=tls;lr>
 Record-Route: <sip:rr$n=net_sp_tls@icccppr3.emea.prv.webex.com:5061;transport=tls;lr>
 Record-Route: <sip:rr$n=net_me_tls@62.109.228.74:5061;transport=tls;lr;bypassvcs=true>
 Record-Route: <sip:proxy-call-id=8f09a8f7-dd5a-4fca-91ea-fd4b6119ae8d@20.20.20.20:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=8f09a8f7-dd5a-4fca-91ea-fd4b6119ae8d@192.168.20.20:5061;transport=tls;lr>

The Record-Route headers from the 200 OK above are then reversed and modified to Route headers thus making sure the next request (ACK) is following the expected path.
Well, I don’t see the two Expressway IPs you might say – there are only 3 Route headers instead of 5. Yes, indeed, these are removed as the ACK message leaves Expressway. You would see them though on the internal processing via the B2BUA component of Expressway.

ACK sip:l2sip-UA@l2sip-afra-02.wbx2.com:5062;transport=tls SIP/2.0
 Via: SIP/2.0/TLS 20.20.20.20:5061
 Via: SIP/2.0/TLS 192.168.20.20:5073
 Route: <sip:rr$n=net_me_tls@62.109.228.74:5061;transport=tls;lr;bypassvcs=true>
 Route: <sip:rr$n=net_sp_tls@icccppr3.emea.prv.webex.com:5061;transport=tls;lr>
 Route: <sip:l2sip-afra-02.wbx2.com:5062;transport=tls;lr>

Summary

That’s it, folks.
I’ve tried to remove all the unnecessary bits and pieces to really make you understand the Record-Route and Route SIP headers.
I know however that there are some items I touched upon along the way that could have their own article.

Curious to know your opinion, was this useful and clear enough?
Get in touch here or leave a comment below.

SIP