1. Configuration Guide
  2. Session Routing and Load Balancing
  3. Parallel Call Forking
  4. Forking Operation

Forking Operation

When you enable parallel forking on a local-policy, the ESBC can use it to establish a list of routes to which it can simultaneously forward an INVITE. There can be multiple sets of these parallel routes as well as routes for serial forking ordered by cost in these route lists. In addition, the system can change the contents and order of the list based on external replies, such as DNS responses or 3xx replies. When attempting to reach an endpoint, the system uses timeouts and errors to trigger attempts to reach the next route(s). During these timeouts, the system waits to receive a 200 OK from one of the endpoints. The ESBC ends this search when it receives the 200 OK and cancels any incomplete session setups.

The ESBC refers to your cost and priority configuration to establish "batches" of routes to use for parallel forking. Batches are typically endpoints that have the same cost and priority. The ESBC collects these together to create a routing sequence. When triggered by an INVITE, the ESBC uses parallel forking to signal all endpoints within a batch simultaneously. If there is only one endpoint in a batch, the ESBC signals that endpoint only.

For example, consider a configuration that results in the following "batches".

This configuration results in the ESBC attempting to reach:

  1. The endpoints in Batch-1 simultaneously
  2. UAC3 alone (Batch-2)
  3. The endpoints in Batch-3 simultaneously

This next example demonstrates how responses can affect this routing. Consider a configuration that results in the following two batches:

  • Route1 – cost 5 – parallel-forking enabled
  • Route2 – cost 5 – parallel-forking enabled
  • Route3 – cost 10 – parallel-forking enabled
  • Route4 – cost 10 – parallel-forking enabled

Based on configuration, the ESBC route procedure includes:

  1. Parallel forking to Route1 and Route2 (two INVITEs sent out).
  2. Parallel forking to Route3 and Route4 (two INVITEs sent out).

If Route2, however, returns a 302 response that includes 2 contacts, the ESBC route procedure changes to include serial forking to the two contact provided by Route2:

  1. Parallel forking to Route1 and Route2 (two INVITEs sent out - Route1 fails - Route2 sends 302)
  2. Forward to the first Route2 contacts.
  3. If the first contact fails, such as 18x timeout/error response, try the next 302 contact.
  4. If the second contact fails, parallel fork to Route3 and Route4.

In this next example, consider the configuration of the applicable routes wherein Route 2 has parallel forking disabled:

  • Route1 – cost 5 – parallel-forking enabled
  • Route2 – cost 5 – parallel-forking disabled
  • Route3 – cost 10 – parallel-forking enabled
  • Route4 – cost 10 – parallel-forking enabled

This configuration results in three batches with parallel forking used only for Route3 and Route4, if the process reaches them.

Behaviors in Response to 302 Messages

Another simple scenario has the ESBC responding to a 302 response with multiple contacts from a route.

  • Route1 – cost 5 – parallel-forking enabled
  • Route2 – cost 5 – parallel-forking enabled
  1. The ESBC performs parallel-forking with Route1 and Route2.
  2. If Route1 destination returns a 302 with 3 Contacts, IP1, IP2 and IP3, the ESBC performs serial forking to these IPs.

Consider the scenario wherein the ESBC forks the INVITE to Route1 and IP1, and both Route1 and IP1 reply with a 302 with the following contacts:

  • Route1 302 has uas1 and uas2 as Contact IPs.
  • IP1 302 has uas3 and uas4 as Contact IPs.

In this case, the ESBC uses the following procedure.

  1. Upon receiving the 302 from Route1, the system forks the INVITE to uas1.
  2. Upon receiving the 302 from IP1, the system forks the INVITE to uas3.
  3. After the uas1 timeout, the system forks the INVITE to uas4, because, upon receiving the first 302, the system's redirect list includes uas1 and uas2.
  4. Upon receiving the second 302, the system's redirect list includes uas1, uas3, uas4 and uas2.

    The ESBC sends INVITEs using the same sequence. Also in case either uas1 or uas3 or both of them respond with some provisional response, then next redirect from the list will be tried only after the timeout of all pending transactions, that is when timeouts or error-responses come from uas1 and uas2.

Behavior Using DNS Resolutions

There are cases wherein the ESBC receives an INVITE that uses an FQDN as a target, requiring a DNS dip before it can determine its routing. Generally speaking, the ESBC only uses the first IP address in the DNS response as a target for a parallel forking scenario. Similar to 3xx redirect scenarios, however, the ESBC performs serial forking on the remaining resolutions if the first resolution results in no response or a 503 response.

Consider the following configuration, and assume the DNS response to the FQDN includes 3 targets, including IP1, IP2, IP3:

  • Route1 – cost 5 – parallel-forking enabled
  • Route2 (FQDN) – cost 5 – parallel-forking enabled
  • Route3 – cost 5 – parallel-forking enabled

A simple scenario has the ESBC sending INVITEs and taking the following steps in response to 503 or no response:

  1. Performs parallel-forking to Route1 and IP1, the first resolution from DNS
  2. IP2 as a serial fork
  3. IP3 as a serial fork
  4. Route3

Note:

If Route 2 gets multiple DNS-resolutions that the SBC reaches through a session-agent, you must have enabled ping-all-addresses for the system to use serial forking on the DNS-resolved targets.

When not configured for parallel-forking, the ESBC will use serial forking for the configuration that includes the FQDN above when it sends an INVITE to IP1 in response to the following scenarios:

  • If the INVITE times out or IP1 responds with 503 response, the ESBC sends the INVITE to IP2. If the IP2 INVITE times out, the ESBC sends the INVITE to IP3.
  • If IP1 sends a 1xx response and then times out, the ESBC does not try to reach other DNS-resolved targets. Instead, the ESBC routes using the next policy-attribute.
  • If IP1 sends 302 with 2 contacts, the ESBC sends INVITES to those 2 contacts serially. If these contacts timeout, the ESBC ends the call.
  • If IP1 sends a 4xx or 5xx error response, with the exception of 503, the ESBC does not try to reach other DNS-resolved targets. Instead, the ESBC routes using the next policy-attribute.
  • If IP1 sends a 6xx error response, the ESBC forwards the 6xx message to the UAC and then ends the call.

When configured for parallel-forking, the ESBC may use parallel or serial forking for the configuration that includes FQDN above:

  • If your configuration causes the ESBC to fork INVITEs to Route1 and IP1, and Route1 sends 180 Ringing then times out, and IP1 sends no response:
    1. The system tries to reach IP2 after 32 seconds.
    2. If the IP2 contact fails, the system tries to reach IP3.

Scenario Including Both FQDNs and 302 Responses

Consider the following configuration, and assume the DNS response to the FQDN includes 3 targets, including IP1, IP2, IP3:

  • Route1 – cost 5 – parallel-forking enabled
  • Route2 (FQDN) – cost 5 – parallel-forking enabled

In this case, the ESBC:

  1. Forks in parallel to Route1 and IP1 in parallel. Assume Route1 responds with 302 with 2 Contacts (UAS1, UAS2).
  2. If there is no response/error response from IP1, the system tries UAS1 serially.
  3. If there is no response/503 response from UAS1, the system tries UAS2 serially.
  4. If there is no response/503 response from UAS2, the system tries IP2 serially.
  5. If there is no response/503 response from IP2 the system ends the call.