Application Parameters
N2SCP Application Configuration
In addition to the common N2SVCD application parameters,
all N2SCP applications support common top-level per-instance application parameters, defined in
the parameters section of the application configuration. Each parameter must have a name and a value.
A sample application parameters configuration might be:
    <application name="<application instance name>" module="LhoScpApp">
      ...
      <parameters>
        <parameter name="trace_level" value="1" />
        <parameter name="trace_level_max" value="1" />
        <parameter name="trace_per_second" value="1" />
        <parameter name="retention_count" value="20" />
        <parameter name="edr_enabled" value="1" />
        <parameter name="edr_app_name" value="EDR" />
        <parameter name="default_edr_stream_key" value="n2scp" />
        <!-- Other N2SCP application-specific parameters -->
      </parameters>
      ...
Configuration Details
The available parameter types for all N2SCP application instances are:
| Attribute | Type | Description | 
|---|---|---|
| parameters | Array | Array of name=valueParameters for this Application instance. | 
| "min_grant_secs" | 1-120 | The shortest grant (in seconds) which the service logic (typically instructed by the external
      OCS) will be permitted to apply in real-time.  Any attempt by the service logic (or OCS) to
      use a lower value than this will cause the charged call processing to be aborted. Very short grant periods will cause significantly increased call processing overheads. The shortest allowable grant period must be at least one second higher than the configured `service_logic_ms` processing window. (Default = 5seconds). | 
| "correlation_id_ms" | 10-5000 | The limit (in milliseconds) in which the SigtranAppmust return our correlation ID
      when we request one for including in theEstablishTemporaryConnectionfor an off-switch
      SRF interaction.(Default = 1500milliseconds). | 
| "default_tcap_immediate_ms" | 10-5000 | The limit (in milliseconds) within which an "immediate" TCAP component must arrive
      after another message.  For example, at the end of a call we expect any of the following
      applicable components ( CallInformation,EventReportBCSM,ApplyChargingReport) to arrive "immediately" one after the other.Individual SSP models may override this value. (Default = 500milliseconds). | 
| "default_tcap_margin_ms" | 10-15000 | The grace period (in milliseconds) within which a medium/long-term expected TCAP component may
      arrive late because of allowance for processing and network time. Specifically for SSP it allows an ( Answer/NoAnswer)EventReportBCSMto arrive slightly after theapplicationTimertimeout.For SSP it also allows the first message at the end of the call (e.g. ApplyChargingReport,EventReportBCSM, orCallInformationReport) to be slightly
      later than theaChBillingChargingCharacteristicscontents strictly specify.For an SRF definition, this parameter adds a margin on top of max_pa_secsormax_pacui_secsto allow for network/processing delay.Individual SSP models may override this value. Individual SRF definitions may override this value. (Default = 3000milliseconds). | 
| "default_max_monitored_call_secs" | 300-7200 | The is the permitted maximum duration of a "Monitored", which is a call which uses Disconnect ERBCSM
      to monitor the duration of the call but which does not use the "Charged" call mechanism to perform
      initial/extension grants. A Monitored call may use CallInformationReportand orActivityTest, 
      but in any case this maximum duration still applies.Individual SSP models may override this value. (Default = 7200seconds). | 
| "default_max_charged_call_secs" | 300-86400 | This is the maximum total granted talk time that the SCP layer will ever permit for a "Charged" call
      either using ApplyChargingor the CAMEL1 alternative using onlyActivityTest.
      If the service logic (typically instructed by the OCS) attempts to grant a call longer than this
      duration, the SCP layer will truncate the grant to the configured duration and forcibly terminate the call
      when that time expires.Individual SSP models may override this value. (Default = 86400seconds). | 
| "default_ac_crossover_ms" | 10-5000 | The limit (in milliseconds) within which an EventReportBCSMand/orCallInformationReportmay be received without anApplyChargingReportat the end of a charged call while the most recentApplyChargingReportis being processed.Individual SSP models may override this value. (Default = 500milliseconds). | 
| "default_activity_test_result_ms" | 10-5000 | The limit (in milliseconds) within which an ActivityTestResultresponse must arrive
      after being requested.Individual SSP models may override this value. (Default = 1000milliseconds). | 
| "default_max_pa_secs" | 5-3600 | This is the maximum allowed duration of interaction resulting from sending PlayAnnouncementto this (on-switch or external) SRF.  The SRF connection will be aborted ifSpecializedResourceReportis not received within this time.The additional global TCAP round-trip allowance tcap_margin_mswill be added to this value.Individual SRF definitions may override this value. (Default = 300seconds). | 
| "default_max_pacui_secs" | 5-3600 | This is the maximum allowed duration of interaction resulting from sending PromptAndCollectUserInformationto this (on-switch or external) SRF.  The SRF connection will be aborted ifPromptAndCollectUserInformationResultis not received within this time.The additional global TCAP round-trip allowance tcap_margin_mswill be added to this value.Individual SRF definitions may override this value. (Default = 300seconds). | 
| "default_max_etc_ms" | 10-5000 | This is the maximum time that the SCP layer will allow between sending EstablishTemporaryConnectionto the SSP and receivingAssistRequestInstructionsfrom the SRF.  The SRF connection process will
      be aborted if the ARI is not received within this time window.Individual SRF definitions may override this value. (Default = 4000milliseconds). | 
| "edr_initialdp_extended" | 0/1/yes/no | Include extended InitialDP fields in INITIALDPevent EDRs?(Default = 0, not included). | 
| "private_digits" | 0/1/yes/no | By default, should collected digits be treated as private and masked in PLAYEDEDRs?(Default = 0, not masked). | 
| "connect_send_original" | Boolean | Whether to send the original called party digits in Connectmessages. This may be inserted if this 
       value was present in the receivedInitialDP(in which case the value will be copied directly) or 
       when number translation or redirection occurs (in which case the value inserted will be taken from either thecalledPartyBCDNumberor thecalledPartyNumberfield in the receivedInitialDP,
       as appropriate).Note that for anything other than special number handling, the N2SCP application must still explicitly request any digits to be sent or copied. (Default = 1). | 
| "connect_send_redirecting" | Boolean | Whether to send the redirecting party digits in Connectmessages, as requested by applications.Note that for anything other than special number handling, the N2SCP application must still explicitly request any digits to be sent or copied. (Default = 1). | 
| "connect_send_redirection" | Boolean | Whether to send redirection information in Connectmessages. This may be inserted when number
       translation or redirection occurs (in which case the values inserted will be created) or whenredirectingInformationis present in the receivedInitialDP(in which case the values will be copied directly).Note that for anything other than special number handling, the N2SCP application must still explicitly request any information to be sent or copied. (Default = 1). |