Session Initiation Protocol (SIP) forking refers to the ability of SIP requests to be simultaneously delivered to multiple locations.
When a SIP request such as an INVITE is sent to a proxy server, the proxy can forward the request to multiple destinations at the same time, instead of forwarding to just a single destination.
This results in multiple “forks” of the request being generated.
How SIP Forking Works?
SIP forking occurs due to the nature of SIP URLs. A SIP URL can represent an individual user agent, such as alice@example.com, or it can represent a domain, such as example.com.
When a request is sent to a domain, the domain may support multiple users who are addressed by that domain.
For example, if a call is placed to example.com, the proxy server receiving this request needs to determine which specific user agent at example.com should get the call.
The proxy doesn’t know ahead of time exactly which user agent should receive it. So instead of forwarding to just one user agent, the proxy can forward or “fork” the request to all registered user agents in that domain.
The proxy server maintains a registration database that keeps track of which user agents are registered with each domain.
When the INVITE request comes in for example.com, the proxy looks up its registration database and finds there are three registered user agents:
- alice@example.com
- bob@example.com
- eve@example.com
The proxy will then fork the INVITE and send it simultaneously to all three of these destinations.
This allows the call to reach the intended recipient without the proxy having to know the exact address ahead of time.
Serial Forking vs Parallel Forking
There are two main flavors of SIP forking:
- Serial forking – The proxy sequentially sends the forked request to each destination, one at a time. It waits for a response or a timeout before moving on to the next destination.
- Parallel forking – The proxy simultaneously sends the forked request to all destinations at the same time without waiting. This allows for the fastest call connection.
Most SIP proxies today utilize parallel forking to minimize call setup time.
However, serial forking may be useful in some failover scenarios when you want to try one destination first before moving to the next.
Forking Proxy vs Redirect Server
Forking proxies should not be confused with redirect servers.
A redirect server will receive a request for a user, and then respond back with one or more possible destinations the caller should contact. The client will then need to send a new request to the redirected addresses.
A forking proxy directly forwards the request to multiple destinations without having the client resend anything. This allows for faster and more efficient call connections.
Handling Forked Responses
When a forked INVITE is sent to multiple user agents, each individual endpoint will send back its own response.
The caller’s user agent will receive multiple OK or failure responses for the same INVITE.
The caller’s user agent is responsible for reconciling these forked responses and establishing the call with the first destination that sends back a final successful response.
Once the call is established, any further responses arriving for the same INVITE are simply ignored.
Any failure responses (such as 4xx, 5xx, or 6xx SIP responses) that arrive are stored temporarily by the user agent in case the call needs to failover to a secondary destination. But as long as one destination succeeds, the call is connected.
Forking Use Cases
SIP forking enables several key use cases:
- Ringing multiple devices – Allows simultaneous ringing on a user’s desktop phone and mobile device to reach them wherever they are.
- Failover on loss of registration – If a device loses registration due to a network outage, the forked request can still reach the user at a secondary device.
- Shared lines – A single address like support@example.com can ring multiple devices in a support center. The first agent to answer gets the call.
- Call centers – An inbound call can fork to multiple available agents to connect the caller as fast as possible.
- Redundant proxies – Forking between redundant proxy servers can ensure reliability.
These use cases improve user reachability and ensure robust connections even when individual endpoints may fail.
Forking Loop Avoidance
A danger with SIP forking is the possibility of infinite forking loops. For example, if Proxy 1 forwards a request to Proxy 2, which then forwards back to Proxy 1, an endless loop could occur.
To prevent this, SIP uses the Max-Forwards header. This header decrements by 1 on each hop. When it reaches 0, it will no longer forward.
Proxies may also utilize blacklists or graylists to detect and prevent forwarding loops.
Other Forking Considerations
- Forking proxies should authenticate inbound requests to prevent spoofing attacks and loop avoidance.
- Forks may detrimentally affect media handshake procedures like ICE by having endpoints unknowingly communicate with each other.
- Forking can increase load on proxy infrastructure due to duplicate messages. Caps on max forks may be needed.
- Forking delays failure signaling since the caller waits for final timeout on all forks before receiving failure.
- Forking opens the door for glare situations where multiple endpoints send spam or message floods back to the caller.
Despite these considerations, SIP forking remains a fundamental technique for connecting SIP calls and enabling redundancy.
When utilized properly, it greatly improves overall system reliability and robustness.
Frequently Asked Questions (FAQ)
Ques 1: How does a proxy know where to fork requests?
Ans: The proxy checks its registration database to see which devices are registered to a domain, and forks to all of them.
Ques 2: What are the two main types of forking?
Ans: Serial forking sends requests sequentially, while parallel forking sends them all at once simultaneously.
Ques 3: What happens when multiple responses come back for a forked request?
Ans: The caller’s device accepts the first successful response and ignores any further responses.
Ques 4: How does SIP prevent endless forking loops?
Ans: The Max-Forwards header decrements on each hop and stops forwarding when it reaches 0.
