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

Parallel Call Forking

You can configure the ESBC to direct calls to targets simultaneously using parallel forking. You establish parallel forking behavior by enabling the parallel-forking parameter on one or more local-policy elements and configuring the cost within each applicable policy-attribute.

This feature relies on the system's route selection process to establish a list of routes from which it determines targets for parallel forking. The selection process includes referring to one or more local-policy elements triggered by the initial INVITE for best match and other standard criteria within the applicable policy-attribute sub-elements. Having determined route order, the system then identifies those local-policy elements that have parallel-forking enabled.

Having determined which local-policy elements apply, the system then refers to the cost of each policy-attribute within each applicable local-policy. The ESBC then groups attributes that have the same cost together for forwarding in parallel. The final route list includes batches of routes for parallel forwarding, which may or may not be intermingled with routes the system uses serially.

Having issued a set of INVITEs in parallel, the ESBC waits for all parallel endpoints to error or timeout before proceeding to the next routes, which may or may not be another group of parallel routes. When any endpoint accepts the call, the system issues CANCELs to the any other endpoints forked in parallel and stops trying to reach any further parallel or serial endpoints. These CANCEL messages use the sip-locally-generated-cancel-for-parallel-fork entry in the local-reponse-map to signal the cancel. Unless you configure it otherwise, the system sends the default reason. 

Reason: SIP; cause=0; text=”Call completed elsewhere"

Note:

This feature supports HMR and Session Translation tools you use to change To and FROM numbers and formats, such as E.164 and National, in INVITEs.

You configure parallel call forking based on the state of the parallel-forking and cost parameters. The system can perform parallel-forking with this local-policy if:

  • You have enabled parallel-forking
  • You have set the same cost in the policy-attribute of the targets

The diagram below depicts the ESBC supporting a simple parallel call forking scenario. The CANCEL includes your configured reason-header.

This image depicts the ESBC supporting parallel call forking.

The ESBC may also perform serial forking within the context of parallel forking call flows when it encounters:

  • A local-policy in its sequence that targets a single station
  • Multiple DNS resolutions to an FQDN
  • A 302 responses to the INVITE indicating the target has moved

The system attempts to reach serial targets when it reaches them in the route list or when serial targets are generated by a current route target. If any target responds with a 302 response, the system attempts to reach those targets serially. If it receives a 302 during an active parallel forking batch, the system attempts to reach the 302 targets serially when all parallel targets fail. If there is no response or 503 errors from a serial target the system proceeds with the next targets in the route list, which may or may not include parallel forking targets.

If it receives no responses or 503 error responses from all targets, meaning no stations have accepted the call, the system ends the call after all timeouts expire.

The parallel forking feature works in conjunction with the merge-early-dialogs feature. It is mandatory that you enable merge-early-dialogs on the ingress realm-config for parallel forking. Without it, media does not flow correctly. Refer to the Merge Function within Early Dialog Support topic in this guide for operational information, including limitations.

This implementation also supports parallel forking for early media flows.

The ESBC can perform parallel call forking to local-policy destinations configured as:

  • IP address
  • MSISDN
  • ENUM
  • LDAP
  • LRT—When forking to routes in an LRT, the system ignores the LRT entries' weight and cost. Instead, the system parallel forks to all destinations.
  • session-agent—The ESBC can fork to a session agent whether it targets an IP address or an FQDN, performing a DNS dip for FQDNs. If the FQDN, however, produces multiple resolutions, the system attempts to reach each resolution serially.
  • session-agent-group (SAG)—The ESBC performs parallel forking to all agents in a session agent group if you have enabled sag-recursion on that group. If sag-recursion is disabled, the ESBC can perform parallel forking with equal cost endpoints and the first agent in the group only.

    A SAG may include session agents configured as FQDNs. If a call flow triggers this SAG, the system obtains resolutions to the FQDN, but forwards to those resolutions serially.

    For example, consider the system forwarding in parallel to an endpoint named UAS1 and a SAG that includes two session agents configured as FQDNs. Next, assume these DNS lookups result in 2 IPs (IP1, IP2) for FQDN1 and 2 IPs (IP3, IP4) for FQDN2. In this case, the ESBC:

    1. Forks the INVITE to UAS1 and IP1 in parallel.
    2. If both UAS1 and IP1 timeout, the ESBC forwards the INVITE to IP2.
    3. If IP2 times out, the ESBC forwards the INVITE to IP3.
    4. If IP3 times out, the ESBC forwards the INVITE to IP4.
    5. If IP4 times out, the ESBC terminates the call with the UAC.

    If any endpoint accepts the call, the ESBC sends CANCELs to outstanding INVITEs and stops attempting to reach any further endpoints.

  • FQDN—The ESBC performs parallel forking with only the first target in any DNS response. Parallel forking scenarios wherein the ESBC targets an FQDN include a targeted local-policy as a session-agent with a hostname that is an FQDN.

    The system uses serial forking to cycle through all of a DNS lookup's resolutions before resuming with the original route list.

Configuration

You enable parallel-forking on a local-policy by enabling the feature and disabling terminate-recursion. 

ORACLE(local-policy)# parallel-forking enabled
ORACLE(local-policy)# terminate-recursion disabled

If desired, you can configure a custom response that the system sends to the endpoints it does not select for a these calls. This configuration uses the sip-locally-generated-cancel-for-parallel-fork error within the local-response-map, which allows you to configure a custom sip-status and sip-reason. This does not affect functionality and is typically used to specify custom reason text. 

ORACLE(local-response-map)#
entries               
      local-error            sip-locally-generated-cancel-for-parallel-fork               
      sip-status             200               
      sip-reason             Call Completed at other place

Note:

Within the ESBC WEBGUI, the parallel-forking configuration appears only when viewing advanced attributes.

You must also manage the number of steering-pools ports available within parallel forking scenarios. The ESBC reserves ports for all forked destinations and does not release them until it receives a 200 OK for the call. This process can temporarily consume a large number of ports.

Related Configuration

This parallel-forking feature interacts with other ESBC configuration that can change or affect its behavior:

  • terminate-recursion—Disable the terminate-recursion parameter in local-policy under policy-attribute if you want to use forking, either parallel or serial. If terminate-recursion is enabled, the ESBC does not try to reach the next route.
  • merge-early-dialogs—Enable the merge-early-dialogs parameter in conjunction with parallel-forking to merge the early dialogs so that the applicable UACs only need to maintain a single dialog. When using merge-early-dialogs with parallel-forking causes the ESBC to send only a single final response to the applicable UAC. If one forking destination returns a 200 OK and the others return CANCEL, 487, ACK and so forth, the system only sends the 200 OK to that UAC.
  • sag-recursion—Enable the sag-recursion parameter on any SAG you use as a parallel forking target, if you want to parallel fork INVITE to all session-agents in that SAG.
  • prevent-duplicate-attrs—Enable this parameter in the account-config to properly update ACME FlowIDs and FlowType AVPs in ACRs for CDR generation.
  • policy-priority—If the route sequence includes routes of equal cost from multiple local-policy elements, and all of those local policies have the same policy-priority, the system forwards to all routes in parallel. If, however, a local-policy has a different policy-priority, the system does not include those routes in the parallel forking batch.

    A policy-priority setting does not affect route order, but when it reaches those routes in the list order, the system handles the routes in that local-policy as its own batch.