SCP

Overview

N2ACD has some configuration that is only applicable at runtime for INAP call processing. Configuration can be applied for the following features:

Generate Lua

N2ACD stores flows designed in the flow editor in a JSON format. That JSON is translated into protocol-specific Lua representations that are also stored when the flow is saved. The protocol-appropriate Lua representation of the flow is what’s actually executed when N2ACD handles a call with/for the corresponding flow.

The generate_lua property in the scp configuration block determines whether the INAP-specific Lua representation of a flow should be generated, compiled, and saved when a flow is saved. Lua generation can be disabled on a per-protocol basis to minimise unnecessary system processing overheads.

    "scp": {
        "generate_lua": true
        , ...
    }

Value true means the INAP-specific Lua representation of flows will be generated, compiled, and saved when flows are saved.
Value false means the INAP-specific Lua representation of flows will not be generated, compiled, or saved when flows are saved.

Note that the update_lua.pl script in the N2ACD bin directory can be used to generate, compile, and save any missing Lua flow representations.

Defaults to true.

Node Types

Various flow editor nodes require or support configuration.

The node-type configuration that only affects the INAP-specific N2ACD runtime components is specified in the node_types sub-section of the scp configuration block.

Defaults to:

    "scp": {
        "node_types": {}
    }

The following nodes can be configured within the node_types sub-section:

• Caller Type
• Cellsite Routing
• End Call

Caller Type

The Caller Type node has to determine what type of caller the call has been received from. In the SCP/INAP implementation of N2ACD that determination is made based on the INAP InitialDP callingPartysCategory information element value. The Caller Type node must be configured with the lists of calling party’s categories associated with each caller type.

Currently there are four recognised caller types:

• international
• landline
• mobile
• payphone

The values associated with each caller type are network-specific ISUP calling party’s category values. Generic meanings for calling party’s category values can be found in ITU-T Recommendation Q.763.

Defaults to:

    "Caller Type": {
        "international": []
        , "landline": []
        , "mobile": []
        , "payphone": []
    }

Cellsite Routing

The Cellsite Routing node has to determine which cellsite the caller is attached to. This determination is made based on a deployment-specific mobile location identifier. The value of the mobile location identifier is expected to be determined in the service loader.

The Cellsite Routing node supports configuration of the available cellsites and their associate mobile location identifiers via the cellsites property.

cellsites is an object.
Each property key in the object is a cellsite label which should align with cellsites configured for the flow editor.
Each property value is an array of mobile location identifiers.

    "Cellsite Routing": {
        "cellsites": {
            "AKL": [ 1, 2, 3 ]
            , "WLG": [ 4 ]
            , "CHCH": [ 5 ]
        }
    }

Defaults to:

    "Cellsite Routing": {
        "cellsites": {}
    }

End Call

The End Call node must be configured to enable mapping of protocol-independent reasons to protocol-specific end call details. In the SCP/INAP implementation of N2ACD the only protocol specific end call detail is the INAP ReleaseCall cause value. Standard meanings for ISUP cause values can be found in ITU-T Recommendation Q.850.

    "End Call": {
        "reasons": [
            { "key": "route_select_failure", "cause": 3 }
            , { "key": "busy",               "cause": 17 }
            , { "key": "no_answer",          "cause": 19 }
            , { "key": "normal_unspecified", "cause": 31 }
        ]
    }

If the End Call node’s reason is not selected or the cause associated with the selected reason is not specified, the ReleaseCall cause will be populated from the platform’s default release cause. Alternatively, if the End Call node follows a termination attempt, when enabled (see default_release_details_from_b_leg) and available the cause may be populated from the cause embedded in the eventSpecificInformationBCSM in the EventReportBCSM received from the b-leg.

Defaults to:

    "End Call": {
        "reasons": []
    }