SIP

Overview

N2ACD has some configuration that is only applicable at runtime for SIP 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 sip configuration block determines whether the SIP-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.

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

Value true means the SIP-specific Lua representation of flows will be generated, compiled, and saved when flows are saved.
Value false means the SIP-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 SIP-specific N2ACD runtime components is specified in the node_types sub-section of the sip configuration block.

Defaults to:

    "sip": {
        "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 SIP implementation of N2ACD that determination is made based on the calling party’s number. The Caller Type node must be configured with the lists of calling party number prefixes associated with each caller type.

Currently there are four recognised caller types:

• international
• landline
• mobile
• payphone

The values associated with each caller type are country or network-specific calling party number prefixes.

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 SIP implementation of N2ACD the only protocol specific end call detail is the SIP INVITE response code or BYE Reason header cause value. Standard meanings for SIP response codes can be found in IETF RFC 3261 section 21.

    "End Call": {
        "reasons": [
            { "key": "route_select_failure", "code": 404 }
            , { "key": "busy",               "code": 486 }
            , { "key": "no_answer",          "code": 480 }
            , { "key": "normal_unspecified", "code": 603 }
        ]
    }

If the End Call node’s reason is not selected or the code associated with the selected reason is not specified, the code/cause in the INVITE response or BYE Reason header will be populated from the platform’s default code/cause. Alternatively, if the End Call node follows a termination attempt, when enabled (see default_release_details_from_b_leg) and available the code/cause may be populated from the corresponding value in the INVITE response or BYE received from the b-leg.

Defaults to:

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

Response Codes

Various N2ACD nodes support branching based on the result of a termination attempt. N2ACD recognises the following results:

• Route select failure.
• The called party is busy.
• The called party did not answer.

In some cases the SIP stack is able to determine the result clearly for N2ACD. However there are scenarios in which N2ACD has to make a deployment-specific result determination based on a response code. The response_codes sub-section of the sip configuration block enables N2ACD to make this determination.

    "sip": {
        "response_codes": {
            "default": "RSF"

            , "404": "RSF"
            , "480": "NO_ANSWER"
            , "486": "BUSY"
        }
        , ...
    }

Result must be one of:

• RSF
• BUSY
• NO_ANSWER

Any number of response codes can be mapped to a result. The default property can also be used to define the result for response codes that don’t have a mapped result.

Defaults to:

    "response_codes": {}