SIP - Forking

Sometime a proxy server forwards a single SIP call to multiple SIP endpoints. This process is known as forking. Here a single call can ring many endpoints at the same time.

With SIP forking, you can have your desk phone ring at the same time as your softphone or a SIP phone on your mobile, allowing you to take the call from either device easily.

Generally, in an office, suppose boss unable to pick the call or away, SIP forking allow the secretary to answer calls his extension.

Forking will be possible if there is a stateful proxy available as it needs to perform and response out of the many it receives.

We have two types of forking −

  • Parallel Forking
  • Sequential Forking

Parallel Forking

In this scenario, the proxy server will fork the INVITE to, say, two devices (UA2, UA3) at a time. Both the devices will generate 180 Ringing and whoever receives the call will generate a 200 OK. The response (suppose UA2) that reaches the Originator first will establish a session with UA2. For the other response, a CANCEL will be triggered.

Parallel Forking

If the originator receives both the responses simultaneously, then based on q-value, it will forward the response.

Sequential Forking

In this scenario, the proxy server will fork the INVITE to one device (UA2). If UA2 is unavailable or busy at that time, then the proxy will fork it to another device (UA3).

Sequential Forking

Branch - ID and Tag

Branch IDs help proxies to match responses to forked requests. Without Branch IDs, a proxy server would not be able to understand the forked response. Branch-id will be available in Via header.

Tags are used by the UAC to distinguish multiple final responses from different UAS. A UAS cannot resolve whether the request has been forked or not. Therefore, it need to add a tag.

Proxies also can add tags if it generates a final response, they never insert tags into requests or responses they forward.

It may be possible that a single request can be forked by multiple proxy servers also. So the proxy which would fork shall add its own unique IDs to the branches it created.

Call leg and Call ID

A call leg refers to one to one signalling relationship between two user agents. The call ID is a unique identifier carried in SIP message that refers to the call. A call is a collection of call legs.

A UAC starts by sending an INVITE. Due to forking, it may receive multiple 200 OK from different UAs. Each corresponds to a different call leg within the same call.

A call is thus a group of call legs. A call leg refers to end-to-end connection between UAs.

The CSeq spaces in the two directions of a call leg are independent. Within a single direction, the sequence number is incremented for each transaction.

Call Leg Id

Voicemail

Voicemail is very common now-a-days for enterprise users. It’s a telephone application. It comes to picture when the called party is unavailable or unable to receive the call, the PBX will announce to calling party to leave a voice message.

User agent will either get a 3xx response or redirect to voicemail server if the called party’s number is unreachable. However, some kind of SIP extension is needed to indicate to the voicemail system which mailbox to use—that is, which greeting to play and where to store the recorded message. There are two ways to achieve this −

  • By using a SIP header field extension

  • By using the Request-URI to signal this information

Suppose for the user sip:Tom@tutorialspoint.com has a voicemail system at sip:voicemail.tutorialspoint.com which is providing voicemail, the Request-URI of the INVITE when it is forwarded to the voicemail server could look like −

sip:voicemail.tutorialspoint.com;target = sip:Tom@tutorialspoint.com;cause = 486

The following illustration shows how the Request-URI carries the mailbox identifier and the reason (here 486).

SIP Voicemail
Advertisements