Have you ever wondered why some calls drop unexpectedly or why media doesn't flow during a session? The answer often lies in the correct configuration and handling of SIP headers. In this article, we’ll explore two critical headers in the Session Initiation Protocol (SIP) — the Via and Record-Route headers. These headers play a pivotal role in routing SIP messages, ensuring seamless call setups and media exchanges across IP networks.

By understanding these headers, you’ll be better equipped to troubleshoot and configure SIP systems effectively, minimising call disruptions and improving the user experience.

SIP is a signaling protocol used to initiate, manage, and terminate real-time communication sessions like voice and video calls. Headers in SIP act like GPS markers, guiding messages through the network. Among these, the Via and Record-Route headers stand out for their role in ensuring messages and responses reach the intended destinations.

The Record-Route and Via headers are fundamental components of the Session Initiation Protocol (SIP), which is a signalling protocol used for initiating, managing, and terminating real-time sessions that involve video, voice, messaging, and other communications applications across IP networks. Both headers play critical roles in SIP's operation, ensuring proper routing of requests and responses between SIP entities. Their development and use are closely tied to the history and evolution of SIP itself.

The Via header is used to track the path of request messages as they traverse through the network of SIP servers to reach the intended recipient. It also provides a route for the responses to follow back to the originator. Each SIP proxy or server that forwards a request adds its address to the top of the Via header list. When the response is generated, it travels back through the list of Via headers, ensuring it follows the same path back to the originator.

The Via header has been part of SIP since its inception. SIP was developed by the Internet Engineering Task Force (IETF) and first standardised in RFC 2543 in 1999. The Via header was designed to solve the problem of response routing in IP networks, where requests could traverse multiple nodes, and responses needed a way to navigate back through the same nodes.

The Record-Route header is used by SIP proxies to ensure that the signalling for subsequent SIP messages (such as mid-dialog requests) follows the same path as the initial request. When a SIP proxy wants to stay in the path of future requests in a dialog, it adds a Record-Route header to the initial INVITE request. This ensures that all subsequent messages within the same dialog traverse through the recorded route, enabling features like billing, call recording, or session management to be applied consistently.

Like the Via header, the Record-Route header has been a part of SIP since its early days. It was introduced to address the need for maintaining the signalling path for the duration of a SIP session, especially in complex scenarios involving multiple proxies and network elements. The concept of recording the route was crucial for deploying SIP in real-world networks, where the control over media and signalling paths needed to be maintained for the functionality and security of communication sessions.

Both headers reflect SIP's flexibility and its ability to navigate the complexities of IP network architectures. Over the years, SIP has evolved through various RFCs (Request for Comments), with significant updates including RFC 3261 in 2002, which solidified many of the protocol's core operations, including the behaviours of the Via and Record-Route headers. These headers ensure that SIP can operate effectively over the diverse and distributed nature of the Internet, supporting the reliable delivery and routing of communication sessions across multiple hops and domains.

When managing SIP (Session Initiation Protocol) communications, ensuring seamless call setup and media flow is crucial for both service providers and their customers. A common issue encountered during SIP transactions is the failure of ACK messages to reach the end device, confirming the final response to the initial SIP INVITE. This can prevent the establishment of media sessions, leading to call setup failures and, ultimately, calls being dropped with a SIP BYE message and the reason as "ack_timeout." In this article, we'll delve into the intricacies of the Route headers in calls and explain why omitting these headers in a 200 OK response can cause such problems.

The Via header tracks the path of SIP request messages as they traverse the network and ensures responses follow the same path back to the originator. Each SIP proxy or server that forwards a request adds its address to the top of the Via header list. When a response is generated, it uses this list to navigate back to the originator. This mechanism ensures that SIP messages follow the same path in both directions, preventing misrouting.

Example:

The Record-Route header is added by SIP proxies to ensure all subsequent messages in a session (e.g., mid-dialog requests like ACKs or BYEs) follow the same path as the initial INVITE. This is crucial for applying features like call recording, session management, or billing consistently.

Without Record-Route headers, subsequent messages might bypass critical network elements, potentially breaking functionality.

Example:

When a callee sends a 200 OK response to accept an INVITE request, this response should include Route headers that mirror the path taken by the initial INVITE. This inclusion ensures that the ACK message, which confirms receipt of the 200 OK, is routed back through the same network elements, reaching the callee and signalling that the session can proceed with media exchange.

If the 200 OK omits these Route headers, the network may not have the necessary information to route the ACK back to the callee correctly. As a result, even though the call appears to be established from the perspective of the initiating party (such as Telnyx), the lack of ACK receipt at the callee's end means the session cannot transition to media exchange. Consequently, without media flow, the call is eventually terminated with a "ack_timeout" hang-up cause.

To provide a clear understanding, let's illustrate two examples based on the provided SIP INVITE and 200 OK messages. These examples aim to showcase the issue arising from the omission of Record-Route headers in the 200 OK response and how their inclusion ensures successful SIP call establishment.

Without the Record-Route headers in the 200 OK response, the ACK message sent by Telnyx might not follow the intended path, potentially failing to reach the customer's system. This misrouting can prevent the call from being fully established, leading to issues such as calls not connecting or being dropped unexpectedly.

By including the Record-Route headers in the 200 OK response, the customer ensures that the ACK message sent by Telnyx correctly follows the predefined path through any intermediate proxies.

This scenario illustrates what happens when a client initiates a SIP INVITE to Telnyx, and subsequent SIP messages (like ACK) fail due to misconfigured or reordered Route headers in the client’s response.

In this response, Telnyx includes Record-Route headers to ensure subsequent requests follow the same path through the SIP proxies. The client must reverse the order of these headers and construct the correct Route headers in its ACK.

The client incorrectly omits or reorders the Route headers. The correct order, based on the reversed Record-Route headers from the 200 OK, should be:

Successful ACK

Why This Succeeds

From Telnyx's perspective, when a call faces such an issue, it remains in a "call in progress" state until the ack_timeout occurs. Customers might observe calls being dropped with "ack_timeout" as the hang-up cause.

Yes, the order of Record-Route headers in the customer's 200 OK response is important and has specific implications for SIP message routing. Record-Route headers are used by intermediate SIP proxies to insert themselves into the path of the request and its subsequent responses within a dialog, like Telnyx's SIP Proxy, ensuring that the signalising messages for the entire session traverse through these proxies.

When the Telnyx SIP proxy adds a Record-Route header to an INVITE request, it's essentially saying that all subsequent SIP messages within this dialog (such as ACKs and BYEs) should route through this proxy. The order in which these headers are added dictates the path that these messages will take:

Therefore, the order of Record-Route headers in the 200 OK is crucial because it sets the route that all subsequent messages within the dialog will follow. If the headers were reordered incorrectly, it could lead to SIP messages taking an inefficient path through the network or, worse, not reaching their destination at all due to misrouting.

Which can lead to issues in processing the message. In SIP communications, as well as many other Internet protocols, the carriage return (CR) followed by a line feed (LF) characters (\r\n) are essential for delineating the end of a line in the message header and the beginning of the message body or separating headers. If these aren't properly included, the receiving system might not recognise the end of one line and the start of another, leading to parsing errors or the message being ignored altogether.

The solution in such cases is to ensure that the message formatting strictly adheres to the protocol specifications, including the use of carriage return line feeds (CRLF) to properly structure the message. Correcting the formatting issue in the ACK packet should resolve the problem and allow the message to be processed as intended.

Another often-overlooked header—CSeq (Sequence Number)—is just as critical to the successful establishment of SIP calls. The CSeq header maintains synchronisation between SIP requests and responses by indicating the order of transactions. Each new SIP request within the same dialog must increment the CSeq number. A mismatch between the CSeq numbers in the INVITE, 200 OK, and ACK can lead to issues such as dropped calls or failures to establish media, even when the Record-Route and Via headers are correct.

Consider the following call flow:

In this case, the server is expecting CSeq: 3 ACK to confirm the 200 OK. When it receives CSeq: 2 ACK, it considers the transaction incomplete and does not establish media. This mismatch leads to a "ack_timeout" disconnect, despite all other headers being correctly configured.

To prevent such issues and ensure reliable call setup and media flow, it's essential for customers and their network administrators to:

The correct handling of Route headers in SIP communications is crucial for ensuring that calls are set up successfully and that media can flow between endpoints. By adhering to best practices and ensuring that your network is correctly configured to handle SIP messages, you can minimise disruptions and provide a seamless communication experience for your users. If you encounter persistent issues, working closely with your SIP service provider can help resolve these challenges effectively.