Parallel Forking Call Flows

The SBC supports parallel forking within multiple contexts. These context include adjusting target lists based on FQDN responses, 302 responses as well as LDAP and LRT dips. These contexts provide a framework within which the SBC invokes parallel forking when triggered. The flow diagrams presented here, therefore, have similar structures with the triggers and results of parallel forking residing within the flows at similar points within each flow, and with similar denotation.

For example, consider the simple call flow presented at the beginning. The basic configuration that produces this flow is below. This same call flow would apply for multiple equivalent functions by changing the next-hop value.

local-policy        
from-address                *
to-address                  2222
source-realm                sip192
parallel-forking            enabled       
policy-attribute            
next-hop                    UAS1
realm                       sip172                
cost                        10       
policy-attribute               
next-hop                    UAS2
realm                       core2
cost                        10

The same call flow would result when using:

A DNS dip, such as sip.pstnhub.microsoft.com
An LDAP dip, such as ldap:default-query
An LRT dip, such as lrt:test1
A multi-stage lookup, such as:
- next-hop LRT:Test1;key=$TO
- lookup multi

Parallel Forking and 302 Response

Consider the scenario wherein the SBC engages parallel-forking with one of the target stations replying with a 302: Moved. In this case the SBC responds to the 302 by using the new station within the parallel forking step. The system removes UAS2 from consideration and add UAS3 as a replacement.

This image depicts the SBC supporting Parallel Forking with a 302 Response.

Parallel Forking and PRACK

In this scenario, the SBC and both UAS end points support PRACK, but the PSTN does not. The SBC supports the requirements the end points send for the PSTN and supports the PRACK transactions.

This image depicts the SBC supporting Parallel Forking with a local PRACK.

Parallel Forking and PRACK2

In this scenario, the SBC and the PSTN support PRACK, but both UAS end points do not. The PSTN generates the 100-rel requirement and the SBC supports the requirement and the PRACK transactions on behalf of the end points.

This image depicts the SBC Supporting Parallel Forking with a PSTN PRACK.

Parallel Forking and Early Media

An important feature to support within parallel forking is early media. This next call flow shows all three destinations UAS1,UAS2 and UAS3 sending early media. The SBC is supporting this media, relaying it to the PSTN while the scenario finds an end station, UAS2 in this case, to answer the call. After the 200 OK comes from UAS2, the SBC cancels the setups to UAS1 and UAS3.

Key to this feature is the SBC latching to the most recent early (eg, the last) SDP/media flow when multiple endpoints (UAS below) send early SDP/media. The SBC makes any previous early media inactive, preventing the PSTN from having to handle multiple early media flows simultaneously.

This image depicts the SBC Supporting Parallel Forking with all stations issuing early media.

Parallel Forking to a Session Agent Group

In this scenario, the SBC receives an INVITE that triggers a local policy to UAS1 and a local policy to a Session Agent Group. Although a session agent group can participate as a parallel forking target, it's members do not, with the SBC instead cycling through all other SAG members serially. Therefore, the SBC attempts to reach UAS1 and SAG:SA1 first, in parallel. In this flow, SAG:SA1 accepts the call and sends a 200 OK. So the SBC CANCELs UAS1 and never contacts SAG:SA2.