SCP EDRs (Common)

Introduction

All of the N-Squared Intelligent Networking (IN) SCP interaction and control solutions including The N2DSG-SCP (N-Squared Diameter Signalling Gateway - SCP), N2NP-SCP (N-Squared Number Portability SCP), and N2ACD-SIP (N-Squared Advanced Call Distribution SCP version) are built on a single common ScpApp base class.

This page defines the common SCP-level EDRs which can be generated by any of these SCP call control applications.

The SCP EDR Event Types are:

• SHUTDOWN
• PROBLEM
• INITIALDP
• ABANDON
• TCAP-ABORT
• RELEASE
• TERMINATION
• ANSWER
• TEARDOWN
• PLAY
• PLAYED
• SPECIAL

Each application built on this framework will typically generate additional service-specific Event Data Records which may be merged into the same EDR stream, or may be written to an independent EDR stream.

Not all applications will use all event types.

Common Format

The configuration parameters for configuring EDR output including filename structure and location is defined in the configuration documentation for the EdrApp which is a base component provided by the n2svcd package.

All EDRs are written by the EdrApp application using its file and record formatting rules.

Refer to the n2svcd base documentation for more details on configuring and managing EDR streams, and on the syntax/encoding details for N-Squared EDRs.

SHUTDOWN EDR

The SHUTDOWN EDR Event indicates that a SCP instance ended with an internal processing error. This EDR is generated independently of any other SCP EDRs associated with the call. In most cases, there will be other SCP EDRs associated with this instance containing additional protocol information.

Example:

2018-05-22 03:44:30.181<2771>SHUTDOWN
→ |EXCEPTION=No model selector found for InitialDP without TCAP AC.

PROBLEM EDR

The PROBLEM EDR Event indicates that a SCP instance encountered a CAMEL/INAP processing error, but managed to recover and continue CAMEL/INAP call processing. Examples of such “recoverable” errors might include an external resource not being available, or a received message not containing an expected field.

In most cases, a Warning message will also be written to the n2svcd log file and/or the Syslog.

Note that an error connecting to a resource will generate a PROBLEM EDR Event, but a problem with playing an announcement will result in a PLAYED EDR Event with an ERROR field.

In the case of on-switch announcements, the bundling of ConnectToResource and PlayAnnouncement will typically result in multiple EDRs if the ConnectToResource fails (generating a PROBLEM Event EDR), as the subsequent PlayAnnouncement (generating a PLAY Event EDR) will also fail (generating a PLAYED Event EDR).

Example:

2020-07-15 03:30:11.754<22294871>PROBLEM
→ |ERROR=PACUI Failed (Code 16)|TYPE=INTERACTION

INITIALDP EDR

The INITIALDP EDR Event indicates that an inbound SCP InitialDP has been received by the DSG-SCP/NP-SCP.

Example:

2020-05-04 04:45:37.671<234>INITIALDP|CALLED=0800999013|CALLING=414511860|CLD=0800999013:2
→ |CLG=414511860:3|CPC=f7|SK=30|TRIGGER=ORIG

If the edr_initialdp_extended configuration parameter is set, INITIALDP EDRs may also contain additional fields. All of these fields are only present if the received IDP contained the relevant information.

Note that some core fields may contain additional data if extended IDP EDRs are enabled, as shown above.

TCAP-ABORT EDR

The TCAP-ABORT EDR Event indicates that the SCP service logic has deliberately sent an outbound TCAP-ABORT message on the SSP transaction. Note that a well-formed service will not typically do this, and so this EDR is not usually seen in production sites.

Note that the TCAP ABORT message can be sent or received in many unplanned error situations, in which case a SHUTDOWN EDR will be generated instead of a TCAP-ABORT EDR.

Example:

2020-05-04 00:39:46.517<4>TCAP-ABORT

ABANDON EDR

The ABANDON EDR Event indicates that the caller abandoned the call during the call setup or processing phase. This EDR type is only used in the case where there is no other applicable EDR type.

Example:

2020-07-17 03:13:35.232<1974486694>ABANDON|DURING=Announcement

RELEASE

The RELEASE EDR Event indicates that the service logic has requested the call be torn down via a ReleaseCall operation which is performed instead of attempting to terminate a B-Leg.

Note that the ReleaseCall operation is also sent mid-call, e.g. to forcefully terminate a B-Leg in the case where the service logic denies an extension of talk-time. In that mid-call case there is no RELEASE EDR generated. Instead the REASON field of the TEARDOWN EDR is set to RELEASE and the cause value is indicated in the CAUSE field of the TEARDOWN EDR.

Example:

2020-05-04 00:44:36.470<4>RELEASE|CAUSE=1

TERMINATION EDR

The TERMINATION EDR Event indicates that the service logic has requested the call processing resume with a Connect or Continue operation. Prior to the Connect/Continue operation, the following operations may be sent:

• RequestReportBCSMEvent (one or two)
• ApplyCharging
• CallInformationRequest
• FurnishChargingInformation
• SendChargingInformation

Example:

2018-05-22 03:44:30.3442020-05-04 00:45:29.429<7>TERMINATION|ARMED=4/5.2/6.2/7.2/10.1/9.1/9.2
→ |DESTINATION=04200999007|DRA=04200999007:3|NOANSWER=70

ANSWER EDR

The ANSWER EDR Event indicates that the SSP notified us of the success of a termination attempt using an Answer EDP.

Example:

2020-05-04 00:45:30.441<7>ANSWER|EDP=oAnswer_leg2|ONGOING=1

TEARDOWN EDR

The TEARDOWN EDR Event indicates that a B-Leg has been torn down by the SSP either because it failed to be answered, or because of a post-answer disconnection by the A-party or B-party, or because the SSP detected the conclusion of a non-extensible ApplyCharging.

Example:

2020-05-04 00:45:30.441<7>TEARDOWN|EDP=oDisconnect_leg1|FINAL=1|TALK_DS=58

Note that some SSPs will report an EventReportBCSMEvent at the conclusion of Time Charge Period Expiry, while others will not. For consistency, the N-Squared SCP will never set the EDP field in the TEARDOWN EDR in the case of a detected Time Charge Period Expiry, even if one is nominally supplied by the SSP.

PLAY EDR

The PLAY EDR Event indicates the SCP requesting to an on-switch or external SRF that an announcement be played (possibly including variable part content), and that optionally a DTMF digit response be entered by the handset.

Example:

2020-05-04 04:49:02.917<4>PLAY|LANGUAGE=1|MAX_DIGITS=4|MESSAGE_ID=1860|MIN_DIGITS=4|PROMPT=1|SRF=ext-srf

PLAYED EDR

The PLAYED EDR Event indicates that the on-switch or external SRF has completed playing an announcement (possibly including variable part content), and that optionally a DTMF digit response has been entered by the handset.

There should always be a 1:1 correspondence between PLAYED and PLAY EDR Events, and so a missing announcement, or a mid-announcement hangup/abandon will generate PLAYED EDR Events with an ERROR field (rather than PROBLEM EDR Events).

Example:

2020-05-04 04:20:27.206<0>PLAYED|COMPLETE=1|DIGITS=1234

SPECIAL EDR

The SPECIAL EDR Event is created when a call undergoes special number handling.